データマートのモデリングとパフォーマンスチューニング

2024年4月1日 19:46

はじめに

データエンジニアリングが興隆してから数年が経ち、各企業がデータ基盤に注力し始めたり、知見が溜まり始めています。
そんな流れがある中、データマートの乱立やパフォーマンスで悩んでいる方が多いのではないでしょうか？

そこで、本記事では重要な分析基盤の1つであるデータマートに焦点を当てつつ、データ基盤のデータモデリングから構築、運用に至るまでの手法と考え方を解説していきます。

データマートの目的と要件の明確化

データマートには様々な用途がありますが、いずれの場合も最初に重要なのは、そのデータマートの目的と要件を明らかにすることです。例えば、単なる可視化(ダッシュボード)用なのか、多次元分析用なのか、アプリケーションへの組み込み用なのかです。

目的に応じて、モデリングアプローチ、データ粒度、スキーマ設計は全く異なってきます。さらに、リアルタイム性、セキュリティ、パフォーマンスなど、様々な要件の優先度を検討する必要があります。

初期段階で作り手と利用者の認識に齟齬があれば、後に手戻りが発生し、無駄なリソース消費につながりかねません。そうならないためにも、目的と要件の明確化は不可欠なステップになります。

データマートの乱立とモデル統制の課題

データマートの乱立

データマートは各部門や用途別に作成することが多いです。よって、同じようなマートが複数登場したりとデータマートの乱立が発生します。

データマートの乱立により以下のような問題が発生します。

データ重複と不整合
高コストな運用管理
システム統合の複雑化

よく散見されるのが、データマートが多段になっており、その中の一部のレコードが重複して集計が間違っているケースです。10段、20段になっていたりすると人間の管理が届かなくなることがあります。

モデル統制の課題

データマートの乱立と同様に、多くの組織で深刻な問題となっています。
統制されていない複数のモデルが存在することで、複雑化します。

モデル定義の非標準化
データソースの不統一
変更管理の欠如

各マートでビジネスロジックが異なることで集計結果が異なることがあります。例えば、アクティブユーザー数の「アクティブ」が1日に1回ログインしたか、1週間に1時間滞在したか、などの定義が部門毎にバラバラであることでレポート結果が異なるといった場合があります。

データモデリングの種類

こちらで紹介するのは、分析基盤全体、バッチアナリティクスのデータモデリング手法です。データマートに限る話ではありません。

結局、データマートのみを設計するのではなく、データウェアハウス層込みでどのようなモデリングをするのかが重要になります。

①Inmonのデータウェアハウス

こちらの手法は、徹底的にETLに重点を置き、細かい粒度で高度に正規化されたERモデルに基づいて、組織から集めたデータが統合されます。

②ディメンショナルモデリング

これも有名どころですが、Ralph Kimball氏が考案したモデリング手法です。データはディメンションおよびファクトとしてモデル化されます。

メリットは、拡張性を担保できることです。
デメリットは、モデリングコストが高いことと、ファクト・ディメンションの冪等性担保が難しい点です。

また、この手法でよく登場するスタースキーマとスノーフレークスキーマについては、以下の記事をご覧下さい。

③DataVault

Data Vaultは、ステージング領域とプレゼンテーション領域の間にHub、Satellite、Linkと呼ばれる3種類のテーブルで作られたエンタープライズデータモデルの領域を作るという手法です。

④大福帳モデリング（ワイドテーブル）

すべてのカラムが一つのテーブルにまとまっている横長のテーブルテーブルです。

メリットは、モデリングコストが低いことです。
デメリットは、拡張性を担保するのが難しい点があります。

⑤4層管理

staging層をlake層とdwh層の中間に追加します。
dbtのベストプラクティスの1つである「How we structure our dbt projects」にも記載がありますが、データを共通した処理でクレンジングします。

データモデリングの選定

上記のような複数のアプローチがある中、データマートをどのように設計するのが良いでしょうか？
ケースバイケースなので、答えは1つではありません。結局、複数のモデルを組み合わせると上手くいくケースが多いです。

以下はあくまで筆者の提案です。（目安として考えてください）。
①②と③④は少し性質が異なりますがご了承ください。

