Comment on page
データ基盤入門
このドキュメントの目的は Wantedly におけるデータ基盤の存在意義と構成要素を紹介し、データを活用するための基礎的な知識を理解してもらうことです。
経営においてデータを使って判断することは必要不可欠であり、その正確性とスピードがビジネスの勝敗を決めます。 Wantedly のデータ基盤の存在意義の1つは、そのビジネスにおける意思決定の正確性とスピードをサポートすることです。
- 例：紙や Excel でのデータ分析・管理からの効率化。分散されたデータでの分析の難しさの解消。ユーザー行動データを元にしたプロダクトの価値検証・開発。
また Wantedly のプロダクトでは、データそのものがユーザーにとっての価値を生み出します。 そのユーザーにとっての価値を絶え間なく提供し続けることも、Wantedly のデータ基盤の存在意義の1つです。
- 例：ユーザー行動を元にアイテムを提案し、ユーザーの意思決定支援をプロダクト価値として提供する。
Wantedly データ基盤の概略図を以下に示します。
データを貯めて分析クエリを実行するデータウェアハウス製品として Google BigQuery を採用しています。
Wantedly の BigQuery 上のデータは『Raw Layer』と『Transform Layer』で層が分けられ、テーブルは『source』『staging』『mart』の3種類を定義しています。
データ層
- Raw Layer: 生のデータ群を扱う層
- Transform Layer: 変換したデータ群を扱う層
テーブル種別
- source: データソースの構造に準拠したスキーマとテーブル
- staging: データをモデリングする上での最小単位であり source と1対1の関係。一貫性のあるカラム名や構造にするための加工を施したもの
- mart: 処理手順やエンティティを表現するモデル
もともと実態としては『source』データと集計したデータくらいの分けしかありませんでしたが、こういった分類を新たに定義して2022年から運用をはじめました。
主に分析業務の効率化と目的として以下を狙っています。
- データ分類を定義して目的のデータを発見しやすくする
- モデリングや前処理の手法、分析者の知見を適切な場所にコミットできる環境をつくる
文字通り、データを収集してデータウェアハウスに蓄積するコンポーネントです。 この方法で集めたデータは『source』テーブルになります。 データの発生源によってそれぞれデータ収集コンポーネントが存在します。
Android / iOS といったモバイルアプリのイベントログは、Google Firebase Analytics や TreasureData といった SaaS を使ってリアルタイムで行われます。 モバイルアプリにおいてユーザーのイベントログを新しく追加したい場合は、それぞれのツールの SDK に沿ってアプリケーションコードを書くことになります。
フロントエンドのイベントログ収集では frolog と呼ばれるデータ収集コンポーネントを内製して利用してリアルタイムで行われます。 フロントエンドにおいて新しくイベントログを追加したい場合は、この frolog の client ライブラリに沿ってアプリケーションコードを書くことになります。 イベントログ収集において機能が足りない場合はこの frolog に機能追加することになります。
アプリケーションサーバーのイベントログ収集は fluentd を経由してリアルタイムで行われます。 このアプリケーションからイベントログを fluentd に転送する実装は社内ライブラリである servicex にまとめられており、アプリケーションに servicex を導入することでアクセスログや任意のイベントログを Fluentd に転送できます。 アプリケーションサーバーのイベントログを新しく追加したい場合は、各言語の servicex を利用してアプリケーションコードを書くことになります。
データベースのテーブルをデータウェアハウスに収集するには、内製モジュールである analytics の RDB import 機能を利用します。 Ruby で書かれており、DSL を記述することで任意のデータベースのテーブルをデータウェアハウスに転送することができます。 実行スケジューラーの実装は Kubernetes の CronJob になっており、DSL を追加してデプロイすると CronJob に変換されます。だいたい daily か hourly で設定することが多いです。
データベース内の個人情報や機密情報など、社内でも分析用途での取り扱いが禁止されているデータにつ いては、このモジュールで特定カラムの除外・マスキングを行っています。
また analytics にはデータベースの他に、Salesforce やその他 SaaS のデータを取り込む機能が実装されており、ビジネスチームもこの analytics の DSL を書いています。
『source』から『staging』や『mart』といったテーブルやビューに変換するツールです。Wantedly では以下のツールを採用しています。
- dbt(data build tool): SQL でモデルや前処理を定義し、実行することでモデルの実態（テーブル）を生成するツール。モデル同士の依存関係を解決できる。
- analytics: SQL でモデルを定義し、実行することでモデルの実態（テーブル）を生成するツール。内製。Ruby の DSL でモデルと実行スケジュールを記述する。
もともと analytics は Wantedly データ基盤の初期に開発されたもので、データ収集・変換・出力がまとまったコンポーネントです。 長年データ変換処理を運用していくツラミや生産性向上の観点から dbt が新たに導入されました。
BigQuery 上のデータを活用して可視化するツールです。Looker と DataPortal がよく使われています。
継続的にモニタリングしたり、複数人で共有する場合は Looker でモデルを作り込むほうがおすすめです。 クエリ結果を雑に可視化したい場合は、Google DataPortal がおすすめです。
詳しくは Looker 入門 で解説される予定です。
データ基盤における処理は「定期実行バッチ」という体系を取るものが多いです。そのためのジョブスケジューラーが必須になります。 analytics での RDB import や データ変換ジョブのスケジューラーとしては Kubernetes CronJob を利用しています。
ジョブスケジューラーに加えて、高度なデータ変換や集計、特に機械学習では、マイクロサービスの境界を超えたデータやジョブの依存関係を持つ必要があります。 そのため、ジョブの依存関係を定義して実行してくれる Argo Workflow というワークフローエンジンが導入されています。Argo Workflow には CronWorkflow というジョブスケジューラーも内包されており、これをメインで利用しています。 詳しくは『 Data Scientist 向けに Wantedly の推薦基盤を支える Argo Workflow や Kubernetes などのインフラ、New Relic や Datadog などの SaaS を紹介する速習会をしました！ | Wantedly Engineer Blog 』も見てみてください。
BigQuery のメタデータ管理・検索ツールである DataCatalog を活用しています。データ分析における効率を上げるために、データ収集コンポーネントに設定を入れることでデータのメタデータを収集・DataCatalog で検索できるようにしています。
イベントログテーブルの宣言的な管理として bqs というものを作っています。bqs では Ruby の DSL でテーブルのメタ情報を書くとテーブルが作成されます。 この bqs にテーブル説明やカラム説明を記述することで、DataCatalog でテーブルの検索が可能になります。
データ変換ツールでもモデルの説明やカラム説明を設定することができ、同様に DataCatalog で検索できるようになります。
メタデータ（テーブル説明やカラム説明、コードの意味合い）は、データ分析を効率的に行う上で重要な役割を果たしています。 何者かわからないテーブルは活用のしようがなく、不要なコミュニケーションコストを発生させます。 新しくデータを作るときは、メタ データをしっかり設定するようにしましょう。
レコメンドシステムやメール施策におけるターゲットユーザーの抽出など、システムからデータ基盤にアクセスすることがあります。 この場合はレコメンドシステムやメール配信ジョブが所属する各マイクロサービスから、BigQuery のデータを Pull する形を取ります。
BigQuery は通常のアプリケーションで利用されるリレーショナルデータベース (RDB) とは異なる特性を持っています。 たとえば、RDBではリクエスト単位で処理を行うため、高速なレスポンスが求められますが、BigQuery を代表とするデータウェアハウスでは、大量レコードの抽出・集計処理に特化しており、パフォーマンス特性が異なります。 したがって、データウェアハウスに対して RDB のような感覚でクエリを実行したりアプリケーションを実装するとパフォーマンスに問題がでたり予期せぬところで問題が発生します。 以下のポイントには気をつけましょう。
- BigQuery では1レコードを抽出するクエリを複数回実行するのではなく、1クエリでデータを取得してアプリケーション側で処理する
- BigQuery では 1レコードに対して頻繁に更新(UPDATE, DELETE)する処理はパフォーマンスや計算資源的に不利なため、なるべく行わない。大量レコードを一括で変更したり非同期で行うことを推奨する
- 2015 前半 DOMO 利用開始
- 2016 後半 分析基盤を TreasureData から BigQuery に移行
- 2016 後半 データロード・集計を行う wantedly/analytics を開発・導入
- 2016 後半 機械学習が People で運用開始
- 2016 後半 機械学習が Visit で運用開始
- 2017 後半 Visit の募集一覧のソート結果が BigQuery に保存され、過去分の再現がしやすくなる
- 2018 前半 アプリケーションのイベントログ転送を BigQuery への直接ロードから Fluentd 経由に移行開始
- 2018 前半 BigQuery スキーマ管理として bqs を開発・導入
- 2019 前半 ワークフローエンジンとして Argo Workflows 導入
- 2019 後半 全てのイベントログが Fluentd 経由で BigQuery に蓄積されるようになる
- 2019 後半 BigQuery View 管理のための bqv を開発・導入
- 2020 後半 Looker導入/DOMO解約
- 2022 前半 データ変換に dbt を導入
- 2022 前半 メタデータ管理・検索に DataCatalog の活用を開始
- https://github.com/wantedly/looker
- https://github.com/wantedly/analytics
- https://github.com/wantedly/bqv-catalog
- https://github.com/wantedly/bqs
最終更新 1yr ago