こんにちは、データ基盤の開発、運用をしていた谷口です。最近は配信基盤の開発と運用をしています。

ZOZOではオンプレやクラウドにあるデータをBigQueryへ連携し、分析やシステムで活用しています。BigQueryに連携されたテーブルは共通データ基盤として全社的に利用されています。

共通データ基盤は随分前に作られたこともあり、様々な負債を抱えていました。負債を解消しようにも利用者が約300人以上おり、影響範囲が大きく改善したくても改善できずにいました。

本記事では旧データ基盤の課題や新データ基盤の紹介に加え、どのようにリプレイスを進めたかご紹介します。同じような課題を抱えている方や新しくデータ基盤を作ろうとしている方の参考になると嬉しいです。

データ基盤の紹介

冒頭でご紹介したとおり、ZOZOではオンプレのSQL ServerにあるテーブルをBigQueryに連携して利用しています。

データ基盤は大きく分けて2種類あり、日次でデータ連携してるものとリアルタイムにデータ連携しているものがあります。日次データ基盤ではSQL Serverの全量データを転送しています。リアルタイムデータ基盤ではSQL Serverで変更のあった差分データをBigQueryへ連携しています。

日次の全量データとリアルタイムな差分データを組み合わせることで、リアルタイムにBigQuery上でSQL Serverのテーブルの状態を再現できます。今回はこれらのうち日次データ基盤（以下、旧データ基盤と呼びます）をリプレイスした事例をご紹介します。

リアルタイムタイムデータ基盤については以前書いた以下の記事をご確認ください。オンプレDWHの移行に伴い連携するテーブルが増えたため、現在はGKE上で運用しています。

旧データ基盤の紹介

リプレイス対象の旧データ基盤についてご紹介します。旧データ基盤では中間DBをハブとして多段に連携していました。まず、オンプレの基幹DB（SQL Server）で管理されているテーブルを中間DB（SQL Server）に書き込みます。次に、中間DBをハブとしてBigQueryに書き込みます。

実はBigQueryの他にもう1つのオンプレDWHにも中間DBからテーブルを連携していました。このオンプレDWHは配信チーム（MA：マーケティングオートメーション）で管理しているDWHになります。配信系の処理など一部のサービスではオンプレのDWHを活用していました。

テーブルの連携処理はAWS上にあるDigdag（ワークフローエンジン）とEmbulk（ETLツール）を用いていました。

現在はオンプレDWHと旧データ基盤は廃止済みです。オンプレDWHの廃止の詳細は以下の記事をご確認ください。

旧データ基盤の課題

ここからは旧データ基盤の課題をご紹介します。以下の図にあるように旧データ基盤では基幹DBから中間DB、中間DBからDWHに連携するまでに様々な加工処理を施していました。具体的にどのような加工処理を施していたのか、運用上どのような課題があったのかご紹介します。

変更があっても更新されないデータ

旧データ基盤では以下の図にあるようなテーブルの更新タイムスタンプを使った差分連携を採用していました。

タイムスタンプを用いて変更のあった差分データに絞ることで、サイズの大きいテーブルでも低コストで高速に連携できます。しかし、実際に運用してみると、テーブルに変更があっても更新タイムスタンプが適切に更新されないケースがありました。そのため、基幹のテーブルに更新があってもクエリの条件に合致せず、変更のあったデータがBigQueryに反映されませんでした。

また、基幹テーブルのレコードが物理削除された場合削除されたデータを取得できません。それゆえ、基幹DBで削除されたデータがBigQueryから削除されずに残り続けていました。その他にも物理削除されたデータを残す連携など様々な加工処理を施していました。 そのため、BigQueryにあるデータが基幹テーブルのコピーになっておらず、データ不整合が発生していました。

性質の異なるテーブルを同じ命名規則で管理

1つのデータセットで、性質の異なるテーブルを同じ命名規則で管理していました。

例えば日付サフィックスをつけるテーブルがあります。

<テーブル名>_yyyymmdd

この命名のテーブルを見たユーザは、全てのテーブルが同じ性質と考えてしまいます。例えば、最初に日付サフィックスの付いたテーブルが日次の全量スナップショットと認識したら、他のテーブルも同様と考えるでしょう。しかし実際には以下3種類の異なる性質のテーブルになっていました。

• 日次の全量スナップショット
• 日次の差分テーブル
• 日次の物理削除データを含むテーブル

このように、1つのデータセット内で異なる性質のテーブルを同じ命名規則で管理していたため、利用者を混乱させていました。

秘密情報の判断が手動

旧データ基盤では秘密情報の判断を手動でしていました。秘密情報は秘密情報の管理表で管理されています。利用者がテーブルの追加を依頼する際に秘密情報の管理表を確認し、データ基盤の管理者側でも秘密情報がないか確認する運用です。旧データ基盤では秘密情報はBigQueryに入れない運用をとっていたので、秘密情報の場合はマスク処理を施してBigQueryで管理していました。

ただし、利用者の申請ベースの運用だったので、店舗の電話番号など秘密情報ではないのにマスク処理が施されている場合もありました。これまで幸い問題は発生していませんでしたが、人間任せだと誤って秘密情報を漏洩させてしまう懸念がありました。

テーブルの取得元が不適切

基幹DBにはマスタテーブル以外にもレプリされたテーブルがあります。レプリされたテーブルは同じ名前で異なるデータベース内に管理されています。

BigQueryへ連携する際に基幹DBのどのデータベースから連携するか決める必要があります。これまで、テーブルの取得元DBは利用者がテーブルの追加を依頼する際に指定する運用をとっていました。その結果、テーブルの取得元としてマスタDBとレプリDB両方から連携されていました。

冒頭で述べたようにZOZOではリアルタイムデータ基盤も運用しています。リアルタイムデータ基盤では鮮度の高いデータを取得できるようマスタDBから変更のあったデータをBigQueryに連携しています。

リアルタイムデータ基盤ではリアルタイムな差分データと日次の全量データを組み合わせることで、基幹テーブルの最新の状態を作りだしています。旧データ基盤の取得元が不適切だとリアルタイムデータ基盤と旧データ基盤（日次全量）で参照元のDBが異なり、不整合が発生してしまいます。

テーブル追加の依頼者もこうした事情を把握していないため、取得元は不適切になりがちでカオスな状態となっていました。

新データ基盤の紹介

このように様々な辛みがあったので、データ基盤をリプレイスしました。

新データ基盤は以下のような構成になっています。緑の点線部分が今回リプレイスした箇所になります。日次の全量データが正しいデータになったので、リアルタイムデータとマージした全量データも正しいデータにできました。ここからは新データ基盤をご紹介します。

データレイクの構築

新データ基盤ではBigQuery上にデータレイクを構築しています。旧データ基盤にあった特定の用途に特化した加工処理は全て廃止し、全量転送しています。無加工のデータレイクを用意し、特定の用途に特化した処理はデータマートで対応するようにしました。

データセットを分けて管理

新データ基盤では取得元DBとテーブルの性質を考慮して、データセットを分けて管理しています。

旧データ基盤では取得元DBや性質の異なるテーブルを全て1つのデータセットで管理していたため、利用者の混乱を招いていました。そこで、新データ基盤ではBigQueryのデータセットを以下のような命名規則にすることで対応しました。

<データベース名>_<性質>

以下の図にあるデータセット名で取得元DBとデータの性質を考慮して、データセットを分けています。例えば取得元DBが「zozob」の日次全量テーブルは「zozob_daily」、リアルタイム全量テーブルは「zozob_realtime」となっています。

続きはこちら