はてなブックマーク

背景: データ基盤の運用ではクエリのパフォーマンス最適化と向き合わないといけない機会が多い 課題: クエリ改善のヒント、実行情報は見るのが難しい 解決方法: 実行情報とクエリ最適化の紐付けをClaude Codeにさせる 工夫ポイント1: 実行情報をINFORMATION_SCHEMA.JOBS_BY_PROJECTから取得する 工夫ポイント2: ステージ内のステップと実際のコードを紐付ける 工夫ポイント3: 最適化後にクエリの実行結果が変わらないことを保証する 最適化実例 実例1: ウィンドウ関数を使う前にデータを絞り込む 実例2: JOINする前にデータを絞り込む 実装上のその他のTips クエリを発行した瞬間にJOB_IDを取得する テーブルのパーティションを指定する まとめ 背景: データ基盤の運用ではクエリのパフォーマンス最適化と向き合わないといけない機会が多い データ基盤の運用

背景: Data Vaultを運用し続けている事例の公開は多くない おさらい: Data Vaultとは何か データ分析基盤におけるData Vault Data Vault自体の解説記事 Data Vaultを使った開発 with dbt Data Vaultを運用してよかったこと データモデリングを強制される ディメンショナルモデリングとの相性のよさ アリジティが高く、後から拡張ができる AIやLLM Agentとの相性がよい 履歴が使いやすい 運用する中で工夫が必要な点 データソースのスキーマに引っぱられないようにする すでに運用しているデータ分析基盤との付き合い方 Data Vaultの設計をできるメンバーをチーム内でどう増やすか full-refreshとどう向き合うか ハッシュキーの構成の順序問題 Data Vaultを採用すべきだったか? 宣伝: データエンジニアの採用やって

背景: LLM Agentと仕様書駆動開発 Kiroの対抗馬 spec-workflow-mcpでの仕様書駆動開発の体験がよかった 導入が簡単 まあまあ固く作られている 仕様のやり取りをするWebサーバーが立ち上がる 仕様書駆動開発の良さを感じられた まとめ 背景: LLM Agentと仕様書駆動開発 LLM Agentが発展してきたものの、完全なバイブコーディングは厳しいことが分かってきた 仕様を満たしていないものが出来上がったり、メンテナンスがしにくい作りになっていることもしばしば そこで、仕様書駆動開発(Spec-driven Development)の考え方をベースにしたKiroが登場した 考え方は今後の時代に非常に合っていそう Kiroで仕様書駆動開発を試したが、体験はよかった Claude CodeはAuto Compact後に色々情報を忘れてしまう問題があるが、仕様書駆動開発

背景 おさらい: bqコマンドで実行できること 基本のbq query: 思いのほか、多様な破壊的操作ができてしまう... その他の破壊的なオペレーション いかにClaude Codeが意図せぬクエリを実行できないようにするか 素朴だが面倒: クエリ実行を毎回Acceptする 危険なクエリかどうかをLLM Agentに判断させる 最小の権限を保持するサービスアカウントからクエリを実行させる そもそもクエリを実行させたくない場合 Development containers上で実行させる サンドボックス環境で動かす まとめ 背景 Claude CodeにBigQueryのクエリを書かせていて、実行やクエリ結果の確認もClaude Codeにさせたい場面はあると思います その場合、bqコマンドを手元から叩かせることが多いと思います しかし、bqコマンドはBigQueryに関わるかなり広い範囲の

背景 Claude Codeを使っていると、色んな情報を合わせて見たくなります 例: Claude Codeの現在のトークンの利用状況(like ccusage) 例: 現在のディレクトリ 例: セッションID(他のターミナルで--resumeするときに必要) 例: 利用しているモデル 名(Opus or Sonnet) 例: ブランチ名 例: 該当ブランチに紐付くPull RequesのURLおよびそのstatus そういった情報をClaude Codeの下部にステータスラインとして表示できる機能がリリースされていました Status line configuration - Anthropic しかし、これが使い倒そうと思うと書きにくい... 色のことだったり、JSONのparseだったり シェルスクリプトで書こうとすると結構やっかいです 実行頻度のコントロールも必要 Updates

