​​BigQueryにおけるデプロイメント戦略
​​
​​BigQueryはフルマネージド型データウェアハウスです。
​​ギガバイトからペタやテラバイト級の大規模なデータを容易に扱うことのできるサービスです。
​​大変重宝されるサービスですが、多人数での共用だったり複数のアプリケーションからの利用が考えられるときには
​​アプリケーション開発と同様にデータウェアハウス上のコンポーネントの整合性や可用性を保つためにはテストやデプロイメントの戦略を考える必要あります。
​​

​​BigQueryにおけるデプロイメントの対象物

​​
​​BigQuery自体はフルマネージドであるため、サーバ等の管理は不要になりますが
​​ユーザ側で自由にカスタマイズ可能ないくかのコンポーネントが存在します。
​​
  • ​​ソーステーブル: 外部サービス等から格納されたデータ。
  • ​​中間テーブル: 
  • ​​物理テーブル: ソーステーブルを元にジョブ等で構築された物理テーブル
  • ​​論理テーブル: ビュー(View)。物理テーブルと同様に利用可能であるが実態はSQLなどのコード。実行時に計算される。
  • ​​UDF(User Definition Function): ユーザ定義の関数。BigQueryの場合はJSやSQLなどのUDFが存在する。
  • ​​スケジュールジョブ:
  • ​​時間指定がされ定期実行されるジョブ
​​

​​データウェアハウスという性質上の困難

​​
​​BigQueryないしはデータウェアハウスをサービスとして鑑みると
​​「データウェアハウス」がもつ性質上、デプロイを難しくさせる要素がいくつも存在します。
​​
  • ​​多数のデータソースに依存する
  • ​​入力としての依存元が多数ある。
  • ​​依存元から送られるデータは安定しているとは限らず、依存元によってマチマチ
  • ​​多数のサービスから依存される
  • ​​データウェアハウスの中のデータは様々な用途で利用される
  • ​​一個の些細な問題が複数の箇所に波及しやすい
  • ​​複数チームで横断的に共用される
  • ​​データの民主化を進める上では様々なチームでの利用により統制が難しくなる
  • ​​データという状態にコンポーネントが強く依存する。
  • ​​状態のケース数は膨大になりやすい
  • ​​データ量が多いため複製を安価にしづらい
  • ​​データは生ものであるため、時間に対して性質が変わりやすい
​​
​​要は、忌避されがちなモノリシックであることが宿命づけられており
​​データという状態に強く依存する種々のコンポーネントはテストを構築するのにも一苦労します。
​​

​​プラットフォームとしての品質水準

​​
​​データウェアハウスは単なる開発物ではなくプラットフォームとしての側面を持ちます。
​​複数人で利用することが前提であり、利用者の主目的は活用にあります。
​​
​​データの民主化の最も大きな狙いとしては、利用者であるドメイン実践者の知識を取り込むことでもあるはずです。
​​分析が再利用され他の分析に利用される、ようにデータの利用者がそのまま開発者になるということが頻繁に起こり得ます。
​​他方で、データの信頼性や整合性を保つための堅牢な開発は時に、利用のハードルを上げることに繋がり、活用の進行を阻害する要因になりえます。
​​