Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

ikeda-masashi

May 10, 2022
Tweet

More Decks by ikeda-masashi

Other Decks in Technology

Transcript

  1. {{ config(materialized=’incremental’) }}
    dbt Tokyo Meetup #3
    5月10日(火曜日)11時〜12時
               インクリメンタル
    https://developers.freee.co.jp/entry/understand-of-perfect-understandingより引用
    『完全に理解した』、
    〜そして、『何もわからない』へ〜
    通称:ダニング
    ⹀クルーガー曲線
    面白法人 カヤック 池田将士
    ※ちなみに正式名称は株式会社です

    View Slide

  2. 自己紹介
    池田 将士 (@mashiike)
    技術部 SREチーム所属
    職能、肩書きetc…
    ● (自称)データエンジニア
    ● (仮称)アナリティクスエンジニア
    ● SRE
    ● サーバーサイドエンジニア
    Amazon S3
    ※私のIconはS3バケットではありません

    View Slide

  3. 会社紹介
    鎌倉の地にて、主にWeb技術を用いて
    人の印象に深く残るような面白コンテンツを作る会社
    ゲームからWebサービス、ミュージアムetc…
    様々なことに挑戦

    View Slide

  4. 事業紹介
    DBT + Data Vault 2.0 on Amazon Redshift
    大会プラットフォームサービス『Tonamel』
    Tonamelのデータ基盤にて

    View Slide

  5. アジェンダ
    1. DBTとMaterialization
    2. {{ config(materialized=’incremental’) }} 『完全に理解した』
    a. 基本的な使い方
    b. ログ処理での例
    3. {{ config(materialized=’incremental’) }}『なにもわからない』
    a. カラムに変更が入ったら?
    b. 再処理したくなったら?
    c. upsertを実現するには?
    4. incremental、それは...
    今日のゴール

    View Slide

  6. DBTとMaterialization
    DBTには4つのMaterializationが標準搭載されています( Custom materializationを作ることも可能)

    View Slide

  7. DBTとMaterialization
    DBTには4つのMaterializationが標準搭載されています( Custom materializationを作ることも可能)
    ● table:  SELECTの結果を物理テーブル
    として保存する
    ● view:  SELECTの結果を物理ビューと
    して保存する

    View Slide

  8. DBTとMaterialization
    DBTには4つのMaterializationが標準搭載されています( Custom materializationを作ることも可能)
    ● table:  SELECTの結果を物理テーブル
    として保存する
    ● view:  SELECTの結果を物理ビューと
    して保存する
    ● ephemeral:  共通テーブル式(CTE)と
    して、他のモデルの実行時に埋め込ま
    れる

    View Slide

  9. DBTとMaterialization
    DBTには4つのMaterializationが標準搭載されています( Custom materializationを作ることも可能)
    ● table:  SELECTの結果をDBテーブルと
    して保存する
    ● view:  SELECTの結果をDBビューと
    して保存する
    ● incremental: なんかいい感じに
    物理テーブルを更新してくれるやつ!!(雑)
    ● ephemeral:  共通テーブル式(CTE)と
    して、他のモデルの実行時に埋め込ま
    れる

    View Slide

  10. Q. 『いい感じに』って具体的にどういう事?

    View Slide

  11. Q. 『いい感じに』って具体的にどういう事?
    初回実行時

    View Slide

  12. Q. 『いい感じに』って具体的にどういう事?
    初回実行時
    2回目以降

    View Slide

  13. Q. 『いい感じに』って具体的にどういう事?
    初回実行時
    2回目以降
    なんか!
    いい感じに!!
    Tableを更新してる!!!!

    View Slide

  14. つまり・・・
    ● 初回実行時は赤枠の中を描画しない で
    CREATE TABLE
    ● 2回目以降は赤枠の中を描画して
    INSERT TABLE

    View Slide

  15. つまり・・・
    ● 初回実行時は赤枠の中を描画しない で
    CREATE TABLE
    ● 2回目以降は赤枠の中を描画して
    INSERT TABLE
    {{ config(materialized=’incremental’) }} とは
    1つのモデルを、1つの物理テーブルとして実現し      
    継続的に更新し続けるものなり!

    View Slide

  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: ログ読み出しのパーティション
    ● 初回実行時は全行ロード
    ● 2回目以降は直近7日の未ロードのみ
    ※Redshift Spectrumを用いて読んでいて、
    重複がなく、request_idで識別できることを想定した例です。

    View Slide

  17. {{ config(materialized=’incremental’) }}
    完全に理解した!!!
    通称:ダニング
    ⹀クルーガー曲線
    きっと今この辺

    View Slide

  18. {{ config(materialized=’incremental’) }} とは
    1つのモデルを、1つの物理テーブルとして実現し
    継続的に更新し続けるもの
     

    View Slide

  19. {{ config(materialized=’incremental’) }} とは
    1つのモデルを、1つの物理テーブルとして実現し
    継続的に更新し続けるもの
     
    つまり、運用が発生する

    View Slide

  20. {{ config(materialized=’incremental’) }} とは
    1つのモデルを、1つの物理テーブルとして実現し
    継続的に更新し続けるもの
     
    つまり、運用が発生する
    a. 途中でカラムが増えてたら・・・
    b. 再処理したくなったら・・・
    c. upsertを実現するには・・・
    etc.
    例えば、運用中にこんな事思ったりしません?

    View Slide

  21. ようこそ!
    通称:ダニング
    ⹀クルーガー曲線
    きっと今この辺
    『何もわからない』への扉へ
    {{ config(materialized=’incremental’) }}

    View Slide

  22. ようこそ!
    通称:ダニング
    ⹀クルーガー曲線
    きっと今この辺
    『何もわからない』への扉へ
    {{ config(materialized=’incremental’) }}
    incrementalの難しさは運用にあり

    View Slide

  23. Q.途中でカラムが増えてたら・・・
    https://docs.getdbt.com/docs/building-a-dbt-project/building-models/configuring-incremental-models
    A. on_schema_changeの設定に従った挙動をする

    View Slide

  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時代のもので、おす
    すめはしない

    View Slide

  25. Q.途中でカラムが増えてたら・・・
    https://docs.getdbt.com/docs/building-a-dbt-project/building-models/configuring-incremental-models
    A. on_schema_changeの設定に従った挙動をする
    failを指定するとエラーになる
    対応方法もちゃんと提示される

    View Slide

  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

    View Slide

  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される
    ※当然のごとく
    列削除 => 列をもとに戻す
    としても、元のデータは入ってない

    View Slide

  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にて
    書き換えて置くことをオススメ

    View Slide

  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を駆使して頑張る

    View Slide

  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するようになったりする

    View Slide

  31. (具体的にどうしたらいいのか?)
    『何もわからない』!!!
    通称:ダニング
    ⹀クルーガー曲線
    きっと今この辺
    {{ config(materialized=’incremental’) }}

    View Slide

  32. 基本のmaterializationの4つ
    ● table
    ● view
    ● ephemeral
    ● incremental
    物理テーブルや物理ビューを洗替する
    物理的なモノが存在しない
    物理テーブルを継続して更新し、運用する

    View Slide

  33. 基本のmaterializationの4つ
    ● table
    ● view
    ● ephemeral
    ● incremental
    物理テーブルや物理ビューを洗替する
    物理的なモノが存在しない
    物理テーブルを継続して更新し、運用する
    一つの物理テーブルの変更操作を、 1つのモデルに抽象化する
    抽象化=ソフトウェア開発のベストプラクティスの一つ

    View Slide

  34. 基本のmaterializationの4つ
    ● table
    ● view
    ● ephemeral
    ● incremental
    物理テーブルや物理ビューを洗替する
    物理的なモノが存在しない
    物理テーブルを継続して更新し、運用する
    一つの物理テーブルの変更操作を、 1つのモデルに抽象化する
    抽象化=ソフトウェア分析のベストプラクティスの一つ
    incremental、それは・・・

    View Slide

  35. 基本のmaterializationの4つ
    ● table
    ● view
    ● ephemeral
    ● incremental
    物理テーブルや物理ビューを洗替する
    物理的なモノが存在しない
    物理テーブルを継続して更新し、運用する
    一つの物理テーブルの変更操作を、 1つのモデルに抽象化する
    抽象化=ソフトウェア分析のベストプラクティスの一つ
    incremental、それは・・・
    Analytics Engineeringの真髄の一端だった。

    View Slide

  36. ご清聴ありがとうございました。

    View Slide

  37. 以降、ただのネタ

    View Slide

  38. 同じ結果になります
    左と右の違いは・・・drop table if exists … cascade
    左は依存先のDB Viewがcascadeドロップされない。

    View Slide

  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のレンダリング+実行

    View Slide

  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が
    実行できるの
    は、ここだけ

    View Slide

  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する必要。

    View Slide

  42. ネタ解説
    Parseの段階で、DWH上に実際に物理テーブルの存在を確認することはできない
    macroを使わずに1ファイルでtableもどきを作るには、runtimeの.sqlのレンダリング段階
    で、物理テーブルの rowをdeleteする必要。

    View Slide

  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が実行される

    View Slide