背景 最近、本を読むときはClaude Codeなり、Geminiなり、NotebookLMを隣に置くことが多い 音声入力で話してmcp経由でesaにメモ取らせたり、質問して会話したり、などなど こういう形で勉強しているので、輪読会用の資料もLLM Agentと一緒に作りたくなった しかし、Google Slidesのような形だとLLM Agentが扱いにくい deckというOSSがあり、手元のmarkdownに書いたらGoogle SlideのAPIを叩いてスライドにしてくれる これなら一緒に勉強しながらスライド作っていけそうと思ったので、今週の勉強会で試した 引用の範疇を越えるので、スライド自体はここには貼りません やり方 スライドの叩きの作成 by Gemini まず、スライドの叩きを作ってもらう Sub Section毎くらいの単位に分けたmarkdownファイルを用意する epu

背景 NotebookLMは便利だが、音声解説のUIが使いにくい 自分用の音声ファイルをどこにホストするのか問題 不特定多数が聞けるPodcastとして公開したいわけでもない 解決方法 アイディア: Google Driveに音声ファイルを公開する PodcastのRSSフィードをどうやって作るか問題 自分で使ってみた感想 背景 NotebookLMは便利だが、音声解説のUIが使いにくい NotebookLMの音声解説、便利ですよね 長いテキストをベースにしていても、7分前後でコンパクトに耳から情報を接種できるのが好きです ジムで身体を動かしている最中とか散歩のときとか細切れでも気兼ねなく聞けるのでよい 自分の聞きたい切り口毎にPodcastを作れるのもよいです 例: ブックマークしたけど見れてない情報をニュース的に聞く 例: epub / pdfで配布されているテキストを章毎あるいはトピ

アウトプットするものが多すぎて、書きたくても書けてなかったやつが多くなってきた。簡単でもいいので書かないよりはマシの精神で書いていきます。 Findyに「知の巡りをよくするためのメタデータ管理」を寄稿しました Analytics Engineering領域に特化したAgentのためのドキュメンテーション / ガードレースの事例共有会をやりました アジャイルデータモデリングの輪読会をdatatech-jpでやってます 関西データエンジニア/アナリティクスエンジニアMeetup〜モノタロウ、10X、タイミー、ダイハツ〜をやります Data Engineering Studyのアドバイザに就任しました Google Cloud Champion Innovator改めGoogle Developer Expertになりました 本業で採用活動の再開 その他 Findyに「知の巡りをよくするためのメ

社内のデータ基盤チームのメンバー向けの勉強会で発表した内容を放流します*1。「Analytics Engineerのための」とは付いているものの、実際の勉強会には社内の様々な職種の方も参加してくれて、かつ以下のように業務にも役に立ったという声もあるので、割と有益な内容なんじゃないかなと思っています。 デザイナの方がフロント周りのコードリーディングで役に立った例: SWEで馴染が薄いリポジトリの問い合わせ調査に役に立った例: また、以下のXのSpaceで同じようなことを話しているので、そちらもよかったら聞いてみてください。 Analytics Engineering領域に特化したAgentのためのドキュメンテーション / ガードレースの事例共有会を @okiyuki99 さん / @hanon52_ さん / @ktrru さんとやります! 7/16(水) 12:00からXのSpaceなので

背景 Claude CodeはCLAUDE.mdに書いていたとしても、結構忘れがちです 毎回Claude Codeに自分で指摘するのは疲れます... 条件をトリガーに何かを必ず実行させる仕組み、hookがClaude Codeにはあります フックリファレンス - Anthropic Claude CodeのHooksは設定したほうがいい - じゃあ、おうちで学べる Claude Codeの「すぐルール忘れる問題」をHooksで解決する hookのinputはjsonが渡ってくるので、jqなどで加工すればokかつ簡単に書けるので便利ではある しかし、hookは簡単に読みにくいものになってしまう 例えばStopのhook(処理が終わったらntfy経由で通知させる)だと以下のようなめっちゃ長いものが簡単にできてしまう 入力のjsonの複数の要素を使い回したい場合、一度tmpファイルとして出力しな

