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

Slide 1

Slide 1 text

データウェアハウス層は、最初から作らないで良いって本当？データ基盤をこれから作る人が、4なないためのTIPS 2022年、dbt で作るデータ基盤の現場の話 2022/12/14(水)

Slide 2

Slide 2 text

データウェアハウス層は、最初から作らない。

Slide 3

Slide 3 text

初期段階ではデータウェアハウス層をつくらない。データウェアハウス層の設計に着手するのは、データマート層が使われるようになったあとにしましょう。最初にデータマート層をつくるときはデータレイク層を直接参照します。データ活用施策を成功させて「これこそが共通指標だ」と言えるものが明らかになってから、データウェアハウス層をつくりましょう。最初から完成形をつくろうとするのではなく、段階的にシステムを進化させましょう。ゆずたそ・渡部徹太郎・伊藤徹郎, 実践的データ基盤への処方箋, 技術評論社,37p

Slide 4

Slide 4 text

これは本当にそう。

Slide 5

Slide 5 text

Slide 6

Slide 6 text

最初は何に注力すりゃええの？ってなるので、そこについて、話をします。

Slide 7

Slide 7 text

対象者 ● これから、データ基盤作る人。

Slide 8

Slide 8 text

話さないこと ● データウェアハウス層の細かい設計

Slide 9

Slide 9 text

自己紹介ぺい @pei0804 近森淳平(チカモリ　ジュンペイ) CARTA HOLDINGS （旧VOYAGE GROUP） Zucks システム局エンジニア

Slide 10

Slide 10 text

techblog.cartaholdings.co.jp, The Zen of Zucks, 2022/06/10, https://techblog.cartaholdings.co.jp/entry/the-zen-of-zucks

Slide 11

Slide 11 text

初っ端から結論を言うと、細かいデータの層がどうとかいいから、筋が良いデータパイプラインを作ろう。

Slide 12

Slide 12 text

データ活用施策を成功させるには、検証サイクルを、たくさん回せるのが大事。データパイプラインが辛いと、びっくりするくらい鈍化する。

Slide 13

Slide 13 text

データパイプラインとはデータ・パイプラインは、データ分析のために、ロウ・データを様々なデータ・ソースから取り込み、データレイクやデータウェアハウスなどのデータストアに移動するメソッドです。 www.ibm.com, データパイプラインとは, 2022/12/08, www.ibm.com/jp-ja/topics/data-pipeline

Slide 14

Slide 14 text

筋が良いデータパイプラインを作ろう筋が良いデータパイプラインを、最初から目指しましょう。データ活用の検証サイクルの回しやすさや、データウェアハウス層を、実際に作るフェーズになった時、いつ何時でも、筋が良いデータパイプラインは、欲しくなります。

Slide 15

Slide 15 text

筋が良いデータパイプラインを作ろうバッチ処理と聞くと、何を想像しますか？大変という印象をお持ちの人は、少なくないでしょう。データパイプラインは、バッチ処理の塊です。単体のバッチ処理よりも、当然複雑化しやすく、そうなるとコントロールは難しくなります。しかし、バッチ処理に関する良い方法論は、既にあります。良い方法論を使わずに実装すると、データパイプラインに関しては、本当に大変になるので、良い方法論を使うことは、リッチな実装ではなく、最低限やっておくべきことだと、私は考えています。

Slide 16

Slide 16 text

データウェアハウス層を作る前にやること 1. 筋が良いデータパイプラインを作ろう。 a. 再現性を担保する。 b. Transformにdbtを使う。 c. ワークフローエンジンを使う。 2. 筋が良いデータパイプラインが出来たら。（おまけ）

Slide 17

Slide 17 text

Slide 18

Slide 18 text

再現性を担保する。

Slide 19

Slide 19 text

プロセス(≒データパイプライン)の再現性データを元に、KPIを監視したり、洞察を得て、意思決定をしたり、データの活用が進めば、当然ながら、データを作るプロセスの信頼性が求められるでしょう。そのため、プロセスの再現性は、重要です。データは本当に厄介で、想定外がいくらでも発生します。そんな時に、私達を助けてくれるのは、再現性のあるプロセスです。もし、何か問題が起きる度に、プロセスから疑っていては日が暮れます。少なくとも、プロセスを再現性のある作りにするのは、非常に大事です。

