サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
猫
www.yasuhisay.info
背景: アドホックなモデルをいつまでも残したくない dbtを使う場合、ある程度規則に沿ったレイヤリングの元に運用されることが多いと思う(例: staging / raw vault / fact & dim / martなど)。品質が必要な場合はこのレイヤリングに沿ってモデルを作ることになるが、急なビジネス要求によってこのレイヤリングに沿わないアドホックなモデルを作らなければならない場面は現実的にそれなりにあると思う(例)。こういった要求を受け入れつつ、アドホックなモデルをいつまでも運用しない形にしたい。 アドホックなモデルがいつから運用されているか機械的に把握する ひとまずアドホックなモデルがいつから運用されているかを簡単に知りたい。アドホックなモデルの数が多い場合、それらを手動で洗い出すのは面倒なので、機械的に出したい。テーブルが洗い替えされる場合、INFORMATION_SCHEMA
背景 担保したいこと 1: ホットキーで一撃で呼び出せる 2: ウィンドウを透過させてターミナルと他のウィンドウを同時に眺められること 調査したこと & 解決方法 ホットキーで呼び出せるか => hammerspoonで割り当てで対応 ターミナルの透過 => 無理そうなので、代替手段で対応 メモ: ターミナル関係のキーバインド tmuxっぽくしたい その他キーバインド 背景 iTermをずいぶん長く使ってきたけど*1、VSCodeのターミナルが急速に進化しているので、乗り換えを検討した。 VSCodeが色々便利になってきた 自分が使っている範囲だと、vimキーバインドも特に問題ない*2 普段のコーディングはVSCode、コマンド操作くらいしかiTermは使っていない 特にCopilot系の進化は目覚ましい、長い物には巻かれろというか長期的にはエコシステムに乗っておきたい エディタだけでなく
dbtや同じ系統のDataformなど、ELTの特にTransform部分に強みを持つツールを使い始めて大体3年になる。主観だけど、それなりに使い倒している部類だと思う。 開発効率を計測するデータ基盤の管理にDataformを使ってみた - yasuhisa's blog dbtを触ってみた感想 - yasuhisa's blog dbt カテゴリーの記事一覧 - yasuhisa's blog これらのツールで巷でよく言われる データリネージの可視化ができる データに対するテストが簡単に書ける エンジニア以外の人ともコラボレーションしやすい あたりの話は耳にタコができるくらい聞いていると思うので、ニッチではあるもののそれ以外のdbtの個人的に推しなポイントをダラダラと書いてみたいと思う。データエンジニアやデータガバナンスを推進する人には共感してもらえる内容かもしれない。 推しポイント:
dbtを使っていなら、not_nullテストは何度も書くことになると思う。このテストを書いていて「手元では通るが、CIでは通らない」という一見謎現象に思えることにブチ当たったのでメモ。 起きた現象 手元からnot_nullテストを書いた。コンパイル済みのSQLは以下のようなものになる。 SELECT column FROM model WHERE column IS NULL このテストをコミットしてCIで動かしていたところ、CIが落ちた。落ちた原因を調べていると、落ちたクエリは以下のものになっていることが分かった。 SELECT * FROM model WHERE column IS NULL 落ちている原因としてはテスト対象のテーブルにBigQueryの列レベルセキュリティがかかっていて、CIを実行しているサービスアカウントがその列にアクセスできないから、というものであったが、そもそ
dbtや同じ系統のDataformなど、ELTの特にTransform部分に強みを持つツールを使い始めて大体3年になる。主観だけど、それなりに使い倒している部類だと思う。 開発効率を計測するデータ基盤の管理にDataformを使ってみた - yasuhisa's blog dbtを触ってみた感…
背景: dbtを使っていてもER図は欲しい! どうやってER図を生成するか どうやってER図を見やすくするか まとめ 背景: dbtを使っていてもER図は欲しい! dbtはモデル間のリネージなど可視化が得意なツールではありますが、万能なわけではありません。モデルの生成過程などはリネージで担保できますが、分析時に「どれとどのモデルがJOINできて、JOINする際のキーはこれを使って」というER図で扱うような可視化はディフォルトではできません。 DWHを作っている側からすると「このテーブルはあの辺のテーブルと一緒に使うと便利で、いつもあのキーでJOINして」というのが頭の中に入っていることが多いため、ER図がなくてもどうにかなることも多いでしょう。しかし、分析に慣れていない人や分析に慣れている人であっても、普段と異なるドメインのテーブルを触るときはER図が提供してくれる情報は有用です。ちなみに
前提: これは何? dbtを使ったデータプロダクトを作っている社内のチームメンバー向けに書いた勉強会用のドキュメントです 社外に公開できるように少し抽象化して書いてます DWHに限らずdbtを使ったデータプロダクトで生かせる話ですが、分かりやすさのためにDWHを題材にしています 3行まとめ elementaryはdbtを利用しているデータパイプラインに対してData Observabilityを強化するツールであり、付属のリッチなレポートやSlachへのアラート通知が便利です しかし、実はelementaryが内部で生成している成果物はDWHの改善に役に立つものがたくさんあります 本エントリではelementaryの成果物や役に立つ実例を多めに紹介します 前提: これは何? 3行まとめ 背景: DWHとデータ品質 Observability / Data Observabilityについて
背景: データ品質を可視化したい 実装: elementaryを使って、正確性のデータ指標を可視化する 実例: ダミーデータを使った可視化 まとめ 背景: データ品質を可視化したい 運用しているDWHでデータ品質にまつわる問題で苦労したことがない人は少ないと思います。Analytics Engineerやデータエンジニアであれば「このテーブル、XXカラムに重複があるんだけど...」「この列の値、割合が入るんだから、マイナスとか1越えるとかおかしくない?」といった問い合わせを受けた経験が多いでしょう。 今回は上記のような完全性(Completeness) / 一意性 (Uniqueness) / 妥当性 (Validity)といったデータの正確性に関わるデータ品質の可視化をスコープにします。データ品質に限らない話ですが、こういった改善を行なうには「現状(AsIs)がどうなっているかを把握した
シリーズの第三弾です。読者の宿題にしてたけど、誰も書いてくれなさそうだったので結局自分で書きました。 背景 Looker StudioはGoogle Workspaceを使っていれば基本的に無料で使えますし*1、権限管理にGoogle Groupとも連携できるので、人気のBIの一つだと思います。私が初めて触ったBIもLooker Studioだったので、(API強化して欲しいとか不満は山のようにありつつも)何だかんだで憎めないし、さっとダッシュボード作りたいときはLooker Studioを使うことが多いです。会社によっては社内の公式のダッシュボードをLooker Studioで作っているところもあると思います。 dbtで作ったテーブルがConnected Sheetsから参照されている場合、一定程度利用されているスプレッドシートからのテーブルの参照状況はデータ基盤を管理する人間としては把
以下のConnected Sheets版です。これはかなり便利なものができたと、自画自賛してます。 背景 Connected Sheetsをdbtのexposureとして取り込む 見所 Connected Sheetsからのクエリか判断する BigQuery Scripting経由で発行されたクエリでもreferenced_tablesの情報を取得する クエリ回数やクエリされた週の数をメタデータとして加える まとめ 背景 Tableauと比べると、Connected Sheetsはアドホックな分析で使われることが多いと思います。実際、筆者が所属している会社でも「Tableauは公式のダッシュボード、それ以外のアドホックな分析はConnected Sheetsで行なってね」と案内しています。とはいえ、公式のダッシュボードにするためにはdbtなどを使ってデータソースを信頼できる形に整備する必要
背景 ConftestによるTerraformのポリシーテスト 例: ConftestでBigQueryのデータセットのlabelにownerが設定されていることをテストする 実際の業務への取り込み方 背景 権限管理を含め、BigQueryのデータセットの管理をTerraformで行なっている人は多いと思います。Terraformでデータセットを管理する際、descriptionやlabelsなどのメタデータはデータマネジメント(データ品質やセキュリティ)でも重要です。 description データセットやテーブルの棚卸しをする際、descriptionが入っていないと用途の把握などに時間がかかってしまいます labels labelsは様々なメタデータをkey/value形式で持たせることができます。代表的な事例は以下にまとまっています マネーフォワード ケッサイのBigQueryリソ
N番煎じですが、やってみる機会があったので一般化してメモしておきます。 背景: コードレビューを素早く行なうことの重要性 レビューのフローを整理する GitHub Actionsでレビュー依頼を自動化する 背景: コードレビューを素早く行なうことの重要性 チーム開発で重要なことは色々あります*1が、Pull Requestを出したときに素早くレビューをしてもらえるというのはとにかく重要なことの一つです(日本語版)。 レビュー依頼がきたら今すぐ仕事をやめてレビューをしなければならない、というわけでないですが、一日に2~3回は見るようにしようと思いながら過ごしています。レビュー依頼を手動で「XXXさん(あるいはチーム)、以下のPull Requestのレビューお願いします!」とmentionしてもいいですが、一日に何回も明示的にレビュー依頼をしていると「ちょっとうるさいかもな、まとめて依頼しよ
この記事はdatatech-jp Advent Calendar 2023の12日目の投稿です。本日は12/18ですが、Advent Calendarの空きがあったのでねじこみました。 背景 困ること: 実行時間が長い 脱線: レコードの削除時に考慮したいこと dry-runモードで何が実行されるかを分かるようにしておく バックアップ用にテーブルをコピーしておく ログはしっかりめに残しておく 削除に必要な最小の権限に絞ったサービスアカウント経由で実行する 複数回コマンドが実行されても問題ない冪等な設計にしておく 復旧用の手順もまとめておく テーブルの利用者に予めレコードの削除が起こることを伝える Pythonで並列にDELETE文を実行させる 背景 データ分析のコンテキストではBigQueryのテーブルに破壊的操作をする際、以下の場合が多いと思います。 CREATE OR REPLACE
3行まとめ テーブルの撤退時にはテーブルの参照回数を見ることが多いと思いますが、テーブル単独の参照回数を見るだけだと不十分なことが多いです 派生先のテーブルの参照回数まで考慮すると、テーブルが撤退できるか安全に判断することができます リネージ上の親子関係をWITH RECURSIVEで考慮しながら、累積参照回数をSQLで導出できるようにし、安全にテーブル撤退を判断できるようにしました 3行まとめ 背景: テーブルの撤退にはテーブル単独の参照回数を見るだけだと不十分 アイディア: 累積参照回数を計算する 実装 テーブル間の親子関係を抽出する WITH RECURSIVEでテーブルの親子関係を辿る テーブルの親子関係を考慮しながら、累積参照回数を計算する まとめ 背景: テーブルの撤退にはテーブル単独の参照回数を見るだけだと不十分 データエンジニアやアナリティクスエンジニアの仕事をしていると、
3行まとめ dbtのジョブが失敗した際やテーブルの廃止検討の際に、BI上のどのダッシュボードで利用されている(データリネージ)か知るのは重要です TableauのGraphQLのAPIからWorkbookとBigQuery上のモデルの埋め込みの関係を知ることができます dbtのモデルとTableau上で使われているWorkbookの依存関係をexposureとして出力するスクリプトにより、dbtのジョブの失敗やテーブルの廃止がTableauのダッシュボードに与える影響などを調べやすくなりました 3行まとめ 背景 課題: dbtのexposureとしてダッシュボードを手動で記入し続けるのは難しい 解決方法: TableauのGraphQLのAPIを使い、 dbtのexposureを自動生成する 発展的話題 背景 業務において、DWHやデータマートの生成にdbtを、BIツールとしてTablea
特にもの珍しいものがあるわけではなく「現状こういうことやってるっす!」というのを説明するときのポインタが欲しくなったので、雑に書く。 ChatGPT 用途1: 壁打ち相手 用途2: 便利な英語の先生 用途3: シェルスクリプトの生成 GitHub Copilot DeepL 所感 ChatGPT 普通に便利、ない生活にもう戻れない GPT-4でしかもう使ってない 時間あたりの回数制限があったけど、最近ではもうそれに引っかかることもほとんどなくなった Custom instructionsも使ってる AIお姉ちゃんまではいかないが、柔らかい & 話しやすい感じの返答をしてくれるように設定している 何かが解決したときは「やったぜ、俺たち天才!!」的なノリに乗ってもらえるほうが気分よく仕事できるので、そういうのに合わせてもらえるような感じにしてる 用途1: 壁打ち相手 エラーメッセージとコードス
データの可用性を可視化したい データの可用性の解像度を上げたい: elementary-data elementaryによる細かい可視化 大雑把にデータセット単位で可用性を可視化したい まとめ データの可用性を可視化したい データ品質は正確性や最新性など様々な項目に分解することができますが、可用性(Availability)はその中でも基礎的な項目です。使いたいときにデータが使えないと困るので。 自分が所属しているチームはdbt(cli)およびdbt cloudを使っていますが、可用性を考えるのであれば cli: dbt runの実行結果 dbt cloud: Jobsの実行結果 をそれぞれ確認したり、こけているようであればアラートを飛ばすという運用が多いと思います。これだけだと「いつこけた」しか分からないので、Datadogを使って「いつこけた」「いつ復旧した」「こけて落ちていた時間はど
なぜ列レベルのアクセス制御とポリシータグが必要か Terraformでポリシータグの作成および権限付与 ポリシータグの付与の仕方 dbt経由の場合 bq loadを使う場合 運用上の注意点 まとめ なぜ列レベルのアクセス制御とポリシータグが必要か 「テーブルの全てのカラムは見せたくない」「rawデータは見せたくなくて、統計量だけは許可したい」などセキュリティ面からの要求でこういったことを実現したい / しなければならない場面はそれなりに多い。個別にカスタマイズしようと思うと、承認済みビューがカスタマイズ性があり便利ではあるが、以下のような課題がある。 用途毎にカスタマイズできてしまうがゆえに、都度承認済みビューを作る必要がある データ基盤のチームが少人数の場合、運用負荷がバカにならない 自分がこれまで所属していた組織でも結構辛かった 権限の整合性を担保するのが難しい 承認済みビューAではX
追記 以下、色々書いていますが、dbt-osmosisの作者に課題感を共有した上でそれを解決したPull Requestを取り込んでもらい、よりシンプルに解決できるようになりました。 meta.osmosis_keep_descriptionを付与した上で--force-inheritanceを使えば意図通りに運用できます。 背景: dbt-osmosisを運用に乗せたい 少し前にdbt-osmosisを紹介するエントリを書いた データリネージを考慮しながら、メタデータの伝播をしてくれる便利なツール しかし、運用に乗せようと思うと、これだけだと足りない点があり、まだ運用に乗せ切れていない... 「親のメタデータが更新されたときに子どものメタデータをどう更新するか」問題 データカタログを強化していきたい機運が高まっており、そうするとカラムのメタデータの役割は非常に大きい dbt-osmosi
小ネタです。割と便利だったので、エントリに書き起しておきます。 背景: エンジニア職種でなくてもでかいデータをBigQueryにアップロードできるようにしたい BigQueryはWebコンソールから手元のcsvなどをアップロードすることができます しかし、これにはファイルサイズの制限があります Google Cloud Console を使用する場合、ローカル データソースから読み込まれるファイルのサイズが 10 MB を超えないようにしてください 10MBは割と簡単に越える量なので、代替手段を考える必要が度々出てきます GCSからBigQueryにロードもできますが、データの管理対象が増えてしまうため、ここでは使わないことを想定しています 数百BM ~ 数GBくらいのデータであればbq loadコマンドなどの利用がぱっと思い浮かびますが、エンジニアリングの経験がない方(例:BizDev
背景 vscode-dbt-power-userがよかったところ 定義にさっと行ける / 戻れる(Go to definitionが使える) VSCode内でモデル間のリネージが見れる VSCode内からdbtのモデルをさっと実行できる モデルファイルの単独の実行も簡単 コンパイル済みのSQLファイルをさっとプレビューできる まとめ 補足: vscode-dbt-power-userの導入方法 背景 dbtは前職時代から含めると二年以上使っていて、SQLでDWHやデータマートの開発をしようと思うともはやこれなしでは生きられないくらいには便利になっている。dbtがあっても大変なクエリは大変ではあるが、大変さは大分緩和してくれる。dbtがなくて、1つのSQLが1000行以上あり、中間クエリがテストもされていない、という状況はもう戻りたくない...。 dbtに限らずであるが、コードは書いていると
Dataplex(旧Data Catalog)によるデータカタログについてあれやこれやれやをまとめておいたポインタが欲しくなってきたので、とりとめもなくつらつらと書きます。 注意点: BigQuery on GCPの運用を前提に書いてます Dataplexはデータカタログ以外の機能もたくさんありますが、データカタログの観点にフォーカスして書いてます 論理的なデータ構造を作成したり、それに基づいた権限管理など 少人数のチームでデータ基盤を運営しており、データカタログの運用自体に工数をなかなか割けない前提で書いてます 自前で作ることも難しいし、ましてそれを継続的に運用するのはさらに難しい 「データカタログ」という言葉が指すスコープも色々ありそうですが、「検索 + メタデータ管理」くらいのスコープで書いてます 包括的に書くつもりはないので、漏れてる観点は多いと思います データカタログがなぜ必要か
背景: 無駄なスケジュールクエリを撲滅したい スケジュールクエリは便利 エンジニアでない方でもクエリを手軽に定期的に実行できるようになる 一方で、設定したけどしばらくすると生成したテーブルを全然見てない(=無駄打ちになっている)...というクエリが徐々に増えてくる スロットやスキャン量も無駄になっており、余分なコストを払うことになってしまうため、検知しておきたい 同様のモチベーションで以下のツールを作っていましたが、今回はスケジュールクエリに特化したバージョンです ↓はGASやCRONなど色々なジョブ基盤に対応したものだった 今回はスケジュールクエリに特化しているので、適用範囲は狭いものの設定箇所の同定などはよりやりやすくなっている 準備: スケジュールクエリの設定値をBigQueryのテーブルに詰め込む Cloud Asset Inventoryでスケジュールクエリの設定がエクスポートで
SQLをレビューしていて、シャーディングテーブル(日付別テーブル)をサブクエリを使ってフィルタしているものがあった。BigQureyのシャーディングテーブルはWHERE句で日付の条件を書いてやるとスキャン範囲を限定することができるので便利ではあるが、サブクエリを使うなど定数でないものが入るとフルスキャンが走ってしまう。 このように書くことによって、スキャン量は from_date ~ to_date までのテーブルしかスキャンしないので全tableのスキャンすることを防ぐことができます。 しかし、このワイルドカードテーブルへのクエリにサブクエリなどの定数式でない条件を使ってしまうと、途端にフルスキャンを行ってしまいます. このこと自体は覚えていたものの「じゃあ、具体的にどうやって回避すればいいの?」というのをぱっと言語化できなかったので、ちょっとまとめておく。 ちなみに、サブクエリを使って
BigQueryの新プランの登場でBigQueryをOnDemandからEditionsに切り替える人も多いと思います。OnDemand環境下ではスキャンするデータ量を見ておけばよかったですが、Editionsではスロット消費量がベースになり課金額が決まります。 「課金額がどれくらいか」「スロット使用量が大きいユーザー / テーブルはどれか」を調べる際に使いそうなクエリを書いたのでまとめておきます。 組織内のプロジェクト毎のスロット使用量の推移を調べる 前提として、以下のことに気を付けましょう。 前提1: INFORMATION_SCHEMA.JOBSではなく、INFORMATION_SCHEMA.JOBS_TIMELINEを使う 前提2: 最短課金時間である 100 スロット/秒 で切り上げる必要がある 以下のエントリになぜこうする必要があるかは書いてあるので、そちらを参照してください。
背景 具体的な設定 コントローラーに設定を生やす workflowを監視するためのカスタムメトリクスを定義する 各workflowに同様のカスタムメトリクスを定義する デバッグ方法 所感 背景 前職に引き続き、現職でもArgo Workflowsを使ってデータエンジニアリング系のバッチ処理を行なっている 以前にCloud Workflowsを調査したことがあったが、まだちょっと厳しい感があった 前職ではCloud Monitoringで監視していたが、現職ではDatadogで監視しているので、全社の体制に合わせてDatadogで監視していきたい Argo WorkflowsはPrometheus Metricsに対応しており、Datadogはagent経由でPrometheus Metricsの収集を容易に行なえることが分かった 同僚のSREであるtapihさんから教えていただいてました、
背景: BigQuery Editionsの登場およびOnDemandの価格変更 注意(Disclaimer) BigQuery Editionsの設定を行なう providerのバージョンを上げる Reservationの作成およびAssignmentの設定 脱線: BigQuery Editionsを選択して、OnDemandよりコストが上がってしまう場合 背景: BigQuery Editionsの登場およびOnDemandの価格変更 2023/03/29からBigQuery Editionsが販売開始され、2023/07/05からBigQueryのOnDemandの価格変更が適用されます(何もしないとコストが上がる)。 趣味プロジェクトでも多少BigQueryを利用していますが、OnDemandを利用しているので何もしないと約25%コストが上がってしまいます。しかし、うまいことBi
最近、新しいPCをセットアップしていたけど、PCのセットアップを完了しないと趣味サイトのdeployすらできないことに気付いた。しばらくdeployしていないと、久しぶりにdeployしたときに大抵事故るし、小まめにやることでdeployの心理的障壁を下げていきたい。現状だと例えば、「寝る前にdeployしてコケると睡眠時間が短かく(2~3時間が飛んでいく)なるから、時間がある週末にやるしかない...」と思ってしまうことが時々ある。そのためにも、テスト済み/ビルド済みの成果物を本番環境にしゅっとリリース可能な状態にしておけるように、CI/CDのパイプラインを整備した。目新しいことは特にはないが、自分用のログを残しておく。 CI/CDの各フェイズの整理 Buildフェイズ Deployフェイズ(+ Releaseフェイズ) sentry ecspresso パイプラインを組む まとめ CI/
3行まとめ ビジネスメタデータはデータ生成者にとってもデータ活用者にとっても重要 しかし、カラムのメタデータを同じ説明をあちこちに書いていくのは大変... dbt-osmosisはビジネスメタデータの管理を省力化したり、自動化できる便利なツール 3行まとめ 背景: メタデータの重要さとメタデータ管理の大変さ 大変さ1: 多段のデータレイヤーにどうメタデータを付与していくか 大変さ2: 継続的な運用をどうするか dbt-osmosisでメタデータ管理を行なう 依存関係を考慮したメタデータの伝播 自動化による継続的な運用 基本的な使い方 使ってみた感想 背景: メタデータの重要さとメタデータ管理の大変さ データマネジメントにおいてメタデータの重要性は今さら説明するまでもないと思います。メタデータは以下の3種類が代表的です。 A: テクニカルメタデータ B: オペレーショナルメタデータ C: ビ
次のページ
このページを最初にブックマークしてみませんか?
『yasuhisa's blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く