In this part we’ll take a closer look at Scio, including basic concepts, its unique features, and concrete use cases here at Spotify. Basic Concepts Scio is a Scala API for Apache Beam and Google Cloud Dataflow. It was designed as a thin wrapper on top of Beam’s Java SDK, while offering an easy way to build data pipelines in idiomatic Scala style. We drew most of our inspiration for the API from S

This is the first part of a 2 part blog series. In this series we will talk about Scio, a Scala API for Apache Beam and Google Cloud Dataflow, and how we built the majority of our new data pipelines on Google Cloud with Scio. Scio > Ecclesiastical Latin IPA: /ˈʃi.o/, [ˈʃiː.o], [ˈʃi.i̯o] > Verb: I can, know, understand, have knowledge. Introduction Over the past couple of years, Spotify has been mi

Whenever a user performs an action in the Spotify client—such as listening to a song or searching for an artist—a small piece of information, an event, is sent to our servers. Event delivery, the process of making sure that all events gets transported safely from clients all over the world to our central processing system, is an interesting problem. In this series of blog posts, we are going to lo

背景 AppEngineはStackDriver Loggingにログが蓄積されますが、それをBigQueryにストリーミングさせることができます。 私も普段この設定を入れて過去のログ保管や検索を行なっているのですが、エラーメッセージはArrayになっており単純に WHERE しただけではエラーになるため備忘としてここに記します。 クエリー内容 UNSET()でArray部分を展開し別名（この例では l （アルファベットの小文字エル）を付ける。 その l に対してWHEREをかける。 下記の例では2017年11月中に発生したOOMのログ、且つURLが /example で始まるものを日付順で抽出する。 SELECT timestamp, l.logMessage, protoPayload.resource FROM `appengine_request.appengine_googlea

メルカリのバックエンドを支える SRE(Site Reliability Engineering) チームに最近加わりました @syu_cream です。 本記事では KPI に関わる数値を計算してレポートを生成する集計システムの刷新に取り組んでいる話を紹介します。 現在は刷新の途中であり、集計項目ベースでいうと 1/3 ほどの実装が済み、現行システムと刷新後のシステムの一部を並行稼動させている状態です。 背景 メルカリではアプリケーションのログファイルやデータベースから、 DAU(Daily Active Users) などの KPI に関する様々な数値を集計するためのシステムを稼働させています。 この集計システムは毎日 Slack やメールにて KPI のサマリーレポートを送信し、全社員が数値を閲覧し、日々プロダクトの傾向を意識することを可能にしています。 集計システムの動作イメージは

セッションIDやアクセストークン、はたまた業務上で使う一意の識別子など、いろんなところで一意のIDを生成しなきゃいけないケースが存在します。 そこで世間で使われているIDの生成方法について調べてみました。 選択基準 ID生成における要求として、以下の観点が上げられるかと思います。 生成の速度 大量にデータを短期間で処理し、それらにIDを付与する場合、ID生成そのものがボトルネックとなることがあります。 推測困難性 IDを機密情報と結びつける場合、IDを改ざんされても、機密データが見れないようにできている必要があります。 順序性 採番した順にデータをソートする必要がある場合は、IDがソートキーとして使えないといけません。 それぞれについて各生成手段を評価します。 ID生成の手段 データベースの採番テーブル 採番用のテーブルを作り、そこで番号をUPDATEしながら取得していくやりかたです。古い

2017年12月4日にBigQueryに機能が追加されました。 この投稿は下記ページのメモです。 https://cloud.google.com/blog/big-data/2017/12/focus-on-security-bigquery-announces-support-for-customer-managed-encryption-keys-and-custom-roles-for-identity-access-and-management 1. 暗号化鍵の管理をユーザができるようになった BigQueryを使うとき、デフォルトでデータは既に暗号化されていますが、このときの暗号化鍵をユーザが管理できるようになった。鍵の管理はCloud KMSで実施。組織のポリシーで鍵の管理を自分たちでコントロールできるようにしないといけないという要件があった場合などは、この機能で対応できるよ

テストがなかった無法地帯のプロジェクトに自動テストを導入して、開発速度を1.7倍にした話をします。 自動テストがなぜないのか 自動テストのないプロジェクトには、そうなる理由が必ず存在します。よくみる理由は、「時間がないから1」「テストの書き方がわからないから」「無理やりテストを書いたつらい経験があったから2」といったものです。今回のプロジェクトの場合は、以下の2点でした： 自動テストの書き方がわからないから レビューがテスト代わりだったから まず、チーム編成が変わって私ともう一人がチームに加わるまで、実装者の中に自動テストの経験者はいませんでした。このような状況では、自動テストは困難になります。なぜなら、何をどうやってどこまでテストするかを決めるには、多少の慣れが必要だからです。この慣れがないと、何をしたらいいかわからないという状態に陥りがちで、結果として自動テストが後回しにされてしまいま

これは Go Advent Calendar 2017 その2 6日目の記事です。 https://qiita.com/advent-calendar/2017/go2 みなさん、こんにちは。 pospome です。 普段は GAE/Go でサーバサイドの開発をしています。 twitter では 実装パターン, DDD, golang, GCP についてつぶやくことが多いので、 同じような分野に興味があれば、 フォローしてマサカリ投げてもらえると嬉しいです。 https://twitter.com/pospome ということで本題に入ります。 golang.tokyo #9 で goddd という github リポジトリを知りました。 https://golangtokyo.connpass.com/event/65921/ ちょっと興味があったので、 goddd に対する自分の感想を書