この記事は、下書き供養 Advent Calendar 2018 - Adventarの2日目の記事です。 めっちゃ専門的な内容になってしまいました。ごめんなさい。
某Slackでの議論内容をブログに書こうとしたのですが、下書きのまま放置していました。
Wednesday, August 15th と書いてあるので、約半年前の内容となります。
もくじ
はじめに
データ基盤と世間一般で言われるシステムには分類があります。 「データ基盤を担当している」という人であっても、話してみると「意外とこの分類を知らない」「アンチパターンで設計している」と感じることがあります。 そこで私なりに解説してみたいと思います。
なお、ここでは分析基盤ではなくデータ基盤と呼びます。 データ分析だけでなく、集計・レポーティングや機械学習にも使うことを想定するからです。 そのため「分析」の基盤ではなく「データ」を活用するための基盤であることを強調するために「データ基盤」と呼称します。1
「データ基盤の3分類」と「（一般的な）技術要素」
1.データレイク（Data Lake）
元のデータを加工せずそのまま1つのシステムに集約したものです。 データソース（水源）から流れてきたデータをそのまま蓄える場所なのでレイク（湖）と呼びます。
何も加工していない、ただのコピーであることが重要です。 もし加工済みデータしか残っていないと、後から「このデータ加工方法は間違っている」ということが判明したときに直せなくなるからです。 データレイクに元の状態のデータが残っていれば、データの調査やロジック修正が容易になります。 サイエンティストならば、中途半端に用意された加工済データが使い物にならず、元データを寄越せと言いたくなったことは多々あるでしょう。
一般的な技術要素としては、S3やGCSなどのストレージサービスを使うことが多いです。 ログファイルやDB Dumpをコピーしてストレージに配備しているなら、それがデータレイクだと言えます。
2.データウェアハウス（Data Warehouse）
複数のデータを統合・蓄積して、意思決定に活用できるように整理したものです。 大量のデータを意味のある形で管理することからウェアハウス（倉庫）と呼びます。
業務ドメイン知識をデータモデリングに反映することが重要です。 元データをただコピーするだけでは使い勝手が悪く、かといって特定用途に限定すると応用できない、という絶妙だが重要なニーズを満たします。 データエンジニアが「こうすればいいだろう」と安易に設計すると必ず破綻します。 かといって最初から事業ドメイン知識を全て把握できるわけではありません。 継続的に再設計し続けることが求められます。
一般的な技術要素としては、Hadoop(hdfs)やRedshift、BigQueryなどの分散データストアを使うことが多いです。 （適切な語句を知らずに）データレイクやデータマートのことをデータウェアハウスと呼ぶ人もいますので、その点はご注意ください。
3.データマート（Data Mart）
特定の利用者・用途向けにデータを加工・整理したものです。 すぐに使える完成品を取り揃えていることからマート（市場）と呼びます。
ユースケースごとに最適化されていることが重要です。 データマートが整備されていれば、パフォーマンスを気にせずに大量データを処理したり、複雑な集計をせずに対象データを見ることができます。 マーケティング担当ならば、見たい数字はシンプルなはずなのに、やたらと集計が大変で疲弊したことは多々あるでしょう。
一般的な技術要素としては、Re:dashやTableauなどのBIツールを使うことが多いです。 なお、落としたデータを元にExcelで複雑な集計を行っているのであれば、そのExcelシートこそが真のデータマートだと言えます。
私が考えるデータ基盤の定義
この3分類はデータ活用の業務フローのどこかに存在します。
「いや、うちの組織にはそんなものはない！」はダウトです。 偉い人やソフトウェアエンジニアが気付いていないだけで、業務担当者のローカルPCにあるExcelシートが、実はデータ基盤の役割を果たしているかもしれません。 そのExcelを開くと、rawデータをコピーしたシート（データレイク）、集計のためのシート（データレイク）、グラフを表示するためのシート（データマート）が見つかるでしょう。
これら3分類の全てをひっくるめてデータ基盤と呼称するのが妥当です。 どれか1つの役割を担うだけでは、データ基盤ではないと思っています。
業務改善チームみたいな特定の部署が、自分たちにとって使いやすい加工済データを提供したとしても、それはデータ基盤とは言えません。 他の部署にとって使い勝手が悪ければ、それは提供部署にとってのデータマートでしかないのです。 組織横断のデータ基盤とは言えません。
私が考えるデータ基盤の定義は「複数のデータソースと複数の利用者をリボンのように結びつけるもの」です。 ここでいう「複数」は「n=1」の場合を含みます。 この定義に従うと、利用者に結びついていないのであればHadoopでさえデータ基盤とは言えず、利用者が使っているのであれば多重参照だらけの重いExcelシートであってもデータ基盤と言えます。 データソースと利用者を結ぶデータの流れのどこかで、3分類の役割が果たされることになります。
私が考える「あるべき構成」
技術要素を分けるのはアンチパターン
一般的な技術要素の例としては S3（データレイク） → Hadoop（データウェアハウス） → Tableau（データマート）といった構成となります。 しかし、私はこれがベストだとは思いません。 保守観点が欠如しているからです。 いわば「進化的データモデリング」を踏まえていないのです。
ある集計処理・加工後データが3分類のどこに属するのかは時と共に変わります。 例えば10の部署がそれぞれのExcelで同じ加工をしているのであれば、その加工処理は共通化したほうが良いでしょう。 それはもはやデータマートではなくデータウェアハウスとして扱うべきです。
また、データ仕様は日々変わることになります。 プロダクトの機能追加やバグ修正によって、データ反映のタイミングや内容が微妙に変わることもあります。 非エンジニアからは同じ動作のように見えても、データ集計処理に影響を与えていることだってあります。
「複数のデータソースと複数の利用者をリボンのように結びつける」ことの難しさがここにあります。 外的振る舞いを変えなかったとしても、一連のデータの流れの中身を継続的に修正し続けることになるのです。 システム保守と言ってもいいし、リファクタリングと言ってもいいし、現代風にいうなら「進化的データモデリング」と言ってもいいでしょう。 データ基盤におけるデータモデリング設計は継続的な分離・結合を通してドメイン知識を反映していくものとなります。
データレイク（元データを反映したもの）とデータマート（ユースケースを反映したもの）が先に存在して、そこからロジックを共通化したものがデータウェアハウスとなります。 データレイクやデータマートが変わっていくのに合わせて、中間テーブルであるデータウェアハウスを継続的に分離・結合することになります。
しかし、S3（データレイク） → Hadoop（データウェアハウス） → Tableau（データマート） のように別システムで管理していると、あるいは別チームが管理していると、データモデリング修正のコストが高くなり、設計は局所最適化してしまいます。
進化的データモデリングを容易にしよう
そこで私の担当現場では、BigQueryのデータセットを3層構造で管理して、それぞれに対応するという設計思想にしています。 つまりデータレイク、データウェアハウス、データマートを全てBigQueryで管理しています。
加工処理は全てSQLファイルで管理して、一連のデータパイプライン上で実行します。 最初はアナリストがTableauで実験的にデータマートを作り、上手くいったらSQL on データパイプラインにロジックを取り込みます。 命名規則とSQLで管理しているため、機械的に影響範囲を洗い出すことができます。2 リファクタリングを通してデータモデリング設計を継続的に進化させることができるのです。
加工ロジックを、S3 → Hadoop → Tableau のように別システムで管理していると、あるいは別チームが管理していると、その分だけ影響調査が困難になります。 上手い仕組みを作れずに、データモデルが汚れてしまい、技術的負債が蓄積されることになるでしょう。 だからこそ私は、同じシステムに寄せるほうがリファクタリングしやすい（＝継続進化させやすい）という思想で、技術要素としてBigQueryとSQLを採用しています。
チームとアーキテクチャを選ぶ
私の観測範囲に閉じて言えば、データサイエンティストや機械学習エンジニアはデータレイク重視、経営企画担当やアナリストはデータマート重視になりがちだなぁと感じます。 これらの人材はシステム開発のスペシャリストではないので、仕方ないことだと思います。 どちらかというと人材アサインの問題です。 システムの全体像（レイク・ウェアハウス・マート）を見渡し、進化的データモデリングという概念を考慮して、データ基盤を設計・保守する。 これができるのはSRE人材です。インフラ人材ではありません。システムの信頼性にコミットできるSRE人材です。
チームやアーキテクチャは重要です。 仮にアナリストチームがTableauで横断データを整理する役割を担っていたらどうなるでしょうか。 Tableauをメインで使うアナリストにとっては快適なデータモデルになるでしょう。 しかし機械学習エンジニアにとっては最悪です。 わざわざTableauの仕様に合わせてデータを使わないといけないのですから。 コンウェイの法則によって、システムの依存関係は過剰に複雑化します。 だからこそ、SREロール（あるいはデータ基盤専門チーム）が主体となって、BigQuery + SQLのような骨太の技術要素で、全体最適となるシステム設計を推進すべきなのです。
まとめ
一般的には S3（データレイク） → Hadoop（データウェアハウス） → Tableau（データマート） のように別システムで管理することが多いです。 これは「1度作ったら終わり」「異なる部署で管理する」といった従来のコンテキストが背景にあるからだと推察されます。 それぞれのレイヤーで得意なツールに寄せれば初期構築が非常に楽になるのは事実です。
しかし、初期構築（Dev）だけに注目するのではなく、保守運用（Ops）も視野に入れてみてはどうでしょうか。 最適なデータ基盤のあり方は、きっとこれまで世間一般で言われてきたものと違った姿になるはずです。
参考
このエントリーの内容は『10年戦えるデータ分析入門 SQLを武器にデータ活用時代を生き抜く』という書籍を参考としています。
10年戦えるデータ分析入門 SQLを武器にデータ活用時代を生き抜く (Informatics &IDEA)
- 作者: 青木峰郎
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2015/06/30
- メディア: 単行本
- この商品を含むブログ (7件) を見る
余談
このエントリーを読んだ上で、以下の登壇資料を読んでいただけると、理解が深まるはずです。 スライドのp135〜p182が該当箇所となります。
追記
技術要素についてツッコミどころに山ほどコメントをいただきました。 皆様ありがとうございます。一部記事を修正しました。
なお、データベースを正確に分類しようと試みている資料としては@fetarodcさんの「ビッグデータ処理データベースの全体像と使い分け 2018年version」を挙げることができます。前提知識についてはこのスライドを参照ください。
ツッコミありがとうございます！
— ゆずたそ (@yuzutas0) December 3, 2018
技術要素でS3とTableauを並列表記するのはさすがにヤバいなと自分でも思いました(笑)
出回っている資料を読んだり、周囲のアナリストと話すと、意外とこの区分けで見ている人が多いみたいなんですよね。
「それは違うぞ」ということで、後半の反論になります！
