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