Hadoop Conference Japan 2014 #hcj2014 でImpalaがPrestoより19倍速いという話をしてきた

タイトルとスライドの通りです。

Hadoop Conference Japan を運営された皆様、本当にお疲れさまでした。
また、私のセッションに参加して話を聞いていただいた皆様、ありがとうございました。

朝のキーノートで「使用しているコンポーネント」で Impala がランクインしていて実は結構驚きました。まだまだ普及していないと思っていましたけど、意外と使われているようでうれしいです。
(後 Hue がランクインしているのにも驚いた)

今回は他のSQLエンジンのセッションの間に挟まれての講演だったので、これは気を抜けないなと思い、結構頑張ってスライドを作りました。
やっぱり調べてみると Impala はとても面白くて、機能の細かい部分などを見て新たな発見もたくさんすることができました。

Impala が爆速なのは疑いようのない事実で、これをどう説明するか思案しましたが、結局 US で公開している以下のブログをベースに紹介することにしました。ブログを日本語訳にしてなかったのでちょうどよかったかなと。
http://blog.cloudera.com/blog/2014/05/new-sql-choices-in-the-apache-hadoop-ecosystem-why-impala-continues-to-lead/

ソースコードもあらためて読んでみると非常に楽しく、新たな発見がありました。
Impala のソースコードは、ヘッダファイル部分のコメントで仕様について非常に詳細に書かれていて、もう一つのドキュメントと言ってもいいぐらいです。

例えば simple-scheduler.h というヘッダファイルの一部は以下のようになっています。

// Performs simple scheduling by matching between a list of backends configured
// either from the statestore, or from a static list of addresses, and a list
// of target data locations.
//
// TODO: Notice when there are duplicate statestore registrations (IMPALA-23)
// TODO: Handle deltas from the statestore
class SimpleScheduler : public Scheduler {
 public:
  static const std::string IMPALA_MEMBERSHIP_TOPIC;

  // Initialize with a subscription manager that we can register with for updates to the
  // set of available backends.
  //  - backend_id - unique identifier for this Impala backend (usually a host:port)
  //  - backend_address - the address that this backend listens on
  SimpleScheduler(StatestoreSubscriber* subscriber, const std::string& backend_id,
      const TNetworkAddress& backend_address, Metrics* metrics, Webserver* webserver,
      ResourceBroker* resource_broker, RequestPoolService* request_pool_service);


また、今回のスライドはUSの開発チームのレビューを受けるために全て英語で作成しました。
全レビューが終わった段階で日本語に再翻訳しています。
実際に使用していないとはいえ、英語で40分セッション用のスライドを作るのは初めてで、結構大変なんじゃないかなと思ったのですが、実際には英語のドキュメントの文言をそのまま流用できるなどのメリットも多く、そんなに苦労はしませんでした。再翻訳の分時間はかかりましたが。


今回は40分という時間の関係上機能や性能を紹介するだけで終わってしまいましたが、実際の使い方などについてもわかったことがたくさんありますし、アーキテクチャの深い部分とか、パフォーマンスチューニングの方法など、かなりのネタを集めることができました。残念ながら今回ほとんど紹介できなかったので、またどこかの機会で是非紹介してみたいですね。

異能力者が抱える承認欲求: 不戦無敵の影殺師2巻

(「不戦無敵の影殺師」 1-2巻のネタバレ注意!!)

echizen_tm 氏の紹介記事を読んだのをきっかけに購入した「不戦無敵の影殺師(ヴァージンナイフ)」ですが、すっかりファンになってしまい、先日発売した2巻を読んでからは、久々に感想記事をブログで書こうと思い立つまでになり、こうして記事を公開するに至りました。

不戦無敵の影殺師 2 (ガガガ文庫)

不戦無敵の影殺師 2 (ガガガ文庫)

作品紹介と1巻のあらすじ

1巻の詳しい解説は echizen_tm 氏の素晴らしい紹介記事に譲るとします。

ここでは簡単に作品紹介をします。
この作品の舞台は現代の東京に極めて近いですが、「異能力者」という存在がいるという点だけが異なります。
普通のラノベですとこの異能力者が街中壊してドッカンドッカンと「敵」と戦ったりするわけですが、この作品ではそのような暴力行為は全て「違法」です。
異能力の使用は異能力制限法という法律により厳しく制限されていて、犯罪行為のために行使することはできません。
そこで、異能力者が異能力者として生きるためには、この世界では芸人のような形で活動しなければなりません。(一部警察官のような異能力者もいるようですが未登場)
主人公冬川朱雀(ふゆかわ すざく)の異能力は煌霊遣い(こうれいつかい)という、死にかけの人と契約して煌霊という使い魔のような形で使役し、その煌霊とコンビを組んで敵を暗殺するという、極めて実戦的な異能力です。
しかし、そのような異能力が「芸人」として売れるはずもなく、大した仕事ももらえずにうだうだしていた、というのが1巻冒頭の状態でした。

以下に、かつて私が現代社会人に例えた1巻のあらすじ紹介ツイートがあるので載せておきます。



1巻での朱雀は、
「俺は強い、だけど世間は認めてくれない。俺より弱い異能力者が俺より人気があるのは妬ましい」
と、卑しい嫉妬と承認欲求を顕にしつつも最後には実際に強さを世間に認めさせることができ、仕事も増えてハッピーエンドになったかのように見えました。
しかし、承認欲求の形は一つではありません。

