これはWHITEPLUS Advent Calendar 2019の1日目の記事です。
はじめに
先日、データレイクが期間にして1ヶ月、実稼働にすると正味7営業日程度で整いました。めでたしめでたし。
これから社内活用を促進しウェアハウス・マートの作成を進めていく段階ではありますが、 今日はデータレイクを整えるに至った経緯や、 構成の選定理由、最終的にはどんなデータ基盤イメージを持っているのか。 などなど、書いていきます。
データ基盤とは？
「データ基盤」というものが、抽象度の高い概念なので、 調べ物をする限り一般解になっていそうなデータ活用の全体像を以下と仮定して、
具体的には、利用者をあえて限定せず将来的に発生しうる利用者のニーズに応えうるデータの提供元。とでも呼ぶものを「データ基盤」として以降、話を進めます。
そして、今回の記事はデータエンジニアリング領域が中心となります。
ちなみに「データ基盤」の概念整理をする上で、この記事が大変参考になりました。
最終的に動いている構成は以下のとおりで、データレイクをBigQueryとし、パイプラインの構築はEmbulkベースのフルマネージドサービスであるtroccoを利用してかなりシンプルなものとなりました。
構築に至った経緯
もともと社内のデータ活用や、将来的なML（Machine Learning）、レコメンデーション活用への布石が打てていない現状に自身としても課題感がありつつ、
優先順位が高くもなく低くもなかったところ、
代表の「データの見える化を進めたいんだけど」という発言を機に、良いタイミングと捉え動き出したのがはじまりでした。
そこからは、あえて問題設定を狭めずに、結局なにが出来るとはかどるのだろうか。という整理に進み、
社内の意見を聞いていくと過去も含めてこんな意見が出てきました。
- 広告データを取得するためのコネクタ開発が追いつかない
- KPIモニタリングするために可視化をしているが、変更が入った場合の対応が属人化している
- 分析目的のデータ抽出依頼が来るが、似たような依頼を何度も対応するのが効率的ではない
- どんなデータがあるのか。誰が見ているのかなど、データ自体や活用具合の見通しが良くはない
- データ定義が定まっていないので、同じ名称でも数字が違ったことがあった
などなど聞けば聞くほど、いろいろと出てきたのですが、
要するに、
- データパイプラインの追加をもっと気軽に
- データ参照元は一元化
- 分析依頼に幅広く応えられる構造化されたデータウェアハウスの準備
- 上記2に類似
- データ定義を、ある程度固く出来るように
というあたりが、今のホワイトプラスで求められるデータ基盤に対する具体的な要件だなと捉え、
上記の要件以前の話として、そもそもデータ基盤は使われてなんぼ。
とも思いますので、「気軽に使われ続けるものであること」を大前提として加え、整理を終えました。
データレイク編
ということで、まずデータの一旦の終着点である格納先（データレイク）は何にしようかな、と調べはじめるのですが比較的スムーズに、
- ある程度無茶なSQLでもスピーディにレスポンスを返してくれる（時間的なコスト良い）
- クエリ単位課金で安い（金銭的なコスト安い）
- 永続UDF（user-defined function）を活用すると、ウェアハウス・マート作成時のデータ定義がある程度固く出来そう（要件5番を満たせそう）
- 構造化されたデータウェアハウスを準備するのも手軽（要件3番を満たせそう）
- データレイク、ウェアハウス、マートは1スタックで完結する方が継続的に成長させやすいだろう
という理由でデータレイクはBigQuery一択で、データレイクに集約するということで、要件の2, 4も自動的に満たせることとなりました。
パイプライン編
次にパイプラインですが、データソースが多岐に渡っていたため実際はEmbulk + Cloud Composerあたりのフルマネージドワークフローエンジンの組み合わせかなと当たりをつけ検討をはじめました。
とはいえ、パイプラインを0から可用性やスケーラビリティを担保しつつ構築する時間の捻出は難しいし...おまけに頑張って構築しても取り込みたいデータソースが増えたら追加コストもバカにならんしな…
と悩んでいた際に、少なくともEmbulkインスタンス群の構築を0からやるのだけは避けたい！何か良い感じにEmbulkをラップしているフルマネージドサービス無いかな〜？と探し始めた時に出会ったのがtroccoでした。
（troccoの詳細説明はサービスページを確認してください）
ちなみに下記がコネクタ一覧ですが、
デフォルトでYSS（Yahoo! スポンサードサーチ）があるのがありがたかったです。
整理・検証してみる
なかなか良さそうだなと思いつつトライアルがあったため、
実際のデータを用いて利用にあたって問題になる点が無いかの検証を行いました。
結果、導入にあたり大きな問題は無かったのですが、検証してみて想像以上に良かった点（単純に事前理解が浅かった点もありますが...）としては、「ワークフローエンジン機能も持っていた」というところでしょうか。
一般的にワークフローエンジンに期待することとしては、
- ジョブの実行時間の把握を簡潔に行いボトルネックの特定・対処が容易になる
- ジョブの再実行がGUIから簡易に行い、リカバリー処理が容易になる
- ジョブの依存関係定義を簡易に行える（=依存関係が把握しやすい）
あたりかと思いますが、現状はtroccoの場合1と3はジョブが増えてくると、見通しが良くはないというのが正直な感想です。
ただし、ワークフローエンジン機能がメインの機能ではないので、不満はまったくなくジョブ実行などのAPIが用意されていますので、必要に応じてCloud Composerなどのマネージドワークフローエンジンを組み合わせることで1と3も解消可能かと思います。
ちなみに今回、データレイクを構築するにあたっては、頻繁に同一レコードを更新するデータソースが一部あったため、 転送処理完了をトリガーにして更新日時を対象に、重複データの排除をするようなSQL実行処理を入れ込むためにtroccoのワークフローエンジン機能を活用しています。
SELECT
id,
〜
updated_at
FROM (
SELECT
id,
〜
updated_at,
ROW_NUMBER() OVER (PARTITION BY id ORDER BY updated_at DESC ) AS rank
FROM dataset.data
)
WHERE rank = 1;
加えて、サポートツールがslackでレスが早く、初期構築が大変はかどったのも想像以上に良かった点です。（troccoの宣伝みたいになってきちゃいましたが、それだけ手軽にデータレイク整えるには充分な機能とサポートがあったという意味です）
残した課題
現時点ではtroccoのワークフローエンジンを使い倒すとタスクの依存関係や前後の処理時間の見通しが悪くなり、
処理のボトルネック把握やタスクの改善・改修をしていく上で、将来やりづらくなる可能性があるだろう。と感じているため、現時点ではあえて使い倒すことはしていません。
データ基盤全体の構築が進み、ワークフローエンジンを使い倒す必要性が高まってきた段階で、Cloud Composerなどの組み合わせにより、タスクの依存関係や前後の処理時間の見通しをあげるかどうかを判断する。という宿題を今回は残しました。
今後の展開
という流れで、データレイクが整い、これからガシガシとウェアハウス・マートの作成を進めて分析や可視化のスピードを上げていく予定で、 一段落つく頃にはデータは揃っているはずなので、事業・経営数値のforecastに取り組み、意思決定スピードも上げていきたいなと思っているところですが、 そんな構想に興味を持っていただけたら、ぜひデータエンジニアへご応募ください！
