この記事は株式会社エス・エム・エス Advent Calendar 2023の6日目の記事です。
エス・エム・エス BPR推進部 カスタマーデータチームの橘と申します。
私は「ナース人材バンク」等のキャリア事業を中心に、社内のデータ活用の推進、データ基盤の開発運用を担当する、データエンジニアの役割を担っています。 今回は私の組織におけるデータエンジニアの役割を簡単にご紹介し、データ活用の推進のために進めている活動の1例として、データカタログの整備についてご紹介します！
データエンジニアとは
そもそもデータエンジニアとはどういう役割でしょうか？
一言でいうと、社内のデータ活用に携わるITエンジニアです。ビジネスの意思決定を決めるデータ活用の基盤として、データ分析基盤があります。そのデータ分析基盤はデータの収集、蓄積、加工、可視化、出力などの機能を持っています。また、データ分析基盤を活用するためのデータの整理、カタログ化、セキュリティの担保等も必要になってきます。これらの開発・運用に携わるのが私たちのチームにおけるデータエンジニアとなります。
私たちキャリア横断開発グループではGoogle Cloud を中心にデータ分析基盤を構築しております。以下の記事でもご紹介しておりますので、合わせてご覧ください。
キャリア事業におけるデータ活用
エス・エム・エスのキャリア事業のみに限定しても、「ナース人材バンク」や「カイゴジョブ」等の複数サービスを展開しており、非常にたくさんの種類のデータが、あちこちに存在します。 これらのデータを1つのデータストレージ、具体的にはGoogle Cloud のBigQuery に連携して、データを活用できるようにしています。 私たちは貯めたデータをもとに、マーケターからヒアリングした課題の解決に向けて、データの出力や可視化、分析を進めています。 とはいえ、単に条件を指定したデータの出力や単純な可視化等は、データエンジニアチームを介すことで実装完了までのリードタイムが生じたり、依頼内容と開発者の認識の祖語が発生したりする問題もあります。そのため、マーケター自らが収集したデータを探して、活用していくという、“データの民主化”に課題がありました。
キャリア事業というドメインのデータ分析基盤は、データメッシュという考え方における、“セルフサービス型データプラットフォーム”を目指してます。データエンジニアに依存せず、マーケター達が自律的にデータを取り扱えるようなデータ基盤を構築し、データカタログ、データマート、BIツール等の各ツールを活用して、データの分析を行う世界を目指しています。 今回はそのうちのデータカタログというプロダクトに焦点を当ててご紹介します。
データカタログの整備
前置きが長くなりましたが、データカタログについての話に入ります。 そもそもデータカタログとは何でしょうか？その名の通り、“データのカタログ”になります。データのメタデータ、ビジネス要件などをドキュメント化して、検索ができるカタログのことを指します。 私たちのデータ分析基盤では、目的に応じた大量のテーブルが存在し、各テーブルには大量の項目が存在しています。 セルフサービス型データプラットフォームは、こういった大量のデータを分析するにあたって、データを発見しやすく、アクセスしやすい環境でなくてはなりません。そのため、データ分析基盤の各データのメタデータをもとに、データカタログを作成する必要があります。
私達のデータ分析基盤(今回はGoogle Cloud のデータウェアハウス、BigQuery 内のデータに限定しています)におけるデータカタログの要件は以下としています。
- 分析を始めたい人がデータカタログにすぐにアクセスできる
- 各データセット、テーブル、項目の定義やビジネス要件が整理されている
- データカタログを検索できる
- メタデータの収集は自動化できる
- ビジネス要件を継続してメンテナンスできる
- これらの仕組みが一か所に集約され、データカタログを起点にデータへのアクセスが容易となっている
単純にメタデータの収集であれば、Google Cloud にも、 Data Catalog という製品があります。 しかし私たちは上記の要件を満たすために、Googleスプレッドシートで簡易的なものを作成して運用しています。 今回はそのGoogleスプレッドシートで作成したデータカタログついてご紹介します。
実際のデータカタログ
こちらが実際のGoogleスプレッドシート上のデータカタログになります。 実際にデータ一覧をお見せすることはできないので、Cloud Loggingからエクスポートしている、App Engineのnginxのリクエストをテストデータとして表示しています。（テストデータのため、論理名や説明は省略してます）
シートの構造は以下の通りです。
- README
- データカタログの使い方を記載したシートです。
- データセット一覧
- 分析用プロジェクト内の、BigQuery データセットの一覧や説明を記載したシートです。
- テーブル一覧
- 分析用プロジェクト内の、BigQuery テーブル（Viewやテーブル関数なども含む）の一覧や説明を記載したシートです。
- 利用者は主にこのシートを参照します。テーブル一覧のみでは分析用途として事足りないので、Google Apps Scriptを用いて、上記キャプチャのように、選択中のセルのテーブルで、項目一覧シートの情報を検索し、結果をモーダルで表示する機能を用意しています。テーブルの情報、各項目の情報を一覧で見れたり、SQLやテーブルスキーマファイルの自動生成などといった機能も用意しています。
- 項目一覧
- 分析用プロジェクト内の、BigQuery テーブル全ての項目の一覧や説明を記載したシートです。
データカタログの更新方法
データカタログの更新方法は、
- BigQuery のメタデータ取得による自動更新
- データエンジニアによるビジネス要件の手動入力
の2パターンがあります。
これらのアーキテクチャを簡単にまとめますと以下のようになります。
BigQuery のメタデータ取得による自動更新
項目名、型、更新日時や件数などの情報はBigQuery のメタデータにあるため、SQLで取得することができます。 以下のようなSQLを実行し、自分たちのデータカタログの各シートに出力できる形に整形して、日次のバッチ処理でスプレッドシートに自動出力される仕組みです。
1.BigQuery データセット一覧を取得
SELECT * FROM INFORMATION_SCHEMA.SCHEMATA
2.取得したデータセット毎に、BigQuery テーブル一覧とメタデータを取得(それぞれのクエリで取得できる情報は異なります)
SELECT * FROM [データセットID].INFORMATION_SCHEMA.TABLES
SELECT * FROM [データセットID].__TABLES__
3.取得したデータセット毎に、BigQuery の全テーブルの項目一覧と、メタデータを取得(それぞれのクエリで取得できる情報は異なります)
SELECT * FROM [データセットID].INFORMATION_SCHEMA.COLUMNS
SELECT * FROM [データセットID].INFORMATION_SCHEMA.COLUMN_FIELD_PATHS
データエンジニアによるビジネス要件の手動入力
テーブルや各項目の説明（集計項目であれば集計ロジックなど）、更新頻度など、メタデータで取得できない情報については、テーブルを実装したデータエンジニアが手動で入力する必要があります。また、不足している情報があればスプレッドシートの編集権限を持つメンバーが更新できるので、入力インターフェースとして準備が簡単だったGoogleスプレッドシートを採用しています。 とはいえ、メタデータ取得は自動的にされているものの、ビジネス要件が入力されておらず、カタログとして情報が不足してしまうことも多々あります。そのため、定期的にデータカタログ上で情報が不足している箇所を検知して、Slackに通知し、データエンジニアに入力を促すなどしています。データを収集してテーブルとして公開するまでが仕事ではなく、実際に分析するユーザーがデータにアクセスしやすい環境づくりを心掛けています。
まとめ
以上、私たちのチームにおけるデータカタログについてご紹介しました。 実際に分析をするマーケターや、開発担当のメンバーからも、
「BigQueryのデータを見るときはまずこのデータカタログから見てます！」
「テーブルをリリースすると項目定義が自動で連携されるから便利！」
といった声が上がっています。
一方で、利用範囲が広がるにつれ、データのオーナー情報、集計ロジックを直接見れるGitHubのURLも載せてほしいなど、データカタログとして管理していきたいビジネス要件が増えてきて対応しきれない部分もあるのが課題としてあります。 社内のデータの活用を推進する立場として、こういったドキュメントの整備も怠ることなく進めて行きたいと考えております。
エス・エム・エスは新しいメンバーを募集しています。 特に私たちのチームでは、データ分析・データ活用の推進に関わるデータエンジニアを募集しています。 今回紹介したデータカタログは、データエンジニアの仕事のほんの一例のご紹介にすぎません。 弊社の事業に携わってみたい方、興味のある方は、ぜひこちらのページものぞいてみてください。
