サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
掃除・片付け
www.yasuhisay.info
最近「ああ、これ前職でも前々職でもやったことあるなぁ」という仕事があった。データエンジニア(やその関連職種)として働き始めて約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から参照されている場合、一定程度利用されているスプレッドシートからのテーブルの参照状況はデータ基盤を管理する人間としては把
以下のConnected Sheets版です。これはかなり便利なものができたと、自画自賛してます。 背景 Connected Sheetsをdbtのexposureとして取り込む 見所 Connected Sheetsからのクエリか判断する BigQuery Scripting経由で発行されたクエリでもreferenced_tablesの情報を取得する クエリ回数やクエリされた週の数をメタデータとして加える まとめ 背景 Tableauと比べると、Connected Sheetsはアドホックな分析で使われることが多いと思います。実際、筆者が所属している会社でも「Tableauは公式のダッシュボード、それ以外のアドホックな分析はConnected Sheetsで行なってね」と案内しています。とはいえ、公式のダッシュボードにするためにはdbtなどを使ってデータソースを信頼できる形に整備する必要
N番煎じですが、やってみる機会があったので一般化してメモしておきます。 背景: コードレビューを素早く行なうことの重要性 レビューのフローを整理する GitHub Actionsでレビュー依頼を自動化する 背景: コードレビューを素早く行なうことの重要性 チーム開発で重要なことは色々あります*1が、Pull Requestを出したときに素早くレビューをしてもらえるというのはとにかく重要なことの一つです(日本語版)。 レビュー依頼がきたら今すぐ仕事をやめてレビューをしなければならない、というわけでないですが、一日に2~3回は見るようにしようと思いながら過ごしています。レビュー依頼を手動で「XXXさん(あるいはチーム)、以下のPull Requestのレビューお願いします!」とmentionしてもいいですが、一日に何回も明示的にレビュー依頼をしていると「ちょっとうるさいかもな、まとめて依頼しよ
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
データの可用性を可視化したい データの可用性の解像度を上げたい: elementary-data elementaryによる細かい可視化 大雑把にデータセット単位で可用性を可視化したい まとめ データの可用性を可視化したい データ品質は正確性や最新性など様々な項目に分解することができますが、可用性(Availability)はその中でも基礎的な項目です。使いたいときにデータが使えないと困るので。 自分が所属しているチームはdbt(cli)およびdbt cloudを使っていますが、可用性を考えるのであれば cli: dbt runの実行結果 dbt cloud: Jobsの実行結果 をそれぞれ確認したり、こけているようであればアラートを飛ばすという運用が多いと思います。これだけだと「いつこけた」しか分からないので、Datadogを使って「いつこけた」「いつ復旧した」「こけて落ちていた時間はど
なぜ列レベルのアクセス制御とポリシータグが必要か Terraformでポリシータグの作成および権限付与 ポリシータグの付与の仕方 dbt経由の場合 bq loadを使う場合 運用上の注意点 まとめ なぜ列レベルのアクセス制御とポリシータグが必要か 「テーブルの全てのカラムは見せたくない」「rawデータは見せたくなくて、統計量だけは許可したい」などセキュリティ面からの要求でこういったことを実現したい / しなければならない場面はそれなりに多い。個別にカスタマイズしようと思うと、承認済みビューがカスタマイズ性があり便利ではあるが、以下のような課題がある。 用途毎にカスタマイズできてしまうがゆえに、都度承認済みビューを作る必要がある データ基盤のチームが少人数の場合、運用負荷がバカにならない 自分がこれまで所属していた組織でも結構辛かった 権限の整合性を担保するのが難しい 承認済みビューAではX
背景 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はデータカタログ以外の機能もたくさんありますが、データカタログの観点にフォーカスして書いてます 論理的なデータ構造を作成したり、それに基づいた権限管理など 少人数のチームでデータ基盤を運営しており、データカタログの運用自体に工数をなかなか割けない前提で書いてます 自前で作ることも難しいし、ましてそれを継続的に運用するのはさらに難しい 「データカタログ」という言葉が指すスコープも色々ありそうですが、「検索 + メタデータ管理」くらいのスコープで書いてます 包括的に書くつもりはないので、漏れてる観点は多いと思います データカタログがなぜ必要か
SQLをレビューしていて、シャーディングテーブル(日付別テーブル)をサブクエリを使ってフィルタしているものがあった。BigQureyのシャーディングテーブルはWHERE句で日付の条件を書いてやるとスキャン範囲を限定することができるので便利ではあるが、サブクエリを使うなど定数でないものが入るとフルスキャンが走ってしまう。 このように書くことによって、スキャン量は from_date ~ to_date までのテーブルしかスキャンしないので全tableのスキャンすることを防ぐことができます。 しかし、このワイルドカードテーブルへのクエリにサブクエリなどの定数式でない条件を使ってしまうと、途端にフルスキャンを行ってしまいます. このこと自体は覚えていたものの「じゃあ、具体的にどうやって回避すればいいの?」というのをぱっと言語化できなかったので、ちょっとまとめておく。 ちなみに、サブクエリを使って
背景 具体的な設定 コントローラーに設定を生やす 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
3行まとめ ビジネスメタデータはデータ生成者にとってもデータ活用者にとっても重要 しかし、カラムのメタデータを同じ説明をあちこちに書いていくのは大変... dbt-osmosisはビジネスメタデータの管理を省力化したり、自動化できる便利なツール 3行まとめ 背景: メタデータの重要さとメタデータ管理の大変さ 大変さ1: 多段のデータレイヤーにどうメタデータを付与していくか 大変さ2: 継続的な運用をどうするか dbt-osmosisでメタデータ管理を行なう 依存関係を考慮したメタデータの伝播 自動化による継続的な運用 基本的な使い方 使ってみた感想 背景: メタデータの重要さとメタデータ管理の大変さ データマネジメントにおいてメタデータの重要性は今さら説明するまでもないと思います。メタデータは以下の3種類が代表的です。 A: テクニカルメタデータ B: オペレーショナルメタデータ C: ビ
これは何? 背景: 権限管理と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だったため、踏み込んだ議論ができる機会はそれほどありませんでした。そのため「きっとこれは筋悪くないやり方のはずなんだけど、イマイチ自信が持てない
夏休みの自由研究です。軽く触ってみました程度の技術調査なので、あまり当てにしないでください...。 Argo WorkflowsからCloud Workflowsへの移行のモチベーション ワークフローエンジン上で動かしている既存のジョブ Cloud Workflowsとは ワークフローを動かしてみる よかったポイント 改善して欲しいポイント 所感 Argo WorkflowsからCloud Workflowsへの移行のモチベーション 仕事やプライベートでデータ基盤や機械学習のワークフローエンジンとして、Argo Workflowsを最近ずっと使っている。単体だと足りない部分も多少あったが、補助のスクリプトを自前で書くことで概ね満足した使い勝手になっている。 一人や少人数のチームで使う分にはいいのだが、Argo WorkflowsはKubernetesネイティブなワークフローエンジンというこ
背景 & Disclaimer 自分自身はこれまでBigQuery Scriptingをほぼ使っていませんでした BigQuery自体は3年くらいの利用歴 SQL単発で済ませるのが苦しそうな場合は、Pythonなどのプログラミング言語 + ワークフローエンジンの組み合わせで戦っており、自分としては特に困っていなかった 社内で他の方が使うケースをぼちぼち見ることがある 自分は困っていなくても、社内のBigQueryユーザーでBigQuery Scriptingを使っていて困っている人がそれなりにいる 著者はそれなりのBigQueryユーザーがいる企業のデータ基盤の人間です さすがに「使ったことないので、分からないですねー」で済ませるわけにはいかなくなってきた そもそもどんなユースケースで便利なのかすらも分かっていない状態なので、便利そうに思える場合をまとめてみることにしました というわけで、
背景 どうやって異常を検知するか BigQuery MLでの異常検知 検知できるモデルの種類 共通設定 データの前準備 モデルの学習 モデルを元にスロット使用量が異常に増加していないか予測する 所感 背景 BigQueryはオンデマンドとフラットレート(定額料金)がある オンデマンドはスキャン量がお金に直結するため、INFORMATION_SCHEMA.JOBS_BY_*などを使ってクエリ警察をしている方も多いはず INFORMATION_SCHEMAに代表されるデータ管理に役に立つ現場のノウハウを最近会社のTech Blogに書いたので、そちらも見てね 一方で、フラットレートに関しては定額使いたい放題のプランであるため、オンデマンドよりはクエリ警察をしていない場合もある 見れるなら見たいが、どうしても支出に直結するオンデマンドを優先して見てしまいがち。工数も限られている が、あまりに自由
背景 (BigQueryに限らず)ビューは便利 テーブル化する必要がないので、ビュー内で参照しているテーブルが更新されたらビューの結果も新しいものを参照できる 物理テーブルと違って、保存料金を気にする必要がない 一方で、ビューにはパラメータを渡すことができない テーブル化するときには渡せるのだが... Running parameterized queries | BigQuery | Google Cloud ↑は時々困る 例: BigQueryのAudit Logを社内で広く公開したい クエリに個人情報などが入るプロジェクトがあり得るため、生のAudit Logを公開したくない 適切にフィルタリングした上で公開したい ビューとして提供すると、期間が固定になってしまう Audit Logの元テーブルは巨大なので、適切に日付で絞れないとスキャン量も巨大になってしまう とはいえ、期間
3行まとめ Cloud Monitoringにメトリックを投稿するのは案外面倒 コマンドラインからさっとメトリックを投稿するのに便利なツールを作った jqでさっと加工して、がっとメトリックを投稿したいときにどうぞ 背景 Cloud MonitoringはGCP上で監視を行ないたい場合、便利なサービス 仕事でも趣味でも使っている 事前に用意されている指標や自分で作ったカスタムメトリックを投稿できる ref: 指標の一覧 | Cloud Monitoring | Google Cloud しかし、メトリックを投稿するのは案外面倒 ref: カスタム指標の作成 | Cloud Monitoring | Google Cloud 別に難しいことはないのだが、「JSONで返ってくるAPIのレスポンスをjqで適当に加工して、Cloud Monitoringに投稿して〜」をやろうとすると
この記事は、datatech-jp Advent Calendar 2021の1日目の記事です。 datatech-jpというコミュニティについて 何をやっているコミュニティなの? The Self-Service Data Roadmap読み会 Airflow困り事相談会 waiwai会 どういうコミュニティにしていきたいか datatech-jpというコミュニティについて こんにちは。モノタロウでデータエンジニアをやっているid:syou6162です。 今年の夏頃からdatatech-jpというコミュニティの運営に関わっています。元々はThe Self-Service Data Roadmapという本の読み会のためにSlackを立てたのがきっかけでした。 評判の良い The Self-Service Data Roadmapの輪読会を8月くらいからゆるっと始めようと思ってます。 興味あ
最近、「なぜid:syou6162はアウトプットを続けているのか」を聞かれる機会があった。 会社のnoteのインタビューを受けた*1中で、もう15年もブログを書いていることについて聞かれたり*2 会社のLT大会をやっているんだけど、なぜアウトプットを推進しようとしているのか聞かれたり 自分のスタンスを説明しているエントリがあると便利だなと思ったので、ポエムを書いてみます。 インプットのためにアウトプット: 情報は出す人のところに集まる 自分が考えていることをぱっと他人に伝えるのに便利 未来の自分へのお手紙 議論: アウトプットはしたほうがよいか? 個人 組織 インプットのためにアウトプット: 情報は出す人のところに集まる これが一番大きい。雑な試行錯誤とか自分用のまとめとか「こういうところ困ってるんだけど、誰か知見持ってる人助けて!!」とかを書くことが多いんだけど、そういった情報を出してお
dbtの紹介 タイトルの通り、モノタロウの(非公式)勉強会でdbtのことについて話してきました。すでに使っている人には新しい情報はほぼないですが、他部門の方に「データ触ってるとこういうところ辛いよね〜」「dbt使うといい感じに解決できるケースもありますよ」という雰囲気の内容で話してます。 合わせて読みたい。 入社してから初の勉強会主催 モノタロウに入社してからまだ半年も経っていないですが、初めて勉強会を主催しました。社内だけど参加者の2/3くらいの方は「zoomでもお話するの初めてでは??」という状態だったのですが、後先何も考えない性格(アホ)だからやれてるんだろうなと思います。ラッキーなことに発表してくれるという方がすぐに集まって OSSへのcontributeの仕方 フロントエンドの開発を爆速にする方法 よい週報の書き方 データメッシュ Cloud Buildとの試行錯誤 など(タイト
次のページ
このページを最初にブックマークしてみませんか?
『yasuhisa's blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く