データ基盤入門
最終更新
最終更新
このドキュメントの目的は 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 でモデルと実行スケジュールを記述する。
BigQuery View (bqv): Mart や Staging を簡易的にビューで実現する。クエリを書くことでビューを管理する rerost/bqv を開発。
bqv の詳細は 『 BigQueryのクエリをコードとして管理する | Wantedly Engineer Blog 』 へ。
もともと analytics は Wantedly データ基盤の初期に開発されたもので、データ収集・変換・出力がまとまったコンポーネントです。 長年データ変換処理を運用していくツラミや生産性向上の観点から dbt が新たに導入されました。
参考 issue: dbt という Alternative bqv-catalog, analytics の導入検証を進めています dev#1321 (internal)
BigQuery 上のデータを活用して可視化するツールです。Looker と Looker Studio がよく使われています。
継続的にモニタリングしたり、複数人で共有する場合は Looker でモデルを作り込むほうがおすすめです。 クエリ結果を雑に可視化したい場合は、Google Looker Studio がおすすめです。
詳しくは 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 の活用を開始
Slack: #あらマチ, #looker_feedback, #wg-data-infrastructure
https://github.com/wantedly/looker
https://github.com/wantedly/analytics
https://github.com/wantedly/bqv-catalog
https://github.com/wantedly/bqs
