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

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

背景 & Disclaimer 自分自身はこれまでBigQuery Scriptingをほぼ使っていませんでした BigQuery自体は3年くらいの利用歴 SQL単発で済ませるのが苦しそうな場合は、Pythonなどのプログラミング言語 + ワークフローエンジンの組み合わせで戦っており、自分としては特に困っていなかった 社内で他の方が使うケースをぼちぼち見ることがある 自分は困っていなくても、社内のBigQueryユーザーでBigQuery Scriptingを使っていて困っている人がそれなりにいる 著者はそれなりのBigQueryユーザーがいる企業のデータ基盤の人間です さすがに「使ったことないので、分からないですねー」で済ませるわけにはいかなくなってきた そもそもどんなユースケースで便利なのかすらも分かっていない状態なので、便利そうに思える場合をまとめてみることにしました というわけで、

というのをチームで議論する機会があったので、書いてみます。「うちではこうしている」とか「ここはこっちのほうがいいんじゃない?」とかあったらコメントで教えてください。 背景 / 前提 データウェアハウスのテーブルを社内に広く提供したい 初期の提供時期が過ぎてしばらくすると、要望を元にスキーマの変更や集計ロジックの変更が入る (事前にレビューはもちろんするが)SQLのミスなどで以前のバージョンに戻したいといったことがありえる 他の部門では新しいバージョンをすでに使っていて、気軽に戻せないこともある データウェアハウスのバージョンを場面に応じて複数提供できると都合がよい 一方で、大多数のデータウェアハウスのユーザーは最新バージョンの利用だけでよいはず SSOT(Single Source of Truth)になっていて欲しいわけなので... 複数バージョン見えていると「どのバージョンを使えばいい

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

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

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

FAQサイト、サポート問い合わせをせずとも自分で疑問を解決できて便利ですよね。でも、検索した単語が一件もヒットしないと、ちょっとガッカリしてしまします。そういったガッカリを減らすために、簡単なデータ分析を使ってFAQサイトを継続的に改善する話を書いてみます。 ...というのも、自分が仕事で関わっているMackerelでは最近FAQをリニューアルしたからなのでした。 MackerelのFAQではZendesk Guideを利用していますが、Zendesk Guideは便利なAPIが用意されているので、それと既存のデータ基盤を組み合わせて改善していく形です。 FAQサイト内の検索語を列挙する まず、FAQサイト内でどういった単語が検索されているのかを列挙します。Google Tag Manager経由でFirebase Analyticsにデータを飛ばすと閲覧状況が分かりますが、そのログをBi

株式会社ハカルスの染田さん(Machine Learning Meetup KANSAI繋がり)からご紹介頂きまして、タイトルの内容で登壇してきました。 今日から始める機械学習〜はてなの事例〜 from syou6162 A-3セッション『今日から始める機械学習～はてなの事例～』吉田 康久さん（はてな）です！ #devsumi #devsumiA pic.twitter.com/Dhej1tIkhV— Developers Summit (@devsumi) 2018年9月28日 登壇に当たって考えたこと 「機械学習を始めたいけど、まだちょっとハードルが高くて踏み出せていない」という方が「機械学習やってみよう!」と思える内容の依頼(大分意訳してるけど)をもらっていました。このテーマ、結構話し方が難しいなと思っていました。というのも、最近の登壇では「機械学習のサービス運用や組織運用、結構大変

最近、社内勉強会で機械学習についてエンジニアに説明する機会があり、その際にKaggleについても説明しました。一方で うーん、「Kaggler はパラメータチューニングやアンサンブル等の自明でインクリメンタルな改善『しか』できない」というような誤解はどうやって解いていけばいいんだろう。— im132nd (@im132nd) 2018年4月4日 という話もあり、(特にデータサイエンティスト以外の職種の人が)Kaggleをやる意義/メリットについてまとめてみました。ガッと勢いで書いたので、項目に結構被りがあります。なお、書いている本人はKaggleほぼ初心者であまり説得力がないです。Kaggle Masterの人がもっといいエントリを書いてくれるのを期待しています、議論の叩き台エントリです!! Kaggleをやる意義/メリット 様々なデータセットを触ることができる kernelでデータ分析の

機械学習の中でもマイナーなテーマであろう異常検知がテーマの勉強会、異常検知ナイトというイベントでLTの登壇をしてきました。マイナーテーマなのに300人以上が集まる東京怖い。 3ページしかないですが、発表資料も置いておきます(LTのレギュレーションで3ページ5分)。 異常検知ナイト LT登壇資料 はてな id:syou6162 from syou6162 LTのテーマは、現在自分がどんなデータで異常検知をやっているか、どういう困り事があるかを発表してプロの方からアドバイスをもらおうというものです。Mackerelで今まさに異常検知機能の開発をしていて、時系列周りのモデルのハイパーパラメータを開発データでチューニンングしたいけれども、そもそも異常データを含む開発データって手に入らないことが多くてどう対応していくのがよいのか?という質問をさせてもらいました。プロからのアドバイスは動画で見れるので