背景: LLM Agentに意味のある小さい単位でコミットして欲しい 解決方法: git addを封印し、専用のカスタムスラッシュコマンドを生やす 参考: 試行錯誤の過程 背景: LLM Agentに意味のある小さい単位でコミットして欲しい Claude CodeなどのLLM Agentに対し「意味のある単位で小まめにコミットしてね〜」とinstructionに書いておいてもしばしば忘れられてしまう その結果、複数の意味がある内容の大きなコミットがされてしまう 大きな単位のコミットはレビューもしにくく、revertもしにくいため、よいことがない 何とか大きいコミットを制限できないものか...、と考えた 解決方法: git addを封印し、専用のカスタムスラッシュコマンドを生やす 意味の単位にgitのhunkを分割してステージングさせるsemantic_commitというカスタムスラッシュコ

はじめに 開発背景 termfeedの特徴 キーバインド データ管理 MCPサーバー連携 RSS登録機能 使い方 開発手法と開発時間 音声入力による開発 開発時間 技術的な発見 TUIライブラリの利便性 TUIツールの応用可能性 プロトタイプ後の課題と改善 CommonJSからESModuleへの移行 アーキテクチャの劣化 レビュー用エージェントの活用 テストの重要性 まとめ はじめに 今日はターミナル上で動くRSSリーダー、termfeedを作ったので、それについて紹介しようと思います。 開発背景 少し前までは、livedoor Readerのようなウェブ上で動くRSSリーダーを使っていた人が多かったと思います。しかし、livedoor Readerがサービス終了してしまい、現在はRSSリーダー自体を使わなくなった人や、若い世代ではRSSリーダーを使ったことがない人も多いのではないでしょ

3行まとめ はじめに Claude Codeのログ保存機能とその特徴 ログ分析の活用例 音声入力の課題と英語プロンプトの活用 DuckDBを用いた分析アプローチ スキーマ情報の重要性とログ分析の活用 ログの長期保存設定 まとめ 3行まとめ Claude Codeの会話ログはJSONL形式で保存されており、DuckDBを使って日次の利用状況や音声入力の課題などを分析できる 英語プロンプトの学習効率化やエラーパターンの特定など、自分の仕事の仕方を改善するための実践的な活用方法がある JSONLファイルのスキーマ情報を整理することで、Claude Codeがクエリを書く際の精度が向上する はじめに Claude Codeは非常に強力なツールで、これ自体は別のブログで書く予定ですが、もはやこれなしでコードを書けないほど便利に使っています。今回は、そのClaude Codeとの会話ログを分析すること

はじめに ビジネスメタデータをどこから入力するか ビジネスメタデータをどう入力するか レベル1: 機械的に埋められるもの(自動化層) レベル2: 変換処理で伝播できるもの(自動伝播層) レベル3: 人間の判断が必要なもの(手動層) 運用を継続するための実践的な仕組み 問い合わせをトリガーにメタデータを拡充するフロー 重要度が高いビジネスメタデータの入力を強制する仕組み データの生産者がビジネスメタデータ生成の責任を持つ よくある失敗パターン: みんなで記入型 生産者責任の整理: 誰が何に責任を持つか LLMとビジネスメタデータ LLMの落とし穴 LLMの適切な使い方 どうしてもLLMを使いたい場合の対策 おわりに はじめに これまで私は、メタデータを活用したデータ品質の可視化や、データカタログの運用など、メタデータを「使う」側面について発信してきました。しかし最近、副業先などから「メタデー

3行まとめ アウトプットの速度を上げたいが、記事を書くのは時間がかかる SuperwhisperとVSCodeのCopilot Agentを組み合せて、音声からブログを書き上げるワークフローを組んだ 実際に使っているpromptを含め、真似しやすいように詳しく紹介 3行まとめ 背景: アウトプット速度を上げたい & LLMの急速な進化 利用している技術 Superwhisper: 技術用語も認識する書き起しアプリ VSCode Copilot Agent: 自然言語で校正のワークフローを組み込む 実用例: どれくらい早くアウトプットできるようになるか 実際のワークフロー 工夫した点 過去に自分が執筆したテキストの資産を活用する 依存関係の抽出を自動で行なう 複数のAgentにレビューをさせる タイトル案の自動生成 実装を通して得られた学び 自然言語でワークフローを組み立てることの難しさ エ

