Clipper Cardの罠・終幕

すっかり確認するのを忘れてましたが10ドル払い戻しされてました。払い戻しされる1週間くらい前にそれまでやり取りしてたところとは違う部署の担当者から「お前のカードに1ドルキャッシュバックすっから後で確認しろや」的なメールが来てて何で10分の1になってんねん！って突っ込みのメールを送るとかしてたんですが、先方の単純なミスだったようで最終的にはちゃんと戻ってまいりました。

今度は西海岸に行く2週間前くらいにValue Addするようにしよう。これと比べると日本のSuicaとかは遥か先を行ってるよね。

Cloudera Manager 5でNFSを有効にしてみる

分散ファイルシステムにアクセスする口としてのNFSはクライアントが分散環境の恩恵を受けることができない（NFSクライアントからのサーバコールが1箇所に集約されるので簡単にボトルネックになる）のでそんなにメリットはないんだけど、HDFSの中身を適当にのぞいて回るくらいの用途ならそれなりに便利ではあるので動作確認がてらCloudera Manager 5でHDFS NFS Gatewayを有効にする手順を確認してみます。

まずサービスの一覧からHDFSを選択します：

HDFSサービス画面からインスタンスのタブを選択します：

ここで "Add" ボタンをクリックしてロールの追加を行ないます：

NFS Gatewayを選択します：

Quickstart VMなのでロールを配置するホストに選択肢はありません：

NFS Gatewayが追加されました：

状態が "Stopped" になっているので nfsgateway にチェックを入れて Actions for Selected から開始してやればOKです。これだけでHDFSの / がまるっとexportされます：

Hueで見えてるのとNFSマウントしてファインダから見てるのが同じだということが確認できますね：

ドラッグ＆ドロップでHDFSにファイルを放り込んでみようと思ったんですがユーザIDの対応関係が適当だったんで書き込めませんでした。これはセキュリティ的に正しい姿ですね。

別のLinuxホストにHDFSに書き込む権限を持つユーザと同じユーザID, グループIDを持つユーザを作成してNFS Gateway経由でアクセスしたら問題なく書き込むことができました。

今回はCloudera Manager 5を利用して取り敢えず試してみただけのお知らせでした。@kernel023のブログ記事 CDH5ベータ1のNFSv3ゲートウェイを試してみました と比較してみるとコマンドラインを一切書いてないのに気付くと思います。コマンドプロンプトとかシェルが嫌いな人には絶賛Cloudera Managerをお勧めします。そうでない人も使うべきというか、これなしで大規模クラスタの運用管理ってムリですよね実際...

続・Clipper Cardの罠

続き。ここしばらく西海岸行く予定ないんだけど、って連絡したらサポートの中の人から2つのオプションが提示された：

• 次に西海岸に行く機会があったら1週間前くらいに連絡くれればカードに取り込めるようにしてあげる

• いまアカウントに設定されているカード情報が支払いに使ったのと同じカードだったら払い戻ししてあげる

ここは迷わず払い戻しを選択。ただし手続きして承認されて払い戻しされるまでに30日くらい掛かるよ、って念を押された。戻ってくるなら何でもいいので一月くらい待ちますわ。そっちこそリファンド、忘れんなよw

Clipper Cardの罠

一部ですこぶる便利だと評判のClipper Cardですが割としょーもない落とし穴があるので自分のために記録しておきます。

• ウェブサイトでチャージしてもシステムに反映されるまでに3〜5日を要する

• システムに反映された金額をカードに取り込むにはカードリーダにかざさなきゃダメ

• ウェブサイトでチャージしたおカネは半年以内にカードに取り込まないと失効する

去年 San Francisco 〜 Palo Alto 〜 San Jose 辺りをうろうろしていたときにすこぶる便利に使っていたんだけど、そろそろ残高心もとなくなってきたからチャージしとこうと思ってチャージしたのが帰国の2日くらい前。そのまま帰国して経費精算するのに乗車履歴見てたらチャージした筈の金額が取り込まれてなくて、システムに反映されるまでにタイムラグがあるのを知ってまぁいいかと思って放って置いて、先月 San Francisco 行ったときに使ったら（=カードリーダにかざしたら）チャージされると思っていたのに実は失効していたという罠。

履歴調べて失効した分を再度カードに取り込めるようにしてくれる、ってサポートから連絡きたけどここ半年以内に西海岸行く予定ないんだよなぁ... どーすべw

Java 7 Update 51 on MacOSX 10.9.1

Java7 Update 51が来てたので早速インストールしておいたんだけど：

shellから確認するとJava 7 Update 45のままなのはどうしてなの？

