データ民主化の負の側面 - wyukawa's diary
データの活用が当然のことのようになってエンジニア以外でもSQL書いてデータ抽出するのが一般的になってきました。さらにデータサイエンティストの登場により高度な分析もされるようになってきて、顕在化してきたのがHadoopクラスタの無法地帯化とエンジニアの疲弊なんじゃないかと最近思っております。なおHadoopに限らずElasticsearchでも言えたりします。 これって要はユーザと管理者のバランスの問題で、Hadoopエンジニアを採用するのが難しいというのが背景にあります。 SQL書ける人はそれなりにいるけど、インフラ側の人材不足ですね。この状態でデータの民主化が進むとどうなるかというと、 クエリの数が増える -> なかにも重いクエリも結構ある -> 管理者がそれをチェックするのに疲れて放置するようになる -> クラスタの負荷が増えて障害も出るようになる -> クエリ実行にも時間かかるように
Prometheusのストレージ - wyukawa's diary
Prometheusのストレージ周りに関してちょっと調べたのでメモっておく。 間違っているところや補足すべきものがあれば教えてもらえると嬉しいです。 公式ドキュメントはこちら https://prometheus.io/docs/operating/storage 他に参考になりそうな資料としてはこの辺 Prometheus Storage from Fabian Reinartz https://promcon.io/2016-berlin/talks/the-prometheus-time-series-database 簡単に説明するとchunkという1024bytesの固定長データをもとに処理しておりインデックスはLevelDBに保持している。 メモリにデータを保持して高速化をはかりつつ予期せぬ停止によるデータロストを最小限にするため定期的にディスクに書き出している。HBaseのよ
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
Prometheus Casual Talks #1を開催しました - wyukawa's diary
Prometheus Casual Talks #1 - connpass 発表者、参加者の皆様おつかれさまでした。ありがとうございました。 Prometheusは日本ではあんまり使われていないと思うのでそんなに人集まらないと思ってたんですが、connpassに公開したその日にすぐ定員はうまるぐらい人気でした。 ただ97人の申し込みに対して実際に来たのは66人で、入退室の面倒くささを考えると今後はdotsを使うのが正しい気がしてきました。 参加者がどういうモニタリング、監視ソフトを使っているのか興味があったので、 事前に任意で「現在業務で使っているモニタリング、監視ソフトは何ですか？」という複数回答可のアンケートを実施したのですがその結果が下記です。 Zabbix 66 Nagios 48 Cloudwatch 34 Kibana 33 Elasticsearch 28 Cacti 26
OSSプロダクトにissue登録する - wyukawa's diary
僕は今見ている社内のログ分析基盤に数多くのOSSプロダクトを使っています。 具体的に言うと、Fluentdでログ収集してHadoopに書き込んでAzkaban経由でHiveバッチを動かしてデータを加工してPresto, Prestogres経由でみたりしています。 また最近はKafkaやElasticsearch, Kibanaといったものも使っていますし、Prometheus, Grafanaを使ってモニタリングするようになっています。 このように数多くのOSSプロダクトを使っている理由は、部品一つ一つを自前実装していたら時間がいくらあっても足りないからです。OSSプロダクトを活用することにより、レバレッジを効かせることができます。 そしてまたOSS界隈の進化のスピードが速いので、仮に自前実装したとしてもすぐに陳腐化してしまう危険性がある。であれば最初からOSSプロダクトを使って巨人の肩
fluentdのCPU使用率をPrometheus, Grafanaでモニタリングしたい - wyukawa's diary
fluentdはRubyで実装されていることもあり複数CPUを使えないので、トラフィックが増えてきた場合などはポートを分けて複数プロセスで起動することが一般的です。 なのでマシンごとのCPU使用率を見てもfluentdの状況がどうなのか判断することは難しいです。 ちなみにJavaだとそういうことをする必要がないしJMXもあるのでfluentdが特殊なミドルウェアなのかなという気がします。 fluentd以外でユースケースを思いつかない。 そこでfluentdのプロセスごとのCPU使用率をモニタリングしたいわけですが、どうやるかというのが今回のテーマです。 やっかいなことにfluentdはsupervisorとworkerの2プロセスあってモニタリングしたいのはworkerです。まずはworkerのpidを求めないといけないわけですが、その辺の話は省略します。 process_nameがある
Azkabanについて書く - wyukawa's diary
ちまたではAirflow(https://github.com/airbnb/airflow)が話題のようですが、Azkaban(http://azkaban.github.io/)を使っている身としてはやはりAzkabanについて書かねばならないと思ったので書きます。別にAzkabanを使ってほしいという意味ではないです。むしろAirflowの運用エントリとか読みたいです。 AzkabanはJavaで実装されたジョブ管理ツールです。開発が若干停滞気味ではありますが、細々と進んでいます。 特徴としては、下記の通りです。 インストールが簡単（バイナリは古いものしか無いのでソースビルドが必要だがgradlewなので簡単） ジョブの依存関係をグラフィカルに見る事ができる。 APIがある ジョブが失敗した時でもボタン一つで失敗したジョブだけ再実行できる TTLがあるけどジョブの実行ログをブラウザか
2種類のログ解析基盤 - wyukawa's diary
僕は仕事では2種類のログ解析基盤を見ています。 1つ目はどちらかというとエンジニアよりの解析基盤でサービス側のエンジニアがShib, ShibUIを通して好きにクエリを投げることができます。ただしtableをcreateしたりdropしたりinsertしたりはできません。selectのみです。データの更新作業は別途cronのhive batchで行います。データはFluentd経由で各サービスのサーバーから収集します。こっちのシステムは古くからあって僕は引き継いだだけなので見ているとはいってもそんなにやることは無いですし、語れることも少ないです。 2つ目は約1年前に僕が一から構築したシステムでプランナーよりのシステムになってます。僕のチーム内のエンジニアだけがrawデータを触ったり更新したりすることができて、プランナーはレポートを通して加工されたデータを見る形になります。なので1つ目のシス
現在のログ解析基盤 - wyukawa's diary
1月のPresto Meetupでログ解析基盤について少し話してから3ヶ月弱経ったんだけどその時から若干変わったのでメモっておく。 以前はこんな感じでした。 Presto in my_use_case from wyukawa Prestoは今は0.100を使っていて特に問題は発生してないです。 Cognos周りはだいぶ良くなって Cognos 10.2.1 + Prestogres 0.4.8 + Prestogres ODBC Driver から Cognos 10.2.2 + Prestogres 0.6.7 + protocolVersion=2だけ使用するようにpatchしたPostgreSQL JDBC Driver に変えました。 patchって言っても1行コメントしただけ。ここ。 https://github.com/pgjdbc/pgjdbc/blob/REL9_3_11
rebuildfm 53のRubyのGCとスレッドの話が面白かった - wyukawa's diary
Rebuild: 53: Less Code Is Better Code (Matz) rebuildfm 53のRubyのGCとスレッドの話が面白かったので書いてみる。 RubyのGCというとクックパッドがユーザのリクエスト中にGCを止めるっていう話があったぐらいなので改善が望まれる分野なんだと思います。 例えば GC を止める・Ruby ウェブアプリケーションの高速化 - 2nd life Rubyは2.1になって世代別GCが導入されるようになりました。その辺は下記に詳しいです。 WEB+DB PRESS Vol.79 作者: 成瀬ゆい,そらは(福森匠大),西磨翁,小川航佑,佐藤新悟,塚越啓介,藤原亮,堀哲也,田村孝文,桑野章弘,松浦隼人,中村俊之,田中哲,福永亘,杉山仁則,伊藤直也,登尾徳誠,近藤宇智朗,若原祥正,松木雅幸,奥野幹也,後藤秀宣,羽二生厚美,笹田耕一,平河正博,東舘智
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
JVM Operation Casual Talksに参加して思ったことをつらつらと書く - wyukawa's diary
JVM Operation Casual Talks : ATND 内容は参加者のブログエントリとtogetterが下記にありますのでそちらを見るとよいと思います。 JVM Operation Casual Talksに参加しました #jvmcasual - @johtaniの日記 2nd 「JVM Operation Casual Talks」発表資料のリンクをまとめてみる #jvmcasual - 元RX-7乗りの適当な日々 JVM Operation Casual Talks に参加してきました。 - susumuis Info JVM Operation Casual Talks #jvmcasual - Togetter で、このエントリでは発表を聞いて思ったことをつらつらと書きます。 ちなみに僕はJava歴10年以上なのですが、JVM運用経験はほとんどありません。最近はちょっと
RDBMSのコネクションプーリングとかその辺の話 - wyukawa's diary
データベース技術の羅針盤 from Yoshinori Matsunobu これは素晴らしい資料で後半のキャリアの話とか面白いんだけど、今回書くのはp6,p8に書かれていた下記の話です。 PosgreSQLは接続がプロセスベースなのでLL言語との相性がよくない Pgpool(これはプロキシサーバー的に使うらしい)などのコネクションプールと併用することが多い MySQLは接続がスレッドベースなのでコネクションプーリングが使いづらいLL言語環境では魅力 なんでLL言語だとコネクションプーリングが使いづらいのかわからずつぶやいたらリプライもらってついでにちょっと前に話題になったRDBMSでコネクションプールが必要な理由、わからない。 - Togetterや7年前のブログエントリであるコネクションプーリングの話 - naoyaのはてなダイアリーを読み返してみて思ったことを書いてみる。全然まとまって
chefとかvagrantとかfabricとか - wyukawa's diary
chefを使いそうなのでその辺素振りしてみる。 chefの前にまずvagrantとvirtualboxをそれぞれダウンロードしてインストール Boxファイルの追加 $ vagrant box add centos63 https://dl.dropbox.com/u/7225008/Vagrant/CentOS-6.3-x86_64-minimal.box $ vagrant init centos63 $ vagrant box list centos63 (virtualbox) saharaプラグインの追加 $ vagrant plugin install sahara $ vagrant plugin list sahara (0.0.16) sandbox on $ vagrant sandbox on 0%...10%...20%...30%...40%...50%...60%
HBaseについての情報源 - wyukawa's diary
クレジットカード現金化詐欺【業界人が教える口コミ情報】 の12/2分として書きます。 内容は薄いというかHBaseの情報源についてのまとめエントリです。 ■本家 Top http://hbase.apache.org/ JIRA https://issues.apache.org/jira/browse/HBASE Subversion http://svn.apache.org/repos/asf/hbase/ ■書籍 HBase 作者: Lars George,Sky株式会社玉川竜司出版社/メーカー: オライリージャパン発売日: 2012/07/25メディア: 大型本購入: 1人 クリック: 9回この商品を含むブログ (5件) を見る 通称馬本。なにはさておきまずはこれ。 序盤はJava APIの解説が多いが8章がアーキテクチャの話でここがメインだと思う。 HBase in Actio
HadoopのMapReduceジョブのチューニングに関する資料があったのでめもっとく - wyukawa's diary
Hadoop Summit 2012でClouderaの人が発表した資料を見つけたのではっておく。 Hadoop Summit 2012 | Optimizing MapReduce Job Performance View more PowerPoint from Cloudera, Inc. HadoopのMapReduceジョブのチューニングに関するもので、内容的にはHadoop徹底入門の10章の「性能向上のためのチューニング」と若干かぶっているが参考になります。 spillとかのシャッフルフェーズをどうチューニングするかについて詳しく書かれていて、record fullってログに出てたらメタデータがspillしてるからよくないよねみたいなことが書かれてます。 徹底入門だと10.2.2の「Map処理でのフレームワークのチューニング」に書かれていますね。ていうかio.sort.reco
fluentdを試してみた - wyukawa's diary
クレジットカード現金化詐欺【業界人が教える口コミ情報】 僕は行ってないんですがTwitter、Ustream、スライド、ブログなどを見る限りだいぶ盛り上がったようですねー。僕自身が仕事で使う予定は今のところ無いんですがログ解析関連の仕事をしていることもあるので素振りしてみようと思います。 環境はVirtualBox上のCenOS 5.7(x86_64)を使いました。 fluentdはRuby 1.9上で動くんですがCentOS 5.7に入っているのはRuby 1.8.5です。Ruby 1.9のインストールから始めるとはまりそうなのでyumでインストールできるtd-agentを使います。td-agentはfluentdの安定版パッケージという位置付けのようです。 試したのは下記３つです。 fluent-catでログを送る Apacheのアクセスログを収集 ApacheのアクセスログをMong
Puppetについての素晴らしい資料があったのでめもっとく - wyukawa's diary
以前ミドルウェアの設定ファイルのバージョン管理について書きました。 ミドルウェアの設定ファイルをどのようにバージョン管理すべきか - wyukawa’s blog で、最近Puppetについての素晴らしい資料を見つけたのではっときます。 Puppetのススメ View more presentations from Gosuke Miyashita こちらも参考になりそうです。 オープンソースなシステム自動管理ツール Puppet：連載｜gihyo.jp … 技術評論社 このスライドではPuppetのマニフェストをSVNでバージョン管理している例がのっています。 ChefのRecipeをバージョン管理する場合でも同様でしょう。 設定ファイルをバージョン管理してシンボリックリンク活用するよりもこっちのほうがいいかも。 あとスライドに出てくるカスタムスクリプト自動化の問題もありがちだなーって思
Hadoopのトラブルシューティングに関する資料があったのでめもっとく - wyukawa's diary
Hadoop World 2011でClouderaの人が発表した資料を見つけたのではっておく。 Hadoop Troubleshooting 101 - Kate Ting - Cloudera View more presentations from Cloudera, Inc. Clouderaのサポートチームの極意が詰め込まれているようだ。 内容的にはHadoop徹底入門の10章の「性能向上のためのチューニング」と若干かぶっているが参考になります。 io.sort.mb < mapred.child.java.opts とすることとか（ていうかmapred.child.java.optsを増やすことはあるかもしれないがio.sort.mbっていじるもんなのかな）、プロセス数やファイルディスクリプタいじれとか、map出力のスレッドいじれとか、Jetty 6.1.26は使うなとか、盛り
Hadoop MapReduce デザインパターンの3章まで読んでみた。 - wyukawa's diary
Hadoop MapReduce デザインパターン ―MapReduceによる大規模テキストデータ処理 作者: Jimmy Lin,Chris Dyer,神林飛志,野村直之,玉川竜司出版社/メーカー: オライリージャパン発売日: 2011/10/01メディア: 大型本購入: 4人 クリック: 254回この商品を含むブログ (16件) を見る いわゆる子象本。小象でも小僧でも無いよw 監修者のブログの Hadoop MapReduce デザインパターン - 急がば回れ、選ぶなら近道 で詳しく紹介されています。 原著はこちら Data-Intensive Text Processing With MapReduce (Synthesis Lectures on Human Language Technologies) また原文のPDFをこちらから入手できます。 Jimmy Lin » Data
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
