データウェアハウス層は、 最初から作らないで良いって本当？ / churadata-event-dbt-2022

イベントページ
https://churadata.connpass.com/event/265852/

dbtによってデータのレイヤー構造を作るのが簡単になりました。一方で、簡単に出来るが故に、早すぎたデータウェアハウス層に気をつけろ！という話も聞くようになりました。言いたいことは分かるけど、後からデータウェアハウス層って作れるの？という一抹の不安もある。これについて、私なりの答えを話します。

動画
https://youtu.be/SQmyZNHHlEU

Transcript

1. データウェアハウス層は、 最初から作らないで良いって本当？ データ基盤をこれから作る人が、4なないためのTIPS 2022年、dbt で作るデータ基盤の現場の話 2022/12/14(水)
2. データウェアハウス層は、 最初から作らない。
3. 初期段階ではデータウェアハウス層をつくらない。 データウェアハウス層の設計に着手するのは、データマート層が使われるように なったあとにしましょう。 最初にデータマート層をつくるときはデータレイク層を直接参照します。 データ活用施策を成功させて「これこそが共通指標だ」と言えるものが 明らかになってから、データウェアハウス層をつくりましょう。 最初から完成形をつくろうとするのではなく、 段階的にシステムを進化させましょう。 ゆずたそ・渡部 徹太郎・伊藤 徹郎, 実践的データ基盤への処方箋, 技術評論社,37p
4. これは本当にそう。
5. 初期段階ではデータウェアハウス層をつくらない。 データウェアハウス層の設計に着手するのは、データマート層が使われるように なったあとにしましょう。 最初にデータマート層をつくるときはデータレイク層を直接参照します。 データ活用施策を成功させて「これこそが共通指標だ」と言えるものが 明らかになってから、データウェアハウス層をつくりましょう。 最初から完成形をつくろうとするのではなく、 段階的にシステムを進化させましょう。 ゆずたそ・渡部 徹太郎・伊藤 徹郎, 実践的データ基盤への処方箋, 技術評論社,37p
6. 最初は何に注力すりゃええの？ってなるので、 そこについて、話をします。
7. 対象者 • これから、データ基盤作る人。
8. 話さないこと • データウェアハウス層の細かい設計
9. 自己紹介 ぺい @pei0804 近森淳平(チカモリ　ジュンペイ) CARTA HOLDINGS （旧VOYAGE GROUP） Zucks システム局 エンジニア
10. techblog.cartaholdings.co.jp, The Zen of Zucks, 2022/06/10, https://techblog.cartaholdings.co.jp/entry/the-zen-of-zucks
11. 初っ端から結論を言うと、 細かいデータの層がどうとかいいから、 筋が良いデータパイプラインを作ろう。
12. データ活用施策を成功させるには、 検証サイクルを、たくさん回せるのが大事。 データパイプラインが辛いと、 びっくりするくらい鈍化する。
13. データパイプラインとは データ・パイプラインは、データ分析のために、 ロウ・データを様々なデータ・ソースから取り込み、 データレイクやデータウェアハウスなどのデータストアに 移動するメソッドです。 www.ibm.com, データパイプラインとは, 2022/12/08, www.ibm.com/jp-ja/topics/data-pipeline
14. 筋が良いデータパイプラインを作ろう 筋が良いデータパイプラインを、最初から目指しましょう。 データ活用の検証サイクルの回しやすさや、 データウェアハウス層を、実際に作るフェーズになった時、 いつ何時でも、筋が良いデータパイプラインは、欲しくなります。
15. 筋が良いデータパイプラインを作ろう バッチ処理と聞くと、何を想像しますか？ 大変という印象をお持ちの人は、少なくないでしょう。 データパイプラインは、バッチ処理の塊です。単体のバッチ処理よりも、 当然複雑化しやすく、そうなるとコントロールは難しくなります。 しかし、バッチ処理に関する良い方法論は、既にあります。 良い方法論を使わずに実装すると、データパイプラインに関しては、 本当に大変になるので、良い方法論を使うことは、リッチな実装ではなく、 最低限やっておくべきことだと、私は考えています。
16. データウェアハウス層を作る前にやること 1. 筋が良いデータパイプラインを作ろう。 a. 再現性を担保する。 b. Transformにdbtを使う。 c. ワークフローエンジンを使う。 2. 筋が良いデータパイプラインが出来たら。（おまけ）
17. データウェアハウス層を作る前にやること 1. 筋が良いデータパイプラインを作ろう。 a. 再現性を担保する。 b. Transformにdbtを使う。 c. ワークフローエンジンを使う。 2. 筋が良いデータパイプラインが出来たら。（おまけ）
18. 再現性を担保する。
19. プロセス(≒データパイプライン)の再現性 データを元に、KPIを監視したり、洞察を得て、意思決定をしたり、 データの活用が進めば、当然ながら、データを作るプロセスの 信頼性が求められるでしょう。 そのため、プロセスの再現性は、重要です。 データは本当に厄介で、想定外がいくらでも発生します。 そんな時に、私達を助けてくれるのは、再現性のあるプロセスです。 もし、何か問題が起きる度に、プロセスから疑っていては日が暮れます。 少なくとも、プロセスを再現性のある作りにするのは、非常に大事です。
20. 個々のタスクの再現性 データパイプラインは、1つ以上のタスクを繋げて動きます。 例えば、SELECT -> INSERTでデータを作るような処理が、1タスクです。 データパイプラインに、再現性をもたせるには、それぞれのタスクが、 何度実行されても、同じ結果を返す再現性が必要です。 逆に再現性がない状況だと、何らかの問題で、タスクが失敗し、 再実行するだけの話でさえ、難しくなります。 なぜなら、失敗したタスクによってもたらされた副作用を、 知り尽くす必要が出てくるからです。 人間社会では、それは職人芸になります。
21. では、どうすれば良いのか？
22. 関数型プログラミングのプラクティスが めっちゃ効きます。
23. 関数型プログラミングとは 関数を主軸にしたプログラミングを行うスタイルである。 ここでの関数は、数学的なものを指し、 引数の値が定まれば結果も定まるという参照透過性を持つものである。 ja.wikipedia.org,関数型プログラミング ,2022-12-08, ja.wikipedia.org/wiki/%E9%96%A2%E6%95%B0%E5%9E%8B%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3 %83%9F%E3%83%B3%E3%82%B0
24. 参照透過性とは プログラミングにおける概念であり、関数等の数式に同じ数値を 入れた時、同じ処理と同じ計算結果をもたらす式のことを 参照透過性のある式と呼びます。 同じ入力に対して同じ出力を示すということです。 gimo.jp,参照透過性,2022-12-08, gimo.jp/glossary/details/referential_transparency.html#:~:text=%E5%8F%82%E7%85%A7%E9%80%8F%E9%81%8E %E6%80%A7%E3%81%A8%E3%81%AF,%E3%82%92%E7%A4%BA%E3%81%99%E3%81%A8%E3%81%84%E3%81%86% E3%81%93%E3%81%A8%E3%81%A7%E3%81%99%E3%80%82
25. 参照透過性のあるタスクが作れれば、 再現性のあるデータパイプラインは作れる。
26. データパイプラインに おける参照透過性 テーブルからSELECTした結果で、 何かのテーブルを作る処理が、 あるとします。 SELECTするテーブル同じなら、 同じ結果になることは勿論。 複数回実行した時に、 二重にINSERTされないことや、 その他の副作用を考慮する 必要がない実装になっている。 このような特徴のことを、 冪等性と呼んだりします。
27. 失敗したら、もう一回動かせばいいや。 というタスクにする。
28. dbt興味あるけど、試してない人。 朗報です。dbtは、参照透過性のある タスクを作るのに、非常に長けています。
29. データウェアハウス層を作る前にやること 1. 筋が良いデータパイプラインを作ろう。 a. 再現性を担保する。 b. Transformにdbtを使う。 c. ワークフローエンジンを使う。 2. 筋が良いデータパイプラインが出来たら。（おまけ）
30. Transformにdbtを使う。
31. Transformに dbtを使う。 これから、データ基盤作る人は、 dbtを使いましょう。 dbtは、データ変換に必要な プラクティスを強制してくれるので、 間違った手を打ってしまう事態を、 未然に防いでくれます。 もし、作り込んでいる内製ツールが あるなら、そのまま使い続けるも 悪くないでしょう。 過去にフルスクラッチのデータパイプラインを、 dbtに移行した時の話を発表しています。 speakerdeck.com, 広告レポーティング基盤に、 dbtを導入したら別物になった話 , 2022/12/08, speakerdeck.com/pei0804/tokyo-dbt-meetup-4
32. dbtは再現性のある タスクを作ってくれる dbtは、再現性を重視した 設計となっています。 そのため、個々のエンジニアの 努力で担保してきた再現性を、 dbt側が担保してくれるため、 私達は、データに集中できる ようになりました。 docs.getdbt.com,Idempotent,2022-12-08, docs.getdbt.com/terms/idempotent 公式の記事で、冪等性について熱く語ってくれてるので、 是非読んでみてください。
33. データウェアハウス層を作る前にやること 1. 筋が良いデータパイプラインを作ろう。 a. 再現性を担保する。 b. Transformにdbtを使う。 c. ワークフローエンジンを使う。 2. 筋が良いデータパイプラインが出来たら。（おまけ）
34. ワークフローエンジンを使う。
35. ワークフローエンジンを使う タスクが冪等な処理だったとしても、様々な失敗の可能性はあります。 例えば、ネットワークの不調によるエラーなどが代表的です。 もう一度動かせばいい冪等なタスク作ったんだから、 勝手にリトライとかしておいてほしいですよね？ ワークフローエンジンなら、簡単にできます。 ワークフローエンジンの選び方や、何が良いかは人によりますけど、 私は安くて、メンテが楽なStepFunctionsを使っています。 これは、本当に好みの問題なので、何でも良いです。
36. タスク 成功したら次 タスク 成功したら次 タスク この流れを、ワークフローエンジンで実装するだけ。 失敗したら リトライ
37. ここまでのおさらい • データパイプラインは、再現性を担保しよう。 ◦ 参照透過性のあるタスクで構成する。 ▪ dbtだと、ある程度乗っかるだけで、悪くない実装になる。 • データパイプライン実行は、ワークフローで制御しよう。 ◦ ネットワークエラーや、やり直せば済むような問題は、 ワークフローエンジンに解決させよう。
38. データパイプラインが出来た！ 次は、なにする？
39. データウェアハウス層を作る前にやること 1. 筋が良いデータパイプラインを作ろう。 a. 再現性を担保する。 b. Transformにdbtを使う。 c. ワークフローエンジンを使う。 2. 筋が良いデータパイプラインが出来たら。（おまけ）
40. データウェアハウス層とか関係なく、 データラングリングは、やろう。
41. データラングリングとは 生データのクレンジング、リストラ、および強化を行うことです。 生データは、処理またはシステムに統合されていないため複雑です。 データのラングリングにより、これらのレコードは標準的な形式に 変換され、貴重なインサイトが強調されます。 このプロセスでは、データを1つの場所に統合し、 欠落している情報やエラーを修正する必要があります。 anyconnector.com,データラングリングとは何ですか？ 6つの主要なステップ ,2022-12-08, anyconnector.com/ja/data-transformation/what-is-data-wrangling.html
42. 活用のされ方は見えなくても、 データの正しさは、定義できるはず。
43. データの正しさとは。 データの正しさとは、どこから降ってくるものではなく、 ビジネスとして、どういう状態を正しいとするか定義することで、 初めて生まれるものです。 これは本当によくある話なんですけど、データ基盤作り始めると、 そもそも、「このデータってどうなってると正しいんだ？」が、 これまで曖昧だったりして、正しさ決めていく仕事が発生します。 面倒くさいですけど、愚直に定義していくことをおすすめします。
44. Garbage In, Garbage Out. (ゴミを入れたら、ゴミが出てくる)
45. Garbage In, Garbage Out. 先に紹介したデータの正しさなどを、ロクに定義せずに、 とりあえず、データを入れたデータ基盤は散見します。 こういったデータは、漏れなくゴミ山になり、 往々にして、データ品質担保がレポート、分析クエリで発行されます。 また、人によって品質担保のやり方が違ったりもします。 品質の低いデータを中心とした仕事は、成果を出すのに苦労します。 特にデータサイエンティストをはじめとする。 データを中心に価値を出す人たちにとっては、死活問題です。
46. 信用できるデータが取れる状態は、 辛いクエリが各所で書かれる前に、 なるべく早く作る。
47. データの正しさ担保（広告ver） 広告を表示する度に発行されるIDがあります。(以下、広告表示ID) 基本的に、1表示ごとに、1広告表示IDが採番されるはずですが、 広告が表示されているクライアントで、何らかの原因で、 同じ広告表示IDが、何度も使い回されることがあります。 しかし、ビジネスとしては、何度も同じ広告表示IDが計上される状態は、 正しい状態ではないので、重複排除して、正しさを担保している。 ここで難しいのが、サービス開始から、積み上がったデータ全てを使って、 重複排除してると、億単位のレコードが日々増えるので、 現実的な時間で終わらないので、スキャン量を限定する工夫はしています。
48. データラングリングされてるだけで、 データ基盤としては、既に便利なんですよね。(感想) そして、されてない世界は、本当に辛いです。
49. まとめ
50. まとめ 筋が良いデータパイプラインがあって、 データラングリングがされていれば、検証サイクルはかなり早くなります。 そして、サイクルが早くなれば、「これこそが共通指標だ」と言えるものが 見えるまでの時間も短くなるでしょう。 そうなったら、シュッとデータウェアハウス層をつくりましょう。
51. 宣伝 関数型プログラミングの プラクティスでdbtのmodelを 実装するとこうなるって話を、 アドベントカレンダーで書きます。 Twitterは@pei0804です。 気になる人は是非読んで いただければと思います。
52. 朗報です。 実はエンジニア採用してます。
53. https://engineering.cartaholdings.co.jp/