分析の前に、データの土壌を疑う（5） 〜分析を始めてよい、と判断できた理由
分析の前に、データの土壌を疑う（5） 分析を始めてよい、と判断できた理由 この連載では、実務でデータ分析基盤を立ち上げる中で、 「分析を始める前に何が必要だったのか」を、 実際の試行錯誤を交えて書いています。 筆者は、プロダクトのログを扱いながら、 分析・データ基盤の整備を行っている実務担当者です。 第1回では、処理が動かないところからの復旧。 第2回・第3回では、数字は出るのに信じきれなかった話。 第4回では、分析とコスト、開発と運用のバランスについて整理しました。 今回はシリーズの最終回として、 「何をもって、データが分析に使えると判断できたのか」 について書いていきます。 例として取り上げるのは、 アクティブユーザーの定義を決めるまでの試行錯誤です。 1. 「とりあえず1年間のMAUとDAUを見たい」 この話は第3回で触れました。 最初は、 「ログが1件でも上がっていればアクティブ」
分析の前に、データの土壌を疑う（4）〜分析は「正しさ」だけでは回らない ── データ分析とコストの現実的な折り合い方
分析の前に、データの土壌を疑う（4） 分析は「正しさ」だけでは回らない ── データ分析とコストの現実的な折り合い方 この連載では、実務でデータ分析基盤を立ち上げる中で、 「分析を始める前に何が必要だったのか」を、 実際の試行錯誤を交えて書いています。 筆者は、プロダクトのログを扱いながら、 分析・データ基盤の整備を行っている実務担当者です。 第3回までで、ログデータは「集まっている」だけでは分析に使えず、 重複レコード 再送ログの判定ロジック 機種情報の整理 といった問題を、一つずつ確認してきました。 ここまで整理が進むと、次に避けて通れない問いが出てきます。 このデータ分析を、どのくらいのコスト感で、どう回し続けるのか？ データの正しさを追いかけるだけでは、分析は現場で回りません。 第4回では、分析とコストをどう考え、どこで割り切ったかを整理します。 1. 数十億レコードを、本当にすべ
Apache Polarisとは何か？オープンなデータカタログが求められる理由とAWSとの組み合わせ方を整理する
Apache Polarisが解決するもの Apache Icebergが普及するにつれ、Iceberg対応のカタログはHive Metastore、JDBC、Nessie、AWS Glue、Snowflakeなど複数登場しました。 それぞれが独自のクライアントライブラリやインターフェースを持っていたため、 言語ごとにカタログクライアントを実装する必要がある カタログ間でアクセス制御の仕様がバラバラ 複数カタログを横断したガバナンスが難しい 結果として、選んだカタログによってアーキテクチャ全体が縛られる といった課題がありましたが、 これを解決するために登場したのがIceberg REST Catalog仕様であり、その仕様をオープンソースで実装し、さらにマルチカタログとRBACを備えたものがApache Polarisとなります。 つまり、Apache Icebergのオープンなカタログ
【書評】小さく作って深く学ぶGo──『Learn Go with Pocket-Sized Projects』
はじめに 社内の掲示板で名前が挙がっていた『Learn Go with Pocket-Sized Projects』が気になったので読んでみたところ、思いもよらず自分にとって読みやすいスタイルで、時間はかかったものの最後までじっくり読み切ってしまいました。 この記事では、いくつかの章を抜粋して紹介しつつ、この本の学習体験の良さという観点から、全体の感想をまとめます。 どんな本？： 11種類ものプロジェクトを用いて、各章ごとに Go プロジェクトの作成方法を伴走で教えてくれる本 著者陣はエアバスグループで長らく Go を使ってきたフランスのシニアエンジニアたち 2025年5月に出版、日本語訳版はまだ 以下の公式ページから、各章の詳しい概要が読めるのでのぞいてみてください。 本書が対象にしている読者 本の中では、「読者にプログラミング経験があることを前提としており、開発者のスキルを伸ばすことを
【ログ分離】 ログデータを DB に保存してはいけません
はじめに TROCCO では ETL ジョブや、dbt 連携、ワークフローなど、様々なジョブで実行ログをリアルタイムで見ることができます。 これによりエラー時のトラブルシュートをスムーズに行うことができます。 そして、この実行ログですが、DB にあるジョブのレコードの1カラムに書き込まれていました。 このように TROCCO の実行ログの表示機能は、データベースのアンチパターンの上に成り立っています。 ログデータは TEXT 型で DB に保存されているためサイズが大きく、また TROCCO の成長に応じてジョブ数は増えるため、ログデータもサービスの成長とともに無限に成長してしまいます。 おかげさまでアカウント数は増加の一方であり、それに伴い DDL が遅くなったり、また SELECT のパフォーマンスも当然落ちるため、INDEX に気をつけたりする必要がありました。 SRE ではこれに課
RDBMS(PostgreSQL)のデータを、DWH(Snowflake)に入れる時に、再考したPrimary keyの重要性
RDBMS(PostgreSQL)のデータを、DWH(Snowflake)に入れる時に、再考したPrimary keyの重要性 PostgreSQL Advent Calendar 2022 の25日目の記事です。 RDBMS（以下、データベース）のデータをデータウェアハウスに入れたいというニーズは、データ統合を進めていくと発生すると思います。筆者は、実際にPostgreSQLのデータを、Snowflakeに取り込みを行いました。その際に、テーブルにPrimary keyがついておらず困りました。なぜPrimary keyが必要なのかについて、自分なりの見解をまとめてみました。 ※現在は、Primary keyをつける方針になり、事なきを得ました。 解決したかったこと 社内に存在しているデータベース。今回だとPostgreSQLに入ってるデータを、Snowflakeにさくっと入れたい。 な
関数の多重下請けをやめよう。単一責任の原則と関数の"責任"について
「多重下請け構造は悪い」、これは世間的にだいぶ浸透してきた考えだと思います。しかし、プログラマは 多重下請けのコードを気づかぬうちに書いてしまうことが多々あります。 なんなら皆さんもついウッカリやってしまっているでしょう。 当然ながらコードベースでも多重下請けは良くありません。今回の記事では、多重下請けコードとは何か、その問題点、回避方法を解説します。 多重下請け構造になってるコードとは? 多重下請け構造になってるコードとは、タスクをたらい回しにしているコードです。 たとえばECサイトで注文するシーンを考えてみます。サーバーの実装はこんな感じです。 def 注文API(): 注文処理(price) 集計DBにログを送る() def 注文処理(price): 決済する(price) 履歴に保存する() def 決済する(price): if キャンペーン期間中だったら: 支払う(price
【Poteto】自作Webフレームワークにホットリロードを実装した話
お正月はどうお過ごしでしたでしょうか？私は自作Webフレームワークの開発をしながらGo正月を過ごしました。 これまでの開発の記録として、前回の記事を貼っておきます。ぜひ興味があればご覧ください。 ホットリロード ホットリロードとは ホットリロードは、ファイルシステムに変更があると、アプリケーションサーバーのプロセスをkillしてもう一度立ち上げなおす仕組みです。開発中に、「ファイル変更→プロセスkill→立ち上げ」のステップを踏むことなく、スムーズに開発できる点が魅力です。 なぜホットリロード 単純に仕組みに興味があった 参考にしているgolangのフレームワークであるEchoには実装されていない(はず？)で差別化できると思った ホットリロードの仕組み 開発のプロセスとしてはまず仕組みを調べることから始めました。こちらの記事を参考にしました。 以下は、私がつたない絵で図に表したものです。
VSCodeのGitHub Copilotが色々便利になっていた件
はじめに 知らない間にGitHub Copilotが結構進化していたので、それらの内容を紹介します。 GitHub Copilot Chatは知っていたのですが、単なるChatGPTみたいな会話機能を追加しただけだと思っていました。 要約 右クリックメニューや#fileのようなコマンドが登場し、それを入力するだけでChatに見てほしいコンテキストを伝えることができるようになった。 ファイル単位だけでなく、選択した行やブロックに限定することもできる。 テストコードや新しいプロジェクトをコマンド一つで生成できるようになっている。 推薦の候補も複数を同時に比較できるようになった。 一度に最大10個くらい出る上、タブで保管できる。 ターミナルや編集中のファイルからコマンド一つでChatを立ち上げることができる。 特別なプロンプトを入力しなくても、開いた場所の文脈を読み取ってくれる。 右クリックメニ
「ソフトウェアアーキテクチャの基礎」と「アーキテクトの教科書」の備忘と感想
はじめに 最近、ソフトウェアアーキテクチャを改めて勉強しようと2冊の本「ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ」と「アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築」を読んだので要点と感想を備忘としてまとめます。 ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築 概要とポイント ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ アーキテクチャには正解も間違いもない。ただトレードオフがあるだけだ。 この本はアーキテクチャを考えるための思考から、代表的なアーキテクチャスタイルの紹介やアーキテクトとしてのソフトスキル（対人スキルやチーム運営、キャリアパス等）まで網羅的にまとめられているものとなります。 アーキテクチャの技術
AWS Lambdaのインメモリキャッシュについて
はじめに AWS Lambdaは、イベント駆動型のサーバーレスコンピューティングサービスであり、API GatewayやEventBridgeなど様々なサービスから起動されます。 この記事ではAWS Lambdaでのインメモリキャッシュのポイントと、その実装方法について解説します。 キャッシュとは コンピューティングにおいて、キャッシュは、データのサブセットが保存される高速のデータストレージレイヤーで、通常は一時的な性質のものです。これにより、それ以降に同じデータのリクエストが発生した場合、データのプライマリストレージロケーションにアクセスするよりも高速にデータが供給されます。キャッシュにより、以前に取得または計算されたデータを効率的に再利用できるようになります。 AWSでキャッシュを活用することのメリット AWSでキャッシュを活用することで以下のようなメリットがあります。 パフォーマンス
これからRustを勉強したいエンジニアにおすすめしたい参考書や教材を紹介します
こんにちは、加藤(@tomo_k09)です。 PharmaXではバックエンド・フロントエンド開発やスクラムマスターなどをやっています。 PharmaXが提供しているサービスでは、バックエンド開発に主にRuby on Railsが使われていますが、一部の機能はRustで開発されています。 このような理由からRustの経験が浅かった私もコツコツとRustの勉強をしており、 少しずつ学習方法に関する知見が溜まってきました。 そこでこの記事では、Rustをこれから学びたいという方向けに、おすすめの書籍や教材について紹介します。 新しいプログラミング言語はどのように学ぶと良いか 私は新しい言語を学ぶとき、まず基本的な文法やどんな特徴を持った言語なのかをひと通り勉強しています。 そしてその言語の概要をつかんだあと、実際に簡単なアプリケーションの実装をはじめて、分からないことがあったらリファレンスを読ん
コードレビューで個人的に意識していること
こんにちは。 PharmaX でエンジニアをしている諸岡（@hakoten）です。 この記事の概要 この記事では、私が普段コードレビューで意識していることを紹介しています。 コードレビューのルールというより、個人としてのルーティンや意識していることについて書いています。 ※ チーム自体の「レビュールール」は別で存在していますので、ルールに沿った上でのルーティーンや心構えという認識で読んでいただければと思います！ レビュールールの運用やルール自体については触れていませんので、ご了承ください。 自身のキャリア どのような経歴のエンジニアからの話なのかを知っていただくと、内容を想像しやすいかと思いますので、私のエンジニアとしての経歴を簡単に紹介します。 ソフトウェアエンジニア 14年 主な領域、モバイル、ウェブ、APIサーバーなどのアプリケーションメインのエンジニア 機能リード、テックリードあた
負荷テストツール「k6」入門
こんにちは。 PharmaX でエンジニアをしている諸岡（@hakoten）です。 この記事の概要 APIの負荷テストツールにGrafana Labs社が開発している「k6」というツールがあります。 k6はオープンソースのCLIツールですが、 「Grafana Cloud k6」というクラウドベースSaaSツールも提供されている便利なツールです。 ローカルのk6は、負荷テストの時に使ったことはあったのですが、真面目に負荷テストの設計をするにあたり、ちゃんと理解したかったため、改めて基本から調べてみました。k6の入門記事としてお役に立てれば嬉しいです。 インストール Macでは、k6を「Homebrew」でインストールすることができます。
VScodeだけでGit操作を完結させるのだ～～ッ!!
VScodeだけでGit操作を完結させる方法について書くのだ。 👀その前に！ この記事は、以下の2つの拡張機能がインストールされている前提で進めるのだ。 Git Graph - Visual Studio Marketplace GitLens — Git supercharged - Visual Studio Marketplace インストールしておいてほしいのだ。 ✅ステージング(git add ◯） 以下のようにするのだ。 ＋ボタンをクリック：ステージングする ーボタンをクリック：ステージングを解除する ▲ステージング→解除 ✅コミット名を自動でつける 右にある✨ボタンを押すと、コミット名を自動で決めてくれるのだ👇 ▲この例だと、変更内容が意味不明すぎて変なコミット名になってるし、現状英語だけみたい？ これは、GitHub Copilotの機能なのだ。 ✅コミット(git c
データエンジニア道の俺のバイブル
先人の知恵に学ぶ データエンジニア道で、本当に良かった！読み物を、不定期に追記していく。 A Beginner’s Guide to Data Engineering — Part I データエンジニアをこれから始める人に、必ず薦める記事。データエンジニアの基本を学べるかつ、どういう世界に広がっていくのかまで、一気に学べるのでとても良い。 Functional Data Engineering — a modern paradigm for batch data processing 関数型パラダイムを使ったデータパイプラインの構築方法。これを初めて読んだ時の衝撃は今でも忘れないし、フルスクラッチからdbtを使ったデータパイプラインになっても健在な設計手法。 Engineers Shouldn’t Write ETL: A Guide to Building a High Function
リファクタリングを避けるコードデザイン(Railsを題材として)
2つの不確実性とリファクタリング プロダクションコードを書いていると、リファクタリングをしなければならないコードにぶち当たります。 正直なところリファクタリングは時間がかかるので避けたいものですが、必要になるようです。 必要な理由は大きく分けて2つあります。 1つ目は市場など外部の不確実性に対抗し、既存実装では不要だった抽象化を機能のために追加するためです。 これは因果的に回避できませんが、プロダクトの改善に直結するという意味でポジティブなものです。 2つ目は内部不確実性に対抗し、既存コードの意図の明瞭化や、必要以上の抽象化で身動きが取れない状況を改善するためです。 これは注意深くコードを構成することで回避可能なものです。 今回の記事では後者のリファクタリングを回避するためにどのようにコードを構成すべきかについて、筆者の判断基準を明確化することと、Railsでの適用例を示します。 (事例は
マイクロサービスの再考: タダ飯なんてものはない
どうも、株式会社プラハCEO兼エンジニアの松原です。 先日かとじゅんさんがツイートで紹介していたマイクロサービスに関する論文を読むついでに、適度に意訳した内容を音声入力してみました。ついでに意訳レベルなので翻訳の質は保証できないのですが、もし内容を読んでみて少しでも興味を持てた場合は実際の論文にも目を通してみると良いかもしれません。 論文のリンク: 「これ日本語でなんて言うの？」って分からなかった部分も多々あったのでより適切な単語があったら教えてほしい...! 導入 マイクロサービスには様々なプラクティスや技術を用いて以下のメリットを目指す 素早いデリバリー 高いスケーラビリティ 自律性 しかし実際にこの業界で実装されるマイクロサービスは採用するプラクティスや効果に大きな差があるため、オンラインサーベイ(51回答)と経験豊富なマイクロサービス実践者14名にインタビューを行った。 わかったこ
Github ActionsによるPythonのコード整形とコミットを自動化
背景 Pythonで開発している時、何らかのコードフォーマッター(blackとかyapfとかautopep8とか)を利用していることが多いと思います。 そして、おそらく皆さんいろいろなタイミングや方法でコードフォーマッターを実行しているはずです。 コミット前に手動で実行 pre-commitで設定しておいてコミット前に問題ないかチェックして怒られたらコードフォーマッターを実行して再度commit リポジトリにpushしてからCIに整形ができていないと怒られてからコードフォーマッターを実行して再度push この記事は上記のどれも毎回コードフォーマッターで整形しなきゃいけないので面倒臭い or コードフォーマッターを実行するの忘れがちだと思った方向けにGithub Actionsにコード整形とそのコード整形後のコミットを丸投げするための方法を書いた記事になります。 パッケージ管理 この記事では
次世代SQLクライアントArctypeを触ってみる
どうも、株式会社プラハCEOの松原です 先日社内のエンジニアに「このSQLクライアントがイケてそう！」と教わったので早速Arctypeを触ってみました TL;DR クエリの補完が最高 チャートやダッシュボードを通して簡単に可視化できる 操作性に優れていて、見た目が綺麗 クエリやダッシュボードごとに権限管理できる プレースホルダーを使えば非開発者ともクエリを共有しやすい 説明しよう、Arctypeとは なんかイケてるSQLクライアントです セットアップ それぐらいしか分からないので、ひとまずDBを立ち上げて実際に使ってみようと思います。こちらのmysql-employeesを使わせていただきましょう docker run -d \ --name mysql-employees \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=college \ -v $PWD/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