長いので3行まとめです。 最近、エンジニアリング経験の浅い方にアドバイスをする機会が増えてきたので、紹介時に使えるポインタをまとめました 何が合っているかは人によるので、正直正解はないと思いますが、少なくとも自分に効いたやり方をまとめています 合いそうなところだけをピックアップして真似してもらうだけでも全然いいと思います 「他にもこういうのをやったら伸びると思うよ!」というのがあったら、SNSなどで反応ください はじめに 真似するのが簡単で効果が大きい Pull Requestをセルフレビューする 趣味プロジェクトを持つ 参考: 自分が過去にやっていた趣味プロジェクト 真似するのは簡単で効果はそこそこ 地味な改善活動を拾い続ける 地道な活動例: READMEやsetupスクリプトの修正 地道な活動例: アーキテクチャ図を書き起こす / 改善する 仕組み化でチームや自分を楽にする 真似するの

あまりよくある話ではないと思うんですが、アナリスト/Analytics Engineerの人にバッチ処理を書いてもらう機会がありました。基本的にはSQLを普段書かれていて*1、場合によってはTerraformを少し書くこともあるというバックグラウンドの方です。これに対して私はレクチャーやサポートする形になったので、メンター的でどういうことを考えていたかをこのエントリでは書こうと思います。 対象のタスク レクチャーしたこと Step by Stepで実装する APIやjqに慣れる Dockerfileを使って環境構築する 正常系を実装する 適切な関数やクラスに分割する コマンドライン引数や環境変数を使う 型アノテーションを付ける loggerについて知る 異常系を考慮する テストどうする問題 脱線 バッチ処理をアナリスト出身の人に書いてもらうのは適切か? バッチ処理初心者とLLMの付き合い方

3行まとめ データエンジニアの界隈で日本からもっとOSSに貢献する人が増えるといいなと思ったので、自分が気を付けていることを事例多めでまとめました データエンジニアの界隈以外でも通じる内容が多いですが、データエンジニアリング文脈多めです 偉そうに書いてますが、自分もまだひよっこ卒業レベルです 3行まとめ 背景: データエンジニアリングの仕事にOSSは欠かせないが、継続的なメンテナンスは簡単ではない Pull Requestを送る前に気を付けていること 類似のissueがないか検索する issueで解決策の頭出しをしてみる 課題が再現する状況をissueに記述する Pull Requestを送る際に気を付けていること 手元でコードを動かす ドキュメントやテストコードを改善する リポジトリの流儀や方針に従う Pull Requestには経緯やWhyを書く リポジトリオーナーがPull Requ

背景: 12月は読むべきAdvent Calendarが多すぎる 紹介したエントリ データ分析で用いるSQLクエリの設計方法 - 風音屋TechBlog datacontract-cliの紹介およびCI/CDについて プロダクトをまたいだクロスセルの施策効果を見積もるためのデータ分析パターン #データ分析 - Qiita セミナーアンケートをBigQueryで簡単に感情分析したお話｜株式会社HR Force Analytics Hub / BigQuery データシェアリング 2024 #AnalyticsHub - Qiita データアナリストが使うと便利な生成AIプロンプト事例 dbtのmaterializationの話 Apache Iceberg BigQuey/BigLake テーブルを触ってみた データエンジニアリング関係の言葉の定義をまとめた（随時更新） #dataengin

会社のAdvent Calendarもdatatech-jp Advent Calendar 2024も枠がめでたく埋まってしまったので、12月感は特にないエントリです。 仕事でdbtのリポジトリの初期設定をすることが時々あるけど、ほぼ同じようなことをやっているので、さっと引用できるようにまとめておきます。この辺をやっておくと、大体安心して仕事ができる、という感覚になります。なお、dbtに関連ないチーム開発で必要な要素も入ってます。 優先度: 高い リポジトリの権限設定 CODEOWNERの設定 Pull Requestテンプレートの導入 sqlfmt / sqlfluffの導入 優先度: 普通 READMEの記載 dbt CloudでのCI/CDの設定 レイヤリングのルールを決めておく レビュー依頼の通知設定 Devcontainerの設定 コストの監視 Renovateの設定を行ない、

3行まとめ データに対する期待値を定義するData Reliability Levelという活動を始めています Data Reliability Levelを設定するには「XXXの場合にはAAAの項目は入力が必須」といった条件分岐や項目数も多く、レビューが大変という課題がありました 最近のJSON Schemaは記述力が高いため、上述のような制約も記述することができました 3行まとめ 前提: データの出口に対する期待値を明示的に設定したい 課題感: 各Data Reliability Levelに対する設定が適切に設定されているかを確認するレビューが大変 解決方法: 各Data Reliability Levelに対する必須入力項目をJSON Schemaで機械的にvalidateする 見所 条件分岐を記述する $refと$defsで繰り返しの記述を避ける anyOfでより柔軟な制約を設定

