データカタログ特集　データ利活用に向けたアーキテクチャ6選

株式会社10X

事業内容

10Xでは「10xを創る」をミッションとし、小売向けECプラットフォーム「Stailer」の提供を通じて、スーパーやドラッグストア等のオンライン事業立ち上げ・運営支援を行っています。Stailerでは業務構築におけるコンサルティングから、必要な商品マスタやお客様アプリ・スタッフ向けのオペレーションシステム等の提供、配達システムの提供、販売促進の支援など、データを分析しながら一気通貫での支援を行っています。

データカタログ導入の背景

以前はデータ分析にデータレイクのテーブルがよく利用されており、カラムのメタデータもスプレッドシート上に記載していました。データガバナンスの強化に伴ないデータレイクの閲覧権限を絞ったため、データ活用者は日常的に分析で利用するDWHやデータマートのカラムの仕様が分からないためデータ基盤の管理者に質問するしかなく、データ基盤の管理者は日々の問い合わせに忙殺され基盤の改善に十分な時間を割きにくい状況になっていました。

データカタログツール(Dataplex)の導入・活用の工夫ポイント

データ基盤の運営では、データカタログを含むメタデータ管理以外のことも課題になるため、データカタログの運用コストを低く抑えられるかが導入のポイントでした。DataplexによるデータカタログはGoogle Cloudによって管理されているため、BigQueryやIAMと深く連携されており、BigQueryを使っていれば時間の面でも金額の面でも大きなコストをかけずにデータカタログを導入 / 運用できています。

また、Googleの検索技術が活用されているおかげで日本語の検索はもちろん問題ないですし、テーブルやカラムのメタデータも横断して検索できます。検索結果の順位付けもクエリによる参照頻度も考慮されているため、現在は全く使われていないテーブルをデータ活用者が参照してしまうリスクを減らせます。

データカタログはメタデータの入力がボトルネックになりやすいため、OSSを活用しながら最小限のメタデータの入力で済むように工夫しています。 (詳しくはこちらをご参照ください)。

データカタログ導入によって得られた成果、解決できた課題

データカタログを活用することによって、データ活用者が必要なデータに自分自身で辿り着けるケースがSlackなどを見ていても増えています。正確に素早く簡単に必要なデータに辿り付けることで、データを通じた事業価値の創出に結び付けやすくなったことは大きな成果と言えるでしょう。

また、データカタログを活用してもらうことにより、データ基盤の管理者が問い合わせ対応を行なう時間を削減できたことで、データの正確性や可用性などデータ品質の改善など別の課題に対して十分な時間を取れるようになってきたと感じています。

著者

エンジニアリング本部 データサイエンス & エンジニアリング部　データエンジニア
吉田 康久 @syou6162

株式会社ビットキー

事業内容

日々の暮らしや、働く場での「体験の分断」を解消するべく「homehub」「workhub」を提供しています。 Data Platformチームは、プロダクトの継続的な価値提供を可視化し、正しくプロダクトを進化させるための意思決定を導くためのデータ基盤を構築しています。

データカタログ導入の背景

ビットキーでは、データウェアハウス（BigQuery）内のデータ理解コスト削減のためデータカタログを導入しました。
具体的な課題として

1. 社歴の浅いデータアナリストのデータ理解コストが高い
2. 開発者がデータ調査のためにBigQueryを利用していたが、目的のデータがどこに格納されているかわかりづらい
   

というものがありました。

上記のように活用シーンが限定的であることが想定されたので、無料で利用でき、既にBIツールとして利用していたLooker Studioを中心に、dbtとBigQueryとNotionを組み合わせてデータカタログとして機能するような形を採用しました。

アーキテクチャ図

データカタログツール(dbt)の導入・活用の工夫ポイント

