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

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

最近「ああ、これ前職でも前々職でもやったことあるなぁ」という仕事があった。データエンジニア(やその関連職種)として働き始めて約5年、3社でフルタイムとして働いてきて「このスキルは業界や組織規模が変わってもデータエンジニアとしてスキルを求められることが多いな」と感じたものをまとめてみることにした。棚卸し的な意味はあるが、特に転職用などではないです。 前提 どこでも必要とされたスキル データマネジメントに関する概要レベルの知識と実行力 セキュリティや法令に関する知識 事業ドメインに関する興味関心 他職種とのコミュニケーション能力 コスト管理 / コスト削減のスキル ソフトウェアエンジニアとしてのスキル DataOpsやアラートのハンドリング能力 分析用のSQLを書く力 古いテーブルやデータパイプラインを置き換えていくスキルや胆力 あるとやりやすいスキル 関連部署の動きを何となく把握しておく力

背景 担保したいこと 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を使っていても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について

シリーズの第三弾です。読者の宿題にしてたけど、誰も書いてくれなさそうだったので結局自分で書きました。 背景 Looker StudioはGoogle Workspaceを使っていれば基本的に無料で使えますし*1、権限管理にGoogle Groupとも連携できるので、人気のBIの一つだと思います。私が初めて触ったBIもLooker Studioだったので、(API強化して欲しいとか不満は山のようにありつつも)何だかんだで憎めないし、さっとダッシュボード作りたいときはLooker Studioを使うことが多いです。会社によっては社内の公式のダッシュボードをLooker Studioで作っているところもあると思います。 dbtで作ったテーブルがConnected Sheetsから参照されている場合、一定程度利用されているスプレッドシートからのテーブルの参照状況はデータ基盤を管理する人間としては把

3行まとめ テーブルの撤退時にはテーブルの参照回数を見ることが多いと思いますが、テーブル単独の参照回数を見るだけだと不十分なことが多いです 派生先のテーブルの参照回数まで考慮すると、テーブルが撤退できるか安全に判断することができます リネージ上の親子関係をWITH RECURSIVEで考慮しながら、累積参照回数をSQLで導出できるようにし、安全にテーブル撤退を判断できるようにしました 3行まとめ 背景: テーブルの撤退にはテーブル単独の参照回数を見るだけだと不十分 アイディア: 累積参照回数を計算する 実装 テーブル間の親子関係を抽出する WITH RECURSIVEでテーブルの親子関係を辿る テーブルの親子関係を考慮しながら、累積参照回数を計算する まとめ 背景: テーブルの撤退にはテーブル単独の参照回数を見るだけだと不十分 データエンジニアやアナリティクスエンジニアの仕事をしていると、

データの可用性を可視化したい データの可用性の解像度を上げたい: elementary-data elementaryによる細かい可視化 大雑把にデータセット単位で可用性を可視化したい まとめ データの可用性を可視化したい データ品質は正確性や最新性など様々な項目に分解することができますが、可用性(Availability)はその中でも基礎的な項目です。使いたいときにデータが使えないと困るので。 自分が所属しているチームはdbt(cli)およびdbt cloudを使っていますが、可用性を考えるのであれば cli: dbt runの実行結果 dbt cloud: Jobsの実行結果 をそれぞれ確認したり、こけているようであればアラートを飛ばすという運用が多いと思います。これだけだと「いつこけた」しか分からないので、Datadogを使って「いつこけた」「いつ復旧した」「こけて落ちていた時間はど

背景 vscode-dbt-power-userがよかったところ 定義にさっと行ける / 戻れる(Go to definitionが使える) VSCode内でモデル間のリネージが見れる VSCode内からdbtのモデルをさっと実行できる モデルファイルの単独の実行も簡単 コンパイル済みのSQLファイルをさっとプレビューできる まとめ 補足: vscode-dbt-power-userの導入方法 背景 dbtは前職時代から含めると二年以上使っていて、SQLでDWHやデータマートの開発をしようと思うともはやこれなしでは生きられないくらいには便利になっている。dbtがあっても大変なクエリは大変ではあるが、大変さは大分緩和してくれる。dbtがなくて、1つのSQLが1000行以上あり、中間クエリがテストもされていない、という状況はもう戻りたくない...。 dbtに限らずであるが、コードは書いていると

