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 側に再エクスポートを依頼せずに、そのまま読み込み直せます。

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

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