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
5.2k
完全に理解した 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
180
運用の役立たないダッシュボードの作り方。
mashiike
3
1k
Amazon Aurora MySQL と Amazon Redshift の Zero-ETL Integration について使い所を考えてみた!
mashiike
0
850
Warningアラートを放置しない!アラート駆動でログやメトリックを自動収集する仕組みによる恩恵
mashiike
6
4.1k
Prepalert ~Mackerelアラートにログや集計値を貼り付けてくれるトイル削減ツール~
mashiike
0
1.9k
人狼ゲームで考えるデータ基盤 〜データとはいったい・・・〜
mashiike
0
350
『エンタープライズ』という言葉の重さ 〜Data Vault 2.0をやめた2022年冬〜
mashiike
2
4.8k
Redshift ServerlessとProvisioned Cluster のちょっとした違い
mashiike
0
6.1k
「北欧、暮らしの道具店」のデータ基盤の変遷
mashiike
1
3.5k
Other Decks in Technology
See All in Technology
マーケットプレイス版Oracle WebCenter Content For OCI
oracle4engineer
PRO
3
900
Абьюзим random_bytes(). Фёдор Кулаков, разработчик Lamoda Tech
lamodatech
0
350
Windows 11 で AWS Documentation MCP Server 接続実践/practical-aws-documentation-mcp-server-connection-on-windows-11
emiki
0
1k
PHPでWebブラウザのレンダリングエンジンを実装する
dip_tech
PRO
0
210
"サービスチーム" での技術選定 / Making Technology Decisions for the Service Team
kaminashi
1
150
セキュリティの民主化は何故必要なのか_AWS WAF 運用の 10 の苦悩から学ぶ
yoh
1
180
2025-06-26_Lightning_Talk_for_Lightning_Talks
_hashimo2
2
100
生成AI時代の開発組織・技術・プロセス 〜 ログラスの挑戦と考察 〜
itohiro73
1
270
SalesforceArchitectGroupOsaka#20_CNX'25_Report
atomica7sei
0
190
5min GuardDuty Extended Threat Detection EKS
takakuni
0
150
AWS Summit Japan 2025 Community Stage - App workflow automation by AWS Step Functions
matsuihidetoshi
1
280
「Chatwork」の認証基盤の移行とログ活用によるプロダクト改善
kubell_hr
1
190
Featured
See All Featured
Why You Should Never Use an ORM
jnunemaker
PRO
57
9.4k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Done Done
chrislema
184
16k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.8k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
124
52k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Stop Working from a Prison Cell
hatefulcrawdad
270
20k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
107
19k
Balancing Empowerment & Direction
lara
1
380
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
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が実行される