よしたく blog

IT技術を中心に様々なことを書いています

DataformCLIの2系を使ってBQに接続するまでの手順

2024 現在の Dataform は、Dataform 3 系の開発とttps://docs.dataform.co/(存在しない URL)にあった Docs の移行がおこなわれている。 最近 2 系の Docs にすぐ当たれない体験が増えてきたので、備忘録として残しておくー。

今回は Dataform CLI を使って、BQ に接続するまでの手順になる。

バージョン

$ node --version
v20.11.1
$ dataform --version
2.9.0

DataformCLI をインストールする

npm i -g @dataform/cli@^2.9.0

Dataform プロジェクトを初期化する

docs には、dataform initを実行すると dataform プロジェクトを初期化できると書いてあったが、BigQuery を使った Dataform プロジェクトを初期化するためには、下記のコマンドとオプションが必要になる。今回は sandbox-dataform ディレクトリの下で実行していくことにする。

$ pwd
/Users/yoshitaku/workspace/sandbox-dataform

$ dataform init bigquery <YOUR_DIRECTORY> --default-database <YOUR_BIGWUERY_PROJECT> --default-location <YOUR_BQ_LOCATION>

コマンドが成功すると、下記のディレクトリとファイルが作成される。

Writing project files...

Directories successfully created:
  /Users/yoshitaku/workspace/sandbox-dataform/dataform
  /Users/yoshitaku/workspace/sandbox-dataform/dataform/definitions
  /Users/yoshitaku/workspace/sandbox-dataform/dataform/includes
Files successfully written:
  /Users/yoshitaku/workspace/sandbox-dataform/dataform/dataform.json
  /Users/yoshitaku/workspace/sandbox-dataform/dataform/package.json
  /Users/yoshitaku/workspace/sandbox-dataform/dataform/.gitignore
NPM packages successfully installed.

また、@dataform/core もインストールされている。

$ cat dataform/package.json
{
    "dependencies": {
        "@dataform/core": "2.9.0"
    }
}

クレデンシャルファイルの生成

dataform init-credsコマンドを実行すると、実行環境へ接続するためのクレデンシャルファイルを生成することができる。 しかしここでも、このコマンドのままでは実行できず、末尾に bigquery を付ける必要があるdataform init-creds bigquery

実行すると対話式で必要情報を入力していく。聞かれることは下記の 2 つになる。

  • 接続する BigQuery が存在している location(おそらく asia-northeast1 を選択することが多い)
  • Google Cloud のプロジェクト ID

無事に完了すると Dataform CLI から、BigQuery に接続する準備ができたことになる。

サンプルファイルの作成と実行

次のコマンドを実行し、サンプルの SQL を作成する。なお、このコマンドは Dataform の公式 Docs に載っていたコマンドになる。

echo "config { type: 'view' } SELECT 1 AS test" > definitions/example.sqlx

dataform には dry-run のコマンドがあるので実行する。 無事に設定が完了しているとコンパイルが実行され、プレビュー実行される。

$ dataform run --dry-run
Compiling...

Compiled successfully.

Dry run (--dry-run) mode is turned on; not running the following actions against your warehouse:

1 dataset(s):
  dataform.example [table]

ちなみに、生成したクレデンシャルファイルを適当なディレクトリへ移動させると dry-run は失敗する。

$ dataform run --dry-run
Compiling...

Compiled successfully.

Dataform encountered an error: Missing credentials JSON file; not found at path '/Users/yoshitaku/workspace/sandbox-dataform/dataform/.df-credentials.json'

supabaseで全件削除するための小技

supabase の Python ライブラリであるsupabase-pyでは、2024-03-06 時点で全件削除できるような実装はないらしい。 そこで擬似的に全件削除のようなことをしたいときにはひと工夫する必要がある。

supabase.com

削除するときのフィルター条件でneqを使って、idが0では無い行を全て削除するようにすれば実現できる。

from supabase import create_client, Client

url = "YOUR_URL"
key = "YOUR_KEY"
supabase = create_client(url, key)

data, count = supabase.table('YOUR_TABLE').delete().neq('id', 0).execute()

Google Cloud Next Tokyo ’23 Day2に行った📝

