KARTEのデータをGCPに流すときの構成の決め方

Web接客ツールで貯まったデータを、自社のデータ基盤に集約したい。KARTE を使っているなら、Datahub 経由で BigQuery につなぐことになる。

つなぐこと自体は難しくない。ただし最初に決めておかないと後から直しづらい項目がいくつかある。ここではその4点を整理する。

なお以下は一般的な構成の話で、特定の案件の設定値は含まない。

何を持ってくるのかを先に決める

KARTE 側にあるデータは大きく3種類。用途が違うので、全部まとめて持ってこようとすると設計が崩れる。

まず1種類から始める。イベントが最も量が多く、設計の失敗が効いてくるので、行動分析が目的なら最初にここを通す。

1. 連携方式を選ぶ

主に3つの選択肢がある。

自社のデータ基盤に集約するのが目的なら、1つ目か2つ目。GCS を挟む構成のほうが後から楽になることが多い。理由は後述する。

2. リージョンを最初に確認する

ここが最大の落とし穴。

**Datahub 側の BigQuery は US マルチリージョンに配置されている。**一方、日本国内向けのデータ基盤は asia-northeast1（東京）に置くことが多い。

BigQuery はリージョンをまたいだデータセット間の直接クエリができない。つまり、Datahub 側のテーブルと自社の東京リージョンのテーブルを、1本のクエリで結合することはできない。

対処は2つ。

• 自社側のデータセットも US に作る。結合は楽になるが、他のデータが東京にある場合は同じ問題が別の場所で起きる
• 一度エクスポートしてから東京側に取り込む。GCS を挟む構成がこれにあたる

どちらを選ぶかは、自社データ基盤の既存リージョンで決まる。すでに東京にデータ基盤があるなら、迷わず後者。ここを確認せずに進めると、テーブルを作り直すことになる。

3. 権限は用途ごとに分ける

Datahub のサービスアカウントに対して、自社の GCP 側で権限を付与する。

押さえておきたいのは次の3点。

プロジェクト単位ではなくデータセット単位で付ける。プロジェクト全体に編集者を付けると、連携と無関係なデータセットまで書き換えられる状態になる。

連携用のデータセットを分ける。外部から書き込まれる領域と、社内で加工した結果を置く領域を分けておく。事故の影響範囲が限定でき、権限も絞りやすい。

誰がいつ付けたかを残す。権限は付けたまま忘れられる。付与の記録を残し、定期的に棚卸しする。

4. 書き込みモードを決める

Datahub から BigQuery に書き込むとき、3つのモードから選ぶ。

Append と Overwrite の選択が、後の運用を決める。

• Append は速いが、同じジョブを2回走らせると重複する。再実行のたびに件数が増える
• Overwrite は冪等（何度実行しても同じ結果）だが、対象範囲が広いと毎回全件を書き直すことになり、コストと時間がかかる

現実的な落としどころは、日付でパーティションを切り、対象日のパーティションだけを Overwrite する構成。再実行しても重複せず、全件を触らずに済む。

全体像

上記を踏まえた、よく使う構成。

KARTE Datahub
   ↓  ① 日次でクエリ実行、結果を GCS に出力
Google Cloud Storage（連携用バケット）
   ↓  ② BigQuery へ読み込み（生データ層）
BigQuery: raw データセット
   ↓  ③ 整形・結合（中間層）
BigQuery: mart データセット
   ↓
BIツール / 各種連携先

3層に分ける理由は、取り込みの失敗と加工の失敗を切り分けられること。数値がおかしいとき、生データ層を見れば「そもそも入ってきていない」のか「加工で壊れた」のかが即座に分かる。

GCS を挟む利点もここにある。取り込みに失敗しても、ファイルは GCS に残っている。KARTE 側に再エクスポートを依頼せずに、そのまま読み込み直せる。

最初に決めることのまとめ

運用に入ってからつまずく点は別の記事で扱う。