2014年7月16日水曜日

DBToaster: Higher-order Delta Processing for Dynamic, Frequently Fresh Views

DBToaster: Higher-order Delta Processing for Dynamic, Frequently Fresh Views

Yanif Ahmad, Oliver Kennedy, Christoph Koch, Milos Nikolic,

Peoc. of VLDB 2012 pp.968-979, 2012
  • DBアクセスを高速化する方法としてview を構築しておく方法がある。
  • しかし、頻繁に書き換えられるDBではviewの書き換えが多発する。
  • これをIncremental にやることで解決する。
  • 具体的には差分を意味するΔview も持っておき、データ入力でこのΔを変更する。
    そしてΔを使って元のviewを変更する、というように再帰的にやるらしい。
  • ストリームシステムSPYよりも圧倒的に速いという結果。というかこのSPYは
    妙に遅い??

2014年7月11日金曜日

Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing

Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing

Matei Zaharia, Mosharaf Chowdhury, Tathagata Das, Ankur Dave, Justin Ma, Murphy McCauley, Michael J. Franklin, Scott Shenker, Ion Stoica
Proc. of NSDI’12, 2012
  • UCBのチーム
  • Resilient Distributed Datasets というものを提唱。これはFlume JavaのPCollectionとほぼ等価に見える。
  • lineage (家系)という概念を導入。要するにどのようにしてそのデータセットが計算されたかの履歴。いつでも再計算できるようにしてFTを実現。これだとiteration があると大変なことになるので、適宜スナップショットを併用する。
  • Spark 上に実装。
  • Iterative なジョブでHadoopと比較している。

2014年7月10日木曜日

Presto SQL Engine

Hadoop Conference Japan 2014 のTD古橋さんによるPrestoのお話

参加するつもりだったのだけど、変な会議のせいで参加できなかったhadoop conferenceでの講演資料がアップされていた。ありがとうございます
  • SQLエンジン。HDFSに対して処理を行うだけでなく他のSQL的にアクセスできる
    DBに対するラッパとしても機能する。
  • アーキテクチャとしては、複数のWorkerをCoordinator が束ねる。CoordinatorはリクエストのSQLを解析してプランニングを行い、個々のWorkerに行なうべき動作を指示する。Workerはコネクタプラグインを介して、バックエンドのDBにアクセスする。
  • workerでの処理はオンメモリ。メモリに乗らないものは扱えない。
  • プラグイン
    • Javaでかく
    • Hive,Cassandra, JDBCがすでに用意されている。
    • SchemeとRow を提供する機能があればよい。
  • Prestogres
    • PrestoのフロントエンドはSQLになっているのだが、ここにアクセスさせる
      アダプタを書くのが面倒
    • Postgresqlをフロントエンドに持つことで、アダプタ実装を回避。
    • 枯れたPostgresql用のアダプタでアクセスできる。

2014年7月6日日曜日

apache S4

論文

  • S4: Distributed Stream Computing Platform
    Leonardo Neumeyer, Bruce Robbins, Anish Nair, Anand Kesari
    Proceedings of the 2010 IEEE International Conference on Data Mining Workshops, Pages 170-177, 2010
  • Performance Evaluation of Yahoo! S4: A First Look
    Chauhan, J; Chowdhury, S.A. ; Makaroff, D.
    Proc of .P2P, Parallel, Grid, Cloud and Internet Computing (3PGCIC), 2012 Seventh International Conference on
    pp. 58-65, 2012

所感

  • 2010年にYahooが発表したフレームワーク。その後apacheに移管されたが、あまり話を聞かない。
  • ストリーム処理を連続したイベントの処理として考え、イベントをノードが投げ合う。イベントを受け取ったノードはイベントを作成して送出する。
  • KVペアをベースにキーで分散先を指定して投げつけるというつくり。キーが同一であれば一つのノードに行くはずなので、そこで集計処理ができる。つまりシャッフル相当のことがこれで実現できている。なので基本的にはMapReduce ができる。
  • ただし一つのキーに対するreduce 的処理を分散して実行する事はできない。これはHadoopでも一緒だが。
  • そもそも、統計的に処理をすることを前提としているので、イベントを落とすことをなんとも思っていない。負荷が上がるとどんどん落とすつくり。まあ、それでいい場合も多かろう。
  • 2010年に論文を読んだ時の印象としては、かなりプリミティブで負荷分散とかうまくいかないだろうなあ、というかんじだった。性能もなかなかくるしそう。FTについてもあまリ考えていないのかなと。
  • 2つめの論文は評価論文。でも台数も少ないし、ワークロードもスタティックでデータのロスレートを見るというぐらいであまリ参考にならない。

2014年7月5日土曜日

docker meetup #3

概要

  • 日時 6月4日 @日経ホール 19−22時
  • 参加者数 240名? なんと2時間で枠がうまったという。。たまたまTwitterを見ていて気がついてよかった。
  • NII 横山先生もいらしていた。
  • コンテナ+スタッカブルファイルシステムというどこかで聞いた技術。コンテナのレポジトリがあるというのがポイントなのか。

講演

