Dataformで個人的にハマったことランキング5選

この記事は株式会社ガラパゴス（有志）アドベントカレンダー2024の20日目の記事です。

今年も残すところあと僅かですが、個人的に今年一番驚いたことがつい先日更新されました。年末年始でも何が起こるか分からないのは皆さんご存知の通りかと思います。油断しすぎないよう最後までお気をつけてお過ごしください。

それでは本題に移ります。

うちの会社ではデータ基盤にDataformを利用しています。DataformはBigQueryを用いたデータ基盤にはとても便利なツールですが、日本語のドキュメントや記事が少なく、カジュアルにさくっと読めるようなものはほとんどありません。
そこで今回は、Dataformを用いて開発をしているエンジニア視点で、開発中にハマったポイントについてまとめてみました！

記事のタイトルは「Dataformで個人的にハマったことランキング5選」ですが、実際にDataform固有の問題は1つのみで、残りはBigQueryや一般的なSQLに関わるものです。予めご承知おきください。

第5位：同一テーブルを2回declare

Dataformではデータソースのテーブルをdeclareすることで、テーブル同士の依存関係をグラフに描画する際にデータ元として含めてくれるのですが、全く同じテーブルを複数回declareするとエラーになります。
そこまで頻繁には起こらないですが、例えばforEachで複数テーブルを一度にdeclareしているのを忘れて、別途個別にdeclareしようとする状況が考えられます。

["charges", "subscriptions", "line_items", "invoices"]
  .forEach(source => declare({
      schema: "dataset",
      name: source
    })
  );

declare({
  schema: "dataset",
  name: "charges"
});

第4位：別リージョンのテーブルをJOIN

これはDataformというよりもBigQueryの制約です。
BigQueryでは別リージョンにあるデータセットを一度に扱うことができません。例えばUSリージョンにあるテーブルとasia-northeast1リージョンにあるテーブルをjoinするようなSQLは、どちらのリージョンからでも実行できません。
その場合は一方のデータセットのリージョンを変更する必要があるのですが、私はBigQueryのデータ転送でデータセットコピーを用いて同じリージョンに作成し直しています。転送設定はBigQueryのコンソールから行っておりますが、これもDataformで管理できるようになって欲しいと思っています。

第3位：SAFE関連の関数名を間違える

BigQueryでは安全にデータ型を変換するためのSAFE関数がいくつか用意されています。SAFE関数を用いることで仮に正しい型に変換できなかったとしてもエラーにならず、代わりにNULLが入るので安心です。ですがこれらの表記が微妙に異なっており、使うたびに正しい関数名を検索してしまいます。
最も代表的なものはSAFE_CASTです。

SAFE_CAST('1' AS INT64)
SAFE_CAST('2024-12-20' AS Date)

SAFE_CASTは便利ですが、変換時に日時データをパースする必要がある場合は、以下のような関数を用います。

SAFE.PARSE_DATETIME('%Y/%m/%d %I:%M:%S %p', '2024/12/20 12:34:56 PM')
SAFE.PARSE_DATE('%Y/%m/%d', '2024/12/20')

毎回のようにSAFE_PARSEとか書いてしまい、あれ？となっていたのですが、2025年はこの辺りをスラスラ思い出せるようになりたいです。ちなみに私はSAFE_DIVIDEの存在も毎回忘れてしまい、割り算のたびに律儀にCASE文で分母判定してしまいます。

第2位：DATETIMEとTIMESTAMPの使い分け

こちらは頻出ですが、やはりBigQueryにおけるDATETIMEとTIMESTAMPの扱いはいつも微妙に間違えてしまいます。解説記事は他にいくつもありますので今回は省略します。

第1位：WITH句のカンマの入れ忘れ、付け過ぎ

今年も圧倒的な1位でした。複雑な集計をする際にどうしてもWITH句を複数回利用するケースがあるのですが、以下のような形式で実装する必要があります。

WITH t1 AS (
  -- t1の定義を書く
),
t2 AS (
  -- t2の定義を書く
)
SELECT ...

ですが、t2の部分を前にコピーしてカンマが付いていないとエラーになったり、逆にt1をt2の場所にコピペして最後のSELECTの前にカンマが付いてエラーになったり。今年も数え切れないほどやりました。おそらく2025年になっても個人的に1位が濃厚なので殿堂入りしても良いかもしれません。

いかがでしたか？
皆さんもハマりポイントに注意しながら、来年もデータ基盤やSQLと仲良くしてあげてくださいね！