導入背景でも触れましたが、Looker StudioはBIツールであり、単体でデータカタログの役割を持ちません。なのでdbtでテーブルやカラムのdescriptionを定義しています。これがBigQueryに連携され、それをSQLで整形し、参照する形をとっています。
また情報の網羅性を担保するための工夫もしています。dbtはGitHubにPRした際にCIを実行することができ、全てのカラムに対しdescriptionが定義されてるかテストしています。
更にSQLで整形する際、テーブル情報にサンプルクエリのリンクを結合したり、データセットに対し推奨度を付与するなどし、活用しやすくしています。

データカタログ導入によって得られた成果、解決できた課題

データカタログを導入後、新たにjoinしてくれたデータアナリストのオンボーディングに活用しました。
入社直後、簡単なデータ集計を担当してもらいましたが、必要なテーブルをデータカタログから判断することができており、データ理解へのハードルを大きく下げることができました。
また、データへのアクセス性の向上により、開発者がデータ調査時にBigQueryをこれまでより活用するようになり、横断的なデータアクセスが必要な場面においての問い合わせ対応のスピードが向上しました。

著者

Data Platform / 三河内 拓也 @i_am_miko__

株式会社エブリー

事業内容

エブリーは、日本が抱える「食」「子育て」「地方創生」の3つの大きな課題に向き合っており、「DELISH KITCHEN」をはじめ「トモニテ」「TIMELINE」と3つの動画メディアプラットフォームを運営しています。そうしたメディアやプロダクトに蓄積される膨大なデータとテクノロジーを活用し、"暮らし"と"企業"をアップデートしていくことを目指していて、中でも、ユーザー/メーカー/小売りの三者をつなぐプラットフォームである「リテールメディア」の構築は今後の成長戦略の柱と位置付けています。

データカタログ導入の背景

今までのDELISH KITCHEN事業では、データの増加に伴い把握が困難になっていました。
基本的なログだけでも600件以上のテーブルがあり、派生するテーブルも含めると膨大な数のテーブルを管理しています。またこれらのテーブルに関するドキュメントが整備できておらず、管理が属人化しており、全てを把握するには途方もなく時間のかかる状態でした。

特にデータ活用する際には、下記3点が不明瞭な事が大きな課題になっていました。

1. 必要なデータがどこにあるか
2. このデータは何なのか
3. どのように使えばよいのか

そこで、以下の機能をもつデータカタログを導入することで上記の課題を解決できると考え、導入に至りました。
1. データのドキュメント化、タグ付け 2. 1を利用した柔軟な検索 3. リネージ機能によるデータの流れの把握

### アーキテクチャ図

データカタログツール(OpenMetadata)の導入・活用の工夫ポイント

前提として、OpenMetadataは導入したものの完全に活用が出来ている状態ではなく、現在も試行錯誤の途中である状態です。

データカタログ導入で意識した点は、下記の2点です。

1. データ基盤で利用しているツールと繋ぎ込めるか
2. エンジニア以外でも利用可能か(使いやすいか)

そこで、2つのOSSを試験導入して比較をしました。

1. DataHub
2. OpenMetadata

基本的な機能については、どちらも不足しているものはない状態でした。
しかし、DataHubでのデータソースの繋ぎこみに関して、Databricks、Redashとの接続は問題ありませんでしたがTreasure Data (Presto)だけ上手く接続ができませんでした。

一方のOpenMetadataでは、必要なリソースすべての接続に成功しました。またOpenMetadataはk8s以外でのデプロイが可能であることが分かり、社内ではEKSよりもECSでのサーバー運用ナレッジが多くあったこと、その他UIや検索が使いやすかった為、結果としてOpenMetadataを導入するに至りました。

データカタログ導入によって得られた成果、解決できた課題

データの情報が一元的に閲覧/検索可能になったことで「どのデータがどこにおいてあるのか」「データが何を表しているのかが分からない」といった課題が解決されました。

データを業務上メインで扱うデータエンジニア・データサイエンティストに対しては、新たな分析軸の立案や新規参入者へのデータ理解コストの削減に繋がっている実感があります。一方で会社全体では、未だデータに対する認知負荷が下がるまでの浸透ができていない状態です。今後も職種の垣根を超えてデータ利用が促進されるよう、データカタログの整備を継続していきたいです。

