HadoopのMapReduceのシャッフル - wyukawa's diary
象本2版の6.4 シャッフルとソートを読んでMapReduceのシャッフルって面白いし興味深いなーと思い、ついでに軽くHadoop 0.20系のソースもあわせて読んでみたのでメモっておく。 シャッフルっていうとまずソートのイメージだよね。ていうか僕自身はそうだった。 ワードカウントの例でいうとこんな感じ。キーでソートしてるね。 まあソートもメインな処理なんだろうけど他にもいろいろやってます。 map関数の出力からreduce関数の入力までの一連の処理をすべてシャッフルと呼ぶと思うんだけど、以下のようなことをやってます。 まずmapタスク側の処理を見て行きましょう。HadoopのソースはMapTaskが該当します。 mapタスクでは出力が書き込まれる循環メモリバッファがあります。これがMapOutputBufferに相当します。 このバッファの大きさがデフォルト100Mで80%書き込まれると
Hadoopはルイーダの酒場 - wyukawa's diary
昨日の深夜に某氏講師による「JavaエンジニアのためのHadoop入門」 の話題がネタになってましたが、僕はJavaエンジニアとしてキャリアを積んできてHadoopに入門しました。キリ HadoopはJavaで書かれているのでJavaエンジニアのキャリアのひとつとしていいと思いますけどね。 当初はHiveでデータ処理をしていましたがうまくHiveQLが書けず、DBエンジニアからHadooperになった人にSQLやデータモデルについて教えてもらったりしてました。 最近はインフラまわりをやるようになって、HeartBeatわかんねーーーーってなって、インフラエンジニアからHadooperになった人にいろいろ教えてもらったりしてました。 かようにHadoopを使う場合はいろいろなスキルが求められます。 まずインフラ構築、運用ならざっと下記のような作業が必要になるでしょう。 ハードウェア選定 ハー
Presto雑感 - wyukawa's diary
約1年間Prestoを運用していて気づいたことを書いてみようと思う。 Prestoが素晴らしいOSSプロダクトであることは間違いなくて、Hiveを使っている人はインストールして損は無いと思う。 メリットは下記の通り Hiveに比べるとオンメモリで処理するので高速でアドホッククエリに向いている 安定している。 ストレージを持たないアーキテクチャなのでアップデートが簡単 開発が活発。最近は以前に比べるとバージョンアップのスピードは落ちてきたがそれでも3週間に1回はバージョンアップしている。 バグ報告すると数日で修正されたバージョンがリリースされる。 開発がオープン。pull requestも受け付けておりコードレビューが丁寧 コードが奇麗でモダンJavaの代表だと勝手に思ってる 最近の変更を見る限りPrestoは安定性を重視しているように見え、これは僕のような管理者にとっては運用負荷が少なくな
ETLフレームワークとジョブ管理 - wyukawa's diary
Treasure Dataが面白い記事を書いていたのでこれに関連してETLフレームワークとジョブ管理について僕の経験、意見を書いてみようと思います。 Managing the Data Pipeline with Git + Luigi - Treasure Data Blog リンク先の記事を僕なりに要約すると、 データやそれを加工するスクリプトがちらばって管理が辛くなり、エラーが起きた時のリカバリが難しい。 ↓ それを解決するETLツールというのもあって、例えばGUIでフローチャートみたいなのを書いてデータの加工処理を行うことができる。 ↓ それだとバージョン管理できないし、ビッグデータにフィットしないケースもある。 ↓ そこでGitとLuigiを使ったData Pipelineが良いよ！ 紹介されているコードの例がこちら。 Hiveで集計してTDのテーブルにinsertするのがTas
HBase in Actionの4章に書かれているRow Keyの話 - wyukawa's diary
昨日のエントリでも少し触れましたが、HBase in Actionの4章ではTwitterのようなつぶやきサービスを作るときのRow Keyの設計について考察がされています。今回はそれについて少し書いてみます。 つぶやきするユーザはuseridを持つものとします。 ユーザAのuseridはuserid_Aとします。 ユーザBも同様とします。 フォロー関係を表すテーブルを下記のように設計したとします。 Row Keyfollows userid_A1:userid_B2:userid_C3:userid_D4:userid_E userid_B3:userid_D4:userid_E ユーザAがユーザB,C,D,Eをフォロー、ユーザBがユーザD,Eをフォローしているという状況です。 このfollowsテーブルは2行あってRow Keyはuserid_Aとuserid_Bです。Column F
Hadoopの異端さが面白い - wyukawa's diary
Hadoopはほんとブームです。バブルだと言っていい気がします。各種セミナーはすぐに埋まりますし、実際に聞きに行くと会場は満員です。 この分野は日本だとNTTデータが先頭をきったように見えます。 NTTデータ、Hadoopの商用ディストリビューション「CDH3」を販売開始 | 日経 xTECH（クロステック） またHadoop専業会社「ノーチラス・テクノロジー」というのもできました。 ウルシステムズとイーシー・ワンが経営統合、Hadoop専業会社を立ち上げ | 日経 xTECH（クロステック） しかし最近では富士通やIBMもHadoopソリューションを展開しておりレッドオーシャンな感じです。 富士通がビッグデータ分析・活用向けのPaaSサービス | 日経 xTECH（クロステック） 日本IBM、表計算のように分析できるHadoopソフト新版「BigInsights」 | 日経 xTECH（
Alertmanagerについて書いてみる - wyukawa's diary
Prometehus, Grafanaでモニタリングできるのはもうわかったので監視をどうするかというとAlertmanagerを使うことになります。 Prometehus本体に比べればAlertmanagerはまだ成熟してないと思うけど、使う価値は十分にあると個人的にあると思ってます。 その理由は2つあって、Prometehusで収集したメトリクスに対してアラートを設定できることと、アラート通知をまとめることができるということ。 1番目はまあわかりますよね。GangliaでモニタリングしてNagiosで監視とかだとツールが分かれているのでやりづらい。Gangliaでモニタリング結果に対してNagiosでアラート通知できないからね。 2番目が今日最も書きたかったこと。 監視はナイーブにやると、いったんアラートがなったときに対処しない限り延々とアラートがなり続けることになります。 例えばあるプ
SQLとRedisでのランキングの扱い方 - wyukawa's diary
今日はランキングの話を書いてみたいと思います。 サンプルデータは以下です。プレミアリーグの昨シーズン（2011-12シーズン）の得点データの一部です。 name score Kun Agüero 23 Mario Balotelli 13 Edin Džeko 14 Wayne Rooney 27 Robin van Persie 30 Emmanuel Adebayor 17 Demba Ba 16 Papiss Demba Cissé 13 Clint Dempsey 17 Grant Holt 15 Yakubu Ayegbeni 17 Steven Fletcher 12 ここで今シーズンの今のところの得点王であるDemba Baさんが昨シーズン得点ランキング何位だったかを知りたいとします。 危険なほどのスピードで動作するといわれるRedisの「ソート済みセット型」を使う場合は以下
Prometheusについて書いてみる - wyukawa's diary
現状のモニタリング、監視の仕組みにあまり満足していない部分があって、別のツールないかなあと思ってたらふとしたきっかけでPrometheusを知りました。これちょっと面白そうなんで書いときます。 https://prometheus.io 日本語の記事だと【入門】PrometheusでサーバやDockerコンテナのリソース監視 | Pocketstudio.jp log3が参考になります。 ちなみに現状の不満点は何かと言えば、下記の通りです。 モニタリングと監視が完全に分かれている HDD使用率などの汎用的なメトリクスをモニタリングするツール（例：Kurado）とミドルウェア、アプリケーション固有のメトリクスをモニタリングするツール(例：Growthforecast)が分かれている Prometheusはモニタリングと監視が統合されたツールで各種メトリクスも統一的に扱えます。ただし監視に関し
rebuildfm 35のAPIの話が面白かった - wyukawa's diary
Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima)の最後の方のAPIの話が面白かったのでそれについて書いてみる。 HTTP JSON APIにしろHiveServerが提供しているようなThrift APIにしろバックエンドにあるAPIサーバーにクライアントがアクセスして情報を取得してそれをもとに画面表示するっていうパターンは多いと思います。ここでいうクライアントってのは別にPCブラウザに限らなくてiPhoneやAndroidのようなスマートフォンだったりタブレットだったりいろんなケースがありえます。 iPhoneアプリでトップページを表示するのにAPIを10回叩く必要があるとかだと、レイテンシの問題もあるし開発の手間も増えますよね。そうじゃなくてiPhone専用のAPIみたいなのがあればそれ1回呼べば済むのでレイテンシの問題もなく
疎結合っていいよね - wyukawa's diary
今までの経験でいろんなレイヤーで依存性べったりで密結合なシステムを見てきてそれをちょっとだけ改善してきて思うところを書いてみる。 小さなシステムであれば多少は密結合でも何とかなるかもしれない、というか扱うファイル数、Gitプロジェクト数が1つでむしろやりやすいかもしれないけどシステムが大きくなるにだんだん拡張しにくくなる。かといって最初からあまりにも小さなシステムに分割するとそれはそれでやりづらい。完璧な答えは無いけれど僕が見てきたシステムの話をしよう。 その前にまず依存性といってもいろんなレイヤーがあると思うので、ここでは以下の３つの話をしよう。 アプリケーション内のコンポーネント間の依存性 システム間の依存性 バッチ内の各ジョブ間の依存性 1番目のアプリケーション内のコンポーネント間の依存性の例をあげるとMVCである。 SpringでWebアプリケーションを組んだ場合にModelがあっ
シェルスクリプトのユニットテスト - wyukawa's diary
ちょっとシェルスクリプトを書く機会があったので、ユニットテストできるかなーと思って調べてみたのでメモ。 こんなんがあった。 Google Code Archive - Long-term storage for Google Code Project Hosting. ダウンロードして解凍 $ wget http://shunit2.googlecode.com/files/shunit2-2.1.5.tgz $ tar zxvf shunit2-2.1.5.tgz サンプル実行 $ cd shunit2-2.1.5 $ ls Makefile doc lib src bin examples share $ cd examples/ $ ls equality_test.sh math.inc mkdir_test.sh lineno_test.sh math_test.sh party
大規模受託開発におけるCI - wyukawa's diary
そろそろ大規模ソフトウェア開発に一言いっておくか。デイリービルドとリグレッションテスト すばらしいスライドだ。ディリービルドとリグレッションテストを大規模パッケージ開発において適用したときの雰囲気が良く現れている。10年前の話のようだが今で言うCI（継続的インテグレーション）だよね。 僕も2年ぐらい前にパッケージ開発でCruiseControlを適用したことがある。junitのテストケースがあったがメンテされていなかったので使わなかった。結合レベルの自動テストもあったがこれもメンテされておらずそんなに使わなかった。スローテスト問題もあったしね。その代わり新たに結合レベルの自動テストを作っていってそれなりにうまくいったように思う。ただ実質一人プロジェクトだったこともあり途中から面倒になってやらなくなった。一人だと自分のローカルがマスターといってもいいので大規模に比べるとCIのメリットは薄い。
データ分析環境について書いてみる - wyukawa's diary
ログをHDFSに集めてHiveでETLや集計を行い集計結果をRDBMSに蓄積してレポーティングツールで可視化するというのは一般的な話だと思います。 データの流れでいうと App -> HDFS -> RDBMS -> レポーティングツール という感じです。 他にもPrestoのようなlow latencyなツールが加わることがあると思います。これらのツールをどう組み合わせてどうETLをまわしていくのがいいのかつらつらと最近考えております。 僕が経験したのはPythonでETL処理を書いて（内部的にはhiveserverにhiveクエリを投げたり、MySQLに集計結果を保存したり）、スケジューリングはcron, Azkabanで、集計結果はMySQLでレポーティングツールは自作でというものです。adhocなデータ分析はshib使います。まあこれでも十分運用回ってるんだけど、他にも良い方法が無
LL言語でのhot deployとJavaでのhot deploy - wyukawa's diary
JVM Operation Casual Talksで出てた話としてJavaでhot deployってどうしてんの？ってのがありました。 hot deployっていうのはアプリケーションコードを変更してもAPサーバーを再起動せずに反映する技術です。 この辺別に僕は全然知らないし答えを持っているわけではないですが、まあちょっと興味があったのでLL言語でのhot deployとJavaでhot deployを簡単に調べたのでメモっときます。 コードを変更してAPサーバーを再起動する場合、APサーバーが止まっているときにアクセスが行くと困るので、ロードバランサから外してAPサーバーを再起動してまた戻すみたいなことをやるのがオーソドックスな方法のようですが、hot deployだとそういったことをやる必要が無くなります。 Server::Starterから学ぶhot deployの仕組み - $s
ログのフォーマットやparse処理についてつらつら書いてみる。 - wyukawa's diary
ある程度構造化された半構造化ログのパターンとしては以下があると個人的には思ってる。 Apacheのcombined ログフォーマットや独自フォーマットなどである程度決まったフォーマットで保存されておりHuman Readableだけどログのparseに正規表現が必要なもの。 アプリで扱っているモデルをそのままMessagePack, Protocol Buffersなどの形式でシリアライズしたもの。Machine ReadableではあるけどHuman Readableではない。 モデルを分解してkey-value形式でJSONやLTSVなどの形式で保存されており(上記1ほどでは無いにしろ)Human Readableであり(上記2ほどでは無いにしろ)Machine Readableでありログのparseに正規表現が不要なもの 個人的な意見として正規表現を使うのは*.txtのような比較的単
ゆとりなJavaプログラマが読むといいかもしれないオープンソースソフトウェア - wyukawa's diary
Java出来ますって言ってるのにOpenJDKのコードをチェックアウトした事も無いようならモグリである可能性は高い。 一歩先行くJavaプログラマが読むべきオープンソースソフトウェア10選 - 設計と実装の狭間で。 OpenJDKのコードをチェックアウトした事も無いモグリです。こんにちは。 ま、それはともかくw 上記はいいエントリだし参考になります。ただまあモヒカンなのは事実だと思うのでゆとり路線でどういうオープンソースソフトウェアを読むと良いかもしれないって言うのを書いてみたいと思います。かもしれないって書いてるのがすでにゆとりですね。サーセンw JUnit すでに語り尽くされているとは思いますが、これは外せない。 僕自身は下記のJUnit3.8.2を読解する記事を読んでからJUnit3.8.2を読んでみましたね。 Java World (ジャバ・ワールド) 2005年 9月号 出版社/
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
