Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
完全に理解した incremetal 〜そして、何もわからないへ〜
Search
ikeda-masashi
May 10, 2022
Technology
2
4.9k
完全に理解した incremetal 〜そして、何もわからないへ〜
dbt Tokyo meetup #3
https://dbt-tokyo.connpass.com/event/246144/
ikeda-masashi
May 10, 2022
Tweet
Share
More Decks by ikeda-masashi
See All by ikeda-masashi
Redshiftを中心としたAWSでのデータ基盤
mashiike
0
130
運用の役立たないダッシュボードの作り方。
mashiike
3
940
Amazon Aurora MySQL と Amazon Redshift の Zero-ETL Integration について使い所を考えてみた!
mashiike
0
750
Warningアラートを放置しない!アラート駆動でログやメトリックを自動収集する仕組みによる恩恵
mashiike
6
3.9k
Prepalert ~Mackerelアラートにログや集計値を貼り付けてくれるトイル削減ツール~
mashiike
0
1.8k
人狼ゲームで考えるデータ基盤 〜データとはいったい・・・〜
mashiike
0
290
『エンタープライズ』という言葉の重さ 〜Data Vault 2.0をやめた2022年冬〜
mashiike
2
4.3k
Redshift ServerlessとProvisioned Cluster のちょっとした違い
mashiike
0
5.2k
「北欧、暮らしの道具店」のデータ基盤の変遷
mashiike
1
3.3k
Other Decks in Technology
See All in Technology
リアルタイム分析データベースで実現する SQLベースのオブザーバビリティ
mikimatsumoto
0
1.5k
Culture Deck
optfit
0
440
開発組織のための セキュアコーディング研修の始め方
flatt_security
3
2.6k
Classmethod AI Talks(CATs) #17 司会進行スライド(2025.02.19) / classmethod-ai-talks-aka-cats_moderator-slides_vol17_2025-02-19
shinyaa31
0
150
Helm , Kustomize に代わる !? 次世代 k8s パッケージマネージャー Glasskube 入門 / glasskube-entry
parupappa2929
0
260
レビューを増やしつつ 高評価維持するテクニック
tsuzuki817
1
790
N=1から解き明かすAWS ソリューションアーキテクトの魅力
kiiwami
0
130
運用しているアプリケーションのDBのリプレイスをやってみた
miura55
1
800
関東Kaggler会LT: 人狼コンペとLLM量子化について
nejumi
3
650
表現を育てる
kiyou77
1
220
抽象化をするということ - 具体と抽象の往復を身につける / Abstraction and concretization
soudai
26
13k
OpenID Connect for Identity Assurance の概要と翻訳版のご紹介 / 20250219-BizDay17-OIDC4IDA-Intro
oidfj
0
300
Featured
See All Featured
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.5k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
A Tale of Four Properties
chriscoyier
158
23k
A Philosophy of Restraint
colly
203
16k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Raft: Consensus for Rubyists
vanstee
137
6.8k
Why Our Code Smells
bkeepers
PRO
336
57k
Navigating Team Friction
lara
183
15k
Practical Orchestrator
shlominoach
186
10k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
114
50k
Transcript
{{ config(materialized=’incremental’) }} dbt Tokyo Meetup #3 5月10日(火曜日)11時〜12時 インクリメンタル https://developers.freee.co.jp/entry/understand-of-perfect-understandingより引用
『完全に理解した』、 〜そして、『何もわからない』へ〜 通称:ダニング ⹀クルーガー曲線 面白法人 カヤック 池田将士 ※ちなみに正式名称は株式会社です
自己紹介 池田 将士 (@mashiike) 技術部 SREチーム所属 職能、肩書きetc… • (自称)データエンジニア •
(仮称)アナリティクスエンジニア • SRE • サーバーサイドエンジニア Amazon S3 ※私のIconはS3バケットではありません
会社紹介 鎌倉の地にて、主にWeb技術を用いて 人の印象に深く残るような面白コンテンツを作る会社 ゲームからWebサービス、ミュージアムetc… 様々なことに挑戦
事業紹介 DBT + Data Vault 2.0 on Amazon Redshift 大会プラットフォームサービス『Tonamel』
Tonamelのデータ基盤にて
アジェンダ 1. DBTとMaterialization 2. {{ config(materialized=’incremental’) }} 『完全に理解した』 a. 基本的な使い方
b. ログ処理での例 3. {{ config(materialized=’incremental’) }}『なにもわからない』 a. カラムに変更が入ったら? b. 再処理したくなったら? c. upsertを実現するには? 4. incremental、それは... 今日のゴール
DBTとMaterialization DBTには4つのMaterializationが標準搭載されています( Custom materializationを作ることも可能)
DBTとMaterialization DBTには4つのMaterializationが標準搭載されています( Custom materializationを作ることも可能) • table: SELECTの結果を物理テーブル として保存する • view:
SELECTの結果を物理ビューと して保存する
DBTとMaterialization DBTには4つのMaterializationが標準搭載されています( Custom materializationを作ることも可能) • table: SELECTの結果を物理テーブル として保存する • view:
SELECTの結果を物理ビューと して保存する • ephemeral: 共通テーブル式(CTE)と して、他のモデルの実行時に埋め込ま れる
DBTとMaterialization DBTには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.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: ログ読み出しのパーティション • 初回実行時は全行ロード • 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-models A. on_schema_changeの設定に従った挙動をする
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時代のもので、おす すめはしない
Q.途中でカラムが増えてたら・・・ https://docs.getdbt.com/docs/building-a-dbt-project/building-models/configuring-incremental-models A. on_schema_changeの設定に従った挙動をする failを指定するとエラーになる 対応方法もちゃんと提示される
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
Q.途中でカラムが増えてたら・・・ https://docs.getdbt.com/docs/building-a-dbt-project/building-models/configuring-incremental-models A. on_schema_changeの設定に従った挙動をする sync_all_columnsを指定すると • 新しく列を追加したら Alterされる • 既存の列を削除したら
Alterされる ※当然のごとく 列削除 => 列をもとに戻す としても、元のデータは入ってない
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にて 書き換えて置くことをオススメ
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でOK unique_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 run parse (not execute) :
DBTの.sqlや.ymlを読み込んだり ref()を解析したりする。 主な成果物として manifest.jsonができる runtime (execute) : 実際にDWHに実行するための .sqlファイルのレンダリング、そして実行する .sqlのレンダリング materializationのレンダリング+実行( DRY RUNで実際にはDWHには何も実行されない) .sqlのレンダリング materializationのレンダリング+実行
ネタ解説 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が 実行できるの は、ここだけ
ネタ解説 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する必要。
ネタ解説 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.sql is_incremental()マクロは、Parse段階では常にFalse Runtime段階で、実際のDWH上の物理テーブルの存在を確認して、 実行時のフラグやmodelの状態もみて、True
or Falseを返している。 なので、この.sqlファイルはRuntimeの.sqlのレンダリング時にdeleteが実行される