  • これでは足りない。もっと多くの人に認めてほしい!
  • 俺が認めてほしいのは何もわからない一般人じゃない。俺の技術を本当にわかっている人達に認めてほしい!


こうした、違った形の承認欲求を描くのがこの2巻です。

羨望と嫉妬

朱雀は、強くないけどバラエティアイドルとして売れている蟠龍院川匂(ばんりゅういん かわわ)を素直に「うらやましい(p.37)」と思います。川匂の方がTwtterのエゴサーチのヒット数が圧倒的に多いし、テレビでの出演回数の多い彼女こそまさに「異能力者としての成功者」だと思っていました。そして朱雀の羨望と嫉妬の対象の頂点こそ、1巻の最後で倒した滝ヶ峰万理(たきがみね ばんり)でした。

しかしそんな朱雀自身が、実は他の同業者の羨望と嫉妬の対象になっていたのです。

バラエティ番組で明るい笑顔を振りまく川匂は、番組の打ち上げ会場で朱雀にその嫉妬と敵意をあらわにします。

「すべてを高みから見下ろしてる、その態度が許せないんです! 何様のつもりなんですか!」
(p.126)

「だけど、業界内で評価されるのはあなたですからっ!」
(p.127)

「(前略)ぶっちゃけた話、わたしがいないと成立しない番組なんて一つも存在しないんですよ! わたしが消えたら、他のアイドルの子を呼べばいいんです!」
(p.128)

「この異能力者業界の中で正しいとされるのは、いつもいつもいつもいつもあなたみたいな個性の強烈な異能力者のほうです! わたしだって、これでも一本一本真剣勝負なんですよ!(中略) だけど、ほかの先輩も、同期も、業界の話題で出すのは、あなたや滝ヶ峰先輩なわけですよ。わたしが『異能力者の話題』や『異能力者の文脈』で語られることなんて一度だってないんですよ!」
(p.128)


彼女は異能力者として異能力者に評価されたかったのです。

このシーンのすぐ後に、今までは割とおちゃらけたキャラだった後輩の柏木小犬丸(かしわぎ こいぬまる)でさえ、「朱雀は異能力者の夢である強さを認めてほしいというものをかなえてしまった、だから嫉妬されるのは当たり前だ」とはっきり言います。

また、この2巻にはようやくラノベらしい悪の組織が登場します。その組織は「売れない異能力者」を戦力として多数抱えています。
登場した能力をいくつか挙げると、確かにどれもテレビの芸人としては売れなさそうな感じがします。

