下町柚子黄昏記 by @yuzutas0

したまち発・ゆずたそ作・試行錯誤の瓦礫の記録

データ基盤をHadoopからBigQueryに移管するときのアンチパターン

この記事は、SRE 2 Advent Calendar 2018 - Qiitaの4日目の記事です。

主張

データ基盤の移管プロジェクトをやるときは、データサイエンティストではなくSRE人材が推進すべきだと思っています。

この記事の概要

SRE人材が介在しないまま、システム全体の運用・保守観点を踏まえずに、データ基盤の移管を進めるとどうなるか。 「データ基盤をHadoopからBigQueryに移管する」というプロジェクトで、とある現場が実際に踏んだアンチパターンをご紹介します。

語句の説明

「データレイク」(元データのコピー)と「データウェアハウス」(加工済みデータ)の概念を分けて考えます。 詳しくは以下のエントリーを参照ください。

yuzutas0.hatenablog.com

元の構成

f:id:yuzutas0:20181203204909p:plain

  • いわゆるレガシーな20年モノのWebシステムで、DBはOracleを使っています。
  • バッチ処理Oracleからデータを取り出してORC形式でHadoopクラスタに疎通します。Hadoopがデータレイクの役割を果たしています。
  • Hadoopクラスタ上でデータ活用のための集計処理を行います。Hadoopがデータウェアハウスの役割を果たしています。

やろうとしたこと

f:id:yuzutas0:20181203204951p:plain

  • 分析環境の技術要素をHadoopからBigQueryに移管することになりました。
  • 方針としてHadoop(データレイク)からBigQueryにデータを流し込もうとしました。

失敗例

f:id:yuzutas0:20181203205146p:plain

  • 実態としては、Hadoop(データレイク)とHadoop(データウェアハウス)の境界が曖昧でした。
  • そのため中途半端に加工済みのデータがBigQueryに流れてしまいました。
  • 最初のDB(Oracle)と比べたときにデータの欠損や不整合が生じました。

何がイケてないか

f:id:yuzutas0:20181203205221p:plain

  • Hadoop(データウェアハウス)からBigQuery(データウェアハウス)への移行プロジェクトだと言っています。
  • しかし実態は、Hadoop(ごった煮)にBigQuery(ごった煮)を継ぎ足して、システムをより複雑にしただけです。

どうすべきだったか(Hadoopを使う案)

f:id:yuzutas0:20181203205240p:plain

  • 素直に考えると、Hadoop(データレイク)とHadoop(データウェアハウス)を明確に分離するのが第一歩と言えます。
  • その上で、Hadoop(データレイク)からBigQueryにデータを流して、Hadoop(データウェアハウス)を除却すれば良さそうです。
  • しかし、技術要素としてHadoopからBigQueryに移そうとしているのですから、Hadoop(データレイク)を残すメリットはありません。

どうすべきだったか(Hadoopを使わない案)

f:id:yuzutas0:20181203205355p:plain

  • OracleのReadOnlyレプリカを立て、純粋なエクスポートファイル(HDFSではなくDump)を吐き出し、そのDumpをBigQueryに読み込ませます。
  • つまり、Hadoop(自称データレイク)に継ぎ足すのではなく、DBのレプリカ&Dump(真のデータレイク)を参照する、という構成です。
  • 最後にHadoopクラスタ自体を除却すれば、技術要素としての「Hadoop → BigQuery」移管が完了します。

なぜこれができなかったか

f:id:yuzutas0:20181203205630p:plain

  • WebサイトのDBは、WEBサイトのエンジニアリング部隊が管理しています。
  • Hadoopクラスタはデータサイエンティスト部隊が管理しています。
  • データサイエンティスト部隊にとっては、HadoopからBigQueryにシステムを移管するならば、自分の見える範囲内でやるのが手っ取り早いです。
  • つまり「コンウェイの法則」が働いたということです。

なぜアンチパターンと言えるのか

2018年現在、多くの組織において「プロダクト」と「分析」の担当者は分かれています。 データの源(ログ)はプロダクト担当者が持っています。 そのため、分析担当者からプロダクト側にアクセスするには、サイロ化した組織の壁を突破する必要があります。

分析担当者に巻き込み力がないと、あるいは経営者・マネジャー・テックリードが全体を見渡して指示できないと、システムを継ぎ足すような選択肢しか選べなくなります。 分析担当者が素早く成果を出そうとすると、わざわざ時間を掛けてシステムの並行稼働・切り替えを行わずに、今あるシステムに継ぎ足すといった局所最適解を選びがちです。

その結果、データ基盤が複雑化して、データモデリングにおける負債が蓄積し、データ活用施策の品質・デリバリーが悪化します。

一般的な組織構造とアーキテクチャを前提としており、多くの現場で容易に再現されうる事象です。 それゆえにアンチパターンだと言えます。

どうすればよかったか

f:id:yuzutas0:20181203205812p:plain

  • 「プロダクト」と「分析」の間を取り持つDataOpsロールが必要です。
  • システム全体を最適化する部隊(つまりSRE)がこのロールを担うことが望ましいです。
  • 要するに、データサイエンティストではなく、SREがデータ基盤を構築・運用すべきです。

備考: DataOpsとは何か

  • 概念としてはDevOpsのデータ版です。つまり DevOps ≒ DataOps です。
  • DevOpsの具体的なプラクティスがSREです。Googleいわく class SRE implements DevOps です。
  • つまり class SRE implements DataOps とも言えます。要するに、鍵を握るのはSREなのです。

詳しくはデブサミの登壇資料をご覧ください。

yuzutas0.hatenablog.com

まとめ

バズワードとしてのビッグデータ・データサイエンティスト・AIが終焉を迎え、より実践的なデータ活用事例が増え始めたフェーズだと認識しています。 そして、データ活用の寄る辺となるデータ基盤の重要度は極めて高くなっています。

しかし、まだまだ「データサイエンティスト採用要件: Hadoop利用経験 n年以上」といった雑なリクルーティング・アサインが多いのも事実です。 結果として本エントリーでご紹介したようなアンチパターンを踏み抜いてしまった、という現場は多いのではないでしょうか。 これからそういう事例がどんどん出てくるのではないかと思います。

データ基盤と言えど、つまるところはITシステムです。 短絡的な視点に基づいて設計・構築・運用をすれば、技術的負債が蓄積していずれ限界を迎えます。 だからこそシステムの信頼性を最適化できるSRE人材が鍵になるのだと思います。

とりあえずデータサイエンティストの採用予算を、データ基盤エンジニアに一部振り替えましょう。