はてなブックマーク

仕事で BigQuery のクエリの結果を共有用のフォルダに Google Sheets 形式で保存して、Slack で URL を共有する、ということを頻繁にやっているのですが、 WebUI だと、クエリ結果を Google Sheets 形式で保存できるけど、ファイル名とフォルダが指定できないので、いちいち名前を変えて、フォルダを移動しないといけない。Slack 通知はできない。 Google Apps Scirpt (GAS) だと、全部実現できるけど、コードの管理を GitHub でやるのが面倒 と定形処理なのに、イマイチ効率の良い方法がなかったのを、tumugi で Ruby スクリプト化しました。 tumugi について詳細に知りたい方は、Ruby と tumugi によるデータパイプライン構築 をご覧ください。 タスクを分割して、定義する 「BigQuery のクエリ結果を

データを扱う仕事をしていると、何らかの形でデータをある順序に沿って処理する Workflow = データパイプラインを構築する必要になる場面に出くわすことが多いと思います。 こうした処理に適用できるソフトウェアは既にいくつか存在するのですが、自分が仕事で使う上でマッチするものがなかったので、tumugi を Ruby のライブラリを作成し、 gem として公開しました。ロゴはこんな感じ。 Workflow Engine をつくろう！ シリーズ連載は、元々このライブラリの設計を整理するために書いていた記事でした。まだ、未完ですが興味のある方はそちらもお読みください。 注釈 この記事は tumugi が Python で書かれたワークフローエンジンである Luigi に強く影響されて書いたことから、対比として分かりやすいため Building Data Pilelines with Pytho

