派生先テーブルの参照回数も考慮して安全にテーブルを撤退する - yasuhisa's blog
3行まとめ テーブルの撤退時にはテーブルの参照回数を見ることが多いと思いますが、テーブル単独の参照回数を見るだけだと不十分なことが多いです 派生先のテーブルの参照回数まで考慮すると、テーブルが撤退できるか安全に判断することができます リネージ上の親子関係をWITH RECURSIVEで考慮しながら、累積参照回数をSQLで導出できるようにし、安全にテーブル撤退を判断できるようにしました 3行まとめ 背景: テーブルの撤退にはテーブル単独の参照回数を見るだけだと不十分 アイディア: 累積参照回数を計算する 実装 テーブル間の親子関係を抽出する WITH RECURSIVEでテーブルの親子関係を辿る テーブルの親子関係を考慮しながら、累積参照回数を計算する まとめ 背景: テーブルの撤退にはテーブル単独の参照回数を見るだけだと不十分 データエンジニアやアナリティクスエンジニアの仕事をしていると、
dbtのモデルとTableau上で使われているWorkbookの依存関係をexposureで表現して、データ管理を効率的に行なおう - yasuhisa's blog
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
Prometheus Metricsを使ってArgo WorkflowsのWorkflowの成否をDatadogで監視する - yasuhisa's blog
背景 具体的な設定 コントローラーに設定を生やす workflowを監視するためのカスタムメトリクスを定義する 各workflowに同様のカスタムメトリクスを定義する デバッグ方法 所感 背景 前職に引き続き、現職でもArgo Workflowsを使ってデータエンジニアリング系のバッチ処理を行なっている 以前にCloud Workflowsを調査したことがあったが、まだちょっと厳しい感があった 前職ではCloud Monitoringで監視していたが、現職ではDatadogで監視しているので、全社の体制に合わせてDatadogで監視していきたい Argo WorkflowsはPrometheus Metricsに対応しており、Datadogはagent経由でPrometheus Metricsの収集を容易に行なえることが分かった 同僚のSREであるtapihさんから教えていただいてました、
データ活用の関係者に課題感のヒアリングをする時の型を紹介する - yasuhisa's blog
背景: データマネジメントのアセスメントのために各部署に現場の課題感をヒアリングしたい 課題: よいヒアリングをするのは簡単ではない 解決案: ヒアリングの型を決める ヒアリングの質問とリサーチの質問を別々に持っておく ヒアリング対象者について事前に理解を深める 全員に同じ項目を聞かない & 全体のカバレッジも担保する その場で問題解決を始めない まとめ 参考 背景: データマネジメントのアセスメントのために各部署に現場の課題感をヒアリングしたい データガバナンスを強化したいときにアセスメント(データマネジメント成熟度アセスメント)をやる人は多いと思う。データ基盤やデータに強い人だけでアセスメントをやって「えいや!!」と優先度を決めるのも一つの手ではある。 しかし、データを通じてユーザーに価値を届けるということまで考えると、データ活用に関わる幅広い職種の現場へヒアリングに行くことが、データ
BigQuery Scriptingの便利な使い方をまとめてみた - yasuhisa's blog
背景 & Disclaimer 自分自身はこれまでBigQuery Scriptingをほぼ使っていませんでした BigQuery自体は3年くらいの利用歴 SQL単発で済ませるのが苦しそうな場合は、Pythonなどのプログラミング言語 + ワークフローエンジンの組み合わせで戦っており、自分としては特に困っていなかった 社内で他の方が使うケースをぼちぼち見ることがある 自分は困っていなくても、社内のBigQueryユーザーでBigQuery Scriptingを使っていて困っている人がそれなりにいる 著者はそれなりのBigQueryユーザーがいる企業のデータ基盤の人間です さすがに「使ったことないので、分からないですねー」で済ませるわけにはいかなくなってきた そもそもどんなユースケースで便利なのかすらも分かっていない状態なので、便利そうに思える場合をまとめてみることにしました というわけで、
Cloud Monitoringのメトリックを簡単にBigQueryにloadできるcloud_monitoring_metrics_fetchを作りました - yasuhisa's blog
3行まとめ Cloud Monitoringのメトリックは便利だけど、使い慣れたSQLで詳細な分析がしたい メトリックをBigQueryに簡単にloadできるツールを作りました ラベルを絞った詳細分析などもできるので、是非使ってね 背景 Cloud Monitoringのメトリックは便利 しかし、詳細に分析しようと思うと、不足する部分がある 例: 時間帯毎の傾向や日時毎の傾向 月初の午前中だけ遅いのでは?とか調べたいけど、Cloud MonitoringのUIだけでは限界がある MQLを頑張って覚えたくない BigQueryに同じデータがあれば簡単にSQLを書いて分析できるのに! 公式からもやり方の案内はある Cloud Monitoring metric export | Cloud Architecture Center | Google Cloud が、ちょっとした分析でこの
最近の砂場活動その25: 複数のnamespaceにまたがるデータ管理ツールをIAPで守る - yasuhisa's blog
背景 複数のnamespaceにまたがるツールを1つにまとめる 問題点: 素朴にはIngress内でnamespaceを分けることができない 解決策: Nginxでwrapする Ingressを設定するためのその他の設定 静的IPの確保と設定 ドメインの確保 & CDNの設定 & 証明書の設定 IAPの設定 所感 背景 最近、Argo Workflowsやdbtなどデータ管理用のアプリケーションをGKE上で動かしています。これらのツールは管理用のWebの画面が存在していて便利ですが、何も考えずにやると全世界に公開されてしまって危険です*1。手元からportforwardすれば自分だけが見る環境を作れますが、毎回portforwardするのも面倒です。portforwardせずに自分だけ管理用の画面を見れるようにIAP(Identity-Aware Proxy)を入れてみたので、それについて
どのrevisionでterraform applyされたものか分かるようにtfstateに情報を埋め込む - yasuhisa's blog
背景 Terraformでリソースをコード管理をしている場合、大抵gitでバージョン管理している terraform applyしたものがまずかった場合、どの差分によるものか、いつから発生していたものなのか、誰の実行によるものかといった情報が欲しくなる backendをgcsなどにしている場合、オブジェクトのバージョニングを有効にしていれば、いつオペレーションが実行されたかなどを追える 事故ってたケースの調査などで特に欲しい revisionの情報や実行者の情報は素のTerraformでは分からないので、何かしらの形で情報を埋め込みたい やってみたこと: makeで情報を外から与える varで外から情報を与えてみる形を考えてみました。こんな感じで変数とoutputを定義しておきます。 variable "current_revision" { description = "terrafor
dbtを触ってみた感想 - yasuhisa's blog
データエンジニア系の勉強会で最近dbtがぱらぱらと話題に出てくるようになった & 4連休ということで、夏休みの自由研究がてらdbtを触ってみました。書いてる人のバックグラウンドは以下の通り。 DWHやデータマートの構築のためのETLツールを模索中(特にTの部分) プライベートではDataformを使っている 前職でも仕事の一部で使っていた 開発効率を計測するデータ基盤の管理にDataformを使ってみた - yasuhisa's blog 定期バッチ処理はArgo Workflows on GKEでやっている 触ってみないと肌感とか自分で運用できるかのイメージが湧かないのでね。 Dataformとの比較 細かいノウハウ 手元や本番環境での動作 Argo Workflowとの連携 環境によってDWHの提供するバージョンを差し替える DWHやデータマートの外の情報をデータリネージに加える 既存
データウェアハウスのバージョン管理をどうやるか - yasuhisa's blog
というのをチームで議論する機会があったので、書いてみます。「うちではこうしている」とか「ここはこっちのほうがいいんじゃない?」とかあったらコメントで教えてください。 背景 / 前提 データウェアハウスのテーブルを社内に広く提供したい 初期の提供時期が過ぎてしばらくすると、要望を元にスキーマの変更や集計ロジックの変更が入る (事前にレビューはもちろんするが)SQLのミスなどで以前のバージョンに戻したいといったことがありえる 他の部門では新しいバージョンをすでに使っていて、気軽に戻せないこともある データウェアハウスのバージョンを場面に応じて複数提供できると都合がよい 一方で、大多数のデータウェアハウスのユーザーは最新バージョンの利用だけでよいはず SSOT(Single Source of Truth)になっていて欲しいわけなので... 複数バージョン見えていると「どのバージョンを使えばいい
esa.ioに分報っぽく投稿するアプリをReactとFirebaseで作った - yasuhisa's blog
こういう風に投稿すると(左)、esa.ioにこういう感じ(右)で投稿される分報風のアプリを自分用に年末年始に作りました。 作った動機 使った要素技術 Firebase Authentication Firebase Hosting + React Firebase Cloud Functions デプロイ自動化 所感 作った動機 きっと皆さんそうしているように、私も日々ログを残しながら作業をしている。仕事ではscrapboxを使っているが、プライベートではesa.ioを愛用している。プレビューを見つつmarkdownで書けたり、タグとカテゴリがいい感じに使えたりするところが気に入っている。あと、アイコンがかわいい。 ちゃんと作業をするときにはesa.ioにページを作るが、そうでない雑なものも記録したいときが度々ある。例えばこういうの。 今度コンビニ行ったとき、忘れずにXXXを買う 統計の本
すうがくぶんか 統計検定1級対策講座 第五回 - yasuhisa's blog
前回はこちら。 今回は最尤推定量や推定量の一致性、十分統計量の話がメイン。 推定量のよさ: 一致性 一致性を示す上で便利な不等式グッズ 一致性を満たす推定量の例: 最尤推定量 最尤推定量のよさ: 不変性 十分統計量 フィッシャー情報量の復習 フィッシャー情報量に関する不等式と十分統計量の定義 フィッシャー情報量を経由しない十分統計量の定義 次回予告: 十分統計量の欠点と完備十分統計量。Lehmann-Scheffeの定理を使ったUMVUEの示し方 推定量のよさ: 一致性 前回の内容にある不偏性も推定量のよさの一つだけど、今回の一致性も推定量のよさをはかる性質の一つ。パラメータに対して、n個の標本から作られる推定量が任意のに対して、以下が成立するとき、推定量が一致性を持つと呼ぶ。 不偏性は標本サイズnに依存せず、exactに真のパラメータに一致することを言っていた。一致性は標本サイズを飛ばし
すうがくぶんか 統計検定1級対策講座 第四回 - yasuhisa's blog
前回はこちら。 今回は不偏推定量について詳しく見ていきました。いつも以上に盛り上がった! 平均二乗誤差とそのバイアス・バリアンス分解 推定量の「よさ」について 真のパラメータについて何も分からない場合 パラメータについて多少知識がある場合 所感 クラメルラオの下限 フィッシャー情報量 最良線形不偏推定量 次回 平均二乗誤差とそのバイアス・バリアンス分解 PRMLなど機械学習の観点でも頻出の話題。 推定量のよさの指標には色々あるが、真のパラメータと推定量の二乗の期待値である平均二乗誤差が小さければ小さいほどよいと定義する。すると、平均二乗誤差はバイアス(の二乗)とバリアンスに分解できる。平均二乗誤差が一定だとすると、バイアスorバリアンスのどちらかをよくしようとすると、どっちかが悪くなってしまうトレードオフの関係にあることは、推定量のよさを考える上では頭に入れておかないといけない。 そして、
オンラインでのプログラミング系の演習を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が通称赤本の読書会をチーム内で始めたので、私もほぼ毎回参加しました。 カスタマ
AWS Fargate上でMackerelのプラグインを実行 & 監視する - yasuhisa's blog
特定のホストの紐付かないメトリックをMackerelのプラグイン経由で監視する場合、AWSであればEC2上に監視専用のホスト(いわゆるmonitoringホスト)を立てることが多いです。これは便利な一方で、以下のような問題点があります。 EC2ホストの面倒を見ないといけない 趣味で使う用途だとEC2のホスト台を毎月あまり払わずに済むとうれしい 特に一番最初の面倒を見るコストが一番大きいわけですが、サーバーレス/コンテナ時代なので、いいソリューションがあればそれに乗りたいわけです。先行研究がすでに存在していて、AWS Lambdaで試されている方がおられます。 自分でも似たようなことをAWS Fargate上でやっているのですが、せっかくなのでどんな感じでやっているか簡単に書いておきます。 mkrおよびプラグインが入ったdockerイメージを作る mkrやMackerelプラグインを入れるD
2018年の砂場活動振り返り - yasuhisa's blog
インフラやミドルウェアにとにかく苦手意識があるが、仕事的にいつまでもそう言ってられない。そこで、最悪全部ぶっ壊れても大丈夫な砂場を作り、そこを土台に活動をするというのを2018年の目標に設定していた。 結構な時間をかけたこともあり、それなりの砂場と活動ができて、自分としても勉強になってよかった点が多かったので振り返りを書きます。一個一個ちゃんとエントリ書いていたので、振り返りが楽で助かった。 完成系はML Newsだけど、2018年1月時点では そもそもWebアプリですらなくCLIアプリだった データの管理もデータベースではなくテキストファイル という素朴な作りだった。 インフラ編 最初はCLIアプリをWebアプリにする活動をやったが、その後はAWS上にインフラ部分の構築を進めた。 次に一台のEC2をAWSコンソールから立てて、sshでログインしてyumコマンドを打って...という10年前
最近の砂場活動その7: Nginxで特定のパスはVPC内からしか接続できないようにする - yasuhisa's blog
しょうもないことですが、Nginx初心者なので自分用メモです。用語とか色々間違ってるかもしれない...。 Client => ALB => Nginx => Appのような構成を考える。ヘルスチェックやサーバーの特定の負荷状況を返すエンドポイント(こういうやつ)が存在し、これはAppから返す。これらは普通のユーザーには見せたくなくて、ALBやVPC内部からのみ参照されたい、というユースケース。ALBで細かいことは難しそうなので、Nginxで制御したい。 VPC範囲内のipからのアクセスであれば拒否すればいいじゃんと思ったけど、Nginxに渡ってくるipは何もしないとALBのipが渡ってきてしまう。このままでは素通ししてしまうので、Clientのipを渡して欲しい。remote_addrというのを変更してあげるようにすればよいらしい。それを実現するNginxの設定は例えばこんな感じ。 ser
最近の砂場活動その6: パフォーマンスを改善する - yasuhisa's blog
最近は登壇とかでエネルギーを取られて、砂場活動シリーズ(?)全然できていませんでした。せっかく前期に砂場を作ったので、勉強の場にしていきます。現状のボトルネックがどこにあって、どこを改善していきましょう、というループを回します。ISUCONとかやってる人には当たり前のことばかりだと思うけど、その辺あまり慣れていないのでぼちぼちとやっていきます。派手なことななく地味にやっていく。 現状を知る 改善をするためには現状のパフォーマンスを知ることが重要です。趣味サイトはユーザーが自分しかいないので、ベンチマークスクリプトをかけてパフォーマンスを見ていきます。スプレッドシートにまとめていくのは面倒だったので、Mackerelのプラグインを書いて可視化しました。 改善していく中でRDS/ElastiCacheのCPU/メモリ/コネクション数/トラフィック量などが一目で分かるようなダッシュボードも作りま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
