2025年にDataformを使うことへの葛藤などなど
どうも。マイベストのデータエンジニア snhryt です。[1] 今回の記事の主役はこちら↓
なんやかんやDataformと4年来の付き合いな私。 コミッターをしているとか、そんな立派な貢献ができているわけではないのですが、ミドルユーザーの端くれとして、今のDataformについて思うことや昔話を書いてみます。
TL;DR
- DataformでTransformationに求められる大体のことは実現できる。ただし、もどかしい部分は結構ある
- これからデータ基盤を構築しようとしている人で、もし導入のしやすさだけで安直にDataformを採用しようとしているなら、一度立ち止まって考えてみてほしい
- 私はDataformを使う。今はまだ
Data Transformationツール情勢
世界のModern Data Stackをまとめている The Modern Data Stack Repository では、Dataformは “Data Modeling and Transformation” というカテゴリに位置づけられています。同カテゴリの顔ぶれと、それぞれのハート数を見てみましょう↓
うーん、残酷w まぁ、Athenaとハート数で並んでいるのでよしとしましょう
このカテゴリでは、dbtが世界でも日本でも圧倒的なデファクト・スタンダードになっています。[2]
TROCCO, Airbyte, Fivetran, OpenMetadata, Dagsterなどの著名なツールがdbt連携機能を提供していたり、Terraformでdbt Cloudがデプロイできるようになったりと、取り巻く環境も実にdbtフレンドリーです。また、dbt自体もSemantic Layer, microbatchなどの魅力的な新機能が搭載され、着々とツールとしての進化を遂げています。
また、「漢は黙ってBigQuery」の時代が崩れ始め、SnowflakeやDatabricksが台頭しはじめています。そんな時代ですので、BigQueryにしか対応していないDataformは、そもそも選択肢にすらあがらないケースも増えているように感じます。
dbt, Dataformに続くTransformationツールとして期待されていたSDFは、なんと、年明けにdbtに買収されました・・!
Dataform vs dbt
イントロからすっかりDataform sage↓な形で入ってしまいましたが、Dataformにも独自かつ最大の強みがあります。それは サービス利用料が無料で[3]、Transformationに求められる大体のことができる という点です。
dbtの場合、CLI版をセルフホストして使う分には無料ですが、クラウド版は決して安くない金額が、人数に対して従量課金で発生します。対するDataformのクラウド版は、Google Cloud上でIAMさえ発行すれば人数制限なく無料で使うことができます。
これだけ価格差があると、機能差もそれだけあるように思ってしまいますが、個人的には価格差ほど機能差があるとは思いません。仮にdbt Cloudを100点だとすると、Dataformは赤点(〜40点)とかのラインではなく、しっかり60点は超えて及第点に達していると思います。
Dataformとdbtの細かい機能比較に関しては、若干古い記事にはなりますが、以下が分かりやすいです。
ここが辛いよDataform
さて、本題です。前述のとおり、Transformationツールに求められる一定の機能がDataformには備わっています。ただ、ちょっと物足りない。なんかむず痒い。 そんな、私が1ユーザーとして直面した(している)ポイントを紹介します。
以下、読み進めるうえで必要なDataformの最低限の知識です。
- Google Cloudのサービスとして(GUIを伴う形で)提供されているクラウド版と、ローカルでも動作可能なCLI版がある
- クラウド版とCLI版を併用することもできる(クラウド版で接続しているリポジトリをローカルにcloneして、各種CLIコマンドを使うだけ)
- クラウド版にはスケジューリング機能が備わっているので、単体でクエリの定期実行まで完結可能。CLI版はどこかにセルフホストして、何らかのサービスと組み合わせないと定期実行はできない
ここが辛いよクラウド版
コード管理できない部分がある
- 定期実行を司る「リリース構成」と「ワークフロー構成」の設定を(連携しているリポジトリ内で)コード管理できない
- 公式ドキュメントにも、コードのコの字も書かれていない
- 一応コード管理できなくはないが、邪道だったり大変だったり
- 案1: Dataform APIに投げるPOSTリクエストの内容を管理する(参考)
- 案2: Dataformのリポジトリ自体をTerraformのリソースとして管理する
よくあるユースケースなのに動かない不具合(仕様?)がある
-
declare
を含むクエリのプレビューができない- incrementalテーブルを作成するときに
pre_operations
による日付定義は頻繁に使うので普通に困る
- incrementalテーブルを作成するときに
Notification機能が内包されていない
- 公式からCloud Loggingを使う方法が案内されているが、設定がめんどくさい(ドキュメントが読む気なくなる・・)&通知のUXが貧弱
- となると、自前で通知の機構を開発したくなるが、ワークフロー自体の成功/失敗のログしか取得ができず、どのファイル(テーブル)でコケたのかはログに現れない[4]
初心者泣かせのUX
- 「実行」と「RUN」の違い
どっちがプレビューでどっちが実行(テーブルの更新)かわかりますか? - その他にもガバガバ和訳。例: 「依存関係」と「依存者」
どっちがdependencyでどっちがdependentかわかりますか?(私は、ヒントを見てもよくわかりませんでした・・・)
エディターがしょぼい
- タブの左右分割表示ができない
- 関数のサジェスト機能がない(BigQueryのクエリエディタにはある)
- カラム名のサジェスト機能があるが、ちょっとおマヌケ(BigQueryのクエリエディタはもうちょっと賢い)
- Geminiによるコード生成機能があるが、使い物にならない(
ref
を使ったDataformのお作法に倣う書き方は全くしてくれない)
ここが辛いよCLI版
上記クラウド版の難点から逃げるべく、あるいはより自由を求めてCLI版に乗り換えたとしても、今度はまた別の苦悩が待ち受けます。
CLIではできないことがある
- dependency/dependentの一覧確認(クラウド版でいうところの"メタデータ")
- DAGの描画(クラウド版でいうところの"COMPILED GRAPH")
- コンパイル後のクエリ確認
- これは、できなくはないが、何個か手順を踏まないといけない(参考)
- dry-run時のエラーログも、コンパイル後のクエリの何行目に〜という表現なので、コンパイル後のクエリがぱっと見れないとトラシューも進めづらい
- 実行結果のプレビュー(クラウド版でいうところの"RUN")
- これも、上記のコンパイル後のクエリ確認と
bq
コマンドを組み合わせればできなくはない
- これも、上記のコンパイル後のクエリ確認と
遭遇率が極めて高い不具合が放置され続けている
新規作成するテーブルに関して、configブロックにdescriptionが入っているとdry-runに失敗する という、単純かつクリティカルな不具合がもう半年以上放置されています。
たったこれだけのコードで再現できてしまう、シンプルな不具合です。
config {
type: "table",
schema: "mart",
description: "hogehogehoge"
}
select
"hoge" as hoge
開発環境が整えづらい
- メジャーバージョンが3(現在の最新)になって以降、Dockerコンテナが公式から提供されなくなった
公式ドキュメントより- Dockerイメージは配布され続けているが、バージョンが古い(3系のβ版まで、2024年3月が最終更新)。たまに、比較的新しめのDataformの記事でこのイメージを使い続けてしまっているものを見かけるので、注意したほうがいい
- 現状用意されているセットアップ方法はNPMのみ
- 公式が開発していたVSCodeのエクステンションもdeprecatedに
- Exampleリポジトリ等も公開されてない
- いやいや、あるやんけ! → last update 5 years ago
クラウド版とCLI版どっちがいいの?
ここまで紹介してきたように、クラウド版とCLI版にそれぞれ難点があることは否めません。もろもろ踏まえて、じゃあどっちがいいの?と聞かれると、正直なんとも言えないです。
私自身はというと、用途によって使い分けています。かつ、クラウド版とCLI版の使い分けだけではなく、BigQueryのエディタも使っているので、厳密には3つを使い分けています。各ツールの棲み分けはこんな感じ。
- ベースになるクエリを書くとき: BigQuery (BigQuery Studio)
- クエリをエンハンスさせるとき: Dataform CLI (on VSCode × GitHub Copilot)
- エラー調査時: Dataform クラウド版 & BigQuery
まとめ
さて、ここまでつらつらとDataformの不平不満を並べてきました。「そんなに文句ばっか言うなら使うなよ!」というお叱りの声が聞こえてきそうです。
そうですよね。正直、dbtに飛びつきたい欲が、個人としてめちゃくちゃあります。 今の圧倒的なdbtの普及度を考えたときに、自分のキャリア形成的にdbtにより明るくなっておきたい思いもあります。
しかし、私は趣味でデータエンジニアリングをしている人間ではなく、企業に所属するデータエンジニアです。それを踏まえたときに、「dbtかDataformか」というのは言ってしまえばツールの違いでしかなく、もっと優先して解決すべき課題がそこら中に転がっています。たとえば、魔法でいまこの瞬間、Dataformのインフラが全部dbtのインフラに置き換わって、私の脳内もdbtの達人になったとして、BigQueryの毎月のコストが1円でも安くなるでしょうか?未実装のあのメトリクスが、warehouseのテーブルに自動で追加されるでしょうか?
もちろん、こういう開発体験の悪さがチリツモで生産性を下げていたり、dbtにリプレイスすることでしか得られない新しい価値もあるでしょう。しかし、3名(フルタイム)のデータ人材で、ヒィヒィ言いながらデータ関連業務すべて(サイエンス、アナリティクス、エンジニアリング、スチュワード、etc.)を回している状況を考えたときに、dbtへの移行検討は、少なくとも今アクセルを踏んで進める仕事ではないと思っています。
アクセルを踏まなくて済むのは、Dataformに無償という強みがあり、かつTransformationに求められる大体のことは実現できるからです。 だから私は、Dataformを使います。少なくとも、今はまだ。
それに、すてきな日本のエンジニアたちがDataformのコミュニティを盛り上げてくれています。大感謝するとともに、ここで宣伝させてください!
最後まで雑記のようになってしまいましたが、共感していただけるDataformユーザーの方や、これからDataformを使うかどうか迷っている方の参考になっていたら幸いです。
We're Hiring!
dbtの移行検討もしたいなぁ。データ人材が足りないなぁ(チラッチラッ
Appendix: 昔話
ここからは時間の余った人向けの昔話になります。とは言っても、私はDataformの黎明期から触っているわけではないので、「比較的」昔話になります。
私がDataformを使い始めたのは2021年初頭。Google Cloudによる買収が発表された1〜2ヶ月後ぐらいだったでしょうか。当時からdbtがやや優勢ではあったようですが、まだ今ほど圧倒的な時代ではありませんでした。
DataformとdbtのGitHubスター数推移 (URL)
Dataformのクラウド版 (Dataform Web) はもともと有償で提供されていたのが、買収を機に全ユーザーに無償で提供されることになったそうです。太っ腹ですね。
Google Cloudに載る前のDataformがどんなものだったかをご存知ない方は、ぜひこちらの動画を見て、追体験してみてください。
どうです?洗練されていませんか?
これが完全無料で使えていました。しかも、これ1つでジョブ実行、スケジュール実行、Slack/Email通知がすべて完結しました。それ以外にも、ワークフロー実行結果の画面に該当テーブルのDAGが表示されたり、テーブルのメタデータの閲覧性がよかったりと、今は失われてしまった良UI/UXが詰まっていました。エディターだけは当時から微妙でしたが。
かつ、これはDataform Webだからというより、Dataformのメジャーバージョン(2系)に依るものですが、当時は「リリース構成」と「ワークフロー構成」に相当するものをコード (environments.json) で管理することができました。
あの頃はよかったなぁ(懐古厨)

株式会社マイベストのテックブログです! 採用情報はこちら > notion.so/mybestcom/mybest-information-for-Engineers-8beadd9c91ef4dc2b21171d48a4b0c49
Discussion