著者

開発本部 CTO室 データ&AI リーダー吉田

株式会社Luup

事業内容

電動マイクロモビリティのシェアサービス「LUUP」を提供しています。展開ポート数は10,000(2024/10時点)を超え、ユーザー向けアプリや社内向けアプリ、外部データなど様々なデータを組み合わせ、日々の意思決定に活用しています。

データカタログ導入の背景

Luupでは、BIツールにはRedash、DataWarehouseにはBigQueryを採用しています。そのためデータ抽出にはSQLスキルが必須です。
その上で、以下のような情報が載っているドキュメントを用意することは必須だと思いました。

1. どこにどういう形で欲しいデータが保存されているか
2. どのデータが正確なのか
3. わからない時、だれに聞けばいいのか(作成者は誰か)
4. 同じ目的で作成されたテーブルが存在しているか
5. どれくらいの頻度、時間でデータが更新されているか

Luupでは、Redashでクエリを書く非エンジニアが多いのですが、BigQueryに保存されている内容がRedashからは見えないため、データカタログに存在している情報が重要になってきます。
以上の理由により、データカタログ導入を決定しました。

アーキテクチャ図

データカタログツール(dbt docs)の導入・活用の工夫ポイント

ツールの要件としては以下6つをポイントに選定しました。

1. シンプルなUI
2. テキスト検索できる
3. 非エンジニアでも使える
4. アクセス管理が容易
5. コード管理できる(APIが提供されているか)
6. カスタマイズ性豊富

最初の実装ではツールに「Notion」を採用し、より開発の効率性を求め「dbt docs」への切り替えを行なっています。

より詳細に知りたい方は以下の記事を参照ください。
データカタログにNotionを選択した理由
データカタログをNotionからdbt docsに切り替えた話

データカタログ導入によって得られた成果、解決できた課題

データカタログを導入することにより、主に工数の大幅削減につながりました。

• 欲しいデータがどこにあるかわかるようになったことで、「このデータある？どこにある？このカラムの定義何？」というコミュニケーションが大幅に削減された
  
• データカタログを手動作成から完全自動化することでエンジニア側の工数を削減しつつ、カタログを担保することができるようになった
  

とはいえ、2024/03時点でカバーできているデータはデータエンジニアリングチームが管理しているデータに過ぎず、BigQueryに流していないデータやDWH、Datamart化していないものについてはカバーできていません。
今後はOpenMetadata等の導入も視野にいれ、社内全体のデータがカバーできるようなデータカタログを用意していく予定です。

著者

COO室 dataチーム DataEngineering 河野匠真 (コウノタクマ) @matako1124

Sansan株式会社

事業内容

弊社は営業DXサービス「Sansan」やインボイス管理サービス「Bill One」、契約データベース「Contract One」などを展開しています。 私の所属しているArchitectグループでは各プロダクトで分離されたデータベースやプロダクトデータ以外の営業活動情報や人事情報などを集約した全社横断データ基盤の開発とそれらを利用したデータ利活用の推進を行っています。

データカタログ導入の背景

全社横断データ基盤ではDWH製品としてBigQueryを採用し、そこにデータを蓄積&データマートを提供しています。 基本的には連携元のデータ定義情報や利用用途の制約などをテーブルレベル/カラムレベルのDescriptionに記載していましたが、経緯や背景といった詳細内容までは記載できませんでした。
そのため、社内のアナリストや研究開発員がデータを利用する際に、データ提供者への仕様の問い合わせが高頻度で発生していました。 また、過去の分析から得られた利用者目線の知見もストック情報として存在していましたが、各利用者の組織内のナレッジとして閉じてしまい、共有されていないという課題もありました。

アーキテクチャ図

データカタログツール(dbt docs)の導入・活用の工夫ポイント

この課題を解決すべく、データカタログを導入することになりました。 要件は優先度の高いものから

