最低限のガイドラインとしたいTreasure Data CDPデータ格納/処理構築のポイント

2021年11月2日

はじめに

Treasure Data CDP（TD）は様々なデータソースを集約することに適したプラットフォームです。

Treasure Data CDPには、エンジニアのみならず、ビジネス側の方も適宜アクセスし、簡単なクエリでデータ集計/分析をして、示唆を得たり施策の検討が進められる状態を作ることが望ましいと考えます。その中で、データの種類が少ない場合は問題となることは少ないですが、扱うデータの種類が増加するにつれて、特に決め事なくインプリの担当者（エンジニア）それぞれがDBの作成やWFの実装した場合、担当者以外の方が「何がどこにあるかが分からない」状態になってしまい、例えば「TDにデータはあるはずなのに活用できない、、、」という状況に陥る可能性が出てきます。

上述の通り、様々なデータソース集約することに適したプラットフォームであるがために起こり得る問題です。インプリ担当者は構築初期段階から、ビジネス側の方や後任者が「何がどこにあるかが把握できる状態」を出来る限り作ることを念頭に置き、構築を進めることが大切だと感じます。また、WorkFlow（以下、WF）やQueryの実装においても、インプリ担当者間で全てでないにしろポイントを絞って一部ルール化しておくことで、処理そのものや確認/レビューなど諸々効率化できる部分があります。

以降、「構造」、「実装」、「運用」に分けて、ポイントを記載いたします。参考いただけますと幸いです。

構造

WFおよびDBをレイヤーで分け、各レイヤーのデータの状態は図中に記載の内容に準じて構成する

同一データソースからのIngest（Load）処理は重複して行わないようにする（開発段階など止むを得ない状況を除く）
DBの名称は、当該DBの位置付けに合わせて接頭辞に”l0_”, “l1_”, “l2_”を付与する。
Layer0（=生データレイヤー）　： l0_(data source具体名)
Layer1（=一次集計レイヤー）　： l1_(data source具体名)　
Layer2（=統合レイヤー）　： l2_(利活用途 or Output先)
例）
WFは、1)実際にデータ加工等の処理を行うWFと2)それらのWFを呼び出すためのWFを別途用意し、②のWFにスケジュール設定するかたちで構成する。
また、1)のWFには、名称の一部に”l0”, “l1”, “l2”の文字列を組み込む。
例）

実装

必要なところ（並び替えを伴わないと成立しない場所）以外にORDER BY句は使わない
（無駄なシングルノードタスクを抑制する）
定期実行するSource、Saved QueryはWFの処理として組み込む
（WFに完結することで、定期実行が不要になったデータ取込〜加工の処理のスケジュールの解除忘れを抑制することが期待できる）
繰り返し処理などにより呼び出し先のWFが1000タスクを超える、または複数WFから共通で呼び出されて1回の実行を守りたい、他プロジェクトのWFを呼び出したい、といったことがない限りは、require>:ではなく、call>:を使用する。
（require>:の場合呼び出し先のWFが実行済かの確認など（オーバーヘッド）があり、結果的にパフォーマンス低下傾向にある）
parallel>:は、他WFの実行スケジュールも加味して使用する。
（特定のWFにparallel>:を多用し同時実行数を消費してしまう結果、他WFの開始遅延などにつながる可能性を考慮する）
WFプロジェクト内のtd>:などで指定されているqueryなどのパスは絶対パスで書くようにする。同一階層を示す「./」や上位階層を示す「../」の指定はしない。
（WF編集画面上でパスをクリックすることで、該当ファイルに遷移またはSplit Viewでの表示ができるので確認やレビューの際に便利）

遷移可能例）td>: queries/aaa.sql
遷移不可例）td>: ./queries/aaa.sql

運用

定期実行不要となった処理（Source, Saved Query, WF）はスケジュール設定を解除する
（削除する必要はない）
（optional）データ定義書：ビジネスユーザがTDへのログインをせずに、テーブルの種類やカラムの種類を確認するために、Google Spread Sheetなどにinformation_schema.tablesやcolumnsの情報を書き出すなどする
（日本語での説明などをGoogle Spread Sheet側で入力しておくなども可能）