2つのTwitterSource.java

CDH 4.5に含まれるFlume-NGにはTwitterからデータを取得するためのTwitterSourceクラスが含まれるようになっています。これがCDH 4.5にTwitter4Jが同梱されるようになった理由。実際こんな感じでjarファイルが転がっているのが見て取れます。

% cd /opt/cloudera/parcels/CDH-4.5.0-1.cdh4.5.0.p0.30/lib/flume-ng/lib
% ls -lF twitter*
-rwxr-xr-x 1 root root 283752 Nov 21 11:07 twitter4j-core-3.0.3.jar*
-rwxr-xr-x 1 root root  27690 Nov 21 11:07 twitter4j-media-support-3.0.3.jar*
-rwxr-xr-x 1 root root  56262 Nov 21 11:07 twitter4j-stream-3.0.3.jar*

これだけで終わってもいいのですが折角なので混乱を招くのではないかと思うTwitterSource.javaについて書いておきます。

世の中には2つのTwitterSource.javaがある

• https://github.com/cloudera/cdh-twitter-example で提供されるもの
• Flume-NGの機能として提供されるもの
• CDH 4.5に入っているのはこれ。CDH 5にも入るハズ

cdh-twitter-example版

• com.cloudera.flume.source.TwitterSource
• TwitterのSample APIを叩く
• 指定されたキーワードを含むものが取得できる
• フォーマットはいじらずに後段に流す

コードからコメント抜いてくるとこう書いてある：

/**
 * A Flume Source, which pulls data from Twitter's streaming API. Currently,
 * this only supports pulling from the sample API, and only gets new status
 * updates.
 */

Flume-NG版

• org.apache.flume.source.twitter.TwitterSource
• TwitterのStreaming APIを叩く
• Firehoseで取得できるものの1%がサンプリングされるらしい
• Avroフォーマットにして後段に流す

コードからコメント抜いてくるとこう書いてある：

/**
 * Demo Flume source that connects via Streaming API to the 1% sample twitter
 * firehose, continously downloads tweets, converts them to Avro format and
 * sends Avro events to a downstream Flume sink.
 *
 * Requires the consumer and access tokens and secrets of a Twitter developer
 * account
 */




まとめ

早い話がClouderaが作ったTwitterSource便利だからApache Software Foundationに寄贈してFlume-NGに取り込まれたけどちょっと機能が変わってますね、ということでした。

CDH 4.5に移行したらFlume agentが動かなくなった

年末年始の休みでアップグレードしようと思ってたのが作業できてなかったので、忘れないうちにと思って3連休の初日にCloudera Manager 4.8 + CDH 4.5の環境に移行してみた。移行作業自体は何の問題も無く終わったんだけど新しくしてから全サービス起動して問題ないか見て回ってたら不審な点に気付いてしまった：

Flumeからデータが流れてきてないw

いやこれ本番環境とかだったら全然笑えない事態だけど。Cloudera Managerからログを調べてみたらagentがエラー吐いてた：

Unable to start EventDrivenSourceRunner: { source:com.cloudera.flume.source.TwitterSource{name:Twitter,state:IDLE} } - Exception follows.
java.lang.NoSuchMethodError: twitter4j.FilterQuery.setIncludeEntities(Z)Ltwitter4j/FilterQuery;
 at com.cloudera.flume.source.TwitterSource.start(TwitterSource.java:141)
 at org.apache.flume.source.EventDrivenSourceRunner.start(EventDrivenSourceRunner.java:44)
 at org.apache.flume.lifecycle.LifecycleSupervisor$MonitorRunnable.run(LifecycleSupervisor.java:251)
 at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
 at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
 at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
 at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
 at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
 at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
 at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:662)

Twitter4Jのところで存在しないメソッドを呼び出すとかアホなことしてる。これ原因は判ってしまえば簡単で、CDH 4.5に入っているTwitter4JのバージョンとFlume agentが使っているTwitter4Jのバージョンが違うのが問題だった。以前のCDHにはTwitter4Jは含まれてなかったのでFlume agentのjarに入れてあったんだけどCDH 4.5側のTwitter4Jを先に見付けてしまって誤動作するという昔懐かしいDLL HELLみたいな状況が起きてた。

判ってしまえば対処も簡単でCDH 4.5用にpomを書き換えてFlume agentをビルドし直してデプロイ、サービス再起動で問題なくデータが流れ始めた。

fork元の cloudera/cdh-twitter-example に差分が来てたのでそれらを kmizumar/cdh-twitter-example に取り込んだだけ。

どうしてCDH 4.5にTwitter4Jが入っているのか、は気が向いたら書きます。