1. データ提供者/利用者双方が編集可能である
2. 非エンジニアでも使いやすいUIを備えている
3. なるべく低コストで実現できる
4. Description記載内容以上の複雑な内容も記載可能である

として、まずはデータカタログ製品を導入せずに、スプレッドシートでデータカタログを提供する仕組みの実装を行いました。 機能としてはシンプルで、CloudComposerのジョブでINFORMATION_SCHEMAからテーブルのメタ情報を取得し、それを基にスプレッドシートを更新します。 また、テーブル/カラムでの変更が発生した場合はそれを検知して、行をグレーアウトするという処理も加えています。 利用者が得たナレッジを自由記述し共有するための列も存在しており、それらの情報は揮発しないように更新処理を行っています。

データカタログ導入によって得られた成果、解決できた課題

上記の自作データカタログを社内のデータ利用者に広く公開した結果、データ利用者の持っていた複雑なナレッジの記載や各組織に持っていたストック情報へのリンクを貼るなど、メタデータの共有が活発になりました。
今後の展望としては、最近、全社横断データ基盤にdbtを導入したこともあり、そちらにデータカタログとしての機能を寄せることを検討しています。 一方でdbt単体では、誰でもドキュメントを拡充することが難しい(yamlを書いたりPRを出したりとアナリストや非エンジニアの方には一定のハードルがある)ため、良い仕組みを模索しています。

著者

技術本部 研究開発部 Architectグループ　中村 崚

株式会社ZOZO

事業内容

ファッションEC「ZOZOTOWN」やファッションコーディネートアプリ「WEAR」の開発・運営を行っています。データ基盤を意思決定のための分析に使用しているのはもちろんのこと、検索パーソナライズ化や画像を元にした類似商品検索などのエンドユーザー向けの機能開発の領域でもデータ基盤を活用しています。

データカタログ導入の背景

ZOZOTOWNは2024年12月に誕生から20周年を迎える歴史のあるサービスです。そのため数多くのテーブルが存在しますが、テーブル定義書の管理が手動であるために情報が古い・ER図が画像で保存されているために検索性が悪いなどの課題がありました。
既存のツールの導入も検討しましたが、図の描画機能が弱い・仮想外部キー(※)に対応していないといった我々のニーズを満たさない点がありましたので、データカタログツールを内製することに決めました。
※ 仮想外部キーとはテーブル定義上は外部キー制約が設定されていないものの実質的には外部キーのような関係を持った列です。

アーキテクチャ図

データカタログ（内製ツール）導入・活用の工夫ポイント

仮想外部キーの推定が特に工夫したポイントです。外部キー制約は設定されていないため、INFORMATION_SCHEMAなどのメタデータテーブルはこの問題解決には適していません。そのためSQL Serverで実際に実行されたSQL文を解析することで仮想外部キーを推定しました。その後に1対1、1対多などのカーディナリティも実際にテーブルに格納されているデータを調査して自動的に推定しています。
また、カラムの説明はSQL Serverのsys.extended_propertiesから取得するなど、可能な限り情報を自動的に取得して人の手によるデータの入力の手間を減らす工夫を行いました。

データカタログ導入によって得られた成果、解決できた課題

情報が手動で更新されているために情報が古い・管理更新のための工数がかかるといった当初の問題はデータカタログの導入によって解消されました。
ZOZOのデータ基盤はエンジニアやアナリストだけのものではなく、全社員に対して開放されています。実際にビジネス職が数百行のクエリを書くことも珍しくありません。このような環境の中で全社員がデータ定義を確認できるカタログを導入できたことは、全社的なデータリテラシーの向上という点で組織全体のデータ活用を強く前に押し進める一因になったと確信しています。ビッグデータを意思決定のための分析で利用するだけにとどまらせず、数多くのエンドユーザー向け機能をリリースできている強いデータ組織を陰で支える存在です。

著者

ZOZOTOWN開発本部ZOZOTOWN開発3部バックエンドリプレイスブロック山本健太
技術本部ML・データ部データ基盤ブロック塩崎健弘