Wantedly Engineering Handbook
  • Wantedly Engineering Handbook
  • まえがき
  • 第一部:開発チームへの案内
    • 技術とアーキテクチャ
    • プロダクト概要(未執筆)
    • 開発チームの構造
    • コミュニケーションの全体
    • ドキュメンテーション(未執筆)
    • カレンダー
    • 障害対応の心構え
    • 効率的な社内知識の調べ方
    • 外部発信(執筆中)
  • 第二部:技術領域への案内
    • Apps
      • アプリを提供するプラットフォーム
      • デザインシステム入門
      • Web アプリのアーキテクチャ
      • プロダクトデザイナーと上手に協働するための心得
      • Web アプリのデザインシステムライブラリ
      • Web アプリ共通ライブラリ "React Shared Component" の紹介
      • モバイルアプリのアーキテクチャ
      • モバイルアプリのデザインシステムライブラリ(未執筆)
    • The System
      • protobuf スキーマと gRPC 通信
      • 実践: gRPC in Ruby
      • 実践: gRPC in Go
      • GraphQL Gateway - アプリ向けに API を公開する
      • Wantedly Visit で BFF GraphQL サーバーを辞めた理由
      • 実践: GraphQL スキーマ設計(未執筆)
      • API での認可処理 (Authorization)
      • マイクロサービス共通ライブラリ "servicex" の紹介
      • 非同期メッセージング処理入門(未執筆)
      • バッチ処理入門(未執筆)
    • Infrastructure
      • Infrastructure Squad
      • プロダクト開発のための Kubernetes 入門
      • インフラ構成概要
      • リリース・デプロイ戦略を支える技術
      • SaaS を活用する:New Relic, Honeybadger, Datadog
    • Data
      • データ基盤入門
      • レコメンデーション
      • Looker 入門
      • 推薦システムの開発に使っているツール
    • 開発プロセス
      • Git の慣習
      • ポストモーテムの取り組み
      • 負債返済日の取り組み
      • プロダクトの課題発見及び解決
      • ソフトウェアデザインの基礎
      • コードレビュー
      • コーディング規約
      • リリース・デプロイ戦略
      • 上長承認が必要な作業
      • アーキテクチャディシジョンレコード(ADR)
      • 作業ログを残す意味
      • 多言語化対応(i18n)
      • メール開発
    • 開発ツール
      • 社内利用している開発ツールの最新状況
      • kube
      • Code Coverage
      • Kubefork
  • おわりに
    • ロードマップ(未執筆)
    • Handbook の書き方
    • コントリビューター
  • 付録
    • 社内用語集
    • 主要な GitHub レポジトリのリスト(未執筆)
    • 今後の挑戦・未解決イシュー(未執筆)
    • プロダクト開発組織のバリュー(未執筆)
    • 採用についての考え方(未執筆)
GitBook提供
このページ内
  • データ基盤の存在意義
  • データ基盤概略
  • データウェアハウス (コンピュートとストレージ)
  • データ収集コンポーネント
  • モバイルアプリ イベントログ
  • フロントエンド イベントログ
  • アプリケーションサーバー イベントログ
  • データベース / テーブル
  • データ変換ツール
  • BI ツール
  • ワークフローエンジン・ジョブスケジューラー
  • メタデータ・スキーマ管理
  • システムからのデータ基盤の利用
  • 歴史

役に立ちましたか?

  1. 第二部:技術領域への案内
  2. Data

データ基盤入門

前へData次へレコメンデーション

最終更新 1 年前

役に立ちましたか?

このドキュメントの目的は 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 が新たに導入されました。

BI ツール

BigQuery 上のデータを活用して可視化するツールです。Looker と Looker Studio がよく使われています。

継続的にモニタリングしたり、複数人で共有する場合は Looker でモデルを作り込むほうがおすすめです。 クエリ結果を雑に可視化したい場合は、Google Looker Studio がおすすめです。

詳しくは Looker 入門 で解説される予定です。

ワークフローエンジン・ジョブスケジューラー

データ基盤における処理は「定期実行バッチ」という体系を取るものが多いです。そのためのジョブスケジューラーが必須になります。 analytics での RDB import や データ変換ジョブのスケジューラーとしては Kubernetes CronJob を利用しています。

メタデータ・スキーマ管理

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

BigQuery View (bqv): Mart や Staging を簡易的にビューで実現する。クエリを書くことでビューを管理する を開発。

bqv の詳細は 『 』 へ。

参考 issue:

ジョブスケジューラーに加えて、高度なデータ変換や集計、特に機械学習では、マイクロサービスの境界を超えたデータやジョブの依存関係を持つ必要があります。 そのため、ジョブの依存関係を定義して実行してくれる Argo Workflow というワークフローエンジンが導入されています。Argo Workflow には CronWorkflow というジョブスケジューラーも内包されており、これをメインで利用しています。 詳しくは『 』も見てみてください。

Slack: , ,

rerost/bqv
BigQueryのクエリをコードとして管理する | Wantedly Engineer Blog
dbt という Alternative bqv-catalog, analytics の導入検証を進めています dev#1321 (internal)
Data Scientist 向けに Wantedly の推薦基盤を支える Argo Workflow や Kubernetes などのインフラ、New Relic や Datadog などの SaaS を紹介する速習会をしました! | Wantedly Engineer Blog
#あらマチ
#looker_feedback
#wg-data-infrastructure