More Related Content Similar to 最新版Hadoopクラスタを運用して得られたもの (20) More from cyberagent (20) 最新版Hadoopクラスタを運用して得られたもの5. ● Hadoopベースのデータ解析基盤
○ HDFS, YARN, Hive, HBase, Flume, Spark, etc
○ Apache Bigtopで内製化したパッケージを使用
● メディアサービスのデータを集約
○ 2.5 PB / 3.0 PB (3 replica)
■ 5〜7 TB / day
○ 約700テーブル、12,000,000パーティション
○ 6000スケジュールジョブ + アドホックジョブ
データ解析基盤Patriot
7. ● Hadoop 2.7.3 + patch → 2.8.1 + patch
● Zookeeper 3.4.6
● HBase 1.3.0 → 1.3.1 + patch
● Hive 2.1.1 + patch (ORC関連のpatch追加)
● Tez 0.8.4
● Flume 1.8.0 (trunk) + patch
● Spark 2.1.0 + patch
● Presto 0.179 + patch (kafka対応追加)
● Presto YARN 1.5
● Slider 0.92.0
● Kafka 0.11.0
現在利用中のパッケージ
Presto YARNのために追加
8. ● Hadoop
○ HADOOP-12366 : expose calculated paths
○ HADOOP-11628 : SPNEGO auth does not work with CNAMEs in JDK8
● HBase
○ HBASE-18000 : Make sure we always return the scanner id with ScanResponse ←
NEW !!!
● Flume
○ FLUME-3026 : Add Kafka 0.10 support for Flume
○ FLUME-3065 : Enable multiple monitoring types
○ FLUME-3100 : Support arbitrary header substitution for topic of Kafka
● Spark
○ SPARK-14958 : Failed task hangs if error is encountered when getting task result
適用しているパッチ
9. ● Hive
○ HIVE-14029 : Update Spark version to 2.0.0
○ HIVE-14999 : SparkClientUtilities does not support viewFS
○ HIVE-15101 : Spark client process can be stuck when UNHEALTHY NodeManager exists
○ HIVE-15237 : Propagate Spark job failure to Hive
○ HIVE-15239 : hive on spark combine equivalent work get wrong result because of TS
operation compare
○ HIVE-15513 : GroupByOperator should initialize GenericUDAFEvaluator before
AggregationBuffer (recurrence of HIVE-697)
○ HIVE-15580 : Eliminate unbounded memory usage for orderBy and groupBy in Hive on
Spark
○ HIVE-16402 : Upgrade to Hadoop 2.8.0
○ HIVE-15178 : ORC stripe merge may produce many MR jobs and no merge if split
size is small ← NEW!!!
適用しているパッチ
11. ● Masterサーバ (Namenode, ResourceManager, etc)
○ 24 CPU core, 64 GB RAM, 2TB (RAID10)
○ 6 ノード
● Slaveサーバ (Datanode, NodeManger, etc)
○ 56 CPU core, 256 GB RAM, 6TB x 12 disks
○ 48 ノード(増設予定)
● Kafkaサーバ
○ 16 CPU core, 32 GB RAM, 3TB (RAID10)
○ 9 ノード
ハードウェア
15. ● デメリット
○ Cloudera ManagerやApache Ambariなどの管理ツールを使うこ
とができないため手間がかかる
■ 特にローリングアップグレードやローリングリスタート
■ 本番環境でコマンド打つのは精神的に疲れる
運用してみて感じたメリット・デメリット
19. ● 調査
○ コンソールログを手掛かりに調査を実施し、YARNのJIRAでカー
ネルパニックに関連しそうなチケットを発見
■ https://issues.apache.org/jira/browse/YARN-5040
● 大規模なジョブを実行するとカーネルパニックが発生する
● カーネルのバージョンを4.8.1にアップデートしたら改善したとい
う人もいた
■ https://issues.apache.org/jira/browse/YARN-4382
● コンテナのプロセスをkillするのが設定値
(yarn.nodemanager.linux-container-executor.cgroups.delete-delay-ms)より
も遅れるとcgroupsのディレクトリを消せなくなる
● cgroupsのディレクトリが増えすぎるとCPUビジーになる
カーネルパニック多発
20. ● 補足
○ cgroups
■ タスクをグループ化し、そのグループに対してCPU、システム
メモリ、ネットワークなどのリソース制限をかけたりすることが
できる
■ 階層的に構成されている
● 構成はcgroupsfs上のディレクトリツリーで表される
■ サブシステムと呼ばれる機能でリソースを扱う
● サブシステムにはcpu(cpuのスケジューリング)、cpuacct(cpuリ
ソースについての自動レポートの生成)、memory(メモリに対す
る制限や自動レポートの生成)などがある
カーネルパニック多発
21. ● 補足
○ YARNとcgroups
■ YARNでは厳密なCPUリソース制限を行う場合、cgroupsを
用いる
■ YARNでcgroupsを用いる設定にした場合のcgroupsのディ
レクトリ構成例(OSのバージョンによって異なる)
カーネルパニック多発
cgroup
└ cpu
└ yarn
├ コンテナ1
├ コンテナ2
├ コンテナ3
└ コンテナ4 ←実行が完了すると削除される
22. ● 調査
○ NodeManagerのログを見てみると
○ /cgroup/cpu/yarn/ の下にできたディレクトリを定期的にカウント
→ 徐々に数が増えていっている
○ YARN-4382の事象と似ている
カーネルパニック多発
WARN util.CgroupsLCEResourcesHandler: Unable to delete cgroup at:
/cgroup/cpu/yarn/container_e59_1505389468296_48619_01_000176, tried to delete for
1000ms
23. ● 対応
○ cgroupsのディレクトリ削除のタイミングを変更
■ yarn.nodemanager.linux-container-executor.cgroups.dele
te-timeout-msを10000msに変更(デフォルトは1000ms)
● JIRAのチケットでは
yarn.nodemanager.linux-container-executor.cgroups.delete
-delay-msについて触れていたが、ソースコードを読む限りは
delete-timeout-msを調整したほうがいいと判断した
○ 念のため/cgroup/cpu/yarn/ の下にできたディレクトリ
のうち、更新日付から1日経過したものを削除するよう
にcronを設定
カーネルパニック多発
24. ● 事象
○ Hadoop2.7.3 → Hadoop2.8.1へのローリングアップグレードを実
施
■ おおまかな手順
● ローリングアップグレードのprepare
○ ロールバック用のfsimage作成
● NameNodeのアップグレード
● DataNodeのアップグレード
● ローリングアップグレードのfinalize
■ 詳細な手順
● https://hadoop.apache.org/docs/r2.8.0/hadoop-project-dist/hadoop-hdfs/Hdf
sRollingUpgrade.html
DataNodeのアップグレードでOOM発生
26. ● 調査
○ HDFSのJIRAのチケットに類似事象の報告が無いか検索し、類
似の事象を発見
■ https://issues.apache.org/jira/browse/HDFS-9536
● HDFS-8578の影響でメモリを多大に消費している可能性あり
■ https://issues.apache.org/jira/browse/HDFS-8578
● これまでDataNodeのストレージレイアウトのアップグレードは
ストレージを順次処理していたため、時間がかかっていた
● ストレージを並列に処理することで大幅な処理時間の改善を実
現するという素晴らしいチケット
DataNodeのアップグレードでOOM発生
28. ● 事象
○ Hadoop2.7.3 → Hadoop2.8.1へのローリングアップグレードを実
施
○ NameNodeのアップグレードまでは順調
DataNodeのストレージレイアウトのアップデートが中途半端
に終わる
29. ● 事象
○ DataNodeのアップグレード
■ 恐る恐る一台目をアップグレード
■ 普通に立ち上がってきたが、hdfsのログをtailしてたコンソー
ルに一瞬スタックトレースが表示された
■ HDFSのログを確認したところ、ものすごく怪しいログが出いていた
● 「Failed to analyze storage directories for block pool ブロッ
クプール名」→ アップデートできてなさそう
● 「loadBlockPoolSliceStorage: 7 upgrade tasks」→ ストレージ
は12本あるので12タスク動くはず
DataNodeのストレージレイアウトのアップデートが中途半端
に終わる
30. ● 実験
○ リトライされるかもしれないので数分待ってみた
■ リトライされる様子なし
○ DataNodeを再起動(1台死亡してもなんとかなるので)
■ 「loadBlockPoolSliceStorage: 5 upgrade tasks」が出力されていた
■ 初回の起動で失敗したとしても、再起動すればリトライされることが
判明
DataNodeのストレージレイアウトのアップデートが中途半端
に終わる
32. ● 事象
○ Zookeeperサーバの1台を再作成した
■ サーバの起動までに時間がかかってしまい、DNSキャッシュ
サーバから該当ホストの情報が落ちてしまった
■ サーバ起動前にDNSにアクセスがあり、ネガティブキャッシュ
が残ってしまった
○ その後、Zookeeper Client(Apache Curator)を使っているソフト
ウェアがZookeeprに再接続できなくなった
○ Zookeeperに常時接続しているもの(HBaseなど)には影響が無
かった
Zookeeperに再接続できない
36. ● Presto YARNの導入
○ Presto on YARN/Slider
● ファイルフォーマット変換
○ SequenceFile → ORC
○ 順次変換中
今回紹介しなかった取り組み
38. ● サーバOSの変更
○ CentOS6.8 → Ubuntu16.04
○ CentOSだとソフトウェアのバージョンが全体的に古い
■ gitのバージョンが低くてBigtop1.2が動かなかった
○ カーネルのトレーシング周りはUbuntuのほうが良さそう
● Hadoopクラスタ管理ツールの開発
○ 各プロセスの開始・停止、ローリングリスタート、ローリングアップ
グレードなどの手作業をなくす
● Zookeeperのアップグレードの検討
○ 3.4系にはバグがあるので3.5系に
現在の取り組み