通常発表

  • 19:00 @philwhln - Orchestration Tools
    さまざまな周辺技術の紹介?
    焦点がよくわからなかった。
    stackato というPaaSを作っているのだが、独自のLXCレイヤを捨てて
    dockerに移行したとのこと。
  • 19:30 @stanaka - Dockerでデプロイ&モニタリング(仮)
    はてなのCTO。
    • コンテナのなかからcpu usageとかをとると、基本的にホスト全体の値が取れてしまってコンテナの数値が取れない。なので、基本的には、ホストの方で、cgroup のお作法にしたがって、やればよい。/sys/fs/cgroup/xxxx/ を見ればいろいろな情報が取れる。
    • デプロイに関してはdocker hub を使って、自動ビルド。さらにwebhook とhubotで自動起動までできそう。
    • Mackerel という社内ツールの紹介。名前はサーバ→鯖から。ロールと言う単位でホスト群を一括管理。
    • 20:00 @mainyaa - Dive into Dockerネットワーク
      トップゲートの方。dockerでクラスタ的なものを作る際のネットワーク設定のオプションには次の3つぐらいがある。
    • -link
      ホスト内ネットワーク。IPを調べるのが面倒とのことだが、自動化すればいいので特に問題にならないだろうと思う。複数ノードに展開はできない。
    • host network
      いわゆるブリッジ。セキュリティ的にいかがなものか。isolation にならない。
    • open vswitch
      GREトンネルでホスト間にも使える。ある意味一番簡単。
    • 20:20 @deeeet - Flynn(仮)
      OSS のPaaSであるFlynnの紹介。HEROKUっぽい。EC2などの上に、独自のPaaSを展開することができる。コンテナを Docker Hubにあげておき、自動的にデプロイさせるとのこと。どんな言語でも対応できるというのが強みか。

    21:00 LT(1人5分)

  • @mopemope - How to Impl lib swarm backend
  • @peryaudo - Docker+CoreOS+GCEで自動スケール分散レイトレ
    タイトル通り。
  • @kzys - Porting Docker to FreeBSD
    これも。まだできてない。Jailでやるとのこと。
  • @nasunom - perfomance Evaluation of Docker
    横山先生と一緒にやっているというかた。外注か。AUFSのwrite が遅いので気をつけましょう。というのが結論か?
    • @y_matsuwitter
      gunosyの方。docker file がモノリシックなので、同じようなものをたくさん書かなければならなくて大変。ということで、複数のサブファイルをマージするツールを作成したとのこと。
      しかし、docker fileってそこまで頑張っちゃうものなんだろうか。shef をきどうするだけ、とかいう感じのほうが良かったりしないのか。本番環境もdockerにするというのなら別だが。。

調べること

  • etcd
  • consul
  • mesos
  • core OS
  • libswarm
  • hubot
  • fleet
  • surf ? serf?

2014年7月4日金曜日

MillWheel: Fault-Tolerant Stream Processing at Internet Scale

MillWheel: Fault-Tolerant Stream Processing at Internet Scale

SaTyler Akidau, Alex Balikov, Kaya Bekiroglu,Slava Chernyak, Josh Haberman, Reuven Lax,Sam McVeety, Daniel Mills, Paul Nordstrom, Sam Whittle
Proc. of Very Large Data Bases 2013, pages 734-746
Googleの イベントストリームプロセッサ。やっていることはよくあるもので、パイプラインと計算ノードを定義してやって、そこにイベントを流してやって処理するというものなのだが、自動負荷分散したり、永続ストレージを持っていたりと芸が細かい。
- exactly once セマンティクスをサポート。背後に持っているストレージに書き込むことで、2重に実行しないようにしている。さらっと書いてあるけど相当な難しいことである。さらに、それでもレイテンシが数十ミリ以内に収まっているのも驚き。。

- 論文のサンプルからはC++で書かれているように見える。




2014年7月3日木曜日

Flume Java

#FlumeJava: Easy, Efficient Data-Parallel Pipelines

Craig Chambers, Ashish Raniwala, Frances Perry, Stephen Adams, Robert R. Henry, Robert Bradshaw, Nathan Weizenbaum
Google, Inc

Proceeding of PLDI '10 Proceedings of the 2010 ACM SIGPLAN conference on Programming language design and implementation

Google論文。MapReduceを置き換えるものとして開発されたJavaのデータ並列ライブラリ。記述力としてMapReduceのスーパーセットであるという主張。複数ノードにまたがる(かもしれない)一連のデータに対して、データ並列でワークフローを書く。この形だとMapとReduceの区別が無く、ほぼフラットに書ける。GroupByという演算があり、これがMapReduceのシャッフルフェーズに相当する。

データ構造はimmutable で次々にデータ構造を作るようになっているが、実際には評価が遅延され、最後の結果を評価したところで、処理のツリーを最適化してから評価するという作り。最終的にはかなり複雑な評価式も一段のMapReduceに落として処理しているとのこと。

たしかに、MapReduceでグリグリ書いていくよりも、ずっと楽だろう。

2010年の論文という点を割り引いても、新規性があるとは思えないが、やはり超大規模環境でちゃんとやってるのが偉いっていうことなんだろう。