データ民主化の負の側面 - wyukawa's diary
データの活用が当然のことのようになってエンジニア以外でもSQL書いてデータ抽出するのが一般的になってきました。さらにデータサイエンティストの登場により高度な分析もされるようになってきて、顕在化してきたのがHadoopクラスタの無法地帯化とエンジニアの疲弊なんじゃないかと最近思っております。なおHadoopに限らずElasticsearchでも言えたりします。 これって要はユーザと管理者のバランスの問題で、Hadoopエンジニアを採用するのが難しいというのが背景にあります。 SQL書ける人はそれなりにいるけど、インフラ側の人材不足ですね。この状態でデータの民主化が進むとどうなるかというと、 クエリの数が増える -> なかにも重いクエリも結構ある -> 管理者がそれをチェックするのに疲れて放置するようになる -> クラスタの負荷が増えて障害も出るようになる -> クエリ実行にも時間かかるように
kafka-fluentd-consumerとfluencyとfluent-plugin-elasticsearchのメモリに関する話 - wyukawa's diary
うちの環境ではkafkaに入ってるログをkafka-fluentd-consumer 0.3.0でconsumeしたのちにfluent-plugin-elasticsearch 1.9.0経由でElasticsearchになげるということをしています。 fluent-plugin-elasticsearchは8プロセス動いていて各プロセスがメモリを5〜8GB使っている状態でした。マシンのメモリは64GBだったので割とメモリがかつかつな状態だったせいか、以下のようなログをはいてkafka-fluentd-consumerが落ちるという状況が発生していました。 failed; error='Cannot allocate memory' (errno=12) # # Native memory allocation (mmap) failed to map 555745280 bytes fo
Hadoop Summit Tokyo 2016に行ってきた - wyukawa's diary
http://hadoopsummit.org/tokyo チケット代が約4万円で高いと噂になったHadoop Summit Tokyo 2016に行ってきました。 ただ海外ではこのぐらいの値段は普通らしく、むしろ日本が異常に安すぎるという。 そのしわ寄せがイベント運営者にいってしまっているのが現状なので、世界基準を知る良い機会だったかも。 僕は2日間とも最初から参加しました。 基調講演を除くと聞いたセッションは下記の通り。 10/26 Real-time Analytics in Financial: Use Case, Architecture and Challenges Path to 400M Members: LinkedIn’s Data Powered Journey Hadoop 3.0 in a Nutshell Apache Eagle - Monitor Hadoo
Hortonworksのイベントに行ってきた - wyukawa's diary
Hadoop and the Modern Data Architecture に行ってきました。 立派なホテルで良いイベントでした。ありがとうございました。＞ Hortonworksのみなさま セッションや会場にいた人との会話について少し書きます。 まず僕が使っているAmbariに関して発表がありました。 それによると、Hueみたいなクエリをsubmitする機能が入る模様。どうもHadoopクラスタへのアクセスをすべてAmbari経由にしたいようだ。うーん、それはどうなんだろ。。。Prestoあるし。個人的にはそれよりもっとクラスタ管理に注力してほしいと思ったり。。。例えばエラー通知をメールじゃなくてHipChatとかSlackにとばせるようにするとか。 Ambariで使っているNagios, Gangilaはdeprecatedになり、メトリクスをHBaseにためてPhenioxでクエ
How Google WorksとHow GitHub Works - wyukawa's diary
rebuildfm 67にNaoya Itoさんが出るというので、もしかしたらHow Google Worksの話が出るかと思ったらでなくて残念。でも別の機会に話してくれそうなのでそれを楽しみに待ちます。 How Google Works 作者: エリック・シュミット,ジョナサン・ローゼンバーグ,アラン・イーグル,ラリー・ペイジ出版社/メーカー: 日本経済新聞出版社発売日: 2014/10/17メディア: Kindle版この商品を含むブログ (7件) を見る この本ですが、僕はちょっと前に読了しました。注釈が20%を占めていて、この手の本にありがちなんだけどカタカナが多い。 で、内容的には、、、正直に言ってしまうと期待していたほど面白くなかった。 一番面白かった部分はAPMというあるポジションに登用したかったけどコンピュータ科学の学位を持ってなかったためそれが出来なかった優秀な社員がいた。
CGI、マルチスレッド、シングルスレッド+イベント駆動そしてNode.js - wyukawa's diary
僕はNode.jsとはそんなに関わりはなくてshibを使っているのが唯一の接点なんだけど、http://mozaic.fm/post/99334017903/10-node-jsを聞いてたら大変に面白かったので面白かった部分について書く。 このpodcastは全部で2時間以上あって全部聞くのはなかなか辛いんだけどw 僕が面白いと思った部分はCGI -> マルチスレッド -> シングルスレッド+イベント駆動 という技術の歴史的な経緯のあたりです。 インターネットが出た当初は同時アクセス数も少ないのでCGIが一般的でリクエストがくるたびにプロセスが起動してさばくというモデルで全然問題がなかった。 それがECサイトとか出てきて同時アクセス数が増えてくるとCGIモデルが辛くなってきたので、リクエストをスレッドでさばくマルチスレッドモデルが登場した。 余談だが僕が2002年に社会人になってServl
ログ分析環境を少しづつ作ってる - wyukawa's diary
まだ本格的な運用は始まっていないけどログ分析環境を少しづつ作ってるのでメモっておく。 ETL処理は既存資産の活用を考慮してPython 2.7でやっています。 hiveserver2との接続はpythonからhiveserver2につなごうとしていろいろハマったのでメモっておく - wyukawa’s blogに書いた通りだいぶ苦労したけど独自にpatchあてて対応した。 sqoop imortもやりつつある。最初はsqoop2を使おうかなと思ったけどhiveとの連携がまだみたいなのと、既存資産の活用もあって古いsqoopのまま処理を進めている。 Hiveからselectして結果をMySQLへinsertする部分はMySQL-Python使っています。この辺も既存資産があるからですね。 Python 3は使っていないので下記にあるような事情は今回特に関係ないです。とはいえPython 3も
RDBMSのコネクションプーリングとかその辺の話 - wyukawa's diary
データベース技術の羅針盤 from Yoshinori Matsunobu これは素晴らしい資料で後半のキャリアの話とか面白いんだけど、今回書くのはp6,p8に書かれていた下記の話です。 PosgreSQLは接続がプロセスベースなのでLL言語との相性がよくない Pgpool(これはプロキシサーバー的に使うらしい)などのコネクションプールと併用することが多い MySQLは接続がスレッドベースなのでコネクションプーリングが使いづらいLL言語環境では魅力 なんでLL言語だとコネクションプーリングが使いづらいのかわからずつぶやいたらリプライもらってついでにちょっと前に話題になったRDBMSでコネクションプールが必要な理由、わからない。 - Togetterや7年前のブログエントリであるコネクションプーリングの話 - naoyaのはてなダイアリーを読み返してみて思ったことを書いてみる。全然まとまって
ログ解析における統計値の妥当性 - wyukawa's diary
ログ解析における統計値の妥当性をどうやって担保するのかは難しい問題だと思っていてぶっちゃけ最終的にはオレを信じろ、でも間違ってたらゴメンの世界な気がする。 社内で閉じていて外に出ない統計値ならまあいいんだけど、世の中そんな統計値ばかりではない。 例えばWebサービスを展開していてそこに広告を出稿してもらって売り上げをたてたいとする。広告を出す方としてはそのサイトにどれぐらいPV/UUがあるか知りたいと思うのは当然ですよね。 広告を出したら出したでインプレッション数が知りたいとかあるかもしれない。 このような統計値はログを集めて集計することによって求めるわけなんだけど、数値が正しいかどうかをどうチェックするかというのは難しい問題ですよね。 本来ならいろんなバリエーションのテストデータを作ってテストするんでしょうけど、テストデータ作るの大変だし、このビッグデータ時代？にはどんなデータが来るかわ
ログのフォーマットや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のような比較的単
HDD障害時のHadoop datanodeの対応について - wyukawa's diary
ここ最近毎日のようにHDD障害が発生しててお祓いに行った方が良いのかなと思い始めているwyukawaです。こんばんは。 HadoopのdatanodeにHDD障害が発生した場合、普通はdecommissionすると思います。 ただdecommissionってやたら時間かかるんですよね。まる１日とかね。まあデータ量が多いからだとは思います。例えばTBいかないならdecommissionしてもそんなに時間かからないのかなと思います。完全に想像ですが。 なので僕は下記のようにdatanodeを止めちゃってます。 hadoop-daemon.sh stop datanodeこの辺は以前下記にも書きました。 dfs.datanode.failed.volumes.toleratedとdatanodeのdecommission - wyukawa’s blog こうすると一時期にレプリカ数が足りないブ
とりあえずStormをローカルモードで動かしてみた。 - wyukawa's diary
身近なところでStormがちょっとブームなので話題についていくためにも軽く素振りしたいと思います。 日本語の資料でざっくり中身をつかむには下記がいいんじゃないでしょうか。 Twitterのリアルタイム分散処理システム「Storm」入門 from AdvancedTechNight StormにはNimbus, Supervisor, Worker, Spout, Bolt, Topologyと用語が出てきますが、 ざっくりHadoop用語に当てはめるとそれぞれJobTracker, TaskTracker, task, map, reduce, jobって感じでしょうか。 上記スライド資料もそうですが、日本だとAcroquest TechnologyさんがいろいろとStormの調査資料をアウトプットしてくれているので見てみるといいんじゃないでしょうか。下記ブログのStorm関連記事もそうで
HBaseのデータ書き込みフロー Part 2 - wyukawa's diary
以前HBaseのデータ書き込みフローについて下記ブログを書きました。 HBaseのデータ書き込みフロー - wyukawa’s blog どういう内容かというとHBaseでデータの書き込みを行う場合は、メモリ上のMemStoreに書き込むとともにディスク上のHLogにも書いて耐障害性を高め、最終的にはMemStoreがディスク上のHFileにフラッシュされるという話です。HFileの数が多くなってきた場合はコンパクションが実行されて複数のHFileがマージされます。 本エントリではHBaseのデータ書き込みについてもっと掘り下げてみたいと思います。 馬本でいうと「8.3 ライトアヘッドログ」辺りの話です。HBaseでいうライトアヘッドログ(Write Ahead Log。WALと略されることもあり)はHLogのことです。 Apache HBase Write Path - Cloudera
HBaseのテーブルがenableでもなくdisableでもなくなった場合の対応方法 - wyukawa's diary
どうもこんばんはwyukawaです。 最近HBaseのテーブルがenableでもなくdisableでもなくまたdropもできないという状態になり、詰んだアカウントがこちらになります。 再現性はたぶん無くて該当のJIRAはたぶんこれ。未解決ですね、はい。 https://issues.apache.org/jira/browse/HBASE-6469 解決策はHMasterの再起動（hbase-daemon.sh restart master）です。 再起動したらenableかdisableのどっちかになります。 1回やってうまくいかなかったら、はりきって再起動しましょう。ここがポイントです、キリ。 僕は最初の再起動ではうまくいきませんでしが、はりきってなかったからですね、たぶん。 2012/11/23追記 http://comments.gmane.org/gmane.comp.java.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
