Pinterestのオフィシャル開発ブログの「いかにPiterestが持続的なグロースを実現しているか（How Pinterest drives sustainable growth）」という素敵なエントリーでグロースチームが継続的に追っている４つのログフォーマットが紹介されていました。 user state transitions Xd28s cohort heat maps conversion funnels 最後の２つは割とポピュラーだと思うのですが、前半２つの「user state transitions / Xd28s」ってなんぞやって感じだと思うので、４つまとめてご紹介したいと思います。 1.user state transitions 曰く、これがPinterestのグロースチームの中で最も重要なチャートとのこと。まず前提条件ですが、Pinterestでは「28日」使わなか

Explore and analyze data with a prebuilt, Google-recommended data warehouse solution that uses BigQuery, Looker Studio, and AI. Try it free.

2020/05/18開催 Alibaba cloud AIソリューションセミナー 第二部：機械学習レスなAIサービスでカンタン画像検索

Product updates, customer stories, and tips and tricks on Google Cloud Platform

これは Craft Conference 2015 で私が行った 講演 を編集して記事にしたものです。その時の 動画 と スライド もご覧頂けます。 あなたのデータベースは、どのようにして確実にデータをディスクに保存しているのでしょう？　ログを使っているのです。 データベースのレプリカは、どのようにして他のレプリカと同期するのでしょう？　ログを使っているのです。 Raft などの分散アルゴリズムはどのようにして合意を取っているのでしょう？　ログを使っているのです。 Apache Kafka などのシステムでは、アクティビティデータはどのように記録されるのでしょう？　ログを使っているのです。 あなたのアプリケーションのデータ・インフラストラクチャはどのように規模相応の堅牢性を保つのでしょうか？　答えは･･･ ログは至るところにあります。私はプレーンテキストのログファイル（syslogやlog

こんにちは。はてなチーフエンジニアの id:Songmu です。 去る、6月16日（火）にHatena Engineer Seminar #5をはてな東京オフィス、イベントスペースにて開催いたしました。火曜の夜という時間帯にも関わらず、多数のご参加誠にありがとうございました。 今回は、全文検索やレコメンドエンジン、機械学習などコアな技術について、はてなならではの取り組みをお伝えできたのではないかと思います。 それぞれ短いながらボリュームのある内容であったので、参加者の皆様の頭も疲れたのではないかとも思いますが、その後の懇親会も非常に盛り上がっていたのも開催者として非常に嬉しく思いました。 これからも、定期的にEngineer Seminarを開催し、皆様にはてな内での技術的取り組みをお伝えしていきます。また、アンケートにも皆様熱心にお答えいただきましてありがとうございました。頂きましたフィ

RDBの専門家として日々活動している中で気づいたことのひとつに、「RDBはデータへのアクセスの実装をインデックスに頼っているが、インデックスは全ての問題を解決できるほど万能ではない」ということがある。インデックスというのはとても強力な部品であり、その点には全く異論はない。だが、世の中の全ての問題（クエリ）を解決できるほど、柔軟性に富んだものではないということだ。RDBは、どのインデックスを使ってデータへアクセスするかということを、オプティマイザを用いて判断する。大抵のRDB製品では、オプティマイザはよい仕事をするので、インデックスとオプティマイザの組み合わせによって、ほとんどの問題に対応できる。だが、100%ではないのであり、そのようなケースがシステムの性能問題を引き起こしたり、プログラマ（アプリケーションの設計者）に、NoSQLへ完全に移行したり、クエリ高速化のために非正規化をすると言っ

Redash helps you make sense of your dataConnect and query your data sources, build dashboards to visualize data and share them with your company. “Redash is as essential as email to my company. We love data but accessing the data is a pain without Redash. Any company I go to, I get them hooked on Redash. It’s an easy sell :)” by Ben Dehghan, Co-Founder of Data Miner Read what our users say → Write

昨日、分散DB本読書会のあとに品川のラーメン屋でリアルタイムとは何ぞや〜みたいな話になった。自分の思いついたポエムをここに書いておこう。現場の問題とはあまり関係がない。 Stream Data Processing: A Quality of Service Perspective (Advances in Database Systems)という本によれば、DSMS (Data Steram Management System) とDBMS (Database Management System)の違いは、クエリを発行するデータ集合の性質にある。つまり、DBMSは今ある有限のデータに対して操作を行うための仕組みで、DSMSはこれからやってくる無限のデータに対して操作を行うための仕組みと定義されていた。このDSMSというやつは、古式ゆかしいストリーム処理システムのことで、まあいわゆるCEP