DMM における AWS から BigQuery へのデータ基盤移行 / 合同会社DMM.com

背景

1500テーブル ほぼ日時処理 biから投げられる30000クエリ/ week 1500mau 新規テーブル・カラムの別作業が5回/week

課題

  • オペの省力化ができていないため、活用拡大にリソースを割きにくい
  • ガバナンス
  • データ活用の拡大
    • 今まではデータは社内利用に留まっていたが、広告システムなどの社外利用に拡大したかった

狙い

  • サーバレスにすること
  • Google製品に連携が用意できること
    • サーチコンソール
    • ADs

基盤移行の流れとポイント

  • データ同期
    • S3toGCSはSTSを使って同期している
    • GCStoBQはGCSの変更検知を使ってイベントドリブンに対象範囲を絞って更新している
  • データの差分検知
    • AWSとBQで全レコードのmd5を見て差分チェックしていた

information schemaでみたら全体で3.5兆レコードあったらしい

質問

  • 過去分のデータはどうしたか。一時的に二つの環境にデータがあることになるはず?
    • 現時点で、もうS3はサポートしない旨を言っていていずれは消す。
    • サービスからはデータをGCSに直接送ってもらっている
  • GCSに置いてあるデータのコスト削減とかは何をしているか
    • 外部テーブル群はデータセット単位で見せないようにしてる
    • また、日にちで区切ってライフサイクル化してる
      • bqに取り込んだ後はストレージクラスを下げたり、消してしまったり

BigQuery のデータ品質やデータ活用を高める Dataplex 等の活用 / GO株式会社

基盤利用者は100人 / week

  • 課題
    • 利用者がすぐにデータ活用できない
    • 障害や仕様変更の調査が大変
    • いつのまにかデータが壊れている
  • DataplexとDatahubで課題解決
  • Dataplex
    • データ周りをまとめた色々製品
      • この中にデータ品質管理がある
      • テスト定義をSQLに変換してテストできたりする
      • レポート配信などで使われる少数の手ブルに導入した
  • Datahub
    • Data CatalogがBQとLookerに対応していないから採用したが、バックエンド技術などがオーバースペックで微妙らしい

質問: - データのテストはどうやってるか - 辞書テストや範囲テスト、鮮度テストのやり方? - また、この時のSQLファイルはどうしているのか - Dataplexでできちゃうよ - データマートのメタデータの管理はどうしているか - データソース側はinformationからとってきていることはわかったけど、手動でつけてる? - DataHubでできちゃうよ - 発表にはなかったが、権限管理はされてる?どうしてる? - 今は全部見せる運用。これからやるならDataplexのデータメッシュで切ってやりたい

--

Dataform で BigQuery データパイプラインをより効率的に / Google Cloud

Goさんの発表で出てきたDataformが気になったので、追加で見てきた。 機能紹介と簡単な事例紹介だった。

Google Cloud Next Tokyo ’23 Day1に行った📝

基調講演

  • ハルシレーションを抑えるグラウンディングをし、事実に基づく生成AIにする
  • Vertexがより協力になっていく話
  • data residency (今日サービス発表)(drz)
  • vertex ai searchの日本語提供
  • Googleワークスペースのduet aiが強力になっていく話
    • Meetでの自動翻訳
    • 会議の途中経過を要約して教えてくれる
      • 質問して、詳細部分を回答をしてくれたりもする
  • duet ai in google cloud
    • cloud station
    • log explorer自然言語でエラー内容を説明してくれる
    • どう治したらいいかも教えてくれる
    • Looker studio pro
      • 自然言語でグラフを生成してくれる
        • そこからスライド作成もできる
    • Database migration
      • oracleからAlloy dbへ
      • duet aiで自動で変換してくれたり、ダメなところは確認が必要だと提供してくれたりする
    • Memorystore for redis clusterがnew

生成AIの話が多く、Google製品とのコラボレーションが熱くなっていきそうだった。 知らない製品多めでVertex AIもあまり知らなかったので、色々できること増えていきそうだなと思ったけど、自社に組み込むのはまだまだ先な感じがあるかなぁ


任天堂のデータ分析基盤 / ニンテンドーシステムズ株式会社

