サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
どうなる？Twitter
www.yasuhisay.info
背景: データマネジメントのアセスメントのために各部署に現場の課題感をヒアリングしたい 課題: よいヒアリングをするのは簡単ではない 解決案: ヒアリングの型を決める ヒアリングの質問とリサーチの質問を別々に持っておく ヒアリング対象者について事前に理解を深める 全員に同じ項目を聞かない & 全体のカバレッジも担保する その場で問題解決を始めない まとめ 参考 背景: データマネジメントのアセスメントのために各部署に現場の課題感をヒアリングしたい データガバナンスを強化したいときにアセスメント(データマネジメント成熟度アセスメント)をやる人は多いと思う。データ基盤やデータに強い人だけでアセスメントをやって「えいや!!」と優先度を決めるのも一つの手ではある。 しかし、データを通じてユーザーに価値を届けるということまで考えると、データ活用に関わる幅広い職種の現場へヒアリングに行くことが、データ
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ネイティブなワークフローエンジンというこ
小ネタです。色々教えてもらったりしたので、記憶が蒸発しないようにメモしておきます。教えてもらった同僚に感謝。 BigQueryのUI上の配列を展開する Data Studioでデータソースのプロジェクトと課金プロジェクトを別のものを使う データ基盤の相談に乗る前にどういう利用の仕方をしている人なのか監査ログからざっくり把握する 社内のBigQueryのリソースの枯渇状況をData Studioで可視化する BigQueryのUI上の配列を展開する BigQueryのWeb UIが最近変更され、プレビューやクエリ結果に配列が含まれている場合は閉じた状態で表示されるようになりました。閉じた状態で表示されることで、より多くの行や列を画面内に表示することができるようになっています。 まとめて一気に配列を開閉したい 一方で、配列の要素が展開された状態で見たい場合もあります。以下のエントリでは、各パー
背景 & Disclaimer 自分自身はこれまでBigQuery Scriptingをほぼ使っていませんでした BigQuery自体は3年くらいの利用歴 SQL単発で済ませるのが苦しそうな場合は、Pythonなどのプログラミング言語 + ワークフローエンジンの組み合わせで戦っており、自分としては特に困っていなかった 社内で他の方が使うケースをぼちぼち見ることがある 自分は困っていなくても、社内のBigQueryユーザーでBigQuery Scriptingを使っていて困っている人がそれなりにいる 著者はそれなりのBigQueryユーザーがいる企業のデータ基盤の人間です さすがに「使ったことないので、分からないですねー」で済ませるわけにはいかなくなってきた そもそもどんなユースケースで便利なのかすらも分かっていない状態なので、便利そうに思える場合をまとめてみることにしました というわけで、
背景 どうやって異常を検知するか BigQuery MLでの異常検知 検知できるモデルの種類 共通設定 データの前準備 モデルの学習 モデルを元にスロット使用量が異常に増加していないか予測する 所感 背景 BigQueryはオンデマンドとフラットレート(定額料金)がある オンデマンドはスキャン量がお金に直結するため、INFORMATION_SCHEMA.JOBS_BY_*などを使ってクエリ警察をしている方も多いはず INFORMATION_SCHEMAに代表されるデータ管理に役に立つ現場のノウハウを最近会社のTech Blogに書いたので、そちらも見てね 一方で、フラットレートに関しては定額使いたい放題のプランであるため、オンデマンドよりはクエリ警察をしていない場合もある 見れるなら見たいが、どうしても支出に直結するオンデマンドを優先して見てしまいがち。工数も限られている が、あまりに自由
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の輪読会を８月くらいからゆるっと始めようと思ってます。 興味あ
最近、「なぜid:syou6162はアウトプットを続けているのか」を聞かれる機会があった。 会社のnoteのインタビューを受けた*1中で、もう15年もブログを書いていることについて聞かれたり*2 会社のLT大会をやっているんだけど、なぜアウトプットを推進しようとしているのか聞かれたり 自分のスタンスを説明しているエントリがあると便利だなと思ったので、ポエムを書いてみます。 インプットのためにアウトプット: 情報は出す人のところに集まる 自分が考えていることをぱっと他人に伝えるのに便利 未来の自分へのお手紙 議論: アウトプットはしたほうがよいか? 個人 組織 インプットのためにアウトプット: 情報は出す人のところに集まる これが一番大きい。雑な試行錯誤とか自分用のまとめとか「こういうところ困ってるんだけど、誰か知見持ってる人助けて!!」とかを書くことが多いんだけど、そういった情報を出してお
dbtの紹介 タイトルの通り、モノタロウの(非公式)勉強会でdbtのことについて話してきました。すでに使っている人には新しい情報はほぼないですが、他部門の方に「データ触ってるとこういうところ辛いよね〜」「dbt使うといい感じに解決できるケースもありますよ」という雰囲気の内容で話してます。 合わせて読みたい。 入社してから初の勉強会主催 モノタロウに入社してからまだ半年も経っていないですが、初めて勉強会を主催しました。社内だけど参加者の2/3くらいの方は「zoomでもお話するの初めてでは??」という状態だったのですが、後先何も考えない性格(アホ)だからやれてるんだろうなと思います。ラッキーなことに発表してくれるという方がすぐに集まって OSSへのcontributeの仕方 フロントエンドの開発を爆速にする方法 よい週報の書き方 データメッシュ Cloud Buildとの試行錯誤 など(タイト
背景 Terraformでリソースをコード管理をしている場合、大抵gitでバージョン管理している terraform applyしたものがまずかった場合、どの差分によるものか、いつから発生していたものなのか、誰の実行によるものかといった情報が欲しくなる backendをgcsなどにしている場合、オブジェクトのバージョニングを有効にしていれば、いつオペレーションが実行されたかなどを追える 事故ってたケースの調査などで特に欲しい revisionの情報や実行者の情報は素のTerraformでは分からないので、何かしらの形で情報を埋め込みたい やってみたこと: makeで情報を外から与える varで外から情報を与えてみる形を考えてみました。こんな感じで変数とoutputを定義しておきます。 variable "current_revision" { description = "terrafor
データエンジニア系の勉強会で最近dbtがぱらぱらと話題に出てくるようになった & 4連休ということで、夏休みの自由研究がてらdbtを触ってみました。書いてる人のバックグラウンドは以下の通り。 DWHやデータマートの構築のためのETLツールを模索中(特にTの部分) プライベートではDataformを使っている 前職でも仕事の一部で使っていた 開発効率を計測するデータ基盤の管理にDataformを使ってみた - yasuhisa's blog 定期バッチ処理はArgo Workflows on GKEでやっている 触ってみないと肌感とか自分で運用できるかのイメージが湧かないのでね。 Dataformとの比較 細かいノウハウ 手元や本番環境での動作 Argo Workflowとの連携 環境によってDWHの提供するバージョンを差し替える DWHやデータマートの外の情報をデータリネージに加える 既存
というのをチームで議論する機会があったので、書いてみます。「うちではこうしている」とか「ここはこっちのほうがいいんじゃない?」とかあったらコメントで教えてください。 背景 / 前提 データウェアハウスのテーブルを社内に広く提供したい 初期の提供時期が過ぎてしばらくすると、要望を元にスキーマの変更や集計ロジックの変更が入る (事前にレビューはもちろんするが)SQLのミスなどで以前のバージョンに戻したいといったことがありえる 他の部門では新しいバージョンをすでに使っていて、気軽に戻せないこともある データウェアハウスのバージョンを場面に応じて複数提供できると都合がよい 一方で、大多数のデータウェアハウスのユーザーは最新バージョンの利用だけでよいはず SSOT(Single Source of Truth)になっていて欲しいわけなので... 複数バージョン見えていると「どのバージョンを使えばいい
背景: Terraformを使いつつ、データマネジメントの観点から統制を取りたい Terraform Moduleを定義する 例: データセット まとめ 背景: Terraformを使いつつ、データマネジメントの観点から統制を取りたい GCPでデータ基盤を管理する場合、Terraformはよい選択肢の一つです。データセットやそれに関連するIAMの管理、データセット内のビューの定義をIaCとして管理できます。 google_bigquery_dataset | Resources | hashicorp/google | Terraform Registry google_bigquery_table | Resources | hashicorp/google | Terraform Registry データマネジメント、特にメタデータ管理の観点でもTerraformは有用です。例えばこう
3~4年前はモブプロにめちゃくちゃ苦手意識があったんだけど、最近はなぜか(?)モブプロを推進していく旗振りをしている。モブプロの取り組み自体については今度会社のTech Blogに書く予定だけど、このエントリでは自分の心境の変化にフォーカスを当てる。人間、数年すると割と変わるもんだなぁと思って面白かったので、記録に残しておく。 モブプロが苦手だった頃 なぜモブプロしようとなったか 今はどうモブプロしているか 所感 モブプロが苦手だった頃 前職の開発チームにいた頃(3年前くらい)で、状況はこんな感じ。 7~8人くらいの規模の開発チーム 京都と東京でそれぞれメンバーは分かれているが、まだ物理出社している時期だったので、大きなディスプレイに写された自分の画面をみんなが見るスタイル 時間は60~90分くらいだったかな タイピストはガンガン交代するスタイルではなく、1回を1~2人のタイピストで回して
差分転送するモチベーション 機械学習を使った情報推薦を行なうために、RDSのテーブルをBigQueryに定期転送しています。細かいことは気にしたくなかったので、一日一回の洗い替え(全データ送信で全部上書き)していましたが、もう少し鮮度を上げたくなりました(新しい情報に対して推薦ができないため)。何も考えずに定期転送の頻度を上げると 1: 転送のためのCPUコスト 2: AWSからGCPへのデータ転送量 が気になってきます。個人の趣味プロジェクトでは、特に2が大きい。先月のAWSの利用料金を見て、涙を流していました...。というわけで、情報の鮮度は上げつつもう少し効率的に定期転送するべく、Embulkでの差分転送をすることにしました。 やり方 差分だけBigQueryに転送する 基本的にはメルカリメソッドそのままです。いつもお世話になっております。 updated_atのような最終更新日時が
以前ブログにも書いたNPSの信頼区間を題材に、統計学勉強会で発表しました(します)。資料はこちら。 自分の目的に合った統計量と そのバラ付きを計算しよう ~NPSを例に~(統計学勉強会) from syou6162 3/19に最終出社したばかりなので発表の時期としては微妙なところですが、3/31までははてなの所属ということで発表することにしました(広報担当の方にも確認済みです)。はてなではアウトプットの重要性を何度も教わったので、最後の最後まで攻めるのです。 内容としては統計学の基礎的な知識をベースに、業務に必要な統計量(今回の場合はNPS)とそのバラツキ(今回の場合は95%信頼区間)を自分で求めてみよう、というものです。教科書的な問題設定だとカハーできないものは案外あるし、自分でこういうものを計算してみるのは結構楽しいよ!というのが伝わるとうれしいです。Enjoy statistics!
Twitterでは先に言っていましたが、現職のはてなを3月末で退職します。3/19が最終出社日でした。はてなでの思い出はこちらに書きました。 そのため、転職活動をしたわけですが、コロナ禍での転職活動は平常時と異なる部分も結構ありました。また、データエンジニアとしての転職は初めての経験でした。誰かの参考になるかもしれないので、私が考えたことや感じたことをメモ書きとして残しておきます。 在宅勤務と就業可能な地域 Web上でのアウトプット データエンジニアという職種の多様性 転職にあたって重視したこと 魅力に感じた点 当然、不安もある 在宅勤務と就業可能な地域 カジュアル面談させてもらった企業さんは、ほぼ在宅勤務に移行済みだった 隔週や月一で物理出社という会社も半々くらい? 緊急自体宣言が出ていない時期(夏〜秋)にカジュアル面談させてもらったので、今は状況が違うかも カジュアル面談、採用面談もz
2021/02/23に受験しまして、合格しました。やったー。 前提: 受験前の私の状態 なぜ受験したか 試験のための準備 データエンジニアリングで頻出の話題をカバーする 個別コンポーネントの知識を取り込んでいく 権限 / セキュリティ / 監査回り 練習問題をひたすら解く 試験当日 これから 参考 前提: 受験前の私の状態 受験前もこの一年ほどデータエンジニアリング的な仕事はしていました。ただ、メインで使っているのもBigQueryくらいで、データに対する要求(データ量やリアルタイム性、可用性など)はそこまで厳しいものではなかったと思います。別に「仕事をサボって質を下げていた...」というわけではなく、過剰品質でデータを提供するより、他にもやるべきこと(データ分析など)はたくさんあったためです。 また、機械学習はある程度専門でやっていたため、一般的な知識(再現率とか正則化とか過学習とか)は
登壇は明日ですが、スライドと発表に至った経緯や発表内容決めるまでに考えたことをまとめておきます。 オープンセミナー岡山 これから始めるデータ活用 from syou6162 発表タイトルに至った経緯 直接の経緯はオープンセミナー岡山の実行委員長であるid:a-knowさんに登壇してもらえないかと打診を受けたからです。同僚のid:a-knowさんからの打診であり、二つ返事でokしました。しかし、発表時間40分もあるし、聴講者もデータ関連の人に限らない、ということで内容をどうするかは結構迷いました(最近は結構専門性の高めのイベントでの登壇が多かったので)。 データ活用、目につく機会も増えて当たり前になりつつあるような気もしますが、本当にそうかというとまだまだだよなぁーと感じています。登壇で目につく発表は、組織も数百人規模、データ活用の専門のチームがいるケースが多く、データアーキテクチャも今風で
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を買う 統計の本
前回はこちら。 今回は完備十分統計量を使ったUMVUEの構成法や検出力について。長かった(?)推定論の話も、今回で一段落ですね。 十分統計量の定義の復習 十分統計量の別の定義とFisher-Neymanの因子分解定理 十分統計量を用いた不偏推定量のRao-Blackwellization化 Rao-Blackwellization化で分散が改善する例 不偏性の証明 分散が改善することの証明 Lehmann-Scheffeの定理 完備十分統計量 Rao-Blackwellization化を使って、Lehmann-Scheffeの定理を示す 検定論: 検出力 参考 十分統計量の定義の復習 十分統計量は定義がいくつかあるが、前回の講義では直感が効くようにフィッシャー情報量を経由した定義がなされた。 元々のデータと同じく、何らかの統計量Tについてもフィッシャー情報量を定義できる 「元々のデータが一
先週はデータ基盤やデータ整備のイベントで2件登壇してきました。どちらもオンライン登壇でした。 Data Engineering Study #4「データ分析基盤の障害対応事例LT祭り」 CROSS Party online 2020 データ整備人が語る！DXにも不可欠なデータ整備の姿 今後の予定 Data Engineering Study #4「データ分析基盤の障害対応事例LT祭り」 @yuzutas0さんにお声がけいただきまして、登壇することになりました。聴講者数多いし、他の登壇者の方もプロな方ばかりだったので、登壇前は胃が痛かった...。 私が担当しているデータ基盤、現時点ではめちゃくちゃ巨大なデータをパイプラインで扱っているわけでもなく、リアルタイム性がめちゃくちゃ重視されたりというわけでもなく、割と素朴なデータ基盤です。派手さはなくてひたすら地味ですが、世の中的にはむしろこちらの
前回はこちら。 今回は不偏推定量について詳しく見ていきました。いつも以上に盛り上がった! 平均二乗誤差とそのバイアス・バリアンス分解 推定量の「よさ」について 真のパラメータについて何も分からない場合 パラメータについて多少知識がある場合 所感 クラメルラオの下限 フィッシャー情報量 最良線形不偏推定量 次回 平均二乗誤差とそのバイアス・バリアンス分解 PRMLなど機械学習の観点でも頻出の話題。 推定量のよさの指標には色々あるが、真のパラメータと推定量の二乗の期待値である平均二乗誤差が小さければ小さいほどよいと定義する。すると、平均二乗誤差はバイアス(の二乗)とバリアンスに分解できる。平均二乗誤差が一定だとすると、バイアスorバリアンスのどちらかをよくしようとすると、どっちかが悪くなってしまうトレードオフの関係にあることは、推定量のよさを考える上では頭に入れておかないといけない。 そして、
自分の勉強用メモです。統計の区間推定や検定でほぼ必ずお世話になる分布やt分布だけど、正規分布と比べると確率密度関数が覚えきれないくらい複雑。天下り的に分布やt分布を定義されても結構しんどい。現実的なモチベーションから必要な道具を作っていった結果、分布やt分布が手に入る、というストーリーが自分としてはしっくりくるので、区間推定を例に整理する。 区間推定: 正規母集団かつ分散既知を仮定 区間推定: 正規母集団かつ分散が未知 前提 t分布の導出 t分布の定義 区間推定: 非正規母集団かつ分散が未知 区間推定: 正規母集団かつ分散既知を仮定 スタートはいつもここから。簡単な前提(正規母集団の仮定 & 分散既知)を置ける場合を考えてから、現実に近づけるために仮定を少しずつ取り外していく。ヨビノリ分かりやすい。 標本平均はであるが、正規母集団を仮定しているのではそれぞれ平均分散の正規分布に従う確率変数
去年に引き続き、東京都立大学の非常勤講師の依頼をid:mamorukさん(小町先生)からして頂いたので、今年も講義を担当してきました。講義の内容としては Mackerelでのロール内異常検知を題材に、機械学習をプロダクトに取り込んでいく際、どういった視点が必要になるのか 実際の開発はどういった形式やツールで行なわれているのか、擬似的に体験してもらう といった内容(講義 & 演習)で行ないました。内容としては昨年とほぼ一緒ですが、新型コロナウイルスの影響で演習パートがオフラインの対面ではなく、オンラインで行なう点が一番違いました。演習系のサポートは学生さんの手元の環境がそれぞれ違う、などあって去年も苦戦しました。今年は同じ感じでいくとさらに大変そう(というか見切れない...)だろうなと思って、やり方を考えてみました。 他にいいやり方があったら誰か教えて & 自分用の今後*1のメモという感じの
ここ最近、チーム内でSQLのレクチャー会をやっています。世間的にはプランナーの人や営業の方がSQLを書くのもそれほど珍しいことではなくなってきていると思いますが、チーム内ではまだまだ一般的ではないです。なんとかしていきたい。 SQLレクチャー会の目的はこんな感じです。 チーム内のSQL / 分析力の底上げ データの民主化的なやつ データライフサイクルの改善 集計側であれこれ無理に頑張るより、入力データを集計側に合わせてもらうほうが圧倒的に省力化されることが多い データの入力側と集計側の意識を合わせることで、チームのデータ分析のしやすさを高めていきたい 毎月、毎期末作っているスプレッドシートの自動化 手間を減らしたり、手作業によるミスを減らしたり このエントリをきっかけに「うちでも似たことやってるけど、この取り組みをやってみたらさらにうまくいったよ」といったことが知れるとうれしいです。 背景
次のページ
このページを最初にブックマークしてみませんか？
『yasuhisa's blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
