イケてない企業あるある7選!!
どうも、ITコンサルタントのShoheiです。
今日はイケてない企業あるあるを上げていきたいと思います。
自社で感じたことや、周りの話から得たことを元に書いていきます。
とりあえず会議を長めかつ大人数で設定する
「よくわからないけど２時間とっときました」てインビテーションがくる会議は我慢大会のお誘いかなと思います。
またやたら人数が多い会議も、会議をお祭りか何かと勘違いしてるのかなと思っちゃいます。
集中の継続が可能な時間は、いろんな説がありますが、諸々調べてると、15分刻みが一つの周期で、大体45-50分程度で集中力が低下し始める、なんて説はいろんなところに見られました*1。
また超短期の集中力の話ですが、マイクロソフトの調査だと「人間の集中力は８秒で、金魚の９秒より短い」なんて説も出てます*2。
イケてる企業の一つであるGoogleの会議は基本30分、長くても50分、最大8人みたいですね。*3*4。
結論が出たのに会議を終えない
30分で結論が出たのに、90分ぐらいダラダラと話してる会議、カフェでの会話かなと思っちゃいます。
目的が明確になっていない会議ほどこんな目に合いがちです。
また、おしゃべり好きな営業さんなど、絶対お前喋りたいから引き伸ばしてるだろ、ってやつも時々います。
部下が何をやっているかわからないマネージャー
「上に言われてるから」「上に報告しなきゃいけないから」が唯一の行動理由となっているゴミマネージャーが見受けられます。あなたの仕事は伝言ゲームですかと思いますね。
なおマネジメントの意味は以下ですね
具体的には、組織の目標を設定し、組織を作ります。そして部下の動機付けやコミュニケーションをはかり、その部下を評価し、それを元に人材育成するという使命を持った役職です。*5
外資とかだと、マネージャーになるということは偉くなるということとも限らず、職種を変更するだけという意味合いだったりします。
イケてない企業だとマネージャーの素質がない人も年功序列で時が経つとマネージャーになったりしますよね。それがゴミマネージャーを生む要因になってたりもするかと思います。
職場環境が劣悪
これも我慢大会の類ですね。戦時中かなと思います。
事務処理が古典的
例えば社内承認に上司がサインをする文化。スピード感、コスト、信ぴょう性、全てに置いてウンコだと思います。
無能マネージャーへの形だけの説明、形だけの残業承認、このへんもウンコですよね。
営業が社内ヤクザ
お客さんの声を届けるってのは大事だと思うんだけど、それに会社が振り回されずに会社の意思で判断をしていくというのも重要ですよね。
こういうのに限って、営業は技術とか全くわからず調子よくお客さん先で出来ます出来ます言っちゃってるケースだったりするんですよねー。
重鎮絶対主義
最後はこれ。部の歴史だとか昔ながらのノウハウという名の重い束縛を抱え、そしてそれを周りに強要してくる重鎮という名のウンコの存在。
ノウハウ蓄積は大事だと思いますが、重要なものはシェアする仕組みを作らなければ意味がないと思います。またノウハウに縛られすぎて柔軟な判断が出来なくなると、みんなが思考停止してしまいます。
柔軟性の欠けた重鎮を生産してしまう前に、人事異動等で動かすべきだと自分は考えます。
まとめ
今日はイケてない企業あるあるを作ってみました。
Sierとコンサルタントの違い
どうもー、Keiです。
もう12月ですねー。寒くなってまいりましたので、風邪など引かないようにしてくださいね。
今回のトピックは「Sierとコンサルタントの違い」についてですが、意外と答えにくい質問だと思うのですよね。
特に、現在コンサルタントの方はSierとはぜんぜん違うよ、というプライドや意識を持っていたりして、自信を持って違いを言える方が多い印象です。
一方で、この２つの職業は具体的な業務内容が外からだと想像しにくい側面があるため、違いを明確に言うのは難しいと僕は思うのです。
特に、最近はコンサルもITコンサルのように戦略だけでなく、IT領域のPMOやSIをやるコンサルも出てきたため、両者の境界線が曖昧になっていると感じます。
ぼくは前にITコンサル系の会社の面接に行った際に、本当にこのブログのタイトル通りの質問をされたことがあります。
「コンサルとSierの違いってなんだと思う？」
しかも、その1社だけではなくて、
他のITコンサル系の会社からも、これと似た質問をもらったんですよね。
そのときは、コンサルはお客様から課題を聞いて、それに対して提案を～みたいな答えを返していましたが、今ならもう少し上手く答えられるかな、と思います。
この質問は、けっこうSIよりのITコンサルでは聞かれる質問みたいなので、自分の中で回答を持っているといいですね。
ぼくの考えは、このブログのもう少し後ろの方で書きます。
Sierのイメージ
まず、両者のイメージがないと違いも何もないですよね。
僕のSierのイメージを書き出してみます。
最後だけバイネームになってしまいましたが、こんな感じですよね。
あと、仕事を横に流すだけで仲介料ばっかり高くなる胡散臭いイメージもあります。
別に、ぼくはアンチSierではありませんよ。
Sierが多方面で叩かれているのは事実ですが。
余談ですが、暗い話題の多いSierですが、それを真摯に受け止めて今後Sierはどのように活躍すれば良いかについて、下記の本では非常に良くまとめられています。
これからのSierの話をしよう エンジニアの働き方改革 ThinkIT Books
- 作者: 梅田弘之
- 出版社/メーカー: インプレス
- 発売日: 2017/09/08
- メディア: Kindle版
- この商品を含むブログを見る
コンサルタントのイメージ
特にSierと違いが分けにくいITコンサルのイメージについてもばらばらと書いていきます。
- 激務
- クライアントへ提案する
- PM
- 技術はあまり詳しくない
- 胡散臭い
激務と胡散臭さが一致したイメージですね。
個人的に、というかクライアント的にはSierよりコンサルの方が何やっているかわからない、という場合もあるのではないでしょうか。
良くわからないが、ただの紙切れのために何千万、何億と払ったり、自社で
なんとかできないのか！？って思う方もいると思います。
Sierとコンサルタントの違い
さて、ここまでイメージの話ばかりしてきましたが、結局Sierとコンサルの違いはなくなりつつあると思います。
一方で、よくSierとコンサルタントが違うと言われているポイントについてコンサル目線で話をしたいと思います。
端的に言うと、コンサルはSierと違って仮説を持ってクライアントの課題に対して提案ができる点です。
ここでいう、課題が自明であればSierでも答えを提示するかもしれませんが、プロセスの決め方などやり方が多岐に渡る場合では、Sierはお客様に決めてもらうか、どのようなパターンがあるかをお客様に提示するに留まります。
一方で、コンサルは抜け漏れなく方法論のパターンを示した後、お客様の最適なプロセスはこれだろうという仮説を作成し、落とし所を作るという部分だと思います。
当たり前だろ、と思うかもしれませんが
この仮説を持つという部分とそれをお客様にキレイに見せる部分がコンサルの根っこの部分ではないかと考えます。
もちろん、Sierの人が何も考えず仕事をしている、とは言っているわけではありません。
あくまでロール上の話です。
さて、今回はSierとコンサルの違いについて話をしました。
就活中の方の参考になれば良いかと思います。
それではまた！
大規模データ処理を便利に実現するhadoopエコシステムって？
どうもkoheiです
気が付けば12月...今年も終わりですね。
今日は前回振れたHadoopについて、もう少し掘り下げて書きたいと思います。
前回のおさらい Hadoopはデータを貯めるにも加工も容易？
前回の記事でデータレイクとして使われるアーキテクチャとしてHadoopが主流になりつつあるという話をしました。
hadoopを使うことで下記の二つが期待できます。
1．分散ファイルシステム「HDFS」によってさまざまな形式のファイルを大容量で保存できる。
2. MapReduceやほかのHadoopエコシステムを通じて、HDFSに保存されているデータへのアクセス・加工が容易になる。
1. については、分散処理のところで少し説明しましたが、今回は2.のエコシステムというものを掘り下げて説明してきます。
Hadoopの構成
Hadoopは現在、大きく下記の3要素で構成されています。
HDFS: 巨大なファイルを分割して保存するファイルシステム
MapReduce: 分散サーバ上でのデータ処理を簡単にするためのプログラミングフレームワーク
YARN: 分散サーバ上の処理を管理し、MapReduceなどの分散処理を制御するソフトウェア
こうした要素を使うことで、比較的簡単に巨大なデータも、複数のサーバを使った分散処理が実現できるようになりました。やったね。おしまい。
・・・という形でHadoopは終わることはありませんでした。
便利なものはもっと便利にしよう!
という発想で、Hadoopをより便利に使うためのアプリケーションが次々に開発されていきました。
こうしたHadoopを中心とした便利アプリケーションの集まりをHadoopエコシステムと言うようになります。
Hadoopの弱点
エコシステムに触れる前に、その背景をもう少し掘り下げます。
Hadoopを使って比較的簡単に、分散処理ができるようになったと言いましたがいざ実際に使ってみようとするといろいろ困りごとが出てきます。
だいたいhadoopを使いたい人というのは、データ解析を主体とする人でそれほどプログラム開発メインではなく、もっと楽に使いたいという意思が強いです。
- HDFSはファイルを分散して管理するため、「特定ファイルの一部を書き換える」といったことをすると、処理のオーバーヘッドが大きい。小回りが利かない
HDFSは巨大なファイルを細かく分けてサーバにばらし、必要な時は一括で読み取って処理して、また別のファイルとして書き出す、という仕組み原則です。小さなファイルや部分的な変更を行うには処理が大掛かりになってしまいます。
-
一回で大容量のデータを処理する場合はいいが、複数サーバでデータを読み込んで処理して、まとめて、またサーバに戻して、書き込んで・・・とやっていると、繰り返し処理に時間がかかり過ぎ
MapReduceの都合上、データを読み込む、処理する、まとめる、ばらす、書き出すというステップを踏みます。ループ処理や機械学習などの反復計算が必要になると、速度的メリットがなくなります。。。いわゆるバッチ処理向きということです。
こうした弱点を補うべくHadoopエコシステムが作られていきます。
Hadoopエコシステム
Hadoopエコシステムと呼ばれるアプリケーションにはどんなものがあるのか、
試しにHadoopベンダーのHortonWorksのサイトを見てみます。
すると
見にくいですが、縦棒1本が一つのアプリケーションで、20以上も存在することがわかります。
さらに、Clouderaといった他のhadoopベンダもまた、別のエコシステムアプリケーションを開発しています（重複するものも多いですが）
このようにhadoopベンダによってHadoopエコシステムの定義が若干変わります。。。
おまけに、新しく開発されるもの、開発が縮小していくものもあり、日々エコシステムは変化しています。
エコシステムのアプリケーションがたくさんあるので、この中で一つ目の課題
を解決すべく作られたものを紹介します。
Apaceh Hive: 分散処理をSQLで実現する
hadoop象が蜂の体とくっついててなかなかキモイですが
このhiveは、javaでゴリゴリ書かなくても、SQLで書いた処理を、MapReduce処理に変換してくれます。
Apaceh Pig: スクリプト言語で簡単にMapReduceを実行
次は豚です。象はいずこに
SQLではちょっと細かなところに手が届かないときはPigの出番です。
raw = LOAD 'excite.log' USING PigStorage('\t') AS (user, time, query);
clean1 = FILTER raw BY org.apache.pig.tutorial.NonURLDetector(query);
clean2 = FOREACH clean1 GENERATE user, time, org.apache.pig.tutorial.ToLower(query) as query;
pigのtutorialから抜粋しましたが、上記のように、データの入出力形式や、様々な加工処理をスクリプト言語の形で簡単に実行できます。
が、正直Hiveでかなりのことは網羅しているので、Pigはあまり見ません。
まとめ
Hadoopの構成と、その欠点、そしてhadoopエコシステムについて少しふれました。
次回エコシステムの他のアプリケーションを掘り下げたいと思います
ではでは
AmazonもLINEもメルカリも採用。マイクロサービスアーキテクチャって何?
どうも、ITコンサルタントのShoheiです。
こたつの季節がやってきましたね。今日はこたつからの更新です。
さて今日は、マイクロサービスアーキテクチャについて簡単に説明をしていきたいと思います。
マイクロサービスアーキテクチャとは
早速ですが、マイクロサービスアーキテクチャって聞いたことありますか？
僕は勉強するまで知らなかったのですが、多数の大手Webサービス提供会社が採用している有名なアーキテクチャです。タイトルに書いた企業の他にも、Netflix、クックパッド、Gunosy、ウォールマート、Twitterなども採用を公表しています。
これが何かを超絶端的に言ってしまうと、「多数機能を実現する大規模なサービスからシステムを作るのではなく、多数の独立したサービスの集合体からシステムを構成させるアーキテクチャ」のことです。イメージは下の絵です。
もう少し説明するよ
もう少しだけ、ざっくりですが説明しましょう。
サービスを分離する指針は？
基本的なサービス指針としては、以下のようなものが挙げられます。
- サービスの境界をビジネスの境界に合わせる。 (独立・重複なし、１サービス１ビジネス機能)
- 一つのサービスを複数の組織で開発しない
- 他のサービスの変更をせずに、単独でサービスの変更やデプロイが行えるようにする
- 各サービスのコード数の規模感は「２週間で書き直せるもの」程度にとどめる
サービス同士はどうやり取りする？
いくつかやり方があるのですが、例えばREST APIなどを利用することで、他サービスから情報を得たり、他情報に情報を与えたりしています。
重要なことは、下の図のようにあるサービスが他サービスの内部事情を知る必要がない仕組みにしておくことです。
主なメリット
では、このアーキテクチャを導入するメリットを説明しましょう。
実装技術が異なっても良い
例えば、サービスAは実装にjavaを使うが、サービスBにはrubyを使うだとか。
サービスごとに独立をしているので、技術も異なって問題ありません。
また、何か新しい技術が出た時、全体を置き換えるにはリスクがある、といった場合にも、あるサービスに閉じて導入ができるので、迅速に最新技術の導入が進められるというのもメリットです。
独立してスケーリングできる
以下のようなケースの場合にスケールアップ考える場合、モノシリックシステムでは、ボトルネックとなっているサービス以外も一緒にスケールさせていく必要があります。
- サービスAの利用数がかなり増えてきた
- 土日だけサービスBの利用者量が増える
一方でマイクロサービスアーキテクチャでは、リソースが逼迫しているサービスだけインスタンスを拡張するなどといった局所的スケーリングが可能となります。
機能追加にかかるタスクを小さくできる
モノシリックシステムでは、特定の部分に小さな変更を加えたとしても、他の様々な部分に影響を与えてしまう可能性があります。そのためテストを入念に実施する必要が出てきたり、それがゆえに各機能でまとめてリリース作業をしたりします。しかしそれではスピード感が損なわれる上、まとめてのリリースは変更差分が大きくなるのでリスキーです。
その点マイクロサービスアーキテクチャでは、他サービスとのやり取りに使うAPI仕様などを変更しない限りはあるサービスに閉じた変更が可能なので、スピーディーな変更に対応ができます。
再利用可能
例えば、上の図はInstagramのような写真投稿のシステムのイメージでサービスA/B/Cを書いてみましたが、その会社で新たに動画投稿のサービスを作ろうと思った場合。
モノシリックシステムでは全て作り直しになりますが、マイクロサービスアーキテクチャではサービスごとに独立しているので、例えばサービスBの部分は新システムでも使いまわそうといった、個別での再利用が可能となります。
書籍紹介
マイクロサービスアーキテクチャといえば、この本です。
ただ、THE・和訳本て感じで、すごく辛いです。内容もかなりタフです。
まとめ
今日は簡単ですがマイクロサービスアーキテクチャについて説明をしました。
次回は少しだけ突っ込んで、実際にあるサービスの構造を見ていきましょう。
議事メモを制するものはプロジェクトを制す（小並）
どうも、Keiです。
皆様、毎日本当にお疲れ様です。
今日は初心に帰って「議事メモ」を取り上げてみます。
皆様、「議事メモ」ってなんでしょう？
「議事録」でもなく単なる「メモ」でもない。「議事メモ」
会社や部署、チーム単位でも独自ルールがあると思うのですよね。
そして、たいてい会社の若手が最初に担当する仕事ですよね。
今回はそんな「議事メモ」について、今一度書く目的を振り返って、何を書けばプロジェクトのためになるかを書いていきたいと思います。
自分の忘備録的なところもあります。
「議事メモ」を書く理由
まず、これがはっきりしていないと書くモチベーションもわかないですし、後から見返したときに必要な情報がない！なんて状況になってしまいます。
「形式的に昔からみんな書いてるから」なんて現世にいないと思いますが、そんな場合は書く必要があるかどうかのレベルから見直すべきです。
さて、議事メモを書く際には大きく以下の目的があるかと思います。
- 証拠能力
- ToDo、アクションアイテムの明確化
- 全体の意識合わせ（齟齬がないか）
もちろん、上の全てが目的の場合もありますし、1つだけの場合もあるでしょう。
証拠能力
会議中の発言はホワイトボードやディスプレイ上で記録していても、後からテキストで共有しないと「言った言わなかった問題」が発生する場合がありますよね。
これを避けるために、証拠として議事メモを会議に参加した全員に共有します。
ToDo、アクションアイテムの明確化
会議中の議論は発散を経て、収束することが多いかと思いますが、会議後に「誰」が「何」を「いつ」までにするのかが意外に明確になっていない場合があります。
そのため、議事メモでそこを明確化することで、次のアクションが明確になります。
全体の意識合わせ
会議中は決まった！と思っても実は認識がズレていた。。なんてことが特に会議時間が短い場合はあるかもしれません。
こんなときに議事メモを共有して齟齬がないことを確認することができます。
（大事な会議を短い時間でやったり、後で議事メモで齟齬が出たりは最悪ケースなので、こういうのは会議のファシリテートで解決すべきですけどね。大事な会議だから、会議の最後のまとめの時間を増やしたりとか。こういうケースでは、議事メモは転ばぬ先の杖的な利用をすると良いと思います。）
議事メモの中身
さて、上記のように議事メモを書く目的が複数あるように、議事メモの書き方（中身）も目的に合わせた書き方があることがわかると思います。
例えば、本当に「誰」が’「何」を言ったのかの証拠能力だけを議事メモに求めるなら、議事メモは音声データだけで良いと思います。
一方で、同時にToDoも明確化したいし、認識の齟齬も出したくない場合がほとんどだと思うので、議事メモを見てわかりやすいように、構造化したり、ToDoアクションアイテムを前出ししたりするのですよね。
フォーマット
上述した3つの目的を満たすためには、一般的な議事メモとしては下記があれば良いかと思います。
ヘッダ
- 会議名
- 日付
- 参加者
- 場所
コンテンツ
- ToDoアクションアイテム
- メイントピック（省略可）
- その他議事メモ（省略可）
まあ、ぶっちゃけ何の変哲もない議事メモの構成ですよね笑
議事録でなく、議事メモの場合は個人的にはToDoアクションアイテムがしっかりと書かれていると良いかと思います。
「メイントピック」や「その他議事メモ」は、上述した証拠能力を持たせるためにいるようなもので、この人がこう言ったことを記録に残し、協調したいときに使用するべきかと思います。
なので、よく「その他の議事メモ」に自分がメモした内容を延々と書き連ねる人がいますが、個人的には意味がないと思っています。なぜなら、それを書く目的が薄いために、読み手へ伝えたいものがないからです。
この場合、議事メモの目的イメージがあってないと、読む方も証拠能力があるからと全て読まなければならないので、時間の無駄です。
時間と構造化
もう一つ、ぼくが議事メモを書く際に気を付けたいことが2つあります。
「時間」と「構造化」です。
時間
特に議事メモの場合、メモでいいから早く全員に共有して、ToDo・アクションアイテムをはっきりさせて、各々が動けるようにしようという意味合いもあるので、議事メモの作成に1時間以上かけるのは避けたいです。
なんなら、会議中に書いたものをそのまま上司のレビューに回すくらいの速さと完成度が求められます。
しかし、特に若手やチームが変わったばかりだと、誰の発言が重要かわからなかったり、知らない単語のオンパレードで聞き逃したり等あると思います。
そのため、レビューを含めて1時間以内には終わるように会議の前から段取りを立てておくことも大事かと思います。
議事メモにそこまで、、と思うかも知れませんが、
自分の業務のキャッチアップにも繋がりますし、書いた議事メモが後で見返されることになることも知れません。
しっかりとした議事メモを作成することは非常に重要です。
構造化
テクニックというか、皆さん無意識のうちにやっているかと思いますが、ポワポ・ワードが必須であるこの現代、インデントを使ってトピックをキレイにまとめる構造化をしない人はいないかと思います。
一方で、議事メモを発言順にばあ～～っと書いていた人はこの構造化が出来ていない人です。
ここで、難しいのが「時間」と「構造化」の両立です。
構造化は、グルーピングのようなもので同じ話題を同一のインデントで分けて書くことで見やすさ、頭の整理をするものです。
しかし、会議の議論中では各々が五月雨式に意見を言うため、そのままメモを取るともちろん構造化ができません。
そのため、会議中に議事メモを作成する場合は、発言をそのままメモをとるのではなく、構造化しながら要点をまとめる必要があります。
個人的に議事メモをとる速度はプロジェクトの習熟度と比例すると思いますが、構造化をするスピードが上がると、プロジェクトの理解度が浅くても、議事メモをとるスピードは平均的にあがると思います。そして、そのプロジェクトのキャッチアップのスピードも。
さて、いかがだったでしょうか。
今回は議事メモについてまとめました。また次回！
One life, One password その２
どうもhaseです。
前回SSOの話題を取り上げました。
今回はその実装方式について見ていきたいと思います。
実装方式の種類
wikipediaさんによると、実装方式は大きく5つあります。
上記4と5を合わせてフェデレーション方式なんて言い方もしますが、こちらが今後主流となる方式と言われています。
では実際に中身を見ていきます。
-
ケルベロス認証
とりあえず名前がかっこいい。冥界の番犬ケルベロス君に守ってもらえばどんなサービスも安心ですね。でもハリー◯ッターしかり、琴で眠らされて門番としては結構ザルなイメージが…笑
ザルイメージはさておき、ケルベロス認証はインターネットなど公開されたネットワークで使うために開発された認証システムです。仕様は、RFC4120やRFC4121で規定され、マイクロソフトのActive Directoryなどが対応しています。クライアントは、まず認証サーバーへとログオンし、シングルサインオンしたい各種サーバーの利用時に、チケット交付サーバーから利用先のサーバー用チケットをもらってアクセスします。
引用元：ケルベロス認証（Kerberos Authentication）とは
Kerberos認証では、チケットが盗聴されるとなりすましの被害を受ける可能性があるため、「時刻同期」によってその対策を実施しています。
チケットの中には、送信時刻（タイムスタンプ）が記録されていて、チケットを受け取ったサーバーが、チケットのタイムスタンプとそのサーバーの設定時刻とのズレが大きいと認証に失敗するようになっています。例えば、Active Directory環境では、初期設定で5分ずれると認証時にエラーが表示されるため、クライアント・サーバ間で時刻同期を実施しておく必要があります。
-
リバースプロキシ型
リバースプロキシ型のシングルサインオンは、Webブラウザからのアクセスを一度リバースプロキシサーバーが受け、そのリクエストをバックエンドに置かれたWeb サーバーに中継する構造を取ります。
引用元：https://boxil.jp/mag/a2411/
リバースプロキシへのアクセスが集中してしまうため、負荷分散等は必須であるものの、アプリケーションに依存せず、セキュアな認証を構築できます。
ユーザ数が少なく、アプリが多い場合に向いていると思います。
-
エージェント型
エージェント型とは、アプリケーションサーバー自体に仲介役の「エージェント」というソフトを入れる方法です。HTTP cookie(クッキー)が利用されます。
引用元：https://boxil.jp/mag/a2411/
リバースプロキシ型と違い、ネットワーク構成を気にしたり、負荷分散等を考える必要はありませんが、Webサーバごとにエージェントを入れる必要があったり、Webサーバがエージェントに対応していなかったり、エージェントの管理がちょっと大変そうです。
ユーザ数は多いけどアプリが少ない、なんて場合に向いてるんじゃないでしょうか。
-
フェデレーション方式
SAML, OpenIDについての詳細は次回に譲るとして、まずはフェデレーション方式について概要を説明します。
フェデレーション方式とは、クラウドサービス間を、パスワードの代わりにチケットと呼ばれる情報を受け渡しすることで、シングルサインオンを実現する方式です。
引用元：https://boxil.jp/mag/a2411/
この方式の画期的なところは、異なるドメイン間でSSOが実現できるという事です。というよりも、クラウドサービスの目覚ましい発展を受けて、それらに対してSSOを実現するために標準化（SAMLやOpenIDなど）されつつあるのがフェデレーション方式です。そういった意味で、今後主流になっていく、と言われています。実際、「Office365」、「G Suite」、「Salesforce」、「Box」など、多くの海外クラウドサービスが対応しています。
まとめ
SSOを実現する方法について幾つか触れました。
データレイクとは？DWHとどう違うの？
どうもKoheiです
三連休、いい天気が続きそうですね。
前回までの記事でデータウェアハウス（DWH）＋BIを中心とした解析環境の話をしておきました。
今日はデータレイクについて書きたいと思います。
データレイクとは？
みなさんはデータレイクという言葉は聞いたことがあるでしょうか？
2010年ごろにBIツール企業のPentahoのCTOであるJames Dixonが提唱した考え方で、構造化されたデータ、非構造なデータ問わず、あらゆる分析で利用する可能性のデータを保持することのできるシステムのこと。。。と言われています。
「考え方」というところがポイントで、こういう技術を使えばデータレイクになる！というような明確な定義がありません。
データレイクが実現すること
定義が曖昧なデータレイクですが、 データレイクを通じて実現したいことは下記のとおりです。
- 構造・非構造など形式に関わらずデータを蓄積できること
- 生成されたのと同じ形式の生データを持つこと
- 必要に応じてデータをピックアップし、加工・解析ができること
昨今IoTの発展や通信の大容量化により、テキスト、画像、動画、音声といった様々な形のデータが増え続けており、こうしたデータを解析して、次のビジネスにつなげることが必須になってきました。
こうした非構造なデータも含めて、まとめて貯めて置いて必要に応じて解析したい
というニーズを満たすのがデータレイクになります。
DWHとの違いは
以前説明したデータウェアハウス(DWH) も「データの倉庫」としてデータ解析のためのデータを保持するシステムとして紹介しました。
DWHとデータレイクの最大の違いは、
分析目的に基づいたデータ設計がなされているか？
という点です。
DWHは主にRDBMSを使うケースが多く、それゆえ、分析したい要件に応じて事前にデータを加工・整理しています。
一方、データレイクは、まだ具体的な分析要件が固まってないけど、とりあえずためておくとなんか使えるかも、くらいの目的でデータを保持します。
つまりDWHより、より柔軟な分析要件にこたえられるような対応を想定しています。
データの沼地
とはいえ、
ストレージ買ってきてデータをとりあえずデータを突っ込んでおけばokでしょ！
データレイク完成！
とすると落とし穴にはまります。
ただやみくもにデータを貯めておくと、誰からも使われないデータ置き場になり、「Data Swamp(データの沼地)」になってしまうケースがあります。
- 必要に応じてデータをピックアップし、加工・解析ができること
これを満たしていることが肝になります。
なので、単にデータストアとしての一面だけでなく、どんなデータが蓄積されているのかというメタデータ管理の側面も持ち合わせています。
データレイクを実現するアーキテクチャ
さて、最初にも言いましたが、データレイクを実現するための必須アーキテクチャは存在しないです。
要件に応じてNoSQLデータベースを作るかもしれません。
あるいは大容量のオブジェクトストレージを用意するかもしれません。
多種多様なデータを生情報として保持し、解析する際にピックアップできればokなわけです。
・・・とはいえ、データレイクとして使われるのに主流のアーキテクチャは存在します。それが以前も説明したHadoopになります。
Hadoopがデータレイクとして適しているのには下記のような特徴を持つからです。
Hadoopの分散ファイルシステム「HDFS」によって様々なファイル形式のデータを保持することができる
これは、データレイク要件の中の
構造・非構造など形式に関わらずデータを蓄積できること
生成されたのと同じ形式の生データを持つこと
を満たします。
hadoopのコア技術である分散ファイル処理によって、多種多様なデータを保持することができ、容量が足らなくなったらサーバを増やすことでスケールアウトも容易です。
MapReduceやほかのHadoopエコシステムを通じて、HDFSに保存されているデータへのアクセス・加工が容易に行える
データレイク要件の中の
必要に応じてデータをピックアップし、加工・解析ができること
に該当します。
hdfsに保存されているデータに対しては、MapReduceを使った分散処理が可能です。
また、Hadoopエコシステムと呼ばれるHDFSへのアクセスや分散処理を簡単にするためのフレームワークがたくさん作られています。こうしたフレームワークを使えば、例えば、大容量データをSQLで簡単に処理したり・・・といったことも可能になります。
まとめ
データレイクについてまとめてみました。
データを蓄えて、ちゃんとデータをピックアップできればなんでもあり感があるデータレイクですが、きちんと保存したデータを活用できるように「メタ情報を管理すること」が要になります。データの沼地にならないように、よく考えてデータレイクを作って利用していくことが大事ですね
ではでは
