最近はデータサイエンティストとして働いているため、データエンジニア時代に得た知見を備忘録として残す。

データ流入量が1TB/日以下、DWHの利用者が1000人以下の現場を想定している。それ以上の大規模組織には以下の話は当てはまらない場合が多そう。

1. DWHには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ツールでダッシュボード化、というのはよくある使い方だ。
ではRDBにALTER TABLEがかかるとどうなるかというと、このテーブルを参照しているのはどいつなんだという影響調査が必要になる。
きちんと用途別にServiceAccountを使い分けていればINFORMATION_SCHEMAで大体の特定は可能だが、いずれにしろかなりの量のSQLの修正が必要になる。

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

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

  1. につながる話として、元データの仕様がバラバラであっても腐敗防止層があればインターフェースの仕様は統一できる。せっかくなのでテーブルの統一仕様を決めたほうが良い。 例として以下のようなルールを厳守するようにしておくと後々幸せになれる
  • (日本企業の場合) JSTの時刻データはDATETIME型にする。それ以外のタイムゾーンはUTCに変換してTIMESTAMP型にする

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

分析を簡単にするという目的でビジネスロジックを盛り込んだデータマート/ビューを用意していくと、結局分析サイドは仕様を把握しきれずデータカタログやドキュメントをもっと整備してほしいという話になってくる。
こうなってくるといくら人手があっても足りないので、分析用に提供するデータマート/ビューはビジネスで取り扱うエンティティに対応したマスターデータ・トランザクションデータだけにしたほうが良い。
非正規化にはこだわらずにアトミックにしたほうがよい。多少クエリコストがかかろうとも結局それが分析側の学習コストを下げ、分析コードの可読性は上がり、トータルで見るとコスト抑制になる。

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

データ基盤は社内システムであり、データエンジニアは間接部門に属する事が多い。
そのためふんだんにコストが投入されることは珍しく、基本的にはどこも常に人手不足だと思う。
更に大学にデータサイエンス学部などが創設されてデータサイエンティストは増え続ける一方だが、データエンジニアを目指す人はレアであり需要増に対して供給が全く足りていない。

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

最近はBigQuery周りの色々が進化しまくっているので、大体の場合は以下の構築パターンでいいんじゃないかと思う。

RDBデータ連携

  • Datastream

スピードレイヤー

  • Pub/Subに入れてBigQueryサブスクリプション(docs)

バッチレイヤー

  • GCS → Data Transfer

データマート生成

  • SQLで完結するならDataflow
  • しないものはワークフローエンジン行き

ワークフローエンジンの選定に関しては一概に言えない。（大体の場合マネージドAirflowで良いとは思う）

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

バッチジョブのエラーやマシンリソースの監視は大体どこもやっているだろうが、データの品質についての監視を行っている現場は意外と多くないのではと思う。
ちょっとMLOpsにはみ出た話ではあるが、重複・欠損・異常値などデータの中身を監視する仕組みを作ったほうがいい。

別部門が入力してきたデータをDWHに流すだけ、利用者に指摘されてから調査する、という後手後手の姿勢では無駄なリカバリ作業が増えるし、文化的にもどんどん社内下請けに成り下がってしまう。

9. コストの可視化は早めに始めたほうがいい

Bizサイドが委託したアナリストが激重SQLをRedashのスケジュールで毎朝回し、しかもBizサイドはダッシュボードをあまり見ていない。使っていないなら止めろとデータエンジニアから連絡するも対応されない。 なんて光景をよく見てきた。
インフラコストは利用者の関心事ではないために起こる話だと思う。

組織文化にもよるがあなたがデータ利活用の責任者ポジションであるならば、利用部門ごとにINFORMATION_SCHEMAからコスト概算を算出して通知するくらいの仕組みは早めに整備して、使い放題じゃない事を認識してもらったほうがよい。 （Reserved slotを使っているのであれば使用スロットでコストを按分するとか）

コストカットというよりもクエリやダッシュボードの整理整頓はしましょうねという話で、その辺の意識が利用側にあるかどうかとデータエンジニアの離職率には強い相関があるように感じる。

他にも思い出したら追記する予定