Part 1 Task の依存関係の解決 Part 2 Workflow の冪等性 Part 3 Task 間でのデータのやり取り Part 4 Task の並列実行 Task の並列実行 今回は Workflow Engine に Task を並列実行できる機能を実装をします。Workflow Engine が利用されるのは、ある程度以上の数の Task を含む処理になるので、全体の実行時間を短縮するために並列実行の機能はとても重要なものになります。 ![Alt text](http://g.gravizo.com/g? digraph G { rankdir=LR; Task2 -> Task1 Task3 -> Task1; Task4 -> Task1; Task5 -> Task1; Task6 -> Task2; Task6 -> Task3; Task6 -> Task4;

Deis は Docker/CoreOS/Fleet がベースになっている Heroku buildpack と互換性のある Private PaaS を実現する OSS です。 Deis には AWS で動かすための CloudFormation のテンプレートが公式で提供されているのですが、はっきり言ってお試し用であり、そのままプロダクションに投入するのは危険です。 Install Deis on AWS ここでは、実際にプロダクションに投入した経験から得た Deis を AWS でプロダクションに投入するために必要なことを書いていきます。なお、Deis は絶賛 v2.0 が開発中ですが、ここで話すのは v1.12.3 の話です。 まずは公式の情報を手に入れる Deis をプロダクションに投入するする際の Tips を公式が提供しているので、まずはこれを読みます。 Production

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Part 1 Task の依存関係の解決 Part 2 Workflow の冪等性 Part 3 Task 間でのデータのやり取り Part 4 Task の並列実行 まえおき この連載記事で作成する Workflow Engine は、Luigi の設計思想に大きく影響を受けています。なので、 @k24d さんの Luigi によるワークフロー管理 を先に読んでおくと、理解が深まると思います。 前回は Task の依存関係の解決方法を実装しましたが、Part 2の今回は Workflow の冪等性について実装していきます。 Workf

Part 1 Task の依存関係の解決 Part 2 Workflow の冪等性 Part 3 Task 間でのデータのやり取り Part 4 Task の並列実行 Workflow Engine って何？ Workflow Engine と言っても多機能なものから、シンプルなものまで様々なものがあります。そこで、主旨がぶれないように、この記事での Workflow Engine は、以下の要件を満たすソフトウェアとします。 Workflow Engine とは、依存関係のある複数の Task を、意図した順番通りに実行するもの この記事では、この要件を満たす Workflow Engine を Ruby でつくる方法について解説します。 依存関係を記述する 依存関係を解決するコードを書く前に、依存関係を記述する方法をまず決めましょう。 依存関係を記述するには、luigi のように Ta

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

https://cloud.google.com/bigquery/release-notes#08252015 の速報。 詳細は後日追記予定。 UDFs(user-defined functions) のサポート 多分、今回の目玉機能。JavaScript でユーザ定義関数(UDFs)が書けるようになりました。 これは機能がデカイので、別エントリーで。 https://cloud.google.com/bigquery/user-defined-functions http://googledevelopers.blogspot.jp/2015/08/breaking-sql-barrier-google-bigquery.html サンプルで雰囲気を感じ取ってください。 こんな感じで JavaScript で関数を定義、登録して、 // The UDF function urlDeco

以前、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-NULL な値だけを数えてくれるという嬉しい仕様です。 というわけで、前の記事と同じく実際に publicdata:samples.github

4/16 に Google Cloud Platform Blog にて Cloud Dataflow の Public Beta の開始と共に、BigQuery の各種アップデートが発表されました。 リリースノートも久々に更新されています。 しかし、ここに書いてある事以外にも色々と変更点が発見されていますが、情報が散在しているため、変更点をまとめてみました。まだ、漏れがあるかもしれないので、ご指摘をお待ちしております。 （4/18追記）4/17 に公式 Blog でもまとめ記事が出ました。確認中です。 アップデート内容一覧 Streaming Insert の制限の緩和 Streaming Insert の値段の変更 Batch Insert (Load) の制限の緩和 Google Cloud Datastore データのロードに対応 API リクエスト数制限の緩和 クエリの追加（ドキ

これは大々的に発表された割には誰も使っているという噂を聞かない Google が提供する Docker の Private repository サービスである Google Container Registry を、Google Container Engine (以降、GKE）と組み合わせて使ってみようといいう記事です。 結論 GKE 使うなら、Google Container Registryはとても便利なので、利用を強く推奨します。 GKE のドキュメントがなさすぎるのが普及にしない原因なんじゃないかと思う。 利点 Docker の Private リポジトリサービスは本家の Docker Hub とか Quay.IOなどがありますが、Google Container Registry の利点は、 Private リポジトリの数は無制限で、安い（GCS のストレージとネットワーク料

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

まずは結論 こんな環境が Google Container Engine 上に一発で作れるスクリプトとDocker Imageを作った。 要素技術 Locust Python製OSSの負荷テストツール。分散テストモードがあって、簡単に複数台から負荷をかけるクラスタを構築することができる。今回は、環境変数で master, slave を切り替えられる Docker Image をベースにしている。 Docker Private Registry Google Container Engine で private repository を利用する方法を参照してください。 使い方 事前準備 ビルドサーバに gcloud SDK をインストールし、認証が終わっていること gcloud コマンドでデフォルトの GCP の PROJECT_ID が設定してあること（下記のコマンドでは --proje

三行でまとめると Docker Registry w/ Google Cloud Storage driver を利用し、イメージは GCS 経由で共有する Push: ビルドサーバに Docker Registry を立てて、そこにビルドしたイメージを push Pull: Google Container Engine の pod の1つとして Docker Registry を立てて、そこから service の portalIP 経由で Pull 以下、手順詳細 事前準備 ビルドサーバに gcloud SDK をインストールし、認証が終わっていること デフォルトの GCP の PROJECT_ID が設定してあること（下記のコマンドでは --projectId オプションを全て省略しているため） GCS に Docker registry 用のバケットを作成していること ビルドサー

mongobq とは MongoDB の特定のコレクションのデータを BigQuery のテーブルとしてインポートするためのコマンドラインツールです。 想定している使用方法 fluent-plugin-bigqueryなどでBigQueryにログやトランザクション系のデータが登録済みである ログ中には商品IDなどは入っているが、商品の値段などの詳細データはMongoDBで管理されている 両者を JOIN して分析するために、MongoDB 上のマスタデータを BigQuery に日次バッチなどでインポートしたい インストール方法 npm パッケージとして公開しているので、Node 0.10 以上が必要です。 Usage: mongobq [options] Options: -h, --help output usage information -V, --version output t

簡潔に言うと、BigQuery の COUNT(DISCTINCT(X)) は正しい値を返さないことがあるので使わない方が良い。（ちゃんと仕様を理解して使おう） 2015/5/28 追記 「GROUP BY して COUNT()」が面倒だという人は、EXACT_COUNT_DISTINCT(X) を使おう。 BigQuery では COUNT(DISTINCT(X)) ではなく EXACT_COUNT_DISTINCT(X) を使おう BigQuery の DISTINCT の仕様 https://cloud.google.com/bigquery/query-reference?hl=ja#aggfunctions より引用 Returns the total number of non-NULL values in the scope of the function. If you u

AWS の public DNS に対して ansible を実行すると、us-east-1リージョンでは成功するのに、ap-southeast-1リージョンでは、ControlPath too long というエラーが発生するという現象に悩んでいた。 よくよく調べてみると、デフォルトが %(directory)s/ansible-ssh-%%h-%%p-%%r という設定になっていて、ap-southeast-1リージョン（*.ap-southeast-1.compute.amazonaws.com）のように長いホスト名だと108文字の限界を越えてしまうせいだった。 The path to use for the ControlPath sockets. This defaults to "%(directory)s/ansible-ssh-%%h-%%p-%%r", however o

ちょっとはまったのでメモ代わり。 Docker 0.11.1 までは、homebrew でインストールできたのですが、1.0 からはboot2docker を含んだ公式インストーラが追加されたので、homebrew からは削除されるかもしれません。（そういう提案が出ています） 公式ドキュメント: Installing Docker on Mac OS X なので、現時点で、Docker 1.0 を Mac OS X にインストールしたい場合は、 公式インストーラをダウンロードしてインストールする homebrew-cask を使い、公式インストーラでインストールする のどちらかの方法になります、なおどちらもインストールされるものは同じです。 それぞれの方法を簡単に説明しておきます。 公式インストーラをダウンロードしてインストールする 以下の URL から公式インストーラをダウンロードしてき

先日発表された Elastic Beanstalk for Docker で、任意の言語で書いたアプリケーションを Elastic Beanstalk 上で動かすことができることができるようになりました。 なので、さっそく Go で書いた Web アプリを動かしてみました。 ここで使用したソースコードは以下から入手できます。 Web アプリケーションの作成 作成する Web アプリケーションは、gitで管理する必要があります。 以下、Helloと出力するだけの Go の Webアプリを hello.go という名前で保存してください。 package main import ( "fmt" "net/http" ) type Hello struct{} func (h Hello) ServeHTTP( w http.ResponseWriter, r *http.Request) {

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

カスタムAMIを使わずに .ruby-version を見て、バージョンを切り替える秘伝のタレ的な、.ebextensions を発明した。以下の様な設定ファイルを .ebextensions 配下に作って、デプロイするだけで良い。 とりあえず、2014/3/6 現在はこれで動く。ついでに、Rubyのビルドの高速化とgitからbundle installした場合にPassengerがgemを認識しない問題の修正も入っている。 xbuild を使っているので、perl、python, php, node, ruby の全てに応用できるはず。t1.micro インスタンスだと起動に30分くらいかかるけど、そこは初回だけなんで我慢しよう。 option_settings: - namespace: aws:elasticbeanstalk:application:environment opti

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Norikra はコマンド自体がデーモン起動オプションを持っているが、標準の仕組みに載せたいの upstart 化してみた。これが正しいかは分からないが、とりあえず動いてはいる。みんな、どうやっているんだろうか？ 事前準備 norikra ユーザの作成 xbuild で /usr/local/bin/jruby-1.7.10 に jruby-1.7.10 を インストール ログディレクトリを /var/log/norikra に作成し、所有者を norikra:norikra にしておく upstart スクリプト description "norikra" start on runlevel [2345] stop on runlevel [016] setuid norikra setgid norikra env PORT=26571 env LOGDIR=/var/log/nori

require 'aws-sdk' # AWS.config(access_key_id: 'xxx', secret_access_key: 'yyy', region: 'us-east-1') class SnsAndroidPush def initialize(sns) @client = sns.client end def notify(endpoint_arn, message) @client.publish( target_arn: endpoint_arn, message: message ) end def create_application(name) res = @client.create_platform_application( name: name, platform: 'GCM', attributes: { 'PlatformPrincipal'