はじめに
私は職務上、お客様のデータ分析基盤のアーキテクチャ選定に関わることがあります。
更改であれば観点が明確だと思いますが、はじめて作る場合は観点出しが難しいですよね。
特に「DWHを選定するのは初めてで…」というケースもあるのではないでしょうか。
業務システムで馴染みのRDBMSは既にあるけど、DWHのラインナップって全然違いますよね。
そこで、本記事ではDWHを選定する際に意識しておきたいことをまとめようと思います。
この記事に書いてあること
- 選定する際に重要となる考え方
特に、はじめてデータ分析基盤を構想したときに思いつかない観点を伝えたいです
この記事に書いてないこと
各DHWサービス/製品の比較
- 使い勝手・機能
- 利用料金
これらは比較表に必ず入る項目ですが、選定が意図ではないので記載しません
大事な考え方
まずは機能が、とか、AI対応が、とか始める前に少し引いて考えてみましょう。
現実世界と照らし合わせて考えることが重要です。
おそらく「データ分析基盤」を作りたくてDWHを選ぼうとされていると思います。
「データ」と「分析」に分解して考えてみましょう。
まずは「データ」についてです。
ヒト・モノ・カネ・情報が４大経営資源だと言われています。
情報とデータはイコールではなく、データを情報にしていくのにはステップがありますが、
雑に捉えるとデータは経営資源（の源泉）だと言うことが出来ます。
４大経営資源を見たときに、「情報」は総量を分けあう構図でないことに着目してください。
つまり、原則としてみんなに同じものを同じだけ提供できるという特徴があります。
つまり、情報（データ）というのは本質的にも会社の共有資産であるということが言えます。
データは会社の共有資産である
「データ」についてはまずこれを忘れないようにしてください。
次に「分析」について考えてみます。
分析を何のためにするかというと、当然ですが事業のためにします。
事業計数あるいはKPIの達成のために分析を活用するので、事業活動の一環になります。
つまり「データ」そのものとは異なり、「分析」は事業(≒事業組織)に紐づくものと捉えられます。
分析は事業組織に紐づくものである
これをITという観点に置き換えて考えてみましょう。
「データ」は全社の共有資産であるという話をしました。
これはITの観点で考えると、ストレージと考えることができます。
「分析」については事業組織に紐づくものとしました。
これはコンピューティングリソースと考えることができるでしょう。
つまり、ストレージを共有しながら、コンピューティングリソースを事業ごとに分割できると現実世界と適合できると言えます。
ストレージは共有、コンピューティングリソースは事業ごとに分割するのが原則
これをすることで、どの事業がどのくらい分析にリソースを使っているのかがわかります。
実際にそのリソースのコストを配賦するケースは少ないと思いますが、どこがどのくらい分析をしているかという情報はデータ分析の拡大していくためにも必要な情報となってきます。
ある事業の分析が別の事業の分析にとってのノイジーネイバーとなることも防ぐことができます。
基本的にこの原則はどのDWHであっても適用するように設計できるはずです。
ただし、どのように実現するかはバラバラです。複雑になるケースもあります。
ここはサービス選定の大きなポイントになるでしょう。
選定前に実現手段までイメージできていることが望ましいです。
コストに対する考え方
コストに対して考えるとき、まず目を向けるのはサービスの利用料金だと思います。
最初に載せた通り、利用料金についてはここでは触れません。
利用料金以外で考慮に入れるべきコストは主に基盤の維持に要する労務費です。
労務費については、既にチームにいるエンジニアで対応するので追加で見込む必要はないと考えるケースも多いですね。
データ分析基盤の維持を行うエンジニアは定常的に何をしているのでしょう？
イメージしやすいのは
- 基盤に取り込むデータを増やすための対応（データ種の拡大、接続システムの拡大）
- 基盤を利用するユーザーを増やすための対応
あたりだと思います。
これらは利用がどんどん拡大していることの証左でもありますので、喜ばしいことですね。
一方で、運用を開始して利用が拡大していくと直面する課題があります。
それがデータスキューです。
DWHというのはデータを分散配置した上で、パラレルにデータを取得することで大量データを効率的に処理します。
この分散配置において偏りが生じてしまうことをデータスキューといい、データ処理の効率性が落ちてしまいます。
データスキューが発生すると効率性が落ちるので、データの配置についての見直しが必要になる
正しく設計をしていればデータスキューは発生しづらいですが、正しさは時間の経過とともに変わっていきます。
データスキューに対応するだけの知識やリソースがある場合は無視していいと考えますが、そうでない場合は、設計思想としてデータスキューが起こり辛いDWHを選定するのが良いです。
DWHの２大メンテナンスコストは、以下に係る労務費です。
- データスキューの最適化
- コンピューティングリソースの優先順の調整
コンピューティングリソースの優先順の調整は、前章で述べた通りうまく分離をしていれば発生しません。
分離がされていない場合は、状況を見ながら優先順位を調整する対応が必要になります。
労務費に関する検討はサービス比較の時点で検討に入れておきたいですね。
データやユーザーの拡大に従事してもらうはずのエンジニアが、他の対応で手いっぱいになってしまいます。
さいごに
この記事は選定をテーマに意識するポイントを書いてきました。
原則を書いていますので、それはすなわち設計をする際にも意識したいポイントになります。
選定や設計など目の前のタスクに追われるとついついミクロなポイントに目が行くと思いますが、
時々マクロな観点に目をやることは大事だと考えています。
この記事が何かの役に立てば幸いです。最後までお読みいただきありがとうございます。