##適切なデータ分析基盤の設計
こちらの記事のまとめと所感。
引用: https://xtech.nikkei.com/atcl/nxt/mag/nc/18/041400166/061500003/
データ分析基盤設計の代表的なパターンとしては、以下の3つがあるようです。
①データレイク型
②統合型
③分散型
それぞれにメリット・デメリットがあり、各社のデータ特徴、エンジニアの質などを総合的に踏まえて、適切なアーキテクチャを選定することが重要。
上記3パターンを順番に考察していきます。
##①データレイク型
1.概要
各業務DB、IOTデバイス等が集めてくるデータ達を、そのままの形で1つのストレージにガバっと保存しておきます(このストレージを「データレイク」と呼びます)。
こうして会社内のあらゆるデータが集まったデータレイクから、用途に合わせて必要な分だけ抽出・適切な形に加工し、(これを「ETL」と呼びます)、利用する、というものです。
以下はAWSのサービスを利用した例。
クラウドサービス各社が「分析基盤はこうして設計するのだ！」と、セミナーなどで提唱しているのも、大体この型です。
引用:
https://www.slideshare.net/akuwano/aws-69861007
https://www.slideshare.net/AmazonWebServicesJapan/aws-70254977
https://cloud.google.com/solutions/build-a-data-lake-on-gcp?hl=ja
2.メリット
以下3つのメリットがあると言われています。
①データを一元管理できること
②インプット(データを入れる)システムとアウトプット(溜めたデータを何かに使う)システムを分離できる
③各アーキテクチャが疎結合で、柔軟性が高いこと
データは各社によってその性質も、量もバラバラです。
自社の特徴に合わせて柔軟に構築できる点では、非常にコストメリットも大きいのではないでしょうか。
また、自社で様々なサービスを持っている会社などは、各サービスが別個でデータを管理し、どんなデータが何処にあるか分からず、分析のハードルが高い(データがサイロ化した)状態になりやすかったりします。
1つこういう基盤を持っておくことで、サイロ化を防ぎ、意思決定補助のスピード感を高めることも可能かと思います。
3.デメリット
記事、所感からデメリットは3つあります。
①図を見れば分かるかと思いますが、様々なサービスを使用しなければなりません。
柔軟でカスタマイズの幅が広い分、各サービスに対する理解を深めておかなければ無駄なコスト、性能リスクが発生しやすいです。使いこなすには難易度の高いアーキテクチャと言えると思います。エンジニア魂が燃えますね。
②次に、「色んなデータを使える形で加工する」、ここが本当に難しい。データへの深い理解と、不良データに負けないストレス耐性。ビジネスサイドからの無理難題...こいつらを解決しなければなりません。
③運用難易度が高いです。各サービスを統合管理できません。AWSなどではcloudwatchなどを駆使すればいけそうかと思いますが、ここの仕組みを構築するのは高額です。
統合監視の難易度が高い分、運用は複雑になります。
##②統合型
1.概要
DB界最強のOracleや、SQLserver、SAP HANA、最近だとSnowflakeが流行ってますね。
1製品であらゆる機能を賄おう、という考えです。
2.メリット
以下3つのメリットがあると言われています。
①構成を考えるのが楽です。ベンダーが予めカスタマイズしているものに当てはめればいいので。必要な機能は大体最初から備わっています。
②各製品独自の機能が便利です。特にリカバリやセキュリティといった部分。当然オンプレミスにも対応なので、リスクに厳しい大企業・金融系などはよくoracleを選択してますね。
③データレイク型と被りますが、こちらもデータを一元管理できるので、サイロ化は起きづらいです。
3.デメリット
こちらも3つあると言われます。
①シンプルに高い。本当に。中小企業だとコストに圧し潰されます。
②柔軟性はデータレイク型に比べ下がります。ハード性能などは細かくサイジングできないので、突発的なデータ増・負荷増などに対応しづらい点は、面倒かなと思います。
③「とりあえずそのままの形でデータを保存しよう」が出来ません。製品によって予め決まった型に合わせなければなりません。ここも面倒ですね。
##3.分散型
1.概要
各DBで相互に連携しながら、うまい事処理しましょう、という基盤。
ここまで挙げてきた2つと違い、これといった統合管理をすることが無いのが特徴です。
2.メリット
既存システムに変更を加えなくて良いことです。
また、製品も何でもいいので、業務の特徴に合わせて、例えばMySQLとPostgreSQLを併用する、といったことも可能です。
3.デメリット
反面デメリットは3つです。
①データレイクと被りますが、色々なサービス(製品)を使うので、を統合管理と設計が難しいです。
②データがサイロ化しやすいです。これが最大のデメリットかもしれません。サイロ化のリスクはデータレイク型のメリットでお伝えした通り。サイロ化した基盤を触ったことがある身からすると、これは想像以上に生産性が低いです。
③データ連携が複雑になりやすいです。各DBで微妙にSQLの書き方や仕様は違いますし、「どことどこをどう連携するか」という部分は、DBが増えるにつれて網の目の様に複雑になります。
##結局どのタイプがいいの？
個人的には①を推したいです。
割と新興のアーキテクチャ故、推進出来る人も少ないですが、
何よりコスト面での有用性は高いと思います。
クラウド各社のプロたちから知識も得やすいですしね。
②は、前述しましたがセキュリティ等のリスク絶対守るマンや、
①は難易度が高いよ...既存のやり方でやらせてくれ...って場合にはアリだと思います。
何より、エンジニア的にはガッツリDBの基礎を学べるので、(話は逸れちゃいますが...)新卒エンジニアなどはこれを採用してる現場に行くと、基本が身につきやすくていいと思います。
③は、あまりメリットが思い浮かばず。。。すいません
自分の現在の価値観の中だと、データ整備がうまく出来なかった企業の成れの果て...みたいなイメージでしかありません。
勿論これでうまくやってる会社さんもあると思うので、ぜひ知りたいです。