[概論]データ分析基盤構築プロジェクトをスムーズに遂行するための知識を整理してみる。

前提

• 本記事で想定するデータ分析基盤とは、「本番環境とは切り離された、集計・可視化・レポーティングのようなデータ集計・分析をするための基盤」を指します。
• 知見が更新された場合、随時情報を追加更新していきます。

モチベーション

• データ分析基盤構築プロジェクトについては情報が少ないので、現時点での知見をまとめておき、この記事を叩き台にさらに良い方法を模索していきたいです。

サマリー

• 利用用途（ユースケース）は、重要で集計できていないデータを使った集計・分析が出来る状態を提供するのが良いです。活用される可能性が大きくなります。

• データ分析基盤を最初に導入するのなら、「BigQueryとCloud Composerの構成」がオススメです。

• データの可視化のためのBIツールも最初に展開する場合は、無料かつ無制限アカウントで発行可能な「Google Data Portal」がオススメです。

• テーブルの構成は、「Data Lake・Data Warehouse・Data Mart」の３層構成がオススメです。

• 基盤の運用時では、「再ランが容易にできる冪等性」、「利用状況を把握するためにAuditlogを使ったモニタリング」が重要です。

• 利用者向けテーブルの整備では、「利用者が理解しやすい命名ルール」を意識しましょう。

• 分析基盤の利用促進は、各グループで集計・分析に強い人（チャンピオン）から浸透させていきましょう。

考慮すべき項目

1. 利用用途（ユースケース）を確保する
2. 集めてくるデータを決める
3. データ分析基盤のアーキテクチャを決める
4. テーブルを整備する
5. 基盤やテーブルの運用を考える
6. 利用を推進する

1. 利用用途（ユースケース）を確保する

• データ分析基盤の構築プロジェクトにおいて、ユースケースを探すことが重要です。
  • というのも、データ集計業務に関しては、データベースにアクセスしてデータ集計加工をしているオペレーターに方を既に雇っていたり、データをExcelでゴリゴリ集計して分析するという解決手段が取れるため、改めて基盤に投資するメリットが見られないというケースが多いためです。
• コストがかかっても良い場合は、汎用性の点で人が最強です。
  • そのため、分析基盤のユースケースは、重要で集計が難しいデータや集計が多い要件の自動化など要点を絞って、着手するのが良いと思います。

2. 集めてくるデータを決める

• 最初は、社内で保有する利用ユーザデータ
  • 利用ユーザーの属性情報
  • 運営サービス内の行動ログ
• 社内で保有する利用ユーザデータの集約ができたら、社外にある利用ユーザデータ
  • マーケティング用データ
  • GDN, Youtube, YDNなどデジタル広告の計測情報
  • DMPなど社内サービス外での利用ユーザーの属性情報、行動ログ
  • 売り上げ予測などに使える、マクロ情報（天気、景気動向指数、株価など）
• 社内の事業以外のデータ
  • 会社のマーケティング情報（デジタル広告の計測情報、広報用サイト行動ログ、説明会アンケートなど）
  • 採用や人事情報

3. データ分析基盤のアーキテクチャを決める

• 構築と利用フィードバックをもらうことを優先したいので、構築・運用コストが小さいことが重要な条件です。その点では、フルマネージドサービスとオープンソースを活用したいです。
  • データ蓄積および集計・分析基盤は、 BigQuery
  • データ収集、加工、集約のためのワークフローは、Cloud Composer
  • ストレージ、データベースからのデータ収集は、Embulk
  • 可視化については、大人数の共有を目的としたダッシュボードやレポート用途なら、Google Data Portal。ただし、予算がありアナリストが探索的な分析を行いたい場合は、Tableauがおすすめ

4. テーブルを整備する

• Data Lake・Data Warehouse・Data Martの３層構造が一般的です。BigQueryでは３つのデータセットができる想定です。
  • Data Lakeは、各データソースからデータを集めて貯めておくデータセットです。データ加工は特に行いません。
  • Data Warehouseは、Data Mart向けに汎用的な加工処理を行ったテーブルを置いておきます。user_id毎やapp_id毎など非正規化したテーブルなどを作成しておくと良いでしょう。
  • Data Martは、利用用途や各種レポート毎に作成されたテーブルが置かれた場所です。Data Warehouseのテーブルからgroup by集約が行われたデータを置いておくことが想定されます。

5. 基盤やテーブルの運用を考える

• 基盤の運用時に考えたいのは、システム的な運用面とユーザの利用頻度向上のヒントとなる情報を得る仕組みが必要です。そういう意味では、データ基盤も社内ユーザ向けのプロダクトと見なした方が良いでしょう。
  • 再ランが容易にできる冪等性（データを更新処理しても数値が変わらず整合性が担保される。）の担保
  • データの欠損、異常値を検知するためのテストやモニタリング
  • ユーザの利用状況を把握するためにAuditlogを使ったモニタリング
• 利用者向けテーブルは、利用者が使いやすいことが重要です。
  • 理解しやすい命名ルール（例：uu_gender_dayなど、指標がなんのキーで集約されているテーブルか？を明確にする。）
  • カラムの属性値の言語化（例：性別なら、[1,2] → [男,女]に置換する。）

6. 利用を推進する

• 利用者の想定スキルを分けて利用環境を提供
  • エンジニア経験有、またはSQLを理解しているユーザ向け
    • SQLベースのUI(BigQuery UI), Redash
  • SQLはわからないけどExcelピボット操作が出来て、データの集約条件も意識しているユーザ向け
    • Tableau, Google Data Portal
• 利用者のツールへの興味関心度や利用成熟度はバラバラなので、各組織の中で利用ニーズが高く操作もスムーズに習得できる方（チャンピオン）を見つけて、ツール利用促進や組織内の相談に協力してもらう。

データ分析基盤に関するオススメしたい参考リンク集

システム全体の話

• ビッグデータを支える技術―刻々とデータが脈打つ自動化の世界
  • 所感：アーキテクチャ、テーブル整備、運用まで、システム面を網羅的に勉強できるお得な書籍です。

データ分析基盤のアーキテクチャ関連

• eureka
  • 所感：Cloud ComposerからBigqueryへのデータフローをサンプルコード付きで解説してくれています。

テーブル整備関連

• クックパッド
  • 所感：基盤上のテーブル構成をData Lake/DWH/DMと分離することで、再利用性を高めることが可能です。このテーブル構成は、yuzutas0さんの資料でもよく見ます。

基盤やテーブルの運用関連

• yuzutas0さん
  • 所感：構築後の利用状況を把握方法、利用者権限管理、テーブル欠損などの品質監視など多くのTipsがまとまっています。

利用の促進関連

• Retty
  • 所感：データの民主化で、Google Data Portalによるダッシュボード、モチベーションの強いPMへのSQLトレーニングや、Viewテーブルによる型化により利用の促進を行なっている事例が書かれています。

利用の促進（Tableauの導入）関連

• eureka
  • 要約：当初Redashであったものの、SQLが必要な部分が発生することから、Tableauの活用に動いたそうです。メリットは、データの取得部分をTableauに任せつつ、エンジニア側はデータソースの改善にフォーカスできる点と、ビジュアライズが綺麗に出来る点です。デメリットとしては、費用面がかかる点です。
  • 所感：Redashが定着した中で、費用面もかかるTableauを導入した流れはとても気になる事例として注目しました。