第15回の「Reverse ETL」に続き、今回の勉強会では「データカタログ」について深掘りして学んでいきます。 データカタログとは、データ分析基盤に存在する様々なメタデータをカタログのように整理し、検索・参照を可能にするものです。実際にデータカタログを運用されている企業のご担当者をお呼びし、事例をお話しいただきます。
今回第16回は「データカタログ入門」と題して、3名の方々からデータカタログに求められるものやデータカタログをより活用していくためにどういったことが必要なのかを学んでいきます。
1つ目・2つ目の講演では、LINE株式会社と株式会社ZOZOで活躍されているエンジニアの方々をお呼びし、膨大なデータを扱う社内のデータ基盤でデータカタログを内製したお話をしていただきました。
そして3つ目の講演では、atama plus株式会社のデータサイエンティストの方から、実際にデータカタログを社内で使ってもらうために行った活動をお話しいただきました。
当日の発表内容はこちらになります。
講演「LINEのData Platformにおけるデータ利活用を促進するためのData Catalogの開発」
出典：islandshinji、「LINEのData Platformにおけるデータ利活用を促進するためのData Catalogの開発」、https://speakerdeck.com/line_developers/introduction-to-line-in-house-data-catalog より
島村 信嗣 氏
LINE株式会社 Data Platform室 IU Devチーム ソフトウェアエンジニア
LINE社はグローバルで約2億MAUを持つコミュニケーションアプリをはじめとした多数サービスを展開しています。この多数のサービスから生成されるデータには、多様な活用ニーズが存在します。 私たちは、この多様なニーズに応えるために、Data Catalogを内製しました。 本発表では、Data Lienageを中心とした提供機能でどのようにユーザーのデータ理解を促進し、業務改善を実現したかご紹介します。
Twitterのアカウント
初めにLINEが内製しているデータカタログについて簡単にお話しいただきました。
多様なニーズに応えるためにデータカタログの内製
島村 信嗣氏：「PlatformはLINEが提供しているあらゆるサービスを集積し、統合的なデータ分析環境を構築しています。データ分析や機械学習、Service Planningなどの幅広い領域に応えるために、厳密な権限管理をすることでデータを全社に公開し、データの民主化を進めています。
データ関連業務の効率化のために、アクセスコントロールであったりメタデータ管理・クエリの作成実行等の機能を提供おり、社内の多様なデータ利活用のニーズに応えるために、データカタログの内製しています。」
次にLINEのデータ利活用に関する課題と解決のアプローチをお話しいただきました。
Data Platformにおけるデータの流れ
島村 信嗣氏：「まずデータを集積するIngest、データ運用の形に合うようにデータを加工するProcess、意思決定やサービス開発に役立てるためにデータを利用しやすいように提供するProcessがあります。
LINEのData Platformの特徴として、データ量・種類・活用の規模が大きいことが挙げられ、データの規模に関しては4万のテーブルがあり、その中に400PBのデータが入っています。それらのデータは毎日15万のジョブで生成されて、日々増え続けています。
また、活用の規模に関しては、LINEの企業理念として「Always Data-driven」があるので、利用者がデータエンジニアなどの専門家からサービスプランナーなどの非専門家まで幅広いので、さまざまなツールから利用されます。」
このような社内背景から直面した利活用に関する課題についてお話いただきました。
データドリブンカンパニーであるが故の課題
島村 信嗣氏：「LINEでは全社員がデータユーザーのため、データの専門家でないユーザーも自分自身でデータ分析等のためにデータの理解を深める必要があります。そのため、活用の規模が膨大でデータの理解が困難になります。
データの使用者や関係者、データを変換するユーザーとそのプロセスやデータ同士の関係性を理解することを「データ理解」と言いますが、データを活用するにおいてはそういった情報が重要になります。」
そういった課題を解決するために採用した2つの機能を紹介したいただきました。
データパイプラインを適切に管理するために
島村 信嗣氏：「Data Lineageとは、ある対象のデータについて、データが生成されてから現在に至るまでの経路や、経路上で行われた変更を表現したものです。
これによりデータセット同士の関係性やデータを変換するユーザーとプロセスの把握の可視化が簡単になります。」
Data Lineageの提供機能について
島村 信嗣氏：「データカタログで提供している画面になりますが、選択しているテーブルがあるときに、緑の線がテーブルの生成元（データがどのように生成されたか）を表しています。オレンジの線はデータがどのように利用されているのかを表しています。
歯車の部分がプロセスとなっており、実行したHiveやSparkのクエリが表示されるようになっています。また選択したファイルの管理者やパーティションなどで重要になってくるメタデータを合わせて表示し、詳細な関係性を知りたい場合には、Column Lineageでカラムの関係性を表示することができます。
さらに、Dashboard Lineageではテーブルがどのようなレポートで利用されているのかが分かり、リンクでそれを表示できます。これによって、関連するテーブルや管理者が利用する情報・レポートを一つのサービス上で効率よく確認できます。」
次に、2つ目の機能であるAffected Accountsについて紹介していただきました。
Affected Accountsの提供機能について
島村 信嗣氏：「Authorized Accountsではテーブルにアクセス権限があるユーザーを表示し、提供する画面上では、権限があるテーブルに対して、権限のあるアカウントを表示します。また、Access Acountsは最近アクセスしたユーザーを表示できます。
上の2つをまとめて表示する機能としてUsage Summaryがあります。よく利用しているユーザーや権限が与えられているユーザー、どれだけ実行されたかなどの情報を表示でき、一目でそのテーブルがどれだけ利用されているかがわかるようになっています。」
今まで説明した機能がどのように実現されているのかをお話いただきました。
内製データカタログの詳細
島村 信嗣氏：「まず全体像として、内製データカタログの構成図はSource DataがData Ingestionを通ってデータカタログに流れていきます。Source DataはHiveのテーブルにデータを入れているので、Hive MetaStoreにテーブルやデータベースの詳細が入っています。
また、ログなどのクエリエンジンとして、内部Data Platformで提供しているHive、Sparkがログを収集しています。BIツールとしてTableauや内製のツールを使用しており、これらのデータをStreamingやBatchを経由してデータカタログに入ってくる構成になっています。
Apache Atlasはデータカタログの機能を持っており、よりユースケースにとってデータをまとめて提供して、エクペリンスを上げるために内製のデータカタログを作っています。」
次に、具体的な機能の実現方法についてお話いただきました。
テーブル・Column Lineageの関係性
島村 信嗣氏：「Atlas Hookを各クエリエンジンに設置しており、Atlas Hookはクエリが実行される度にStreamingを通して、AtlasにLineageを登録してくれます。内製データカタログとしてはLinaegeの情報や権限の情報、パーティションを集約して業務プロセスに沿ったUI/UXを提供してくれます。
Atlasを使う上で、テーブル数やジョブ数の多さ等に起因するパフォーマンス問題が発生しても、不要なデータを自動で削減して改善するような仕組みをとっています。」
Dashboard LineageとAffected Accountsの実現方法
島村 信嗣氏：「Dashboard Lineageは、BatchjobでBIツールからレポートを取得し、レポート内のSQLをパースしてテーブルと紐付けて保存します。これの苦労した点としては、複数のBIツールに対応しているということで、データ構造の違いをうまく抽象化して統一的なデータ構造で保存します。
Affected Accountsについては、Authorized AccountsとAccess Accountsの2つの機能があり、Authorized Accountsは、権限データ情報については内製データカタログでデータの権限管理を行なっているため、権限情報を表記して利用しています。Access Accountsは、各クエリエンジンのログを利用して、各クエリにエンジンにhookするモジュールを設置して、そのモジュールがクエリが実行されるたびにストリーミングを通して、hadoopにログを保存します。保存されたジョブをBatchで定期的に収集して、データカタログに保存することで実現しています。」
Data Lineage・Affected Accountsなどの提供機能の活用事例についてもお話していただきました。
Data Lineageによって業務効率が大幅に向上
島村 信嗣氏：「Data Lineageの活用事例は3つあります。データエンジニアにおいてはテーブルのカラムの変更をする際に、どういったユーザーに影響があるのかが簡単にわかるようになりました。
また、ジョブの失敗時のデバックである、ETLジョブが失敗した際の原因調査において、どのテーブルが原因なのかが簡単に確認できるようになりました。Lineageを提供する以前はデータエンジニアはジョブのソースコードを1つずつ確認して、その中で使っているテーブルを特定しメタデータを一つずつ確認していく、といったように様々なツール間を行き来して確認していました。
しかし、内製データカタログを使うことで対応工数が大幅に削減し、業務効率が上がりました。
また、データプランナーのようなデータにあまり詳しくない人にとっては、テーブルがどんなレポートで使われているのかを確認して、レポートの中身を見ることでどうやってデータを使えばいいのかも分かるようになりました。
Affected Accountsの他の活用事例として、データ管理者がUsage Summaryから不要なデータかをすぐに確認できるようになりました。データサイエンティストにとってはたくさんのデータを活用する中で、どのデータがよく使われているかわかり、利用すべきデータの検討が付けられます。また、データガバナーにとってはデータに問題があったときに、権限を持った人やアクセスした人に簡単にアナウンスできます。」
データカタログを内製した今、今後の活動についてもお話していただきました。
島村 信嗣氏：「内製データカタログは広く活用されているので、引き続き開発を続けていきます。その中で、今後の活動のキーワードとして「メタデータの更なる活用」を掲げています。
Query Editorを実行するクエリがアクセスするデータの統計情報に応じて、クエリを実行するのに必要なクエリエンジンを選択できるように向上させていき、提供している検索機能のスコアをメタデータを使ってチューニングをし、よりユーザーが求める結果が上位に来るようにしていきます。
また、Metadata Everywhereでは、UIだけでなく、APIを強化して、BIツール等のデータカタログ以外のツールでもメタデータを活用することを考えています。」
最後に本日の内容をまとめていただきました。
島村 信嗣氏：「内製データカタログによってLINEの「データ管理」を促進し、業務改善を実現することができました。収集した各種メタデータを、業務プロセスに沿って必要な情報に触れられるように、UI・UXを提供するのが重要だと考えています。
また、データの規模が大きくなるとメタデータ収集・表示において、パフォーマンスの維持やDataPlatformに負荷をかけない等、技術的にチャレンジングな課題を解決する必要があります。」
講演「ZOZOのデータカタログ内製事例と、データカタログを整え続けるための仕組みづくりについて」
引用：やまちょふ、「ZOZOのデータカタログ内製事例と、データカタログを整え続けるための仕組みづくりについて」、https://speakerdeck.com/yamamoto7/data-engineering-stydy-16-kenta-yamamoto より
山本 健太 氏
株式会社ZOZO ZOZOTOWN開発本部・バックエンド1ブロック
ZOZOでは膨大なデータを保有しているが、データベースに関する資料があまり整っていませんでした。そこで、カタログシステムを内製しました。既存ツールを利用しなかった理由やシステムに組み込んだロジック、活用事例、データカタログを整え続けるための取り組みについて紹介させていただきます。
githubのアカウント
ZOZOで内製したデータカタログについて、当時の背景を踏まえてお話いただきました。
山本 健太氏：「当時、ZOZOでは元々テーブル定義書、ER図がありましたが、厳密な運用ルールがなかったり、完全手動更新して管理していた程度でした。
ZOZOでは大量のテーブル、カラムを抱えているので、手動では更新しきれないような更新漏れが大量にあり、こういった問題を解決するには更新を自動で行う必要があると考えてました。」
解決すべき課題
山本 健太氏：「解決すべき課題は細かく3つありました。1つ目は「テーブル定義書・ER図の情報が古い」ということです。これはメタデータの取り込み機能を持っているような既存のツールで解決可能できます。
２点目の「テーブル同士のつながりが複雑で不明瞭」という問題は、外部キー制約が正しく貼られていれば、既存ツールで解決可能だと分かりましたが、ZOZOのDBには、ほとんど外部キー制約が貼られておらず、リレーションを持っているテーブル同士でも、その環境をメタデータから認識できないものが大量にありました。
こういった親子関係を特定するためには、リレーションを持つテーブルのペアやどちらかが親でどちらかが子かを推定する必要があり、既存製品やツールでは行ってくれるものが中々ありませんでした。
解決すべき3つ目の課題は、「テーブル数が増大なのでER図の出力形式を工夫したい」というもので、こういった諸々の課題を解決しようと思ったら、一旦全て内製した方が楽だと考え、内製を選択しました。」
実際のプロジェクト進行
山本 健太氏：「2020年の8月に発案してから、約1年で本番公開まで辿り着き、公開の2ヶ月後にdescriptionなどの人力の入力作業が大量にあったので、そういった部分に関しては各チームに頭を下げて入力してもらいました。また親子関係などのロジックで推定できる部分に関しては極力自動で推定するようにしました。」
そこからどのようなシステムを内製したのかをお話していただきました。
山本 健太氏：「大きく2つのシステムを内製しました。ZOZOTOWNのDBサーバーとデータを閲覧する人やデータのメタデータ情報を追加する人と、ER図を閲覧・作成する人の間にある2つのアプリケーションを内製しました。
1つ目がデータカタログやER図を閲覧作成できるアプリケーションで、もう1つがメタ抽出や各種推定を行うバッチアプリケーションです。
各DBごとにER図やテーブル定義書を確認できるようになっています。データカタログ上でも情報が入力できるので、データカタログ上で登録された情報と実データに関しては分けて閲覧できるようになっています。推定データ、イレイション・カーディナリティーの情報がデータカタログ上では閲覧できるになっており、推定データ・実データの情報を分けて描画するようにしていて、外部キー制約に基づく実際のフォーリンキーや推定データ仮想的なフォリンキーは色分け表示するようにしています。
ER図の描画ロジックであったり、Webサイト側のロジックには触れていないが、JavaScriptでHTMLのDOMを入ってER図を出力する形になっています。HTMLのDOMであれば、テーブル数が大量であっても描写できます。また、ER図が誰でも作成が可能で、テーブルを選ぶとER図が生成されます。」
クエリを交えながら、推定ロジックについて解説していただきました。
リレーションを持つテーブルのペアの推定
山本 健太氏：「リレーションを持つテーブルのペアを推定は、本番環境で実際に利用されるSQLのクエリを解析する方法で推定を行います。
例えば、本番環境ではJOINで結ばれているカラムがあればペアの候補とし、2つのカラムのうちどちらかがPKであればリレーションを持つものとして、仮想的な外部キー制約をデータカタログ上で登録します。
実際のユースケースベースで親子関係の推定を行なっていますが、ZOZOではこのやり方でほぼ網羅できていたので、定期的に実施することで仮想的外部キーを付与したり外したりしています。」
レコードが１件以上紐づくのか、また０件なのかの推定
山本 健太氏：「レコードが1件以上紐づくのか、また0件なのかの推定は、解析用のクエリを投げた結果から判断します。”テーブル1″に対して、”テーブル2″は必ず1件以上紐づくのか否かを推定し、結果が返ってきたら、テーブル2はテーブル1に1件以上紐づく事が推定されます。
クエリの結果が0行だとしても、1件以上紐づいているということだけなので、今後もずっと必ず1件以上紐づくという断定はできないことに注意する必要があります。」
対象の親子関係が１：１なのか、１：Nなのかの推定
山本 健太氏：「推定方法は解析用のクエリを投げて、その結果から推定します。結果が返ってきたら、テーブル1とテーブル2は1：N（多数）で対応しており、そうでなければ、1：1の可能性もあります。
カラムのペアがプライマリーキー：プライマリーキーなら、必ず1：1と断定できますが、相手がプライマリーキーでない場合は断定はせずに掲載することにしています。
今まで紹介したロジックが正しく機能する背景には、データの整合性をチェックするロジックが裏で動いているので、推定ロジックの信憑性が高まっています。
紹介したロジックを定期実行することで、データカタログ上の情報を常にアップデートしています。」
データカタログの活用事例についてもお話していただきました。
山本 健太氏：「レプリケーション情報や、テーブル定義の確認などのライトな活用や、今まで資料化が難しかったリレーション情報の確認や情報共有の際に関連テーブルでER図を作成して共有しています。
今後も正しい情報が自動で更新されていくためにはメタデータの入力などのルール作りが必要になってくると考えています。当たり前かもしれませんが、descriptionの入力を必須にしたり、外部キー制約登録を推奨したり、SQLSever特有の問題ではあるが、和訳語をdescriptionに入れておいてもらって、バッチシステム側で仮想enumとしておくことなどが必要になります。」
講演：「メタデータは地味だが役に立つ」
内藤 純 氏
atama plus株式会社 データサイエンティスト
atama plus株式会社では最近メタデータ管理基盤を正式に導入しました。データエンジニアが不在の中で、どのような課題意識から導入を意思決定し、どのように普及させたのか、また結果としてどうのような効果があったのかを、具体的な事例として紹介します。
twitterのアカウント
はじめに内藤氏が所属されているatama plus株式会社についてお話していただきました。
内藤 純氏：「atama plus株式会社は2017年創立で5年半を迎え、社員数は200名程度で、事業は教育プロダクトの開発をおこなっております。
教育のプロダクトを具体的にお話しすると、タブレットで扱うようなデジタル教材を作っており、特徴として生徒の学習ログを用いて学習をパーソナライズし、弱点を分析してレコメンドしています。」
atama plusのビジネスモデル
内藤 純氏：「atama plusは直接生徒に使ってもらうのではなく、一旦塾に使ってもらい、塾を通して生徒に使ってもらうビジネスモデル、いわゆるBtoBtoCになっています。」
atama plusはデータがコアな位置付けなため、データを使うことは社内でも行われていましたが、なぜメタデータ管理が必要になったのでしょうか。
atama plusにおけるデータ基盤の実態
内藤 純氏：「一見、データ基盤として確立していますが、その場限りの分析がメインになっていて、データ基盤はあるにはあるがほぼ未開の状態でした。」
データ活用基盤の実情
内藤 純氏：「BigQueryが導入されていましたが、社内の利用者数は数名程度で、転送料金の方がコストが高い状態でした。BigQueryの中にDWHが作られていましたが、数名の分析者が使うものという認識でした。
データのドメイン知識も一部の人に属人化していたので、分析したくても何がどこにあるかわからないという状況で、最も深刻なことは、こういった現状に問題意識が欠如していたり、こういったようにやっていこうといった音頭を取ってくれるデータエンジニアがいませんでした。」
当時内藤氏が思っていたことをお話しいただきました。
内藤 純氏：「当時はデータ活用をするためにはデータ基盤をもっと整えるべきで、書き捨てのクエリ、アドホックなエクセル分析はやめてちゃんとナレッジを蓄積し、誰かに属人化していると、スケール化しないので標準化すべきとも考えていました。
しかし、“べき論”だけ言っていて一年間何も変わらなかったので、やる人がいないのだったら、自分がやるしかないと考えました。」
イケてるデータドリブンカンパニーになるためにやったこと
内藤 純氏：「元々BigQueryがありましたが、数人しか使っていなかったので、何故使わないのかを聞いて回りました。エンジニアやUXの人に聞いてみると、いくつかの共通点がありました。
3つ目までは各所で共通している点でしたが、4つ目以降はテクニカルな内容で、こういった問題を見ていくと、1〜3はメタデータ管理の仕組みで解決できそうだと考えました。
自社のデータ活用の特徴として、洗い替えをおこなっていたので、BigQueryのスキーマに直接書き込んでも、翌朝には消えてしまうという問題がありました。解決できそうなソリューションを探すと、さまざまなデータカタログをもつ製品があり、それを勉強しているうちにデータ管理を理解したようで、結局何を導入すればいいのかがわからなくなってしまいました。」
初心に立ち帰って要件の整理
内藤 純氏：「何をどこにあるか検索できるようにしたいという要件があったので、メタデータを全文検索できるようにする必要がありました。また、メタデータを誰が入力するかに関してはメタデータを専門に扱う人がいなかったので、全員が気軽に書き込めるようにすることも必要でした。
さらに、本番データベースがPostgreSQLでデータ基盤がBigQueryなので、両方に対応しているものを選択し、データエンジニアがいないので環境構築＋運用コストがほぼゼロなフルマネージドなものを選択する必要がありました。」
trocco®のデータカタログが最適解に
内藤 純氏：「探していると、trocco®が用件を完全に満たしたものをリリースするということを聞いて、当時はクローズドでありましたが、後に導入する運びとなりました。
次にソリューションを決めて、中身が空っぽな状態では社内の人は使ってくれないと思い、2人ぐらいで一気に初期入力を行いました。チームにデータを割り振って入力をしてもらうことも検討しましたが、やってくれるかわからない事とデータカタログの導入に遅れが生じると思い、振り分けは行いませんでした。」
社内の人にもっと使ってもらうために
内藤 純氏：「初期構築が終わっても社内ではまだ使われていないのが実情だったので、社内布教活動を行いました。社内布教活動をする際に意識したことは、非技術者に向けてメタデータの説明から始まり、なぜメタデータを管理しないといけないのかを記事を使いながら説明しました。
布教活動を進める中で、技術よりも「なぜ導入しないといけないのか」の説明を重視しました。さらに、一回布教活動しただけでは使われないと考えたので、「メタデータはデータ活用する上で役に立つ、メタデータを一つでも入力することは組織への貢献、同じ分析を繰り返すのはやめよう」ということを継続的に言い続けました。」
フィードバックを繰り返して、より使いやすいデータカタログに
内藤 純氏：「他にやって良かった事として、社内で使うにあたって足りない所・改善してほしい所は容赦無くtrocco®側にフィードバックを行い、迅速に対応してもらえました。」
データカタログを導入した結果をお話ししていただきました。
内藤 純氏：「結果として、こんなデータがないかと思ったときに探せるのがとても便利だという声や、最近入った人からはSQLが書けてもデータがどこにあるかわからないと困るので、自分で検索してデータを理解できるのがとても助かったなど、ポジティブな声が寄せられました。」
継続的な働きかけによってBQ・データカタログの利用率が大幅増加
出典：Data Engineering Study #16 「データカタログ入門」、https://youtu.be/1tBNmP7UY8w より
内藤 純氏：「atama plusのデータ基盤の利用者は2022年3月時点ではBigQueryでも10人程度だったが、9月には５倍近くにまで増え、データカタログの利用率は約80%になりました。
しかし、データ活用のバイブスが上がってきた中でも、自社はデータドリブンカンパニーになったかというと、そうではありませんでした。」
未だ残る課題とは
内藤 純氏：「利用率は増加したものの、DWHを活用できる人が少数で日頃からクエリを実行している人の割合は依然として少なく、いまだに属人化しているものもあります。社内にはデータエンジニアがいないので、データモデリングとかを真面目にやらないといけないが、自分の手には追えないので困っています。」
最後に、本日のまとめをしていただきました。
内藤 純氏：「伝えたかったことは3つあります。メタデータは地味ですが、役に立つ場面が後々出てきます。データを誰でも理解できる仕組みは活用促進においてとても重要です。ただ重要ではあるが、メタデータは地味なので、重要性は多くの人に伝わりづらく、なぜやるのかの文脈を非技術者にも伝わるレベルで丁寧に話すことが求められます。
あとは、メタデータをみんなで育てる意識を醸成していくのが重要で、誰かが入力してくれるだろうと考えるが、メタデータを一つ入れるだけでもチームへの貢献だと言い続けないと日頃からデータを入力していくことにはつながらないので、泥臭く発信していく必要があります。」
過去のData Engineering Studyのアーカイブ動画
Data Engineering Studyは月に1回程度のペースで、データエンジニア・データアナリストを中心としたデータに関わるすべての人に向けた勉強会を実施しております。
当日ライブ配信では、リアルタイムでいただいた質疑応答をしながらワイワイ楽しんでデータについて学んでおります。
過去のアーカイブもYoutube上にございますので、ぜひご覧ください。
https://www.youtube.com/@dataengineeringstudy6866/featured
また今回のDESでも言及がありましたが、弊社のtrocco®にはデータカタログ/データディスカバリー機能があり、Google BigQueryをベースとしたメタデータの自動作成・収集、メタデータ検索が可能なほか、ユーザーに対して各テーブルの情報を視覚的に共有することが可能で、これまで述べてきたデメリットを解消しつつ容易にデータカタログのシステムを整えることが可能です。
データカタログ導入の際はぜひご検討ください。
