データ基盤開発運用のベストプラクティス

2023/11/03

多くのデータ基盤に携わる中で得られたノウハウをまとめます。
データ流入量が1TB/日以下、DWHの利用者が1000人以下の組織を想定しています。

1. データウェアハウスにはBigQueryを利用する

2023年現在、データウェアハウス（DWH）の主な選択肢はBigQuery、RedShift、Snowflakeの3つが挙げられます。しかし、コスト、パフォーマンス、運用のしやすさ、機能、エコシステムの充実度など、どの観点から見てもBigQuery以外を選択する理由は多くないように感じられます。

詳しい比較については世に多くの情報がありますが、マルチクラウド構成にしてでもBigQueryを選ぶ価値があります。特に「既存のシステムがAWSにあるから」という理由でRedShiftやSnowflake on AWSを選択し、その後BigQueryに移行するケースはよく耳にします。

2. ETLよりもELT

コスト面で理想的なのはETLで必要十分なデータマートを用意することですが、実際にはほとんどの場合うまく機能しません。事業の変化に伴い分析のニーズも変わり、データソースとなるプロダクトも成長に応じて変化します。
ETLの問題点は弾力性がなく、障害やカラムの追加があるたびに過去データを入れ直す必要が生じ、運用コストが高くなりすぎる点にあります。ペタバイト級のデータ量でない限り、BigQueryを利用したELTの方が人的コストを考慮すると経済的です。

3. データマートの前にまずはビューで提供する

データソースやデータマートの要求仕様は常に変化するため、まずは変更コストの低いビューを作成してリリースするのが良い方法です。クエリのコストが高い場合は、マテリアライズドビューを使って中間テーブルを作成し、データを圧縮できるか試みることも有効です。データマートは最終形態と考えるとよいでしょう。

4. 分析で生データに直接アクセスしない

RDBから転送したデータをSQLで加工し、BIツールでダッシュボード化、というのはよくある使い方です。
元のデータベースに変更を加える必要性が生じた時、そのテーブルがどこで利用されているか、どのような影響が生じるかを調査しなければなりません。
組織のデータ活用が進むほどそれは困難になり、調査しきれないままリリースする事になるかもしれません。そして動かない、正しくないダッシュボードが残ることになります。

適切なモデリングを行ったビューを用意しておき、そのビューだけを分析に使うという運用にするとビューが腐敗防止層として働いてくれます。
データソース側の仕様変更があってもビューで隠蔽すれば分析側に影響せず、圧倒的にトータルの運用コストが下がります。ビューの設計が適切であれば分析も格段に容易になります。
生データを格納するデータセットのアクセス権はデータエンジニアだけが持っているというレベルでも全く問題ないと考えます。

5. データマート/ビューの規約を決める

  1. につながる話として、元データの仕様がバラバラであっても腐敗防止層があればインターフェースの仕様は統一できます。せっかくなので分析データの全社統一仕様を決めましょう。 例として以下のようなルールを厳守するようにしておくと、後々かならず役に立ちます
  • 日本国内のビジネスに関連するデータは時刻をJSTのDATETIME型にする
  • 海外のビジネスに関連するデータはUTCに変換してTIMESTAMP型にする

6. データマート/ビューは最小限にする

分析クエリを短くするという目的でビジネスロジックを盛り込んだデータマート/ビューを用意していくと、結局分析者は仕様を把握しきれず、データカタログやドキュメントをもっと整備してほしいという要望が発生します。
分析用に提供するデータマート/ビューはなるべくシンプルに、ビジネスで取り扱うエンティティに対応したマスターデータ・トランザクションデータだけにするのが無難です。
また、非正規化にこだわりすぎる必要はありません。多少クエリコストがかかろうとも結局それが分析側の学習コストを下げ、分析コードの可読性は上がり、トータルで見るとコスト抑制になります。

7. データ基盤を凝りすぎたアーキテクチャにしない

データ基盤は社内システムであるため潤沢にコストが投入されることは珍しく、多くの会社で人手不足となっています。
大学にデータサイエンス学部などが創設されてデータサイエンティストは増え続ける一方、データエンジニアを目指す人は珍しく、需要増に対して人材供給が全く足りていない状況です。

データ基盤の新規開発時にはイメージされ辛いですが、何年か経つと少数のデータエンジニアで大量の依頼を捌いていくことになり、分析PJは「データ連携待ち」「データエンジニア調査待ち」のステータスで溜まっていく場合が多いです。
組織のデータエンジニアのレベルが高かったとしても基盤はできるだけ学習コストが低い作りにして、業務委託などでスケールできるようにするのが無難です。

近年はBigQueryと周辺技術が急激に進歩しており、多くの場合以下の技術スタックで要求を満たせると考えています。

スピードレイヤー

  • Cloud Pub/Sub BigQueryサブスクリプション

バッチレイヤー

  • GCS → Data Transfer
    または
  • Storage Transfer → GCS → BigLake

RDBデータ連携

  • Datastream

NoSQLデータ連携

  • 何らかの方法でトランザクションログをPub/Subに送り、BigQuery CDCを用いてログをテーブルにする
    • 例: MongoDB Atlas Triggers

ELT

  • SQLで完結するTransform処理はDataflow
  • それ以外の処理はCloud Composer

8. データ品質の監視をする

バッチジョブのエラーやマシンリソースの監視は一般的ですが、データの品質についての監視を行っている現場は意外と多くないと思います。
ややMLOpsにはみ出た話ですが、Dataplex等を用いて重複・欠損・異常値などデータの中身を監視する仕組みを整備するべきです。

別部門が入力してきたデータをDWHに流すだけ、利用者に指摘されてから調査する、という後手後手の姿勢では無駄なリカバリ作業が増え、低品質なデータを自転車操業的に保守する形になってしまいます。

9. コストの可視化は早めに始める

ビジネス部門が委託したアナリストが激重SQLをBIツールで毎朝実行し、しかもそのダッシュボードはほとんど見られていない、といったことはままあります。インフラコストは利用者の関心事ではないことに起因した課題です。

組織文化にもよりますが、利用部門ごとにDWHのコスト概算を算出して通知する仕組みを早めに整備し、使い放題ではない事を周知することを検討してください。

主目的はコストカットではなくクエリやダッシュボードの整理整頓を促すことで、利用者側にその意識があるとデータ基盤の運用は格段に容易になります。

アーガス・アナリシス合同会社はデータ基盤の新規開発からデータ利活用の推進まで、総合的なサポートを提供しています。