データ規模 アカウント3.3億ほど 900テーブル

  • 他プロジェクトのBigQueryを見るときは、承認済みデータセットを経由して参照やコピーをしている。
    • 承認済みデータセットは2段階に分けて承認してる
  • 元々はdatafusionをつかっていたが、今はdata transformはbatchを
  • 変換はcomposerでdbtを使っている。
  • データセットごとにdbtを用意してる。プロジェクト間は別で定義
  • bqは20000スロット
  • bigquery data transfer service
  • 開発中のデータソースとbqを統計値を使ってデータ比較検証
  • data visialasionを使っている
  • フォルダ単位でプロジェクトを分けている
  • terraformとGHEをつかって権限管理している
    • GHAで定期的に実環境とのドリフトを検出
    • 構成情報を社内wikiに連携
    • 利用者の権限洗い出しをおこなっている
  • インフォメーションスキーマで利用状況をチェックしてる
    • スロークエリを見つけて対処している
    • ex, 集計済みテーブルがあるのに生テーブル見てたり、ジョインするテーブルがデカすぎる

質問したかった内容: terraformでの権限管理はどうしている? スロークエリを気付ける仕組みは? 今後の展望でのデータカタログの充実をどのようにやっていこうと思っているか 今後の展望でのデータ制度の向上をどのようにやろうと思っているか

いろいろ質問事項あったのに、Ask The Spreakerはなかった...

—-

製造業での Cloud Run を中心としたシステム開発コラボレーション事例 / 株式会社LIXIL

  • cloud shellのteachmeコマンド知らなかった
  • デモ動画でのハンズオンであった

—-

ゴーゴーカレーのデジタル進化: Google の技術を中心とした新たな航路 / 株式会社ゴーゴーカレーグループ

  • ゴーゴーカレーのビジネスについてのトーク
    • いろんな販路があってすごかった
  • SmartHR、MoneyForward、OKRや1on1も実施しているらしい これからアプリの開発もしていく
  • デジタル方針はGoogle中心主義になることを掲げている。
    • Google Cloudのみをデータセンターとして活用
    • AppSheet
  • Google以外はSaaSを使う
    • バックオフィスはMoneyForward

gcloud auth loginとapplication-default loginの違いを整理した

記事の概要

Google Cloud SDKの認証コマンド、`gcloud auth login` と `gcloud auth application-default login` の違いについてまとめた。

gcloud auth login

目的

`gcloud` コマンドラインツールを使用するユーザー自身を認証するためのコマンドになる。

用途

  • 個人の開発マシンでの作業
  • 手動での `gcloud` コマンドの実行

具体例

Google Cloud Platform上で仮想マシンを手動で作成したい場合、以下のコマンドを使用して自分自身を認証する。

gcloud auth login

その後、以下のようなコマンドで仮想マシンを作成することができる。

gcloud compute instances create INSTANCE_NAME

gcloud auth application-default login

概要

特定のアプリケーションがGoogle Cloudのリソースにアクセスできるかどうかを確認するための認証。アプリケーションは、バックエンドのサービスやスクリプトなど、人の介入なしに動作するものを指す。

具体例

  1. WebアプリケーションがCloud Storageから画像を取得: ユーザーにプロフィール画像を表示するWebアプリケーションが、Cloud Storageのバケットから画像を自動的に取得する場合。
  2. ログ処理スクリプト: 一日の終わりに、Compute EngineのインスタンスからログファイルをBigQueryに自動的にアップロードするスクリプト
  3. 定期的なデータバックアップ: Cloud Schedulerを使用して、Cloud SQLのデータベースを定期的にバックアップするスクリプト
  4. 自動的なリソースのスケーリング: Cloud Pub/Subのメッセージキューのサイズに基づいて、App Engineのインスタンス数を自動的にスケーリングするアプリケーション。

具体的なコマンド

gcloud auth application-default login

違い

  • `gcloud auth login` はユーザーの認証のため、`gcloud auth application-default login` はアプリケーションの認証のために使用される。
  • `gcloud auth login` は主に手動の操作のため、`gcloud auth application-default login` はアプリケーションの開発の際に使用される。