最近触っていた Hadoop 周辺の話 – Ambari 2.1.2.1 + HDP 2.3.2 編
こんにちは。次世代システム研究室で Hadoop 周辺をよく触っている T.O. です。
Hadoop 周辺をよく触っているので、最近 Hadoop 周辺を触ってきて得た話などを書いていきます。
最近は Ambari 2.1.2.1 で構築した HDP 2.3.2 のクラスタを触る時間が多かったので、そこで得た話がメインになります。
特にこれといって大きくまとまった話はありません。
Hadoop 周辺をよく触っているので、最近 Hadoop 周辺を触ってきて得た話などを書いていきます。
最近は Ambari 2.1.2.1 で構築した HDP 2.3.2 のクラスタを触る時間が多かったので、そこで得た話がメインになります。
特にこれといって大きくまとまった話はありません。
Ambari 2.1.2.1 + HDP 2.3.2 での話
Ambari を使うということ
特別な理由がない限り、新たに HDP で Hadoop クラスタを構築するならば、 Ambari を使うのが良いのだな、と感じております。以前の職場では、 Ambari などの WebUI から管理できるツールを使ってはいませんでしたが、そこから比べると、圧倒的にハードルは低いですね。ただし、ある種の柔軟性は損なわれるでしょうから（例えば自分でパッチをあてたクラスを適用することを考えるとめんどくさそう）、多少の割り切りは必要かもしれません。それでも、 NameNode, ResourceManager, Hive Metastore, HiveServer2 の HA 構成を WebUI からかんたんにできる、というあたりなどは、かなり優れていると感じていますし、それだけで使う意味があるのでは、ぐらいに思ってしまいます。仕組みをあまり理解せずとも使えてしまう、という利点のような欠点のような話はありますが。
Ambari を使っての HDP のセットアップ
Ambari そのもののセットアップから Ambari を利用しての HDP のセットアップまでは、オフィシャルドキュメント のとおりにやればいけます。特に難しいところはなかったはずです。特に難しいところはなかったので、特に印象にも残っていません。最高ですね。
NameNode を HA にしている場合、 HDFS のバランシングは Ambari の WebUI からはできない件
どうも NameNode を HA 構成にしている場合のみの話らしいですが、 HDFS のバランシングが Ambari の WebUI からできません。Hortonworks のコミュニティで “Balancer not working in hdfs HA” として書いてある内容のとおりです。
エラーメッセージが多少、異なるものの、AMBARI-13373 もあり、同一の原因ならば Ambari 2.2 で直っていることになりそうです。よかったですね。
エラーメッセージが多少、異なるものの、AMBARI-13373 もあり、同一の原因ならば Ambari 2.2 で直っていることになりそうです。よかったですね。
監視と通知の話
Ambari 自体にメトリクスの収集とその監視と通知の機能はありますが、通知の制御の柔軟性を求めるとなると、監視と通知は Nagios に任せると良いのではないか、と考えています。2016年における最適な監視と通知のソリューションをよく知りませんが、 Nagios は適切な選択肢のように思います。 Ambari には REST API があるので、それを適当に利用しつつ、 Nagios plugin の流儀に従ったスクリプトを書いて利用しています。 Ambari REST API については、GitHub に上がっているドキュメントを見ると良さそうですね。ちなみに、 Ambari REST API は、監視だけでなく、 HiveServer2 の定期的で自動的な再起動にも使っています。便利ですね。
なお、本題からは逸れますが、 Nagios については 「Nagios統合監視[実践]リファレンス」がよくまとまっていると思います。 Nagios を使う日本語ネイティブの方なら、一冊持っておいて少なくとも損はないと思います。
Ambari Metrics Collector の話
Ambari には、 Metrics Collector というコンポーネントがあります。これは文字通り、クラスタを構成するノードからメトリクスを受け取って回収します。ところでこのコンポーネントは、 Hortonworks による Ambari のドキュメントあたりを読むとわかりますが、デフォルトの embedded モードだと、ローカルにスタンドアロンの HBase を起動してそこにメトリクスを保存していくようです。ということで、この HBase が健康に動くようにチューニングする、ということも多少、考えないといけません。私が見ている環境では、 hourly で GC が荒ぶって、 loadavg が高まるので（とはいえ、クリティカルではないですが）、改善したいところです。もちろん distributed モードで動かしてなんとかする、というのもありだし、それが正しいようにも思います。 HBase ですし。
Capacity Scheduler の話
Capacity Scheduler のことを理解するための入り口は、これまたオフィシャルドキュメント（リンクは HDP 2.4.0 のもの）を読むことではないかと思います。私は今回 HDP のクラスタを触るまでは Fair Scheduler しか触ったことがなかったので、とりあえずこれを読んで概要はつかんでおきました。また、どのように設定すべきか、は、当然、実行するアプリケーション次第なので、一概には言えないところなので、とにかく少し頭を使って考えることになるでしょう。
次世代システム研究室では、アプリケーション開発や設計を行うアーキテクトを募集しています。アプリケーション開発者の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ 募集職種一覧 からご応募をお願いします。
皆さんのご応募をお待ちしています。
Capacity Scheduler については、ふたつほどパラメータについて言及しておきます。
yarn.scheduler.capacity.maximum-am-resource-percent / yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent
オフィシャルドキュメントを読むと “Maximum percent of resources in the cluster which can be used to run application masters” という説明があります。文字通り、 YARN の Application Master に最大でどのぐらいリソースを割くか、という話のようです。このパラメータのデフォルト値は 10(%) ですが、キューに割り当てている capacity 自体が小さい場合、この値を少し大きめにしておかないと、そもそも Application Master が起動しない、ということがありました。当然といえば当然ですね。
yarn.scheduler.capacity.resource-calculator
stackoverflow に同じようなことがあがっていました（”Spark executor on yarn-client does not take executor core count configuration.”）。なぜか Spark アプリケーションで vcores が 1 しか使われない、という問題です。これについてはこのページに従い、 DominantResourceCalculator を使えば良いようです。あまり深追いはしていません。
Hive の alter table concatenate の話
Hive には alter table concatenate 文があります。 concatenate と言っているとおり、そのテーブル・パーティションを構成しているファイルを結合してくれるようです。小さいたくさんのファイルというのはしばしば問題になりますが、それに対するソリューションなわけですね。さらに、説明を読むと、 “ORC files added support fast stripe level merging of small ORC files using concatenate command.” という記述があり、実際に ORC ファイルについてはそのとおり、複数のファイルに散らばっていた stripe をより少ないファイルにまとめなおす、再配置する、というようなことをやってくれています。あくまで stripe 単位で処理していくので高速、という理屈なわけです。便利です。
ところでこの alter table concatenate 、同じテーブル・パーティションに対して何回も実行できるわけですが、データの内容が変わらないあるテーブル・パーティションに対して、複数回、 alter table concatenate を実行すると、私が見た限りではある状態に収束しきるわけでもないようでした。下記は、既に alter table concatenate を実行したパーティションに対してさらに実行したらどうなったか、という一例です。
| 変数 | 説明 | 数値 |
|---|---|---|
| flash_rate | トレード頻度 | 24 |
| trade_percentage | 資産比率 | 0.01 |
| dc_range | DCの周波数 | 20 |
| atr_length | ATRの周波数 | 24 |
もちろん stripe の数と行数には変化はないわけですが、 stripe のばらけ方がなんとも言えない感じになっていますし、 000004_0, 000005_0 については、変化なしです。あくまで一例なので、たまたまこうなった可能性も高いですが、こういう挙動になることもある、ということで注意したいところですね。
こういう挙動はありつつも、便利なことは便利ですが、場合によっては、そもそも stripe の数が多すぎるので減らしたい、ということも出てくるかもしれません。というか、出てきました。その場合、 insert overwrite select で再構成しつつ上書きする、という手は考えられます。ひょっとしたらパラメータを変更すれば alter table concatenate でもいけるのかもしれませんが、そこは今のところ未調査です。
以上は Ambari 2.1.2.1 + HDP 2.3.2 の環境で見てきた話ですが、最近、 Ambari 2.2.1.0 + HDP 2.4.0 も少しだけ触ってみているので、その際に出くわした話をひとつだけ書いておきます。
おまけ: Ambari 2.2.1.0 + HDP 2.4.0 での話
なお、セットアップ手順については、 Ambari 2.1.2.1 + HDP 2.3.2 と同じく、オフィシャルドキュメントのとおりに粛々とやれば良いです。 いい世の中になりましたね。
Hive Metastore が起動しない
ところが、ひとつ問題がありました。なぜか Ambari から Hive Metastore を起動しようとしても失敗します。エラーメッセージを読むなどしていくと、 AMBARI-14823 が原因であることがわかりました。このページにもパッチがあるものの、これを適用しても解決できず、適当に調べていくと Python 一般の話として “Python スクリプト実行時に UnicodeDecodeError が出る場合の対処方法” に書かれているようなことがあるようなので、これに従ってみたところ、解決し、 Hive Metastore は無事起動しました。こんなことが続くと Pythonista になってしまうかもしれませんね。もちろんこの現象は、 OS 側の設定によりそうなところなので、起きないこともあるだろうと思います。
以上、細かい話を寄せ集めてみました。次世代システム研究室では、アプリケーション開発や設計を行うアーキテクトを募集しています。アプリケーション開発者の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ 募集職種一覧 からご応募をお願いします。
皆さんのご応募をお待ちしています。
