イベントページ https://churadata.connpass.com/event/265852/
dbtによってデータのレイヤー構造を作るのが簡単になりました。一方で、簡単に出来るが故に、早すぎたデータウェアハウス層に気をつけろ！という話も聞くようになりました。言いたいことは分かるけど、後からデータウェアハウス層って作れるの？という一抹の不安もある。これについて、私なりの答えを話します。
動画 https://youtu.be/SQmyZNHHlEU
データウェアハウス層は、最初から作らないで良いって本当？データ基盤をこれから作る人が、4なないためのTIPS2022年、dbt で作るデータ基盤の現場の話 2022/12/14(水)
View Slide
データウェアハウス層は、最初から作らない。
初期段階ではデータウェアハウス層をつくらない。データウェアハウス層の設計に着手するのは、データマート層が使われるようになったあとにしましょう。最初にデータマート層をつくるときはデータレイク層を直接参照します。データ活用施策を成功させて「これこそが共通指標だ」と言えるものが明らかになってから、データウェアハウス層をつくりましょう。最初から完成形をつくろうとするのではなく、段階的にシステムを進化させましょう。ゆずたそ・渡部 徹太郎・伊藤 徹郎, 実践的データ基盤への処方箋, 技術評論社,37p
これは本当にそう。
最初は何に注力すりゃええの？ってなるので、そこについて、話をします。
対象者● これから、データ基盤作る人。
話さないこと● データウェアハウス層の細かい設計
自己紹介ぺい@pei0804近森淳平(チカモリ ジュンペイ)CARTA HOLDINGS （旧VOYAGE GROUP）Zucks システム局 エンジニア
techblog.cartaholdings.co.jp, The Zen of Zucks, 2022/06/10, https://techblog.cartaholdings.co.jp/entry/the-zen-of-zucks
初っ端から結論を言うと、細かいデータの層がどうとかいいから、筋が良いデータパイプラインを作ろう。
データ活用施策を成功させるには、検証サイクルを、たくさん回せるのが大事。データパイプラインが辛いと、びっくりするくらい鈍化する。
データパイプラインとはデータ・パイプラインは、データ分析のために、ロウ・データを様々なデータ・ソースから取り込み、データレイクやデータウェアハウスなどのデータストアに移動するメソッドです。www.ibm.com, データパイプラインとは, 2022/12/08, www.ibm.com/jp-ja/topics/data-pipeline
筋が良いデータパイプラインを作ろう筋が良いデータパイプラインを、最初から目指しましょう。データ活用の検証サイクルの回しやすさや、データウェアハウス層を、実際に作るフェーズになった時、いつ何時でも、筋が良いデータパイプラインは、欲しくなります。
筋が良いデータパイプラインを作ろうバッチ処理と聞くと、何を想像しますか？大変という印象をお持ちの人は、少なくないでしょう。データパイプラインは、バッチ処理の塊です。単体のバッチ処理よりも、当然複雑化しやすく、そうなるとコントロールは難しくなります。しかし、バッチ処理に関する良い方法論は、既にあります。良い方法論を使わずに実装すると、データパイプラインに関しては、本当に大変になるので、良い方法論を使うことは、リッチな実装ではなく、最低限やっておくべきことだと、私は考えています。
データウェアハウス層を作る前にやること1. 筋が良いデータパイプラインを作ろう。a. 再現性を担保する。b. Transformにdbtを使う。c. ワークフローエンジンを使う。2. 筋が良いデータパイプラインが出来たら。（おまけ）
再現性を担保する。
プロセス(≒データパイプライン)の再現性データを元に、KPIを監視したり、洞察を得て、意思決定をしたり、データの活用が進めば、当然ながら、データを作るプロセスの信頼性が求められるでしょう。そのため、プロセスの再現性は、重要です。データは本当に厄介で、想定外がいくらでも発生します。そんな時に、私達を助けてくれるのは、再現性のあるプロセスです。もし、何か問題が起きる度に、プロセスから疑っていては日が暮れます。少なくとも、プロセスを再現性のある作りにするのは、非常に大事です。
個々のタスクの再現性データパイプラインは、1つ以上のタスクを繋げて動きます。例えば、SELECT -> INSERTでデータを作るような処理が、1タスクです。データパイプラインに、再現性をもたせるには、それぞれのタスクが、何度実行されても、同じ結果を返す再現性が必要です。逆に再現性がない状況だと、何らかの問題で、タスクが失敗し、再実行するだけの話でさえ、難しくなります。なぜなら、失敗したタスクによってもたらされた副作用を、知り尽くす必要が出てくるからです。人間社会では、それは職人芸になります。
では、どうすれば良いのか？
関数型プログラミングのプラクティスがめっちゃ効きます。
関数型プログラミングとは関数を主軸にしたプログラミングを行うスタイルである。ここでの関数は、数学的なものを指し、引数の値が定まれば結果も定まるという参照透過性を持つものである。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
参照透過性とはプログラミングにおける概念であり、関数等の数式に同じ数値を入れた時、同じ処理と同じ計算結果をもたらす式のことを参照透過性のある式と呼びます。同じ入力に対して同じ出力を示すということです。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
参照透過性のあるタスクが作れれば、再現性のあるデータパイプラインは作れる。
データパイプラインにおける参照透過性テーブルからSELECTした結果で、何かのテーブルを作る処理が、あるとします。SELECTするテーブル同じなら、同じ結果になることは勿論。複数回実行した時に、二重にINSERTされないことや、その他の副作用を考慮する必要がない実装になっている。このような特徴のことを、冪等性と呼んだりします。
失敗したら、もう一回動かせばいいや。というタスクにする。
dbt興味あるけど、試してない人。朗報です。dbtは、参照透過性のあるタスクを作るのに、非常に長けています。
Transformにdbtを使う。
Transformにdbtを使う。これから、データ基盤作る人は、dbtを使いましょう。dbtは、データ変換に必要なプラクティスを強制してくれるので、間違った手を打ってしまう事態を、未然に防いでくれます。もし、作り込んでいる内製ツールがあるなら、そのまま使い続けるも悪くないでしょう。過去にフルスクラッチのデータパイプラインを、dbtに移行した時の話を発表しています。speakerdeck.com, 広告レポーティング基盤に、 dbtを導入したら別物になった話 , 2022/12/08,speakerdeck.com/pei0804/tokyo-dbt-meetup-4
dbtは再現性のあるタスクを作ってくれるdbtは、再現性を重視した設計となっています。そのため、個々のエンジニアの努力で担保してきた再現性を、dbt側が担保してくれるため、私達は、データに集中できるようになりました。docs.getdbt.com,Idempotent,2022-12-08,docs.getdbt.com/terms/idempotent公式の記事で、冪等性について熱く語ってくれてるので、是非読んでみてください。
ワークフローエンジンを使う。
ワークフローエンジンを使うタスクが冪等な処理だったとしても、様々な失敗の可能性はあります。例えば、ネットワークの不調によるエラーなどが代表的です。もう一度動かせばいい冪等なタスク作ったんだから、勝手にリトライとかしておいてほしいですよね？ワークフローエンジンなら、簡単にできます。ワークフローエンジンの選び方や、何が良いかは人によりますけど、私は安くて、メンテが楽なStepFunctionsを使っています。これは、本当に好みの問題なので、何でも良いです。
タスク 成功したら次 タスク 成功したら次 タスクこの流れを、ワークフローエンジンで実装するだけ。失敗したらリトライ
ここまでのおさらい● データパイプラインは、再現性を担保しよう。○ 参照透過性のあるタスクで構成する。■ dbtだと、ある程度乗っかるだけで、悪くない実装になる。● データパイプライン実行は、ワークフローで制御しよう。○ ネットワークエラーや、やり直せば済むような問題は、ワークフローエンジンに解決させよう。
データパイプラインが出来た！次は、なにする？
データウェアハウス層とか関係なく、データラングリングは、やろう。
データラングリングとは生データのクレンジング、リストラ、および強化を行うことです。生データは、処理またはシステムに統合されていないため複雑です。データのラングリングにより、これらのレコードは標準的な形式に変換され、貴重なインサイトが強調されます。このプロセスでは、データを1つの場所に統合し、欠落している情報やエラーを修正する必要があります。anyconnector.com,データラングリングとは何ですか？ 6つの主要なステップ ,2022-12-08,anyconnector.com/ja/data-transformation/what-is-data-wrangling.html
活用のされ方は見えなくても、データの正しさは、定義できるはず。
データの正しさとは。データの正しさとは、どこから降ってくるものではなく、ビジネスとして、どういう状態を正しいとするか定義することで、初めて生まれるものです。これは本当によくある話なんですけど、データ基盤作り始めると、そもそも、「このデータってどうなってると正しいんだ？」が、これまで曖昧だったりして、正しさ決めていく仕事が発生します。面倒くさいですけど、愚直に定義していくことをおすすめします。
Garbage In, Garbage Out.(ゴミを入れたら、ゴミが出てくる)
Garbage In, Garbage Out.先に紹介したデータの正しさなどを、ロクに定義せずに、とりあえず、データを入れたデータ基盤は散見します。こういったデータは、漏れなくゴミ山になり、往々にして、データ品質担保がレポート、分析クエリで発行されます。また、人によって品質担保のやり方が違ったりもします。品質の低いデータを中心とした仕事は、成果を出すのに苦労します。特にデータサイエンティストをはじめとする。データを中心に価値を出す人たちにとっては、死活問題です。
信用できるデータが取れる状態は、辛いクエリが各所で書かれる前に、なるべく早く作る。
データの正しさ担保（広告ver）広告を表示する度に発行されるIDがあります。(以下、広告表示ID)基本的に、1表示ごとに、1広告表示IDが採番されるはずですが、広告が表示されているクライアントで、何らかの原因で、同じ広告表示IDが、何度も使い回されることがあります。しかし、ビジネスとしては、何度も同じ広告表示IDが計上される状態は、正しい状態ではないので、重複排除して、正しさを担保している。ここで難しいのが、サービス開始から、積み上がったデータ全てを使って、重複排除してると、億単位のレコードが日々増えるので、現実的な時間で終わらないので、スキャン量を限定する工夫はしています。
データラングリングされてるだけで、データ基盤としては、既に便利なんですよね。(感想)そして、されてない世界は、本当に辛いです。
まとめ
まとめ筋が良いデータパイプラインがあって、データラングリングがされていれば、検証サイクルはかなり早くなります。そして、サイクルが早くなれば、「これこそが共通指標だ」と言えるものが見えるまでの時間も短くなるでしょう。そうなったら、シュッとデータウェアハウス層をつくりましょう。
宣伝関数型プログラミングのプラクティスでdbtのmodelを実装するとこうなるって話を、アドベントカレンダーで書きます。Twitterは@pei0804です。気になる人は是非読んでいただければと思います。
朗報です。実はエンジニア採用してます。
https://engineering.cartaholdings.co.jp/
pei0804
dahatake
yoshimi0227
satoshihirose
kosui
nishiuma
coconala_engineer
lycorptech_jp
iamshunta
k1low
stefafafan
loglass2019
pauli
geoffreycrofte
tmm1
panda_program
addyosmani
erikaheidi
tammielis
colly
samlambert
bkeepers
jrom
soudai
lara