TR; DR
はじめに
2018/06/26 あたりに Firebase の BigQuery Export Schema が大幅に変更されました。
前もって準備していたので、私は すんなり移行できました。 …と、思っていました。
実は、移行の時に自分で地雷を埋めていたコトに気付かずに、今日になって思いっ切り踏み抜いたので、記録に残しておきます。
まぁ、超レアケースだと思うので、この記事が役に立つ人は殆ど居ないと思いますがｗ
前提
Google DataStudio でレポートを作るために、中間テーブル的なモノを BigQuery 上にこさえて、解析の高速化とコスト圧縮を図ろうと考えていました。
仕組みとしては、以下のような構成を想定。
- Compute Engine でデイリー cron 動かす
- シェルで Pub/Sub 叩く
- そいつをトリガーに Cloud Functions を実行
- BigQuery と会話して日々の生データを中間テーブルに格納
更に、Pub/Sub に特別なメッセージを Publish することで、過去分も遡って再集計する仕組みも作りました。
ちなみに、Cloud Functions のコードは Cloud Source Repositories の master への push をトリガーにしてたりします。
この辺の話もいつか記事にするかも。しないかも。
現象
で、殆ど仕組みが出来上がったので、「過去データを一気に集計して中間テーブル完成させよう！」としたところ、 Cannot read field 'event_date' of type DATE as STRING といった謎なエラーに遭遇しました。
いや、別に謎では無いけど、普通に動くケースもある状態で、「？？？」って感じになってました。
最初は Web UI 上で巧く動いてて、Cloud Functions 上だと転けるので、そっち方面のドキュメント読み漁ったりしたけど、全く解決せず途方に暮れていました。
原因
で、ふと「そいえば、過去データってどんなの入ってるんだろ？」と思って Web Console を覗いてみたところ、「あれ？ カラム型違わね…？ 」「うお、何か 特定の日を境に DATE 型と STRING 型とでカラム定義変わっとる やないかーい！」という衝撃の事実に気付きました。
で、その日付というのが、「Export Schema 変更実施日」そのものでした。
つまり、手動マイグレーションによって作成されたテーブルと Schema 変更後に作成されたテーブルとで event_date カラムの型が異なっていたわけです。
ここからは推測を含みますが、マイグレーション自体を前々から準備していた所為で、移行日直前に変更されたスクリプトの修正に追従できておらず、結果としてスキーマ定義が異なったまま運用し続けていたもようです。
そもそも発覚しなかった理由としては、 event_date カラムを使っていなかったからなんですが。*1
対応
幸い、マイグレート前の元データは残してあったので、対象期間の新スキーマテーブルを削除して、マイグレーションスクリプトを更新してから再実行して事無きを得ました。
蛇足
Firebase の BigQuery Export Schema は単なるテーブル群として出力されます。
後付けで柔軟にカラム追加するための戦略かなぁ？とか邪推してますが、どうなんでしょう？*2
Partitioned Table の場合はカラム定義の混在ができないので今回の問題は起きなかったと思いますが、何れにしても「ちゃんと確認しましょう」というお話でした。
