読者です 読者をやめる 読者になる 読者になる

Treasure Data Summer Intern 2015

TreasureData

8/3〜9/30 の2ヶ月間、トレジャーデータ(以下、TD)ではSummer Internで3名の学生を受け入れ、その受入責任者を担いました。 初めての試みでしたが、いずれの学生も優秀で与えられたタスク*1を成功裏にこなしてくれました。

熱が冷めないうちに、来年度のためにもここに内容をまとめます。

TDインターンの特徴

TDインターンの特徴は、基本的に開発成果をオープンソースソフトウェアとして公開することです。Fluentdnanosecondサポートマルチプロセスでのソケット共有HivemallへのFactorization Machineの実装それぞれgithubでオープンに開発しております。

成果を全てオープンソースとすることはTD的には利点ばかりではありませんが、インターン生にはインターン期間が終わっても自身が携わったプロダクトに興味を持って頂けえば、と思っております。

インターン生にも2ヶ月しっかりと開発に携わって頂きました。社内Slack部屋などで普段のTDエンジニアリングの雰囲気を肌で感じて頂けたのではないかと思います。

*1:それぞれに成果が見込めるだろう小さめのタスクと挑戦的なタスクの二つをそれぞれに設定。

続きを読む

Treasure Dataを支える(中の人に必要な)技術

Treasure Data(以下、TD)に入社して早2週間が経ちました。

入社してから、平成14年度IPA未踏ユース第1期で同期でスーパークリエイタであった西田さんがTDで働いているのを知りました。MapReduceHadoopが登場した頃、「Googleを支える技術」という技術書*1でお世話になったのですが、いつの間にかTreasure Dataを支える人になっていたんですね*2

Googleを支える技術 ?巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)

Googleを支える技術 ?巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)

TDではおかげさまで結構なペースでお客さんが増えていて事業規模拡大に備えて幅広い職種で人材募集中です。今回はTDのバッグエンド側で働く人材に求められている技術やスキル(どのような人がフィットするのか)について、2週間働いて見えてきた部分を紹介します*3

*1:よく書けていて、当時、Googleの新人もこれを読んでそのインフラを学んだとかなんとか。

*2:古橋くん含め、TDには、私の把握している限りではIPA未踏のスーパークリエイタが3人います。

*3:私なりの理解で書いているのでTreasure Dataで働くことに興味の持った方は人材募集をよく読んでapply下さい。

続きを読む

Treasure Dataに入社しました

TreasureData

3/31付けで4月から国立研究開発法人になった産業技術総合研究所を退職致しまして、4/1からTreasure Dataに入社しました。第一号のResearch Engineerとして東京オフィスで働きます。

CTOの太田さんから2013年頃に一度お誘いを受けておりましたが、2014年になってまた声を掛けて頂き、2年越しでの入社となりました。

なんでTreasure Data?

現在のTreasure Dataでは、毎秒45万レコード、4,000億レコード/日ものデータが投入されていて、Hiveで処理されるデータ量も3+ペタバイト/日と急速な発展をとげております。研究でもこの規模のデータ量を扱うことはGoogleFacebook等の一部の研究者を除いてはありませんから、非常に挑戦的な課題に取り組める環境であることにDB研究者として第一に魅力を感じました。優秀なエンジニアが集まっていて刺激的な環境であることや報酬面ももちろん魅力的です :-)

続きを読む

Prestoのcodegen

以前、Prestoバイトコード生成部分のソースコードを読んだので、hack再開時のためにメモしておく。

  • コード生成にはobjectwebのASMを利用している。Parser generatorはANTLR

  • ExpressionCompiler#internalCompileFilterAndProjectOperator codegenしているのはfilter句とprojection句のみ。Joinは残念ながらcodegenされていない。

  • SqlStageExecution#startTasks evaluate planの中身はremote taskというのがsubStages(StageExecutionPlan)があると作られる

  • join関係のrewriteはPredicatePushDown。Volcanoのexchange抽象operatorでremoteの実行を抽象化。LocalExecutionPlannerのvisitJoinあたりで実行operatorを生成

  • operatorがstageddbみたいにblocking queueみたいので独立に動いている(?) inputが必要なのはpageというのをやりとり

  • PageBuilderでPageを生成。Pageはtuplesのplaceholder

  • Operator#getOutput がeval相当。HashJoinOperatorはbuild/probeのin-memory hash join。 grace hash joinもサポートしていないので、バケットがメモリに乗り切らないと駄目な…な実装ですね*1。ChannelIndexのSlice(nio.bytebuffer)にtupleを保持

  • Sliceはnon-jvmheapにメモリを確保するairliftというライブラリを利用


合わせて読みたい。

*1:大量メモリを確保できる前提なのでしょう

Multiplexed Reservoir Sampling

機械学習 論文

Xixuan Feng Arun Kumar Benjamin Recht Christopher Ré: "Towards a Unified Architecture for in-RDBMS Analytics", In. Proc, SIGMOD, 2012.

だいぶ昔に読んだ論文だけどIn-database AnalyticsのBismarckの論文にMultiplexed Reservoir Samplingというのがあって、それを使うと収束が早いというのが?に思ったので書く。

まず、Reservoir samplingについての前提知識を必要とするのでWikipediaのエントリを参照のこと。 次のようなアルゴリズムで最後に残ったsamplesはランダムなものになっているサンプリング手法。

Multiplexed Reservoir Samplingの概念図は次のとおり。

続きを読む