これは何? 背景: 権限管理とTerraform 権限管理の対象 誰に権限を付与するのか どのスコープで権限を付与するのか どの強さで権限を付与するのか Terraformについて Terraformの概要: 権限管理でTerraformを使うと何がうれしいのか 例: roles/bigquery.jobUserを付与してみる コラム: どこでTerraformを実行するか Terraformでの権限管理の例 例: データセットの作成 例: データセットに対する権限付与 サービスアカウントの管理 iam_member関連の注意点: AdditiveとAuthorativeを意識する Terraformで管理されていなかったリソースをTerraform管理下に置く: terraform import Terraformの登場人物 terraform planやterraform applyの

3行まとめ 9/15で株式会社MonotaROを退職し、9/16に株式会社10Xに入社しました アナリティクスエンジニアとして、相変らずデータマネジメントやデータエンジニアリングを中心に活動してます 引き続き京都で働いてますし、変わらずオンラインのコミュニティ活動もやっていく予定です 3行まとめ MonotaROはどうだったの? 10Xはどうなの? 入社のきっかけ 入社後の印象 データマネジメントどうなの? MonotaROはどうだったの? 自分のキャリアの中でデータエンジニアとしてMonotaROで働けたのは本当によい経験でした。MonotaROに入る前もデータエンジニアの仕事はしていたものの、社内でデータエンジニア専門として働く人は自分だけ*1だったため、踏み込んだ議論ができる機会はそれほどありませんでした。そのため「きっとこれは筋悪くないやり方のはずなんだけど、イマイチ自信が持てない

3行まとめ Cloud Monitoringにメトリックを投稿するのは案外面倒 コマンドラインからさっとメトリックを投稿するのに便利なツールを作った jqでさっと加工して、がっとメトリックを投稿したいときにどうぞ 背景 Cloud MonitoringはGCP上で監視を行ないたい場合、便利なサービス 仕事でも趣味でも使っている 事前に用意されている指標や自分で作ったカスタムメトリックを投稿できる ref: 指標の一覧  |  Cloud Monitoring  |  Google Cloud しかし、メトリックを投稿するのは案外面倒 ref: カスタム指標の作成  |  Cloud Monitoring  |  Google Cloud 別に難しいことはないのだが、「JSONで返ってくるAPIのレスポンスをjqで適当に加工して、Cloud Monitoringに投稿して〜」をやろうとすると

データエンジニア系の勉強会で最近dbtがぱらぱらと話題に出てくるようになった & 4連休ということで、夏休みの自由研究がてらdbtを触ってみました。書いてる人のバックグラウンドは以下の通り。 DWHやデータマートの構築のためのETLツールを模索中(特にTの部分) プライベートではDataformを使っている 前職でも仕事の一部で使っていた 開発効率を計測するデータ基盤の管理にDataformを使ってみた - yasuhisa's blog 定期バッチ処理はArgo Workflows on GKEでやっている 触ってみないと肌感とか自分で運用できるかのイメージが湧かないのでね。 Dataformとの比較 細かいノウハウ 手元や本番環境での動作 Argo Workflowとの連携 環境によってDWHの提供するバージョンを差し替える DWHやデータマートの外の情報をデータリネージに加える 既存