Fluentd Meetup 2015 夏の発表資料

graphite, grafana, sitespeed.io, diamond で継続 Web パフォーマンスモニタリングgraphitegrafanadiamondperformancesitespeed.io Web のパフォーマンス継続モニタリング環境 intro Web の健康状態を把握するためには、きちんとしたモニタリング環境を整える必要がある。 正しくメトリクスが測定できていないと、正しくボトルネックの把握ができないし、チューニングの副作用も正しく把握できない、アプリの変更の影響もわからないし、負荷対策もできない。 単にパフォーマンスチューニングだけのためではない。が、パフォーマンスチューニングには必須、という関係。 そして、メトリクスは一回適当に取っただけでは正確とは言えず、やっぱり定期的な取得が必要になる。 この辺のノウハウは、サーバサイドではかなり成熟している。 しかし

Amazon Machine Learningが公開されて一月半程経ちますが、当ブログを御覧の皆様はこのサービスについてどの程度利用されていますでしょうか？弊社でも幾つかの案件で試験的に使ってみたり、社内でこの分野について興味を持っているエンジニア達が色々触って試行錯誤している状況です。 私もそんなAmazon Machine Learningに興味を持っているうちの1人ではありますが、私自身、機械学習や統計学についてはそこまで詳しかったり、関連する分野での経験をして来ている訳ではありません。むしろ初心者な方です。そんな私がこのサービスを理解するに当たり、そのコンセプトを解説したドキュメントが公開されていましたので読んでみました。読み進めて行く過程で関連しそうなWeb資料やドキュメント等も併せて参考にしてみたのですが、なにぶん初心者なもので『その理解、言葉の使い方間違ってんじゃね？』的なと

BigQuery では COUNT(DISTINCT(X)) ではなく EXACT_COUNT_DISTINCT(X) を使おうBigQuery 以前、COUNT(DISTINCT(X)) の代わりに GROUP BY して COUNT(X) しようという記事を書きました。 BigQuery で COUNT(DISTINCT(X)) を使わない方が良い理由 が、今は時代が変わりました。BigQuery にいつの間にか、EXACT_COUNT_DISTINCT() 関数が追加されたのです！ Returns the exact number of non-NULL, distinct values for the specified field. For better scalability and performance, use COUNT(DISTINCT field). さらに non

Google Developers Summit Tokyo - The Googliness of Google Cloud Platform

antirez/disque は Redis の作者が開発している、オンメモリ分散ジョブキューです。 まずは、簡単に動かしてみることにしましょう。 結論 普通にシンプルな分散ジョブキューです。 まだアルファ版という事だけれど、簡単に非同期を実現する仕組みとしてはかなり良いと感じました。 Redis の事を考えれば、今後ますます便利になっていくと思うので、早いうちに一通り触っておき、考え方を学んでおくのは良さそうです。 セットアップ Mac OSX 10.10.3

今更だけど MySQL 5.6 ではオンラインDDLの機能が追加されている。今日はこのオンラインDDLについて勉強したことを書いてみる。 MySQL のマニュアル MySQL :: MySQL 5.6 Reference Manual :: 14.11 InnoDB and Online DDL にいろいろ書いてある。いまから書くことはこのマニュアルから得た知識が元になっている。 DDL てなによ？ データではなく、テーブル自身を操作するためのSQL文のこと。CREATE, ALTER, DROP, TRUNCATEなど。オンラインDDLではCREATE INDEX, DROP INDEX, ALTER TABLEに適用される。 http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_ddl 5.1 までの ALTER TABLE

データ件数が大量に(レコード数100万以上とか)ある場合、ALTER TABLE時にテーブルの書き込みロックが無視できないレベル(時間)で発生します。 テーブルの書き込みロックについて MySQL5.5以前: ALTER TABLE時に発生 MySQL5.6以降: ALTER TABLEでカラムのデータ型変更、全文検索用インデックスの追加、プライマリキーの削除、文字コードの変換/指定 を行った時に発生 参考: http://takatoshiono.hatenablog.com/entry/2015/03/11/013316 pt-online-schema-changeを使用することで、テーブルロックなしでのALTER TABLEができます。 pt-online-schema-changeのインストール方法(Mac homebrew) $ brew install percona-too