Slide 20

Slide 20 text

個々のタスクの再現性データパイプラインは、1つ以上のタスクを繋げて動きます。例えば、SELECT -> INSERTでデータを作るような処理が、1タスクです。データパイプラインに、再現性をもたせるには、それぞれのタスクが、何度実行されても、同じ結果を返す再現性が必要です。逆に再現性がない状況だと、何らかの問題で、タスクが失敗し、再実行するだけの話でさえ、難しくなります。なぜなら、失敗したタスクによってもたらされた副作用を、知り尽くす必要が出てくるからです。人間社会では、それは職人芸になります。

Slide 21

Slide 21 text

では、どうすれば良いのか？

Slide 22

Slide 22 text

関数型プログラミングのプラクティスがめっちゃ効きます。

Slide 23

Slide 23 text

関数型プログラミングとは関数を主軸にしたプログラミングを行うスタイルである。ここでの関数は、数学的なものを指し、引数の値が定まれば結果も定まるという参照透過性を持つものである。 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

Slide 24

Slide 24 text

参照透過性とはプログラミングにおける概念であり、関数等の数式に同じ数値を入れた時、同じ処理と同じ計算結果をもたらす式のことを参照透過性のある式と呼びます。同じ入力に対して同じ出力を示すということです。 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

Slide 25

Slide 25 text

参照透過性のあるタスクが作れれば、再現性のあるデータパイプラインは作れる。

Slide 26

Slide 26 text

データパイプラインにおける参照透過性テーブルからSELECTした結果で、何かのテーブルを作る処理が、あるとします。 SELECTするテーブル同じなら、同じ結果になることは勿論。複数回実行した時に、二重にINSERTされないことや、その他の副作用を考慮する必要がない実装になっている。このような特徴のことを、冪等性と呼んだりします。

Slide 27

Slide 27 text

失敗したら、もう一回動かせばいいや。というタスクにする。

Slide 28

Slide 28 text

dbt興味あるけど、試してない人。朗報です。dbtは、参照透過性のあるタスクを作るのに、非常に長けています。

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Transformにdbtを使う。

Slide 31

Slide 31 text

Transformに dbtを使う。これから、データ基盤作る人は、 dbtを使いましょう。 dbtは、データ変換に必要なプラクティスを強制してくれるので、間違った手を打ってしまう事態を、未然に防いでくれます。もし、作り込んでいる内製ツールがあるなら、そのまま使い続けるも悪くないでしょう。過去にフルスクラッチのデータパイプラインを、 dbtに移行した時の話を発表しています。 speakerdeck.com, 広告レポーティング基盤に、 dbtを導入したら別物になった話 , 2022/12/08, speakerdeck.com/pei0804/tokyo-dbt-meetup-4

Slide 32

Slide 32 text

dbtは再現性のあるタスクを作ってくれる dbtは、再現性を重視した設計となっています。そのため、個々のエンジニアの努力で担保してきた再現性を、 dbt側が担保してくれるため、私達は、データに集中できるようになりました。 docs.getdbt.com,Idempotent,2022-12-08, docs.getdbt.com/terms/idempotent 公式の記事で、冪等性について熱く語ってくれてるので、是非読んでみてください。

Slide 33

Slide 33 text

Slide 34

Slide 34 text

ワークフローエンジンを使う。

Slide 35

Slide 35 text

ワークフローエンジンを使うタスクが冪等な処理だったとしても、様々な失敗の可能性はあります。例えば、ネットワークの不調によるエラーなどが代表的です。もう一度動かせばいい冪等なタスク作ったんだから、勝手にリトライとかしておいてほしいですよね？ワークフローエンジンなら、簡単にできます。ワークフローエンジンの選び方や、何が良いかは人によりますけど、私は安くて、メンテが楽なStepFunctionsを使っています。これは、本当に好みの問題なので、何でも良いです。

Slide 36

Slide 36 text

