Presto雑感 - wyukawa's diary
約1年間Prestoを運用していて気づいたことを書いてみようと思う。 Prestoが素晴らしいOSSプロダクトであることは間違いなくて、Hiveを使っている人はインストールして損は無いと思う。 メリットは下記の通り Hiveに比べるとオンメモリで処理するので高速でアドホッククエリに向いている 安定している。 ストレージを持たないアーキテクチャなのでアップデートが簡単 開発が活発。最近は以前に比べるとバージョンアップのスピードは落ちてきたがそれでも3週間に1回はバージョンアップしている。 バグ報告すると数日で修正されたバージョンがリリースされる。 開発がオープン。pull requestも受け付けておりコードレビューが丁寧 コードが奇麗でモダンJavaの代表だと勝手に思ってる 最近の変更を見る限りPrestoは安定性を重視しているように見え、これは僕のような管理者にとっては運用負荷が少なくな
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
PrestoとかAnsibleとかその辺の話を軽く書いてみる - wyukawa's diary
今日はPrestoとかAnsibleとかその辺の話を軽く書いてみようと思います。突っ込んだ話が出来るわけではないのであしからず。 僕のところの環境ではPrestoを使っていて、PrestoはDataNodeやNodeManagerと同居してます。主なユースケースはアドホッククエリの実行です。とあるレポートを作りたいってなったときにデータの中身をチェックするのに使います。従来だとこれがHiveだったのですが、HiveだとMapReduceになって遅いので（ローカルモードで済む場合もあるけど）、その点Prestoは早くていいです。ただこれは僕の環境がスモールデータだからっていうのもあって、圧縮済み数百GBのデータに対してselectかけるとかだとPrestoといえども遅くなると思います。あとなにげに良いのがPresto CLI経由だとカラム名が表示されるのでどのデータがどのカラムなのかすぐ分か
hiveserverのモニタリング - wyukawa's diary
hiveserver(not hiveserver2)の調子が悪くOutOfMemoryが発生することもあるのでメモリを増やしつつモニタリングも強化してみている。 メモリを増やしてかつGCログを取るためにhive-env.shに下記を追加。この例ではhiveserverのヒープを2GBにしている。 if [ "$SERVICE" = "hiveserver" ]; then export HADOOP_HEAPSIZE=2048 export HIVE_OPTS="-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps ..." fiそしてhadoop-env.shでHIVE_OPTSを受けとるようにする。 export HADOOP_OPTS="${HIVE_OPTS}"なんでhadoop-env.shをいじる必要があるかっているとh
HDPとAmbariを試している - wyukawa's diary
今度新規にHadoopクラスタを構築する予定なのですが、HortonworksのHDPおよびAmbariをちょっと試しています。 僕は今までApacheのコミュニティ版Hadoop 1系を1年ほど運用していたので、今どきのHadoop事情にうとかったんですがいろいろ変わってるんですね。 NameNode HAとか名前だけは知っていたのですが、実態がどんなもんだかよくわかってなかったし。 今の時点でHadoopのディストリビューションを選択するとしたら、Apacheのコミュニティ版, CDH, HDPのいづれか３択で、どれを選ぶにしてもYARNに突入せざるをえないでしょう。 例えばHiveしか使わないにしても。 で、まあ、とりあえずHDPは新しいし触ったことある人も少なそうなのでちょっと試しています。 yumでひとつづつインストールしていってもいいのですが、AmbariというCloudera
Hadoopのバランサー実行中にdfs.datanode.balance.bandwidthPerSecを変える - wyukawa's diary
Hadoopにはバランサーというものがあります。象本10.1.4.4 バランサー参照。 Hadoopでは時間の経過とともにDataNode間でのブロックの分散度合いのバランスが悪くなっていきます。これを是正するためのプログラムがバランサーで実態はstart-balancer.shというシェルです。 start-balancer.shは利用度の高すぎるDataNodeから利用度の低すぎるDataNodeへブロックを移動するプログラムです。 -threshold引数はバランス度合いを決めるパーセンテージでデフォルトは10です。各DataNodeの利用率とクラスタの利用率の差を意味しています。 start-balancer.shをcronでたたくという運用もあるようですが、僕が見た範囲だと何もしなくても10%以内の隔たりに収まる気がします。 ただ今回僕が遭遇したのはディスク使用率が高いという警告
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 こうすると一時期にレプリカ数が足りないブ
dfs.datanode.failed.volumes.toleratedとdatanodeのdecommission - wyukawa's diary
HDFSにはdfs.datanode.failed.volumes.toleratedという設定項目があります。defaultは0。 <property> <name>dfs.datanode.failed.volumes.tolerated</name> <value>0</value> <description>The number of volumes that are allowed to fail before a datanode stops offering service. By default any volume failure will cause a datanode to shutdown. </description> </property>内容は下記に詳しいです。 By default, the failure of a single dfs.data.dir
RDBMSのコネクションプーリングとかその辺の話 - wyukawa's diary
データベース技術の羅針盤 from Yoshinori Matsunobu これは素晴らしい資料で後半のキャリアの話とか面白いんだけど、今回書くのはp6,p8に書かれていた下記の話です。 PosgreSQLは接続がプロセスベースなのでLL言語との相性がよくない Pgpool(これはプロキシサーバー的に使うらしい)などのコネクションプールと併用することが多い MySQLは接続がスレッドベースなのでコネクションプーリングが使いづらいLL言語環境では魅力 なんでLL言語だとコネクションプーリングが使いづらいのかわからずつぶやいたらリプライもらってついでにちょっと前に話題になったRDBMSでコネクションプールが必要な理由、わからない。 - Togetterや7年前のブログエントリであるコネクションプーリングの話 - naoyaのはてなダイアリーを読み返してみて思ったことを書いてみる。全然まとまって
HiveとHBaseの連携は難しい - wyukawa's diary
Hive 0.11.0にバージョンアップしてmultiple insertに関わるバグである[HIVE-3699] Multiple insert overwrite into multiple tables query stores same results in all tables - ASF JIRAを心配しなくて良くなったけど代わりにネストしたgroup byに関わるバグである[HIVE-5237] Incorrect group-by aggregation in 0.11.0 - ASF JIRAを踏んだwyukawaです、こんにちは。ユニークユーザとか求める時にネストしたgroup byが出てくる可能性はあるのですがcount(distinct ...)とか使って回避しました。 で、今回書くのはそういう話じゃなくてHiveとHBaseとの連携に関してです。結論から言うと結構
SQL, PigのCUBE - wyukawa's diary
SQLで小計や総合計を求める時にGROUP BYを利用することが多いと思いますがいろんな軸で集計したい場合にROLLUP, CUBE, GROUPING SETSを使うことができるようです。 詳しくはこちら参照 http://homepage2.nifty.com/sak/w_sak3/doc/sysbrd/sq_kj04_4.htm ROLLUP, CUBE, GROUPING SETSを使うことができますと断定していないのは僕が試してないからです（汗 なぜ試していないかというとこれらの機能を利用できるのがOracle, SQL Server, DB2だからです。Oracle XEをダウンロードしようかと思いましたけどユーザ登録に心が折れましたw ちなみにMySQLではROLLUPのみサポートしているらしいです。 今回は考えられる全ての組み合わせで集計するCUBEについて書いてみたいと思
Hiveのjoinの最適化 - wyukawa's diary
元ネタはこちら Join Optimization in Apache Hive Hiveは0.7からjoinが最適化されています。どのように最適化されたのか上記の資料をひもといてみます。 いままでのjoin いままでのjoinはいわゆるソートマージジョインです。 mapフェーズでテーブルのデータを読み込んでjoinキー、joinバリューを出力し、shuffleフェーズでソート、reduceフェーズでjoinという流れです。 この場合shuffleフェーズのソート処理がボトルネックとなっていました。 そこで登場するのがMap Joinです。 joinの片方のテーブルのサイズがメモリに収まるほど小さいのであれば、mapperのメモリに読み込んでmapフェーズだけでjoinします。 こんな感じの構文で書きます。 select /*+mapjoin(a)*/ * from src1 x join
スタースキーマと列指向データベース - wyukawa's diary
Webエンジニアのための データベース技術[実践]入門 (Software Design plus) 作者: 松信嘉範出版社/メーカー: 技術評論社発売日: 2012/03/09メディア: 単行本（ソフトカバー）購入: 20人 クリック: 486回この商品を含むブログを見る 僕はWebエンジニアではないけれども上記の本を読み、とりわけ11-3 分析系処理と列指向データベースを興味深く読みました。 そこで分析用途のデータを作る場合にどうやるのがいいのか調べてみたのでメモっておきます。 「おむつを買った人はビールを買う傾向がある」みたいな分析を行うためには時系列に大量の業務データを蓄積してDWHを作ります。 その際にスタースキーマと呼ばれる形式でテーブル設計をします。 中心のファクトテーブルは分析のキー（例：商品ID、顧客ID）と分析対象の数値データ（例：販売数量、販売金額）を持ちます。 この
HBaseのRow Keyの設計についてのメモ - wyukawa's diary
Facebook Messageで使われたり、LINEのストレージで使われたり、と事例も多く出てきているHBase（Bは大文字。これ重要）ですが、個人的に少し興味も湧いてきたのでちょっと調べてます。HBaseはLog-Structured Merge-tree (LSM-tree)というアーキテクチャを使っており大量データの書き込みに最適化されています。なので大量の書き込みがあり読み込みは直近のもののみというメッセージ系アプリに向いているんだと思います。 そういえば半額に釣られてManning | HBase in Actionも買ってしまいました。 この本の4章のRow Keyの設計についての話があってそれがちょっと面白かったので関連してRow Keyについて少し書いてみます。 まずHBaseはカラム指向のデータベースと呼ばれますがデータモデルは多次元ソートマップです。 図解すると下記の
LinuxのTCPチューニング - wyukawa's diary
WEB系エンジニア？はLinuxのカーネルパラメータをチューニングして性能を上げたりしているようですが、その辺に興味があったのでメモっときます。正しいかどうかの確証は全くありません。あしからず。ちなみに僕自身はこの手のパフォーマンスチューニングは経験無しです。 カーネルパラメータといってもいじる項目はいろいろあるようでDB周りだと共有メモリのサイズをいじったりするんだと思いますが、今回はTCPの話です。 なおこのエントリを書くにあたってプロのための Linuxシステム構築・運用技術 (Software Design plus)の4章やLinuxカーネル2.6解読室の24章を参考にしました。 TCPチューニング関連でググってみると参考になりそうなのはこの辺。 見落としがちなLinuxのWEBチューニング | Act as Professional Hadoop徹底入門の10章でもtcp_fi
Hiveのベストプラクティス(かもしれないこと)をめもっておく - wyukawa's diary
Hiveの現場に来て4か月経ち回りのやり方を観察したり、他の事例を調べたりしているうちにHiveを使用する際のパターンというかベストプラクティスが見えてきた気がするので書いてみるよ。 ユースケースはログ解析です。 1. ファイルフォーマットと圧縮 ログは圧縮率高いので圧縮すべし。でもスプリット可能であるためにはってことでSequenceFileでブロック圧縮は確定。 圧縮コーデックは圧縮率を考えてgzip。 ちなみに圧縮率は bzip2>gzip>LZO でスピードは LZO>gzip>bzip2 だ。bzipはスプリット可能で圧縮率も高いんだけどHadoop 0.20系ではまだ使えなかったと思う。Hadoop 0.20系でも使えるらしいですが遅くて使い物にならないようです。 最近はsnappyなんてのも出ててCDH3 Update 1で使えるようになりましたね。 snappyは圧縮率はL
モダン（かもしれない）なEclipse環境(Java)の構築方法 - wyukawa's diary
「モダンなEclipse環境の構築方法」とかね。 2010-07-21 - marsのメモ 僕が書くのも場違いな気がするけど、とりあえず書いてみるよ。 Webアプリ作るという前提だとまずEclipse IDE for Java EE Developersをダウンロードしてインストールする。JDKは別途ダウンロードする。Tomcatも別途ダウンロードする。 JDKはWindowsの場合はデフォルトではProgram Files以下にインストールしようとするがパスに空白が含まれてるのが嫌なのでC直下とかにする。 Tomcatもインストーラを使わずにZIP版を解凍して、パスに空白が含まれていない場所にインストールする。 プラグインはSubversionクライアントとしてSubclipseを、プロパティエディタとしてちょま吉をインストールする。ここまでは必須。 DB使うようならDBViewerもイ
Subversionのリポジトリ構成 - wyukawa's diary
なんか今更感のあるネタですが書いてみたいと思います。大きく分けて３パターンあると思います。 1. 単一リポジトリ単一trunk型 http://.../svn/ProjectA/ | |--------trunk/ |--------ComponentA/ |--------ComponentB/ |--------branches/ |--------Patch_1.0 |--------ComponentA/ |--------ComponentB/ |--------tags/ |--------1.0 |--------ComponentA/ |--------ComponentB/いちばんオーソドックスなパターンといえるでしょう。個人的には好みです。 ComponentAとComponentBのバージョンを同期させる必要があるならこの構成でしょう。 Redmin使ってるならhtt
コミットコメントについてのブログのてきとー訳 - wyukawa's diary
James Lorenzen's Blog: Commit Comments: A Conversation with your Future Self の画像は「バック・トゥ・ザ・フューチャー」のマーティ（マイケル・J・フォックス）とその両親だと思う。 なんか面白そうだったのでこれも訳そうとしたが、、、うーんよくわからん メモ代わりにとりあえずさらしときます。Google翻訳よりはちょっとマシという程度ですけど。 コミットコメント：未来の自分との対話 僕はある機能やバグどこでなぜ入ったのかについてヒントを見つけるためにしばしばsubversionのコミットログを探しているのに気づいた。 たいていは数時間を無駄にし、毎回コミットコメントのなかの対話の欠如からフラストレーションを感じていた。 僕は変更をコミットするときにこの機能を見渡すことの重要性について強調できない。 多くの開発者はこれを
Java開発におけるフォルダ構成 - wyukawa's diary
こんな感じでいい気がしてきた。 http://.../svn/sample/ | |--trunk/ | |--tools/ JDK, Ant, Eclipse, Tomcat, DBなどのツール類 | |--doc/ ドキュメント類 | |--sample-project/ 各プロジェクトのビルドスクリプトを呼び出す大元のビルドスクリプト | |--build.properties |--build.xml | |--build-test.properties |--build-test.xml | |--conf/ Eclipseの設定ファイル(epfファイル)などを格納する | |--sample-common/ 共通的に用いられるユーティリティクラスなどの置き場 | |--build.properties |--build.xml |--.classpath |--.project
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