  • 自己治癒能力
  • 透明な住居を創造する能力
  • (ネタバレなので秘密)


芸人として食べていくことのできない彼らのうちの一人は、朱雀とその煌霊小手毬(こでまり)に対し、「どうしてお前らだけ成功したんだ」とその嫉妬心をぶつけてきます。

ここで朱雀は、かつて自分が滝ヶ峰万理に対して向けていた「あいつは最強のフリをしているだけだ」という嫉妬心からの敵視が、実は自分に対しても向けられていたことを知るのです。

異能力者としての承認欲求

川匂は、終盤で朱雀と小手毬に勝負を挑みます。
バラエティアイドルとしてではなく、異能力者としての真剣勝負です。
戦闘描写を見る限り川匂はかなり強いです。普通の異能力バトルものであれば、最強でなくても間違いなく強キャラの部類に属するはずです。そんな彼女だからこそ、バラエティアイドルに甘んじていることが屈辱だったのでしょう。

「わたしは自分は強いってずっと言ってきました。だれもそれを真に受けたりはしませんでした。いつしか、それはギャグになり、わたしの持ちネタになりました。人はわたしが強いという言葉を聞いて、笑いました。笑うな! あなたたち全員が間違ってて、わたしだけが正しいんだ! それを証明してやる!」
(p.255)


この言葉は、1巻で女子高生アイドルの霧原みぞれが、八百長をしろと指示されて悩んでいるときにこぼした発言を思い出させます。

「みぞれが異能力者の業界に入ったのは強くなりたかったからなんです。(中略)みんなを騙してまで偉くなれだなんて、みぞれを侮辱するにもほどがあります……」
(1巻 p.218)


2巻中盤での小犬丸の以下の発言は、こうした異能力者達の思いを一言で表しています。

「結局、異能力者っていう生き物はですね、みんな、心の片隅では『強くなければいけない』って思ってるんですよ。表でわざわざ言わなかったとしてもね」
(p.141)


専門技術者として

この異能力者と「強さ」というものは、間違いなく「専門技術者」と「技術」のメタファーです。
ここでいう専門技術者には、芸術家なども含まれます。実際、先述の発言の後に小犬丸はこのような話をしています。

「友達のエロゲー絵師が言ってました。本当はもっと上手く絵を描ける。でも、そういう絵が望まれてないから、描かないって」
(p.141)


おそらく著者は実際にエロゲー絵師に取材した内容をほぼそのまま反映しているのでしょう。この言葉には共感できる「技術者」も多いのではないでしょうか?

「自分の強さ」を証明したい、でも「強い」だけでは食べていけない。こうした異能力者が抱える悩みに対し、本巻ではまだきれいな解決策を出せていません。しかし朱雀は、「結局、俺たち異能力者は戦うことでしかわかり合えない(p.263)」と、一つの答えを出していきます。
真剣勝負の結果が川匂の芸人生活にどのような影響を及ぼしたか、本巻ではまだ分かりません。バラドルとしての看板に傷をつけただけで終わったのか、あるいは「強い」異能力者としての新たな一面を見せて人気が上昇したのか、それは次巻以降で明らかになるでしょう。

「不戦無敵の影殺師」は、決して万人向きの作品ではないです。よくある異能力バトルのような、強い主人公が敵をぶっ飛ばして終わり、という作品ではありませんし、きれいなハッピーエンドにも絶望的なバッドエンドにもなりません。あとついでに言うと萌え系サービスシーンもほとんどありません。小手毬がバスタオルを巻いただけというシーンはありますが話の必要上必須だしそのシーンでの萌え描写はないです。それでも、今の自分の仕事のあり方に悩んでいるような30代前後の社会人にはドンピシャな内容だと確信しています。是非一度本屋で手に取ってみてください。

おまけ

「法的に美少女って名乗ったらアウトな年齢なんてないでしょ! みんなが美少女と思ったら美少女なんです!」
(p.250)


法的に問題なくても、各方面で色々物議をかもしそうな問題発言ですね。

Clouderaで作るデータ分析環境

wyukawaさんがデータ分析環境について書いていましたが、全部 CDH を使えば実現可能なので便乗して書いておこうと思います。

1. ETL 処理

CDH なら以下のツールがあります。

ちなみに wyukawa さんが言及している Luigi ですが、中身は単なる Hadoop Streaming なので、今からこれを使うぐらいなら上のツールから選択した方がいいと個人的には思います。

2. ジョブ管理

全部 Oozie でできます。

ジョブネット

Oozie ワークフローがジョブネットに相当するもので、これにより Sqoop でデータをロードして Hive で変換処理、失敗したらメールを送信、などの処理をまとめておくことができます。
Oozie 単体だと xml でワークフローを記述しなければいけないので少々面倒ですが、Hue を使えば Web ブラウザからドラッグアンドドロップで簡単にワークフローを書くことができます。

f:id:shiumachi:20140507070328p:plain

日付を指定してのジョブ実行

Oozie コーディネータを使えば日時を指定してのワークフローのスケジューリングが可能です。毎週日曜の午前4時に実行、毎月1日0時に実行などの指定はもちろん、cron と同じような書式でのスケジューリングも可能です。さらに同時実行数の指定や、キューにたまったときに FIFO にするのか LIFO にするのか、あるいは最新のスケジュールのみを実行するのかなど細かく指定することができます。


f:id:shiumachi:20140507070718p:plain


Web からのジョブの削除

できます。


認証機構

Kerberos 認証があります。

3. 集計結果格納用の RDBMS

計算に時間がかかって困るぐらいに RDBMS が肥大化するほどのデータがあるのなら普通に Hadoop 上で保存しておけばいいと思います。多分 Impala をそのまま実行した方が速いです。

4. アドホック分析

Hue を使えば上記の処理も全部ひっくるめて Web UI できます。

5. 分析用クエリ

CDH なら Impala があります。Hue から Impala を使う人もいれば、BI ツールから JDBC 経由で Impala につなぎにいく人もいます。

Cloudera Impala の本の日本語版もオライリーから無料でリリースされています


デモビデオはこちら

おまけ: Hue を試してみたい!

Hue は上記の他に色々できます。

http://demo.gethue.com/ にアクセスすれば、Hue のデモを触ることができます。まだリリースしたばかりのベータ版なので、Impala でのクエリ実行や検索結果の閲覧、Oozieワークフローの実行ぐらいしかできませんが、どんな感じか理解するためにとりあえず触ってみるものとしては十分でしょう。

デモ以上に試してみたいけどクラスタまでは作りたくないという人はクイックスタートVMを使うといいでしょう。CDH5のコンポーネント一式がVMに収まっています。


Hue の公式サイトはこちら

プログラマ向けMacの不要なファイルを削除するためのコマンド

git や homebrew などに言及しているので「プログラマ向け」と書いてますが、別にプログラマじゃなくても人によっては有用と思います。

現在のドライブ使用量の確認

コマンドじゃないけど、グラフィカルに全体の使用量とその内訳をみたい場合はGrandPerspectiveというソフトが便利。

ドライブ全体
$ df -h
現在のディレクトリ以下の合計サイズ
$ du -sh
現在のパス以下の全ディレクトリを容量順にソート

ファイル数が多いとそこそこ時間がかかる。

$ du | sort -n
現在のディレクトリの全ファイルを容量順にソート
$ ls -lShr

ファイルの圧縮

現在のディレクトリの全ログファイルを gzip 圧縮
$ for file in `ls *.log*`; do 
gzip -c ${file} > ${file}.gz
done

キャッシュや古いファイルなどの削除

※実行は自己責任で。

Mavenリポジトリを削除
$ rm -rf ~/.m2/repository
Git の不要なオブジェクトを削除
$ git gc
homebrew でインストールしたファイルの古いバージョンを削除
$ brew cleanup

brew cleanup -n で dry-run 実行できるので、まずはこちらを実行した方がいい。
パッケージを最新版にしていないと cleanup できないので、普通は brew doctor → brew update → brew upgrade → brew cleanup とする流れになる。
全部のパッケージを一斉にアップデートして古いバージョンを削除するのはリスクがあるので十分注意すること。
慎重に実行するのであれば brew <コマンド> <パッケージ名> などで一つづつ作業していった方がいい。

最終手段

個人情報を巡る政府と企業の関係

前回の記事で紹介した、The Economistの政府対企業の特集の記事の1つに、個人情報関連の記事があったのでこれも要約してみました。


個人情報関係の情報を追いかけている人にとっては目新しい内容ではないですが、「政府と企業」という特集の中でわざわざ一つの記事として扱っていることから、The Economist もこの問題が非常に重要だという認識なのでしょう。


翻訳ではないので結構省略したり別の表現に変えたりしています。
興味のある人は原文を読みましょう。


原文: http://www.economist.com/news/special-report/21596668-governments-relationship-tech-sector-hideously-complicated-looking-both-ways

インターネットは、かつてないほどの偉大な個人情報バンクを生み出した。
多くの人々は、初めはインターネット上で買い物をするのを嫌がっていたが、今ではすっかり慣れてしまい、自分の好き嫌いや、写真、名前、友達の詳細をソーシャルメディアに公開するまでになった。
このようなデータはターゲティングのようなマーケティングを行いたい企業にとっては非常に貴重である。技術の進歩のおかげで、企業はどのような傾向をもつ人でも見つけ出すことができる。


しかし、誰がデータの安全性に責任を持つべきか、そしてデータの用途に制限をつけるべきかどうかという重要な問題も生まれてきた。
インターネット黎明期に政府はこの問題に注目したことがあったが、最近の欧州における新しい法律のドラフトはその当時に比べてはるかに重く厳しい内容である。
この法律の対象となる全ての企業は、概算で8万ユーロはかかるデータ保護担当官を任命しなければならなくなる。
5000点以下の個人情報しか扱わない会社は免除されるものの、たとえ小さな顧客メーリングリストでさえこの制限を超えてしまうだろう。
ドイツでは、16の州それぞれが独自のデータ保護の理事会を持っていて、それぞれ別の法律を施行している。バイエルン州では全てのwebサイトはユーザが匿名のままでいることを許容しなければいけないが、これはFacebookのユーザにとっては問題である。自分の名前でログインしないといけないからだ。


政府はこうした問題に対し、消費者の権利を示す一方、安全保障のために企業がデータを提供することも期待している。
さらにはメールや電話なども直接監視している。こうしたデータはテロリストや脱税を監視するのに便利ではあるが、反体制派を監視することもできる。
また、データを盗み出されるリスクもある。この問題についての議論はスノーデン事件によって激化することとなった。
国家が信用できないのであれば、民間企業もまた信用できない。
民間企業の中にはサイバー攻撃を受けたり何らかの事故によって大量の顧客情報を流出した企業もある。
企業は信用の失墜とブランドイメージの毀損を避けるため、こうした問題を解決する必要がある。
また、企業は政府からの情報公開の要請に歩み寄ろうとしている。
Appleは昨年31組織もの政府機関から情報の要求を受けたことを公開した。その大半は米国政府である。


(原文には2013年上半期の先進諸国政府による、主要webサービスGoogleAppleなど、への情報開示要求についての表がある)


インターネットが人々の生活により深く浸透するにつれ、このような問題は急激に重要になっていき、多くの疑問を生み出すことになる。
Twitterのようなサービスプロバイダは攻撃的なメッセージに対して責任を持つべきなのだろうか?
オンラインでの児童虐待に対し、それらの懸念されるサイトの多くがオフショアで運営されていることを鑑みたとき、何ができるだろうか?


インターネットはグローバリゼーションの究極の事例である。
常に新しくサイトがどんどん生まれていくインターネットを監視するのは非常に困難である。
そして反政府主義者から企業の名前に傷をつけたい不満のある消費者まで、誰もが武器として使用することができる。


インターネットとは、言論の自由、プライバシーの権利、そしてイノベーションの自由などの異なる原理が衝突する場所である。
これらの原理のトレードオフはそれぞれの国や個人によって話し合われなければならないが、相互接続した世界では誰もが満足のいく答えは出ないだろう。

The Economist で企業対政府についての特集

The Economist の2月20日号で、企業対政府についての特集がありました。

以下、ざっと要約してみました。自分なりの解釈も入ってるので、原文にない情報が含まれている可能性があります。

正しく引用したい場合は原文を参照してください。

企業と政府の関係は敵対的になりつつある。しかし、両サイドとも互いを必要としている。


米国政府はセオドア・ルーズベルトの時代から、強くなっていく企業を制限していくような流れを作っていった。
こうした敵対的な雰囲気は増加の一方をたどるが、しかしあまりに強い制約は経済の活性化を阻害するため、政府は企業を必要以上に圧迫できない。
一方で企業も政府を必要としている。政府は、法システムや基本的な安全保障だけではなく、企業の根幹をなす労働者を教育したり、交通などの社会インフラを整えたりしてくれる。
それだけでなく、インターネットや人工衛星など、企業が商用製品を作るのに必要な多くの科学的研究を行ったりもする。
多くの業界において、政府は主要顧客でもある。防衛産業は典型例であるが、製薬業界なども国民厚生サービスなどが大手の顧客である。建設業界も政府の活動に強く依存している。


もしかすると、現在一番厄介な関係はハイテク産業と政府かもしれない。企業の顧客の一部が、政府がその企業のデータにアクセスしたり、企業のデータの使い方に制限をかけることに不安を感じている。
企業は顧客の側に立つのか、それとも政府の側に立つのか?


もう一つの複雑な問題は、企業と政府の両方によって市民に提供される福利厚生である。例えば、多くの政府は産休を拡大することを要求しているが、これは大企業には実現できても、中小企業にとっては実現がより困難なことである。有権者は税金の増加を嫌がるので、政治家は企業負担で福利厚生の向上を行おうとする。


大企業は政府とうまく付き合っていく必要があることを認める一方、政府は一部の大企業、例えば航空会社などを他国の買収から保護するなど優遇措置をとっている。


このレポートでは富裕国における企業と国家の関係について報告する。税金の役割、規制、競争についての政策、ハイテク産業がなぜ特別なのか、ロビー活動などについて議論する。


ここ最近、企業対政府という構図について特に興味を持っていたので、このレポートは非常に興味深いものでした。
多国籍企業は金銭的にも入手できる情報量も平均的な国家を上回っていて、しかも地理的制約が非常に緩いため、いずれ企業は国家を凌駕するのではと思っているのですが、やはりそう簡単にはいかないようですね。

Confluenceの稟議書機能を使う

Confluenceには稟議書というブループリントがあります。
何らかの意思決定をしなければいけないときに、議論をするためのページを作るためのテンプレートですが、地味に便利です。

意思決定に必要な情報が多い場合、チャットだけではそうした情報を正しく把握しながら議論するのが困難なので、私のチームでは稟議書ブループリントを活用しています。

以下のような情報を入力して作成しています。

  • ページタイトル
    • 「◯◯するかどうか」「◯◯の対処方法」など、意思決定に対する質問形式で作成する
  • 背景
    • 「◯◯するかどうかを決定するにはいくつかの問題について検討する必要がある」「◯◯の対処方法にはいくつかある」などの概要を書く
  • 選択肢とメリット・デメリット
    • 「選択肢1: 実行する」という形でいくつかの選択肢を並べ、それぞれについてメリット・デメリットを記載する。
  • 論点
    • 選択をするにあたって、どの部分が論点になるのかをまとめておく。


意思決定に参加する人はコメント欄で以下のような形式で入力していきます。

選択肢1に賛成。なぜなら、(以下論点についてのの主張を説明)


もちろん、議論の中で新たな選択肢や論点、それに既存の選択肢や論点の不備などが出てきますので、その都度説明を修正していきます。


注意点は2つ。

  • 意思決定するまでもないことについて、周囲からの承認を得るためだけにするような稟議は無駄なので上げない
  • 関係者以外は意思決定の場に呼ばない