Twitterでは先に言っていましたが、現職のはてなを3月末で退職します。3/19が最終出社日でした。はてなでの思い出はこちらに書きました。 そのため、転職活動をしたわけですが、コロナ禍での転職活動は平常時と異なる部分も結構ありました。また、データエンジニアとしての転職は初めての経験でした。誰かの参考になるかもしれないので、私が考えたことや感じたことをメモ書きとして残しておきます。 在宅勤務と就業可能な地域 Web上でのアウトプット データエンジニアという職種の多様性 転職にあたって重視したこと 魅力に感じた点 当然、不安もある 在宅勤務と就業可能な地域 カジュアル面談させてもらった企業さんは、ほぼ在宅勤務に移行済みだった 隔週や月一で物理出社という会社も半々くらい? 緊急自体宣言が出ていない時期(夏〜秋)にカジュアル面談させてもらったので、今は状況が違うかも カジュアル面談、採用面談もz

Dataformを初めて使ってみたので、雑に感想を書いておきます。結構よかった。 使ってみようとした背景 Dataformについて 試してみてどうだったか よかった まだまだこれからっぽいところ & 気になり 参考 使ってみようとした背景 今週、社内の開発合宿に参加していた。変更のリードタイムやデプロイ頻度などのFour Keysにあるような指標を計測できるデータ基盤を作るのが目標。様々なチームの開発のパフォーマンスをトラッキングしやすくして、うまくできているチームがなぜうまくいっているのかを明らかにしたり、改善施策を行なった結果指標も改善しているか定量的に確認できるようにして、開発効率を上げる土台を作るというのが目的。この辺の詳しいことは後々別のエントリで書かれると思う。 自分のチームは3人構成で、在宅のオンラインでやっていた。 id:shiba_yu36さん Mackerelチームでも

そろそろ前職を退職してから、はてなで働き始めて5年(!)が経とうとしている。5年も働いていると、昔何をやっていたか、その当時どういう気持ちで働いていたかを忘れてしまう。備忘録っぽく書き残しておこう。ポエムです、長いです、大体自分向けに書いてる。 NTT CS研 => 株式会社はてな チーム開発への適応 インフラ苦手意識の克服 教師なし機械学習の本番環境での運用 データ基盤とCustomer Reliability Engineerへの挑戦 今後はデータエンジニアリング NTT CS研 => 株式会社はてな 基礎研究職からWebアプリケーションエンジニアへの転職だった。ログを残しておくと、こういう時に振り返れて便利。 NTT CS研を退職して、株式会社はてなに入社しました - yasuhisa's blog 割と珍しい(?)転職ではあったかもしれないが、機械学習や自然言語処理はアルゴリズム単

こういう風に投稿すると(左)、esa.ioにこういう感じ(右)で投稿される分報風のアプリを自分用に年末年始に作りました。 作った動機 使った要素技術 Firebase Authentication Firebase Hosting + React Firebase Cloud Functions デプロイ自動化 所感 作った動機 きっと皆さんそうしているように、私も日々ログを残しながら作業をしている。仕事ではscrapboxを使っているが、プライベートではesa.ioを愛用している。プレビューを見つつmarkdownで書けたり、タグとカテゴリがいい感じに使えたりするところが気に入っている。あと、アイコンがかわいい。 ちゃんと作業をするときにはesa.ioにページを作るが、そうでない雑なものも記録したいときが度々ある。例えばこういうの。 今度コンビニ行ったとき、忘れずにXXXを買う 統計の本

去年に引き続き、東京都立大学の非常勤講師の依頼をid:mamorukさん(小町先生)からして頂いたので、今年も講義を担当してきました。講義の内容としては Mackerelでのロール内異常検知を題材に、機械学習をプロダクトに取り込んでいく際、どういった視点が必要になるのか 実際の開発はどういった形式やツールで行なわれているのか、擬似的に体験してもらう といった内容(講義 & 演習)で行ないました。内容としては昨年とほぼ一緒ですが、新型コロナウイルスの影響で演習パートがオフラインの対面ではなく、オンラインで行なう点が一番違いました。演習系のサポートは学生さんの手元の環境がそれぞれ違う、などあって去年も苦戦しました。今年は同じ感じでいくとさらに大変そう(というか見切れない...)だろうなと思って、やり方を考えてみました。 他にいいやり方があったら誰か教えて & 自分用の今後*1のメモという感じの