①初期は大福帳モデリング

データの種類も量も多くない初期は、大福帳にすると運用が比較的楽な印象です。特に分析や可視化の際には、JOINをする必要が無くなるのでアドホックに処理することができます。

ただし、データの種類・量が増え、以下の2つの問題が発生するとディメンショナルモデリングに変更すると良いと思います。

クエリコストが許容できないほど増加する
可視化や集計の性能(スピード)が悪化する

②中期はディメンショナルモデリング

コストやパフォーマンス改善のためにディメンショナルモデルに変更します。ファクト・ディメンションテーブルをJOINすれば大福帳テーブルも作れます。

もちろん初期からディメンショナルモデリングを実装しても良いと思います。ただし、少人数で設計から構築、運用をするのは手が回らなくなってくることが多いです。自チームの人数やスキルにより臨機応変に対応することが重要になります。

ただ、やはりメリット・デメリットがあり、この手法を断念しているケース（※1）もあります。

③管理が複雑になってくると4層管理

データソースの種類が増えてきた時に複数ソースシステムのデータを共通した処理でクレンジングする層を設けます。

多くのテーブルで前処理方法が異なってくると運用・管理コストが高くなります。そこで

④人数やシステム規模が増えてくるとDataVault

Hub、Satellite、Linkと呼ばれる3種類のテーブルで作られたデータモデルのため、何かしらテーブルが追加された時に最低3つは作成する必要があります。この手間に耐えることができるかどうかが重要になります。

チームメンバーの数が増えてくると運用に耐えることができると思うので、ある程度チームが育ってから取り入れるのが良さそうです。

パフォーマンステクニック

①実体化とビューの選定

初期であればビューを選択します。
これは、テーブルの場合、連携処理が失敗するとリカバリーに時間がかかってしまいますが、ビューだと最小限に抑えることができるからです。

ビューで性能やコストが発生した時に実テーブル化を行います。
ビューのデメリットが実テーブルのメリットを超えた時に実体化します。

ただし、最近は各ツールのマテリアライズドビューもコストが下がったり、データ鮮度が上がったりしているので選択肢の1つになります。

②増分モデルとしてテーブル化

定期的に履歴テーブルから新規レコードや変更レコードを抽出し、増分データを特定して比較的小さなテーブルを作成します。

これはアナリストや業務要件によって変わってしまいますが、例えば、毎日1日分のデータだけ別テーブルとして作成します。こうすることで全データを参照することが無くなるので、コストも下がるしパフォーマンスも向上することになります。

運用コストの削減

運用コストを下げるために2つの手法を紹介します。こちらはlake層に関係する部分になります。

①フェデレーテッドクエリ

フェデレーテッドクエリとは、OLAPデータベースがオブジェクトストレージやRDBMSなどのウェブデータソースからクエリを発行できるようにするデータベース機能です。

例えば、OLAPのDBからMySQLやPostgreSQLにあるテーブルのデータを組み合わせて結果を取得することができます。こうすることで、外部ソースが変更されるたびに手動でデータを取り込む必要もなくなります。

②データ仮想化

データ仮想化はフェデレーテッドクエリと似ています。異なる部分としてデータ仮想化を行うクエリシステムは一般にデータを内部に保存しません。外部テーブルをサポートするクエリ処理エンジンはすべてデータ仮想化エンジンとして使用できます。

データ仮想化は様々なデータソースにまたがって保存されている場合には良いですが、無計画に使うべきではありません。例えば、クエリを実行すると、毎回データソースからデータを取得するため負荷をかけることになります。

おわりに

データマートの乱立や不適切なモデリングによる課題を解決するためには、以下の点が重要であるということが分かりました。

データマートの目的と要件を初期段階で明確にする
時と場合によって複数のモデリングアプローチを組み合わせる
ビューと実体化テーブルを状況に応じて使い分ける
増分モデルの活用によるパフォーマンス改善
フェデレーテッドクエリやデータ仮想化によるデータ統合と運用コスト削減

データマートを単一のアプローチで一気に構築するのではなく、プロジェクトの規模や要件に合わせて、適切なモデリング手法とパフォーマンステクニックを組み合わせながら、段階的に発展させていくことが重要になります。