Embulkでやりたいことリスト（2015年7月版） - Blog by Sadayuki Furuhashi
バルクロード機能 1つの設定ファイルで複数ジョブを実行する Running multiple jobs using one config file · Issue #167 · embulk/embulk · GitHub 例えば users.csv と histories.csv の2つのファイルを、それぞれPostgreSQLにある users と histories の2つのテーブル にロードしたいというようなユースケースに対応する機能。 設定ファイルの構文はissueに書いてあるように、default: に書き並べた設定に対して、jobs: に書いた設定をマージしたものを実際の設定ファイルとして実行していく方法で良さそう。しかし、fliters: は配列なので、default: に書かれた filters: に jobs: に書かれた filters: をどうマージするか、あまり良
デシリアライズ速度の比較 ByteBuffer vs DirectBuffer vs Unsafe vs C - Blog by Sadayuki Furuhashi
OpenJDK や Hotspot VM には sun.misc.Unsafe という内部APIがあり*1、これを使うと ByteBuffer.getInt や ByteBuffer.getLong よりも高速にバイト列から整数値をデコードできるという。これを駆使することで、Cで実装された拡張ライブラリに匹敵する速度を出せるらしい。 それが本当なら、データ圧縮やハッシュ関数、シリアライザ/デシリアライザなどの実装を高速化できる。例えば、lz4 や xxhash のJava実装が Unsafe API を使用している*2：jpountz/lz4-java Prestoも、中間データのシリアライズ/デシリアライズにはすべて Unsafe API を使っている*3。 そこで、実際にベンチマークしてみた。 ベンチマーク内容 10MBのランダムなバイト列を生成する 先頭から1バイト読み出す その1バ
Embulk 0.3 & 0.4 の新機能 - リジュームとJavaプラグイン - Blog by Sadayuki Furuhashi
つい先日*1、Embulk の新しいメジャーバージョンを2つリリースしました。 これらのバージョンでは、データ転送ミドルウェア勉強会で得られたフィードバックを元に、リジューム機能、Javaプラグイン機能、そして プラグインテンプレートジェネレータ を追加しています。 リジューム機能 大きなデータをロードする場合、大部分のデータのロードには成功するが、一部だけ失敗してしまうことは良くあることです。ネットワーク障害、サーバの過負荷などの他に、エラー処理が不完全であるなど原因は様々考えられますが、そのためだけに全データをすべてロードし直すのは大変な手間です。 そこでEmbulkでは、分割された複数のタスクのうちの一部だけが失敗した場合に、それらのタスクを後からリトライできる仕組みを導入しました。 使い方は、embulk run に --resume--state PATH オプションを指定するだ
並列データ転送ツール『Embulk』リリース！ - Blog by Sadayuki Furuhashi
こんにちは。古橋です。 先日の*1 データ転送ミドルウェア勉強会で、新しいオープンソースツール Embulk をリリースしました。 Embulk, an open-source plugin-based parallel bulk data loader from Sadayuki Furuhashi Embulk は、リアルタイムなログ収集では常識となった fluentd のバッチ版のようなツールで、ファイルやデータベースからデータを吸い出し、別のストレージやデータベースにロードするためのコンパクトなツールです。 fluentd と同様にプラグイン型のアーキテクチャを採用 しているため、RubyやJavaで簡単なコードを書くことで、様々なファイルフォーマットやストレージに対応することができます。一方で fluentd とは異なり、高速性やトランザクション制御、スキーマを使ったデータのバリ
データ転送ミドルウェア勉強会 - Blog by Sadayuki Furuhashi
Treasure Data, Inc. 古橋貞之です。 来たる1月27日、新しいOSSツール Embulk をリリースします。 EmbulkはFluentdのバッチ処理版のようなツールで、CSVデータやアクセスログなどの構造化データを高い信頼性で転送することができるコンパクトなツールです。 入力元、出力先、ファイルフォーマット、圧縮方式などをプラグインで拡張することができ、S3上のCSVファイル、PostgreSQL、Elasticsearch、Salesforce.com、Treasure Dataなど、異種のストレージやサービスの間でデータを転送・同期することが可能になります。 Fluentdとは異なって、1発実行、あるいは1時間や1日毎で実行するバルク処理に特化しており、 トランザクション制御 冪等性 高速性 スキーマを使ったvalidation などの拡張を備えています。 １回で使
続・リトライと冪等性のデザインパターン - リトライはいつ成功するか - Blog by Sadayuki Furuhashi
三度の飯よりエラー処理。古橋です。 大変好評をいただいた序章リトライと冪等性のデザインパターンの続編です。 前回はほぼ前置きでしたが、今回は冪等でない操作を冪等にする具体的なテクニックもまとめていきます。 パターン２：エラーを区別してDELETEを冪等にする リソースに常に一意なIDが振られていれば、Deleteを冪等にするのは難しくない。そもそも同じリソースを2度削除することはできない。 一つ注意するべきなのは、削除されたリソースのIDが再利用されるケースでは、Deleteの冪等性は保証されない。例えば、kill -KILL <pid> コマンドはDelete系のAPIと考えられるが、pidは再利用されるので、何度も繰り返すと意図しないプロセスを殺してしまう可能性がある。 一般にIDの生成は非常に難しい問題だが、Deleteに関してのみ言えば再利用されなければいいので、単調増加する整数（
リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
