複数の企業でデータエンジニアとして求められたスキル - yasuhisa's blog
最近「ああ、これ前職でも前々職でもやったことあるなぁ」という仕事があった。データエンジニア(やその関連職種)として働き始めて約5年、3社でフルタイムとして働いてきて「このスキルは業界や組織規模が変わってもデータエンジニアとしてスキルを求められることが多いな」と感じたものをまとめてみることにした。棚卸し的な意味はあるが、特に転職用などではないです。 前提 どこでも必要とされたスキル データマネジメントに関する概要レベルの知識と実行力 セキュリティや法令に関する知識 事業ドメインに関する興味関心 他職種とのコミュニケーション能力 コスト管理 / コスト削減のスキル ソフトウェアエンジニアとしてのスキル DataOpsやアラートのハンドリング能力 分析用のSQLを書く力 古いテーブルやデータパイプラインを置き換えていくスキルや胆力 あるとやりやすいスキル 関連部署の動きを何となく把握しておく力
個人的なdbtの推しポイントを書いてみる - yasuhisa's blog
dbtや同じ系統のDataformなど、ELTの特にTransform部分に強みを持つツールを使い始めて大体3年になる。主観だけど、それなりに使い倒している部類だと思う。 開発効率を計測するデータ基盤の管理にDataformを使ってみた - yasuhisa's blog dbtを触ってみた感想 - yasuhisa's blog dbt カテゴリーの記事一覧 - yasuhisa's blog これらのツールで巷でよく言われる データリネージの可視化ができる データに対するテストが簡単に書ける エンジニア以外の人ともコラボレーションしやすい あたりの話は耳にタコができるくらい聞いていると思うので、ニッチではあるもののそれ以外のdbtの個人的に推しなポイントをダラダラと書いてみたいと思う。データエンジニアやデータガバナンスを推進する人には共感してもらえる内容かもしれない。 推しポイント:
dbtで見やすいER図を生成する - yasuhisa's blog
背景: dbtを使っていてもER図は欲しい! どうやってER図を生成するか どうやってER図を見やすくするか まとめ 背景: dbtを使っていてもER図は欲しい! dbtはモデル間のリネージなど可視化が得意なツールではありますが、万能なわけではありません。モデルの生成過程などはリネージで担保できますが、分析時に「どれとどのモデルがJOINできて、JOINする際のキーはこれを使って」というER図で扱うような可視化はディフォルトではできません。 DWHを作っている側からすると「このテーブルはあの辺のテーブルと一緒に使うと便利で、いつもあのキーでJOINして」というのが頭の中に入っていることが多いため、ER図がなくてもどうにかなることも多いでしょう。しかし、分析に慣れていない人や分析に慣れている人であっても、普段と異なるドメインのテーブルを触るときはER図が提供してくれる情報は有用です。ちなみに
DWH改善に生かす! 入門elementary - yasuhisa's blog
前提: これは何? dbtを使ったデータプロダクトを作っている社内のチームメンバー向けに書いた勉強会用のドキュメントです 社外に公開できるように少し抽象化して書いてます DWHに限らずdbtを使ったデータプロダクトで生かせる話ですが、分かりやすさのためにDWHを題材にしています 3行まとめ elementaryはdbtを利用しているデータパイプラインに対してData Observabilityを強化するツールであり、付属のリッチなレポートやSlachへのアラート通知が便利です しかし、実はelementaryが内部で生成している成果物はDWHの改善に役に立つものがたくさんあります 本エントリではelementaryの成果物や役に立つ実例を多めに紹介します 前提: これは何? 3行まとめ 背景: DWHとデータ品質 Observability / Data Observabilityについて
派生先テーブルの参照回数も考慮して安全にテーブルを撤退する - yasuhisa's blog
3行まとめ テーブルの撤退時にはテーブルの参照回数を見ることが多いと思いますが、テーブル単独の参照回数を見るだけだと不十分なことが多いです 派生先のテーブルの参照回数まで考慮すると、テーブルが撤退できるか安全に判断することができます リネージ上の親子関係をWITH RECURSIVEで考慮しながら、累積参照回数をSQLで導出できるようにし、安全にテーブル撤退を判断できるようにしました 3行まとめ 背景: テーブルの撤退にはテーブル単独の参照回数を見るだけだと不十分 アイディア: 累積参照回数を計算する 実装 テーブル間の親子関係を抽出する WITH RECURSIVEでテーブルの親子関係を辿る テーブルの親子関係を考慮しながら、累積参照回数を計算する まとめ 背景: テーブルの撤退にはテーブル単独の参照回数を見るだけだと不十分 データエンジニアやアナリティクスエンジニアの仕事をしていると、
データエンジニア / Analytics Engineer向けの権限管理のためのTerraform紹介 - yasuhisa's blog
これは何? 背景: 権限管理とTerraform 権限管理の対象 誰に権限を付与するのか どのスコープで権限を付与するのか どの強さで権限を付与するのか Terraformについて Terraformの概要: 権限管理でTerraformを使うと何がうれしいのか 例: roles/bigquery.jobUserを付与してみる コラム: どこでTerraformを実行するか Terraformでの権限管理の例 例: データセットの作成 例: データセットに対する権限付与 サービスアカウントの管理 iam_member関連の注意点: AdditiveとAuthorativeを意識する Terraformで管理されていなかったリソースをTerraform管理下に置く: terraform import Terraformの登場人物 terraform planやterraform applyの
データ活用の関係者に課題感のヒアリングをする時の型を紹介する - yasuhisa's blog
背景: データマネジメントのアセスメントのために各部署に現場の課題感をヒアリングしたい 課題: よいヒアリングをするのは簡単ではない 解決案: ヒアリングの型を決める ヒアリングの質問とリサーチの質問を別々に持っておく ヒアリング対象者について事前に理解を深める 全員に同じ項目を聞かない & 全体のカバレッジも担保する その場で問題解決を始めない まとめ 参考 背景: データマネジメントのアセスメントのために各部署に現場の課題感をヒアリングしたい データガバナンスを強化したいときにアセスメント(データマネジメント成熟度アセスメント)をやる人は多いと思う。データ基盤やデータに強い人だけでアセスメントをやって「えいや!!」と優先度を決めるのも一つの手ではある。 しかし、データを通じてユーザーに価値を届けるということまで考えると、データ活用に関わる幅広い職種の現場へヒアリングに行くことが、データ
BigQuery MLでスロット使用量が急増しているプロジェクトやユーザーを異常検知する - yasuhisa's blog
背景 どうやって異常を検知するか BigQuery MLでの異常検知 検知できるモデルの種類 共通設定 データの前準備 モデルの学習 モデルを元にスロット使用量が異常に増加していないか予測する 所感 背景 BigQueryはオンデマンドとフラットレート(定額料金)がある オンデマンドはスキャン量がお金に直結するため、INFORMATION_SCHEMA.JOBS_BY_*などを使ってクエリ警察をしている方も多いはず INFORMATION_SCHEMAに代表されるデータ管理に役に立つ現場のノウハウを最近会社のTech Blogに書いたので、そちらも見てね 一方で、フラットレートに関しては定額使いたい放題のプランであるため、オンデマンドよりはクエリ警察をしていない場合もある 見れるなら見たいが、どうしても支出に直結するオンデマンドを優先して見てしまいがち。工数も限られている が、あまりに自由
コマンドラインからCloud Monitoringに簡単にメトリックを投稿できるツールを作った - yasuhisa's blog
3行まとめ Cloud Monitoringにメトリックを投稿するのは案外面倒 コマンドラインからさっとメトリックを投稿するのに便利なツールを作った jqでさっと加工して、がっとメトリックを投稿したいときにどうぞ 背景 Cloud MonitoringはGCP上で監視を行ないたい場合、便利なサービス 仕事でも趣味でも使っている 事前に用意されている指標や自分で作ったカスタムメトリックを投稿できる ref: 指標の一覧 | Cloud Monitoring | Google Cloud しかし、メトリックを投稿するのは案外面倒 ref: カスタム指標の作成 | Cloud Monitoring | Google Cloud 別に難しいことはないのだが、「JSONで返ってくるAPIのレスポンスをjqで適当に加工して、Cloud Monitoringに投稿して〜」をやろうとすると
開発効率を計測するデータ基盤の管理にDataformを使ってみた - yasuhisa's blog
Dataformを初めて使ってみたので、雑に感想を書いておきます。結構よかった。 使ってみようとした背景 Dataformについて 試してみてどうだったか よかった まだまだこれからっぽいところ & 気になり 参考 使ってみようとした背景 今週、社内の開発合宿に参加していた。変更のリードタイムやデプロイ頻度などのFour Keysにあるような指標を計測できるデータ基盤を作るのが目標。様々なチームの開発のパフォーマンスをトラッキングしやすくして、うまくできているチームがなぜうまくいっているのかを明らかにしたり、改善施策を行なった結果指標も改善しているか定量的に確認できるようにして、開発効率を上げる土台を作るというのが目的。この辺の詳しいことは後々別のエントリで書かれると思う。 自分のチームは3人構成で、在宅のオンラインでやっていた。 id:shiba_yu36さん Mackerelチームでも
はてなで働き始めてからほぼ5年になるので振り返ってみる - yasuhisa's blog
そろそろ前職を退職してから、はてなで働き始めて5年(!)が経とうとしている。5年も働いていると、昔何をやっていたか、その当時どういう気持ちで働いていたかを忘れてしまう。備忘録っぽく書き残しておこう。ポエムです、長いです、大体自分向けに書いてる。 NTT CS研 => 株式会社はてな チーム開発への適応 インフラ苦手意識の克服 教師なし機械学習の本番環境での運用 データ基盤とCustomer Reliability Engineerへの挑戦 今後はデータエンジニアリング NTT CS研 => 株式会社はてな 基礎研究職からWebアプリケーションエンジニアへの転職だった。ログを残しておくと、こういう時に振り返れて便利。 NTT CS研を退職して、株式会社はてなに入社しました - yasuhisa's blog 割と珍しい(?)転職ではあったかもしれないが、機械学習や自然言語処理はアルゴリズム単
esa.ioに分報っぽく投稿するアプリをReactとFirebaseで作った - yasuhisa's blog
こういう風に投稿すると(左)、esa.ioにこういう感じ(右)で投稿される分報風のアプリを自分用に年末年始に作りました。 作った動機 使った要素技術 Firebase Authentication Firebase Hosting + React Firebase Cloud Functions デプロイ自動化 所感 作った動機 きっと皆さんそうしているように、私も日々ログを残しながら作業をしている。仕事ではscrapboxを使っているが、プライベートではesa.ioを愛用している。プレビューを見つつmarkdownで書けたり、タグとカテゴリがいい感じに使えたりするところが気に入っている。あと、アイコンがかわいい。 ちゃんと作業をするときにはesa.ioにページを作るが、そうでない雑なものも記録したいときが度々ある。例えばこういうの。 今度コンビニ行ったとき、忘れずにXXXを買う 統計の本
オンラインでのプログラミング系の演習をGoogle Colab & Google Driveで行なう - yasuhisa's blog
去年に引き続き、東京都立大学の非常勤講師の依頼をid:mamorukさん(小町先生)からして頂いたので、今年も講義を担当してきました。講義の内容としては Mackerelでのロール内異常検知を題材に、機械学習をプロダクトに取り込んでいく際、どういった視点が必要になるのか 実際の開発はどういった形式やツールで行なわれているのか、擬似的に体験してもらう といった内容(講義 & 演習)で行ないました。内容としては昨年とほぼ一緒ですが、新型コロナウイルスの影響で演習パートがオフラインの対面ではなく、オンラインで行なう点が一番違いました。演習系のサポートは学生さんの手元の環境がそれぞれ違う、などあって去年も苦戦しました。今年は同じ感じでいくとさらに大変そう(というか見切れない...)だろうなと思って、やり方を考えてみました。 他にいいやり方があったら誰か教えて & 自分用の今後*1のメモという感じの
BigQueryのテーブルのメタデータをCloud Data Catalogで管理する - yasuhisa's blog
自分が使いたいと思ったBigQuery上のリソース(tableやview)、内容を事前に完全に把握できている、ということは結構少ないのではないかと思います。そういったときに手助けをしてくれるのがメタデータです。BigQueryのリソースに対するメタデータを、Cloud Data Catalogのタグとして付与する方法を紹介します。Cloud Data Catalogを使うことで、分析者が必要なリソースに素早く辿り付いたり、正確な分析をするためのサポートができます。 BigQuery関連のAudit logを元に、以下の情報をData Catalogのタグに入れた。 - 最後にクエリを投げた{日, 人} - クエリを投げられた回数 「あまり使われていないので、信用できないデータかも」「最後にXXXさんがクエリ投げてるから、詳細詳しいかも」みたいな用途を想定してる pic.twitter.co
MackerelチームのCustomer Reliability Engineerになりました - yasuhisa's blog
2020/02からMackerelチームのCRE (Customer Reliability Engineer) になりました。もうちょっと早くエントリを書く予定でしたが、職種が変わった & 期初であれこれイベントが多いということで遅くなってしまった...。 CREになろうと思ったきっかけ 一番大きいきっかけはid:missasanと前期一緒に働けたことだろうなぁと思います。id:missasanはCREであり、現在はCREチームのマネージャーをされています。私がアプリケーションエンジニアとして働いていたとき、id:missasanを含むCREとももちろん一緒に仕事をしていたわけ*1ですが、大きくタスクフォースを一緒に組んで仕事をするといったことはあまりありませんでした。そんな中、今年の夏にid:missasanが通称赤本の読書会をチーム内で始めたので、私もほぼ毎回参加しました。 カスタマ
最近の砂場活動その12: Data Studioを使ってGoogle Analyticsと任意のデータを紐付けてデータ分析する - yasuhisa's blog
仕事でデータ分析をやる機運が高まっていて、Google Data Studioをぼちぼち使っていこうとしてる。仕事のデータは分析する前のデータパイプラインなどあれこれ考える必要があるので、ひとまず趣味プロジェクトのML-Newsを題材にして遊んでみる。こういうときに雑に遊べる砂場プロジェクトは最高。 Data Studioの大雑把な概念 Data Source Reports / Explore 複数のData Sourceを統合して分析 あとは分析しまくる 感想 参考 Data Studioの大雑把な概念 Data Source Data StudioにはData Sourceという概念がある。Data Sourceは名前の通りデータソースで分析をかける対象データを指す。例えば Google Spreadsheet Google Analitics BigQuery Cloud Span
AWS Fargate上でMackerelのプラグインを実行 & 監視する - yasuhisa's blog
特定のホストの紐付かないメトリックをMackerelのプラグイン経由で監視する場合、AWSであればEC2上に監視専用のホスト(いわゆるmonitoringホスト)を立てることが多いです。これは便利な一方で、以下のような問題点があります。 EC2ホストの面倒を見ないといけない 趣味で使う用途だとEC2のホスト台を毎月あまり払わずに済むとうれしい 特に一番最初の面倒を見るコストが一番大きいわけですが、サーバーレス/コンテナ時代なので、いいソリューションがあればそれに乗りたいわけです。先行研究がすでに存在していて、AWS Lambdaで試されている方がおられます。 自分でも似たようなことをAWS Fargate上でやっているのですが、せっかくなのでどんな感じでやっているか簡単に書いておきます。 mkrおよびプラグインが入ったdockerイメージを作る mkrやMackerelプラグインを入れるD
MACHINE LEARNING Meetup KANSAI #3で機械学習を使った趣味サービスにおける工夫を紹介しました - yasuhisa's blog
最近、仕事のちゃんとした登壇が多かったので、趣味でやっているWebサービスにおける機械学習関連の工夫について発表してきました。基本的に昔ブログで紹介したエントリのまとめバージョンです。 趣味の余暇時間で開発しているサービスなので、いかに手間をかけずに済むかというのが大事です。テーマは怠惰!! 機械学習を使った趣味サービスにおける工夫紹介 from syou6162 効率的なアノテーション方法 精度の継続的なモニタリング 多様性を持たせた簡単な推薦方法 パイプラインジャングルと戦う 効率的なアノテーション方法 機械学習、データ数が多くないとなかなか精度が出ないですが、教師データをたくさん作るのも手間がかかります。そこで能動学習を使って効率的にアノテーションしていくツールを作ったので、それの紹介をしました。 精度の継続的なモニタリング 機械学習のコードでは、テストは通ってたけど実は本番では精度
PyCon mini Osakaで異常検知システム構築の裏側について発表しました - yasuhisa's blog
現在仕事で作っている異常検知システムについてPyCon mini Osakaで登壇してきました。異常検知というマイナーなトピックですが、多くの人に聞いてもらえてよかったです。 #pyconjp #pyconosaka 「Pythonを用いた異常検知システム構築の裏側」 吉田康久さんです！ たしかはてなの人だったはず。 pic.twitter.com/hRacSgV59D— PyCon mini Osaka (@OsakaPyConMini) 2018年5月19日 はい、はてなのMackerelチームの中の人です。 機械学習の人からすると「なんだただの混合ガウス分布か」と思われるかもしれませんが、異常検知のシステムを実際に作ろうとすると考えることが色々あります。今回の発表では ユーザーのどのような要望から異常検知機能を作るに至ったか 異常検知とはそもそも何か、どういった問題設定か 異常検知手
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Mackerel Meetup #12で異常検知機能について発表しました - yasuhisa's blog