タスク成功したら次タスク成功したら次タスクこの流れを、ワークフローエンジンで実装するだけ。失敗したらリトライ

Slide 37

Slide 37 text

ここまでのおさらい ● データパイプラインは、再現性を担保しよう。 ○ 参照透過性のあるタスクで構成する。 ■ dbtだと、ある程度乗っかるだけで、悪くない実装になる。 ● データパイプライン実行は、ワークフローで制御しよう。 ○ ネットワークエラーや、やり直せば済むような問題は、ワークフローエンジンに解決させよう。

Slide 38

Slide 38 text

データパイプラインが出来た！次は、なにする？

Slide 39

Slide 39 text

Slide 40

Slide 40 text

データウェアハウス層とか関係なく、データラングリングは、やろう。

Slide 41

Slide 41 text

データラングリングとは生データのクレンジング、リストラ、および強化を行うことです。生データは、処理またはシステムに統合されていないため複雑です。データのラングリングにより、これらのレコードは標準的な形式に変換され、貴重なインサイトが強調されます。このプロセスでは、データを1つの場所に統合し、欠落している情報やエラーを修正する必要があります。 anyconnector.com,データラングリングとは何ですか？ 6つの主要なステップ ,2022-12-08, anyconnector.com/ja/data-transformation/what-is-data-wrangling.html

Slide 42

Slide 42 text

活用のされ方は見えなくても、データの正しさは、定義できるはず。

Slide 43

Slide 43 text

データの正しさとは。データの正しさとは、どこから降ってくるものではなく、ビジネスとして、どういう状態を正しいとするか定義することで、初めて生まれるものです。これは本当によくある話なんですけど、データ基盤作り始めると、そもそも、「このデータってどうなってると正しいんだ？」が、これまで曖昧だったりして、正しさ決めていく仕事が発生します。面倒くさいですけど、愚直に定義していくことをおすすめします。

Slide 44

Slide 44 text

Garbage In, Garbage Out. (ゴミを入れたら、ゴミが出てくる)

Slide 45

Slide 45 text

Garbage In, Garbage Out. 先に紹介したデータの正しさなどを、ロクに定義せずに、とりあえず、データを入れたデータ基盤は散見します。こういったデータは、漏れなくゴミ山になり、往々にして、データ品質担保がレポート、分析クエリで発行されます。また、人によって品質担保のやり方が違ったりもします。品質の低いデータを中心とした仕事は、成果を出すのに苦労します。特にデータサイエンティストをはじめとする。データを中心に価値を出す人たちにとっては、死活問題です。

Slide 46

Slide 46 text

信用できるデータが取れる状態は、辛いクエリが各所で書かれる前に、なるべく早く作る。

Slide 47

Slide 47 text

データの正しさ担保（広告ver）広告を表示する度に発行されるIDがあります。(以下、広告表示ID) 基本的に、1表示ごとに、1広告表示IDが採番されるはずですが、広告が表示されているクライアントで、何らかの原因で、同じ広告表示IDが、何度も使い回されることがあります。しかし、ビジネスとしては、何度も同じ広告表示IDが計上される状態は、正しい状態ではないので、重複排除して、正しさを担保している。ここで難しいのが、サービス開始から、積み上がったデータ全てを使って、重複排除してると、億単位のレコードが日々増えるので、現実的な時間で終わらないので、スキャン量を限定する工夫はしています。

Slide 48

Slide 48 text

データラングリングされてるだけで、データ基盤としては、既に便利なんですよね。(感想) そして、されてない世界は、本当に辛いです。

Slide 49

Slide 49 text

まとめ

Slide 50

Slide 50 text

まとめ筋が良いデータパイプラインがあって、データラングリングがされていれば、検証サイクルはかなり早くなります。そして、サイクルが早くなれば、「これこそが共通指標だ」と言えるものが見えるまでの時間も短くなるでしょう。そうなったら、シュッとデータウェアハウス層をつくりましょう。

Slide 51

Slide 51 text

宣伝関数型プログラミングのプラクティスでdbtのmodelを実装するとこうなるって話を、アドベントカレンダーで書きます。 Twitterは@pei0804です。気になる人は是非読んでいただければと思います。