完全に理解した incremetal 〜そして、何もわからないへ〜

dbt Tokyo meetup #3

https://dbt-tokyo.connpass.com/event/246144/

Transcript

1. {{ config(materialized=’incremental’) }} dbt Tokyo Meetup #3 5月10日（火曜日）11時〜12時 　　　　　　　　　　　インクリメンタル https://developers.freee.co.jp/entry/understand-of-perfect-understandingより引用 『完全に理解した』、 〜そして、『何もわからない』へ〜 通称：ダニング ⹀クルーガー曲線 面白法人 カヤック 池田将士 ※ちなみに正式名称は株式会社です
2. 自己紹介 池田 将士 (@mashiike) 技術部 SREチーム所属 職能、肩書きetc… • (自称)データエンジニア • (仮称)アナリティクスエンジニア • SRE • サーバーサイドエンジニア Amazon S3 ※私のIconはS3バケットではありません
3. 会社紹介 鎌倉の地にて、主にWeb技術を用いて 人の印象に深く残るような面白コンテンツを作る会社 ゲームからWebサービス、ミュージアムetc… 様々なことに挑戦
4. 事業紹介 DBT + Data Vault 2.0 on Amazon Redshift 大会プラットフォームサービス『Tonamel』 Tonamelのデータ基盤にて
5. アジェンダ 1. DBTとMaterialization 2. {{ config(materialized=’incremental’) }} 『完全に理解した』 a. 基本的な使い方 b. ログ処理での例 3. {{ config(materialized=’incremental’) }}『なにもわからない』 a. カラムに変更が入ったら？ b. 再処理したくなったら？ c. upsertを実現するには？ 4. incremental、それは... 今日のゴール
6. DBTとMaterialization DBTには４つのMaterializationが標準搭載されています（ Custom materializationを作ることも可能）
7. DBTとMaterialization DBTには４つのMaterializationが標準搭載されています（ Custom materializationを作ることも可能） • table: 　SELECTの結果を物理テーブル として保存する • view: 　SELECTの結果を物理ビューと して保存する
8. DBTとMaterialization DBTには４つのMaterializationが標準搭載されています（ Custom materializationを作ることも可能） • table: 　SELECTの結果を物理テーブル として保存する • view: 　SELECTの結果を物理ビューと して保存する • ephemeral: 　共通テーブル式（CTE)と して、他のモデルの実行時に埋め込ま れる
9. DBTとMaterialization DBTには４つのMaterializationが標準搭載されています（ Custom materializationを作ることも可能） • table: 　SELECTの結果をDBテーブルと して保存する • view: 　SELECTの結果をDBビューと して保存する • incremental:　なんかいい感じに 物理テーブルを更新してくれるやつ！！（雑） • ephemeral: 　共通テーブル式（CTE)と して、他のモデルの実行時に埋め込ま れる
10. Q. 『いい感じに』って具体的にどういう事？
11. Q. 『いい感じに』って具体的にどういう事？ 初回実行時
12. Q. 『いい感じに』って具体的にどういう事？ 初回実行時 2回目以降
13. Q. 『いい感じに』って具体的にどういう事？ 初回実行時 2回目以降 なんか！ いい感じに！！ Tableを更新してる！！！！
14. つまり・・・ • 初回実行時は赤枠の中を描画しない で CREATE TABLE • ２回目以降は赤枠の中を描画して INSERT TABLE
15. つまり・・・ • 初回実行時は赤枠の中を描画しない で CREATE TABLE • ２回目以降は赤枠の中を描画して INSERT TABLE {{ config(materialized=’incremental’) }}　とは １つのモデルを、１つの物理テーブルとして実現し　　　　　　 継続的に更新し続けるものなり！
16. 実例:ログの処理の例 schema.yml version: 2 sources: - name: log tables: - name: nginx_access_logs description: nginxのアクセスログ columns: - name: time description: アクセス時刻 - name: method description: リクエストメソッド - name: uri description: リクエストされた URI - name: protocol description: リクエストのプロトコル - name: status description: レスポンスステータスコード - name: vhost description: リクエストされたホスト名 - name: request_id description: リクエストID - name: partition_date description: ログ読み出しのパーティション • 初回実行時は全行ロード • ２回目以降は直近７日の未ロードのみ ※Redshift Spectrumを用いて読んでいて、 重複がなく、request_idで識別できることを想定した例です。
17. {{ config(materialized=’incremental’) }} 完全に理解した！！！ 通称：ダニング ⹀クルーガー曲線 きっと今この辺
18. {{ config(materialized=’incremental’) }}　とは １つのモデルを、１つの物理テーブルとして実現し 継続的に更新し続けるもの 　
19. {{ config(materialized=’incremental’) }}　とは １つのモデルを、１つの物理テーブルとして実現し 継続的に更新し続けるもの 　 つまり、運用が発生する
20. {{ config(materialized=’incremental’) }}　とは １つのモデルを、１つの物理テーブルとして実現し 継続的に更新し続けるもの 　 つまり、運用が発生する a. 途中でカラムが増えてたら・・・ b. 再処理したくなったら・・・ c. upsertを実現するには・・・ etc. 例えば、運用中にこんな事思ったりしません？
21. ようこそ！ 通称：ダニング ⹀クルーガー曲線 きっと今この辺 『何もわからない』への扉へ {{ config(materialized=’incremental’) }}
22. ようこそ！ 通称：ダニング ⹀クルーガー曲線 きっと今この辺 『何もわからない』への扉へ {{ config(materialized=’incremental’) }} incrementalの難しさは運用にあり
23. Q.途中でカラムが増えてたら・・・ https://docs.getdbt.com/docs/building-a-dbt-project/building-models/configuring-incremental-models A. on_schema_changeの設定に従った挙動をする
24. Q.途中でカラムが増えてたら・・・ https://docs.getdbt.com/docs/building-a-dbt-project/building-models/configuring-incremental-models A. on_schema_changeの設定に従った挙動をする デフォルトはignoreで何もしない • 新しく列を追加しても Alterされない • 既存の列を削除しても Alterされない ※モデルの更新が成功するかは targetのtypeによる。 この挙動はv0時代のもので、おす すめはしない
25. Q.途中でカラムが増えてたら・・・ https://docs.getdbt.com/docs/building-a-dbt-project/building-models/configuring-incremental-models A. on_schema_changeの設定に従った挙動をする failを指定するとエラーになる 対応方法もちゃんと提示される
26. Q.途中でカラムが増えてたら・・・ https://docs.getdbt.com/docs/building-a-dbt-project/building-models/configuring-incremental-models A. on_schema_changeの設定に従った挙動をする append_ new_columnsを指定すると • 新しく列を追加したら Alterされる • 既存の列を削除しても Alterされない ※削除された列は、 Insertのクエリから 省かれるので、基本的には NULL
27. Q.途中でカラムが増えてたら・・・ https://docs.getdbt.com/docs/building-a-dbt-project/building-models/configuring-incremental-models A. on_schema_changeの設定に従った挙動をする sync_all_columnsを指定すると • 新しく列を追加したら Alterされる • 既存の列を削除したら Alterされる ※当然のごとく 列削除　＝＞　列をもとに戻す としても、元のデータは入ってない
28. Q.途中でカラムが増えてたら・・・ https://docs.getdbt.com/docs/building-a-dbt-project/building-models/configuring-incremental-models A. on_schema_changeの設定に従った挙動をする 基本的にデフォルト挙動を sync_all_columns もしくは append_new_columns にしてdbt_project.ymlにて 書き換えて置くことをオススメ
29. Q.再処理したくなったら・・・ A.--full-refresh もしくは、頑張る https://docs.getdbt.com/docs/building-a-dbt-project/building-models/configuring-incremental-models 全部まるまる作り直すなら –full-refresh ログ処理等で、一分のデータだけ処理したいなら macroやpre_hook、varを駆使して頑張る
30. Q.upsertを実現するには・・・ A. incremental_strategyとunique_keyを用いて実現 https://docs.getdbt.com/docs/building-a-dbt-project/building-models/configuring-incremental-models ※incremental_strategyはtargetのtypeによって使える ものが変わる 基本的にはmergeでOK unique_keyを指定すると以下のように deleteしてから insertするようになったりする
31. (具体的にどうしたらいいのか？） 『何もわからない』！！！ 通称：ダニング ⹀クルーガー曲線 きっと今この辺 {{ config(materialized=’incremental’) }}
32. 基本のmaterializationの4つ • table • view • ephemeral • incremental 物理テーブルや物理ビューを洗替する 物理的なモノが存在しない 物理テーブルを継続して更新し、運用する
33. 基本のmaterializationの4つ • table • view • ephemeral • incremental 物理テーブルや物理ビューを洗替する 物理的なモノが存在しない 物理テーブルを継続して更新し、運用する 一つの物理テーブルの変更操作を、 1つのモデルに抽象化する 抽象化＝ソフトウェア開発のベストプラクティスの一つ
34. 基本のmaterializationの4つ • table • view • ephemeral • incremental 物理テーブルや物理ビューを洗替する 物理的なモノが存在しない 物理テーブルを継続して更新し、運用する 一つの物理テーブルの変更操作を、 1つのモデルに抽象化する 抽象化＝ソフトウェア分析のベストプラクティスの一つ incremental、それは・・・
35. 基本のmaterializationの4つ • table • view • ephemeral • incremental 物理テーブルや物理ビューを洗替する 物理的なモノが存在しない 物理テーブルを継続して更新し、運用する 一つの物理テーブルの変更操作を、 1つのモデルに抽象化する 抽象化＝ソフトウェア分析のベストプラクティスの一つ incremental、それは・・・ Analytics Engineeringの真髄の一端だった。
36. ご清聴ありがとうございました。
37. 以降、ただのネタ
38. 同じ結果になります 左と右の違いは・・・drop table if exists … cascade 左は依存先のDB Viewがcascadeドロップされない。
39. ネタ解説 dbt run の挙動は実は以下のような流れになってる dbt run parse (not execute) : DBTの.sqlや.ymlを読み込んだり ref()を解析したりする。 主な成果物として manifest.jsonができる runtime (execute) : 実際にDWHに実行するための .sqlファイルのレンダリング、そして実行する .sqlのレンダリング materializationのレンダリング＋実行（ DRY RUNで実際にはDWHには何も実行されない） .sqlのレンダリング materializationのレンダリング＋実行
40. ネタ解説 dbt run の挙動は実は以下のような流れになってる dbt run parse (not execute) : DBTの.sqlや.ymlを読み込んだり ref()を解析したりする。 主な成果物として manifest.jsonができる runtime (execute) : 実際にDWHに実行するための .sqlファイルのレンダリング、そして実行する .sqlのレンダリング materializationのレンダリング＋実行（ DRY RUNで実際にはDWHには何も実行されない） .sqlのレンダリング materializationのレンダリング＋実行 configの中身が 書き換えられる のはこのだけ DWHにSQLが 実行できるの は、ここだけ
41. ネタ解説 dbt run の挙動は実は以下のような流れになってる dbt run parse (not execute) : DBTの.sqlや.ymlを読み込んだり ref()を解析したりする。 主な成果物として manifest.jsonができる runtime (execute) : 実際にDWHに実行するための .sqlファイルのレンダリング、そして実行する .sqlのレンダリング materializationのレンダリング＋実行（ DRY RUNで実際にはDWHには何も実行されない） .sqlのレンダリング materializationのレンダリング＋実行 configの中身が 書き換えられる のはこのだけ DWHにSQLが 実行できるの は、ここだけ Parseの段階で、DWH上に実際に物理テーブルの存在を確認することはできない macroを使わずに1ファイルでtableもどきを作るには、runtimeの.sqlのレンダリング段階 で、物理テーブルの rowをdeleteする必要。
42. ネタ解説 Parseの段階で、DWH上に実際に物理テーブルの存在を確認することはできない macroを使わずに1ファイルでtableもどきを作るには、runtimeの.sqlのレンダリング段階 で、物理テーブルの rowをdeleteする必要。
43. ネタ解説 Parseの段階で、DWH上に実際に物理テーブルの存在を確認することはできない macroを使わずに1ファイルでtableもどきを作るには、runtimeの.sqlのレンダリング段階 で、物理テーブルの rowをdeleteする必要。 https://github.com/dbt-labs/dbt-core/blob/main/core/dbt/include/global_project/ macros/materializations/models/incremental/is_incremental.sql is_incremental()マクロは、Parse段階では常にFalse Runtime段階で、実際のDWH上の物理テーブルの存在を確認して、 実行時のフラグやmodelの状態もみて、True or Falseを返している。 なので、この.sqlファイルはRuntimeの.sqlのレンダリング時にdeleteが実行される