8/26に「全日本dbt-osmosisを愛でる会」を開催しました。パネルディスカッション形式のため、細かい資料はありませんが、当日のアジェンダなどは以下のスライドで公開しているため、雰囲気は感じ取ってもらえるかと思います。 開催の経緯: ノリと勢い 開催当日の盛り上がり 開催時の工夫: 頑張らないを頑張る 地方在住での勉強会との向き合い方 開催の経緯: ノリと勢い きっかけは株式会社ヤプリの山本さんが公開してくださった以下のエントリでした。 私が過去に発表したスライドやエントリを参考にしてもらっていて、めっちゃ嬉しかったです。また、bq_sushiなどの東京の勉強会に参加した際に「dbt-osmosis使ってます」と(リポジトリオーナーではなくただのcontributorである)私に声をかけてもらったりすることもありました。「これだけdbt-osmosisのユーザーが増えてきているのであ

今日もbq loadが失敗して涙を流していたデータエンジニアのid:syou6162です*1。このエントリではbq loadを使ったデータ取り込みで泣かないで済む、あるいは泣いても致命傷まではいかないようにするための色々なTipsを書きます。 bq loadをベースに書いていますが、SDKを使ってBigQueryにデータを取り込む際もほぼ同様のことを考えれば十分な場合が多いです。 bq loadの基本形 スキーマを自分で指定する 取り込み失敗時の対処方法 パーティショニング列やクラスタ列を指定する 必要であればbq queryと組み合わせて使う 洗い替えしたい場合 パーティション指定で洗い替え 一癖あるデータと戦う Shift-JISやEUC-JPのファイルを読み込む レコード内に改行を含むCSVを読み込む --max_bad_recordsオプションは最小限に 運用中のスキーマ変更に立ち

背景: データ品質を担保するにはデータソースの品質が重要 データソースの品質を担保する手段としてのData Contract Data Contractの表現方法の一つとしてのProtocol Buffers Data ContractとしてProtocol Buffersを使う データの入出力を一箇所に集約、Protocol Buffersで抑えるパターン ストレージのスキーマをProtocol Buffersで抑えるパターン 発展的な話題 & 読書会の案内 参考文献 背景: データ品質を担保するにはデータソースの品質が重要 私はデータエンジニアをしており、DWHやデータマートのデータ品質について考えることが多い。BigQueryなどにデータが取り込まれた後のレイヤリングやテスト、改善に向けたデータ品質の可視化について、以前発表した。 データが取り込まれた後の整理は進んでいるものの、やは

自分用のメモです。以下のエントリで便利なスクリプトを作りました。 不可解な現象に遭遇 このスクリプトを使って、いくつかのデータを調べていましたが、ぱっと見不思議な現象に遭遇しました。 比較対象のテーブルAとB(クエリは同一のものを仕様。作成元がprodとdevで異なる)があり、特定のカラムで差分が大量に発生している クエリ内のリネージを調べたところ、元データは完全に一致していることが分かった 罠はウィンドウ関数の利用方法にあった 「じゃあ、どこで差分が発生するんだよ...」となるわけですが、データに原因がないとすると、ありえるのはクエリです。乱数を利用しているわけでもないクエリで何で差分が発生するのか少し調べたところ、ウィンドウ関数を利用している箇所に問題があることが分かりました。 具体例があったほうが分かりやすいので、以下のような注文データを考えてみましょう。ユーザーが購入した金額とその

初めて使ったBIツールはLooker Studioのid:syou6162です。これまでTableau / Looker(≠ Looker Studio) / Metabase / Redash / Connected Sheetsなど色々なBIツールを触ってきましたが、不満は色々ありつつも個人的に一番しっくりきて愛着があるのはLooker Studioです。このエントリでは、その魅力と便利な使い方や注意点について書きます。例によって、社内勉強会向けの内容を外向けに公開しているため、内容の網羅性などは特に担保していないことにご注意ください。 Looker Studioの魅力 利用のハードルが限りなく低い & Google Workspaceとの連携が便利 複雑過ぎることができないので、諦めが付けやすい ちゃんとBIツールになっている Looker Studioの便利な使い方 多様なデータソ