この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
さがらです。
2022年3月10日に、はじめてのdbt活用～DWH内のデータ整備が楽になる！～といったタイトルでウェビナーを開催しました。
私はdbtのデモを担当しましたが、たくさんの方にご参加いただき質問も多く頂けて嬉しかったです！
本記事では、このウェビナーの内容を簡単にまとめた上で、時間の関係上回答出来なかった質疑応答の回答をまとめていきます。
MDS : Modern Data Stackとは
弊社の玉井より、クラウドを用いたSaaS製品を組み合わせて構築するModern Data Stackについて、これまでのデータ基盤の流れと合わせて説明しました。
また、玉井より説明がありましたdbtを使用するメインの職種でもある「アナリティクスエンジニア」については、以前に弊社主催のイベントで玉井が登壇して話をしておりますのでこちらもぜひ御覧ください。
他にも、Modern Data Stackに関するレポート記事がありますので、併せて御覧ください。
dbt概要とデモンストレーション
私さがらより、dbtの概要を説明と、dbtでの実際の開発の流れをデモンストレーションしました。
dbtは一言でいうと、データマート開発を効率よく行う事ができるツールです。
何も考えずにがむしゃらにデータマートの開発を行うと、定義不明のSQLやETLツールのジョブが大量発生し、データの信頼性が失われ、最悪せっかく構築したデータ基盤が使われない、という事態を招くリスクがあります。
そんな課題をすべて解消することができるツールがdbtです。特別な知識を必要とせず、アプリケーションの開発手法を用いたデータマートの開発が可能となります。
そして今回私がデモをした内容ですが、実はdbtが用意しているチュートリアルに沿った内容なのです！
玉井がすでにこのチュートリアルを試したブログを書いておりますので、自分でも試してみたい方は、ぜひこの記事を参考に試して頂けると良いと思います。（私のデモではDWHはSnowflakeを使用しましたが、元のサンプルデータはBigQuery上にあります。）
質疑応答
今回のウェビナーでは、大変多くの質問を頂きました。出来れば全てウェビナー中に回答できればよかったのですが、お時間が足りずご迷惑をおかけしました。
以下、ウェビナー中に口頭で回答した内容も含め、全ての質問への回答を記載しておりますので、御覧ください。
1.本日の講演資料は後日公開されるのでしょうか？
資料は本日参加して頂いた方に対して、ウェビナー翌日(3/11)を目処に送付させて頂く予定となっております。
2.アナリティクスエンジニアってデータスチュアートと似てる気がするんですがなにか違いのポイントってあるんでしょうか？
データスチュアートは、データそのものの方針（データの担当者、扱い方、アクセス権限など）を決めることが主な役割だと考えます。対して、アナリティクスエンジニアは、データ分析のために必要なデータを、コード（SQL）を書いて、実際に作成・変換することが主な役割となっています。
3.Github以外のバージョン管理サービスもあると思いますがベストプラクティスがありましたらお伺いしたいです。
「dbtだったらこのGitサービスが良い」というのは特にありません。GithubでもGitlabでも、馴染みのあるGitサービスをお使いいただければ問題ありません。
4.dbtのプロジェクトはどのような単位で作成するものでしょうか？
特に「こういう分け方をしなさい」というものはありません。会社や組織による、というのが正直なところです。
参考として、dbt社自身は下記のような方針でプロジェクトを分けているので、御覧ください。
5.他のETLツールの”T”を使うのと大きな違いのポイントあれば教えてもらえないでしょうか？
dbtの大きなポイントとしては「ソフトウェア開発のベストプラクティス」を取り入れているところです。Gitによるバージョン管理や、自動テスト等、ソフトウェア開発で当たり前のように行われている手法を、データ変換の世界に取り入れています。
6.テーブルの細かい定義（主キー制約やデータ型やNULL制約など）は設定できるのでしょうか
制約というわけではありませんが、not nullや参照整合性のテストができますので、このテストをもって、事実上制約をかけることはできます。
7.dbtとSnowflakeの接続はどのようになっているのでしょうか。同じようにredshiftなど他のDWHでも利用できますか？
対象のSnowflakeのアカウント情報と、ユーザーID＆PW、またはKey pairの情報があれば、Snowflakeは接続可能です。
Redshiftも接続可能です。公式Docに方法が書いてありますので、こちらも併せて御覧ください。
8.スクラッチで開発しているCRMシステムに対してデータ分析基盤を作成する場合のつまづきやすい部分はどのようなところでしょうか。
スクラッチで開発されている場合は、S3などのストレージサービスに対象システムのデータを吐き出して、その後に使用されているDWHにロードする、という流れが多いかと思います。
この際、「S3などのストレージサービスに対してどうやってデータを吐き出していくか」、この設計が重要となるため、つまづきやすいポイントになるかと思います。
9.Cloud版とCLI版の機能に大きな違いがあれば教えていただけないでしょうか。
こちらの記事でまとめておりますので、ぜひ御覧ください。
10.dbt ビルド後の Documentation にテーブルカラムのデータ型の記述があったように見えましたがデータソースのテーブルのカラムの追加削除があった場合dbt の schema.yaml かなにかも更新する必要があるのでしょうか？自動で Documentation も更新されるのでしょうか？
schema.ymlではカラムごとに定義を行う必要があるので、カラムの追加削除が合った場合は、schema.ymlの更新が必要となります。
11.dbt coreだけで使う場合dbt cloudと比べて機能的な制限はありますでしょうか？
機能的な制限としてはないのですが、事前に用意するものが大きく変わってきます。 dbt CoreはOSSですので、dbt Coreを動かすサーバー、実行するためのワークフロー(Airflowなど)、Gitリポジトリ、等を用意するなどが必要です。
こちらの記事も参考になると思いますので、併せて御覧ください。
12.dbtのJob中に実行されたクエリに関するメタデータ（実行秒数など）もdbtのIDE上でみれるものなのでしょうか？それともテーブルやビューに関する定義が中心となるのでしょうか？
ジョブの実行管理画面で、実行秒数などは確認可能となっております。
13.自社では Apache Airflow でデータマート作成のワークフローを構築しています。Airflow から dbt への移行または併用を検討するにあたってdbt と Airflow それぞれが向いているユースケースなどあれば伺えると嬉しいです。
dbt Coreの場合は、Airflowなどのワークフロー管理ツールとの併用がほぼ必須となります。
一方で、dbt Cloudの場合は、Airflowで実行している処理内容にもよりますが、全てdbt Cloudへ移行は可能です。 注意すべき点としては、Airflowで、SQLやdbtのJinjaといったdbtで出来ることだけで処理できないことを実行している場合は、移行が難しい可能性がございます。
14.脱線しますがModeって何？と気になりました。ブラウザで検索してもあまり情報がないのですね。
SQLを用いてデータモデリングし、Pythonなどを使った分析も可能な、BIに留まらない分析プラットフォーム、のようなSaaS製品です。
3/9のAKIBA.SaaSというイベントで、弊社のエンジニアが登壇してModeについて紹介しており、後日登壇ブログが投稿されるかと思います。よろしければこちらのブログも投稿後にぜひ御覧ください。
15.デモでは作ったモデルを JOIN 句で直接 ref 参照せずwith 句の中で参照されていたかと思うのですがどちらが良いなど理由があれば教えて下さい！
今回のデモでは元のクエリとの比較がしやすいように、WITH句の中身をrefを参照するSELECT文に書き換えるだけの形でお見せしました。dbtのチュートリアルもこの形式を取っております。
どちらの形式でも問題はないため、お好みで良いと思います。
16.GCP環境でdbtを導入予定なのですがdbtと組み合わせるワークフローとしてはどの組み合わせがベターでしょうか？ cloud composerはコストが高いのでそれ以外で笑
運用面を考慮するとマネージドサービスを使う方が良いと思いますので、Cloud Composerを使用することを推奨します。 一方でコストがどうしても気になる場合は、自身でGCEやGKEでインスタンスを立ち上げて、Airflowなどのワークフロー管理サービスをインストールして使用するしか無いと思います。
ウェビナーを終えて
まず、１つのウェビナーでここまでの質問を頂けたのは初めてでした。（嬉しい悲鳴ですｗ）
やはり最近dbtの注目度が急上昇しているため、多くの方に参加いただき、質問も多く頂けたのかなと感じております。
引き続き私もdbtの情報発信を頑張っていきますので、その際はぜひご覧頂けると嬉しいです！
4
