Search Offline Dump Cluster 2013はいくつかの大きなアップグレードを行いました：
2013-04
同時にhbaseもメジャーアップグレードを行い、hiveは0.9.0にアップグレードされました；
2013-09, 2013-12
第二段階は、メインアップグレードのmapreduceは、バージョン2.0には、hiveは0.10.0にアップグレードされ、13年の終わりに、hbaseは小さなバージョンアップを実施しました；
この時点で、ダンプオフラインクラスタリングは完全に2.0の時代に入っています：
成熟したNAMENODE HAをサポートしながら、hdfs 2.0の最適化短絡読み取り、ドメインソケット通信の使用などの効率を向上させ、タスクの実行速度を高速化するためにアップグレードすることにより、フェデレーションは、ビューの単一の点について心配クラスタNNを解決するために、クラスタの容量とスケーラビリティが大幅に改善されています。
DUMPアプリケーションアーキテクチャのその後の最適化のための豊富なコンピューティングフレームワークをサポートしながら、クラスタリソースをより効果的に管理するための糸をアップグレードすることにより、スロットの物理的な分割を放棄し、クラスタ全体のスループットを向上させるためにクラスタリソースをより有効に活用するためにメモリリソース制御を使用して、広いステージを提供します。
もちろん、クラスターをアップグレードする過程でも、多くの問題や困難がありました。
アップグレードの第一段階で発生した主な問題：
1、hdfsは2.0にアップグレードすると、同時にハイブのバージョンをアップグレードする必要があります、ハイブのjarコンパイルタスクの古いバージョンの使用は、jarパッケージの新しいバージョンを使用して再コンパイルする必要があります！
2、mr1のタスクは、タスクのhdfs 2.0の一部で実行するために失敗し、主に2.0は、インターフェイスに置き換え、元のクラスになります再コンパイルする必要があるコードの少量は、IOExceptionをスローする下に追加する必要があることができます、hadoop -コアjarパッケージの数に分割されているに依存します。
3、hdfsのシェルコマンドの違い、主にmkdirやtouchzなど。
4は、hdfsのバージョンに起因するラダーdistcpデータから互換性がないため、hftpの方法を使用する必要があり、hftpは、パスワードのアクセスをサポートしていないため、後でパッチソリューション
5、hdfs 2.0クラスタをアップグレードした後、クラスタ全体の読み取りI / Oが大幅に上昇し、その結果、ビルドタスクの遅延のために特に高いI / O需要が発生します。
その理由は、2.0で調整されたdfs.client.read.shortcircuitにあり、ショートサーキット読み込みのパーミッションがあるかどうかをチェックする際に、もしパーミッションがなければローカルのデータノードをデッドノードとして扱い、リモートからデータを読み込みます。また、dfs.client.read.shortcircuit.buffer.sizeの値がhbaseで適切に設定されていないため、不要なデータが大量に読み込まれ、クラスタ全体のI/Oが高くなります。
解決策
プロセスの詳細な分析については、こちらをご覧ください：
アップグレードの第2段階で発生した主な問題：
1、ヤーンにアップグレードした後、キャパシティスケジュールが更新され、ジョブ投入のみリーフキュー名を指定する必要がありますすることができます、フルパスを指定するとエラーが報告されます；
2、マップ/削減スロットの概念なし、クラスタは、利用可能なメモリサイズ、メインパラメータを設定する必要があります：
クラスター
yarn.nodemanager.resource.memory-mbコンテナが使用するために割り当てられるノードマネージャの物理メモリのサイズ。
yarn.scheduler.minimum-allocation-mbリソースは、メモリ割り当ての最小粒度を管理し、一時的に1024に設定し、ジョブ提出メモリは、このパラメータの整数倍でなければならない。
yarn.scheduler.capacity.<queue>.maximum-am-resource-percent資源の割合は、キューによって設定することができ、一時的に0に設定する。.3
yarn.scheduler.capacity.<queue>.user-limit-factor単一のユーザーがジョブの制限を提出するには、キューによって設定することができ、単一のユーザーは、最大リソースを押収するように、あなたは大きな設定する必要がある。アプリケーション
mapreduce.map.memory.mb,mapreduce.reduce.memory.mbマップは、メモリの数を減らし、デフォルトは1024、2048、そのような大規模な設定する必要があるとして、1024の整数倍でなければならない、単純にスロット構成の数として理解することができる。
mapreduce.map.java.opts,mapreduce.reduce.java.optsjavaの子プロセスのjvmのヒープサイズは、上記の値よりも小さい。
mapreduce.job.reduce.slowstart.completedmaps大量のマップを複数回実行する必要がある場合、この値を設定して開始を遅らせると、リソースの浪費を避けることができる。3は、ヤーンは、hadoopクラスパスにjarファイルをコピーすることにより、commons - cli - 2.0-SNAPSHOT.jarと互換性がないアプリケーションを使用するには、関連するディレクトリのそれぞれのアプリケーションにデプロイする必要があり、タスクの提出時に参照する時間です。
4、0.19やその他の古いバージョンのhadoop-streaming.jarを使用している場合は、新しいバージョンのhadoop-streaming.jarに置き換える必要があります。
5、コンテナメモリのオーバーランは、ジョブメモリの自然な成長と共有メモリを使用するタスクのいくつかを考慮して排除されるので、物理メモリのチェックをオフにするには、yarn.nodemanager.vmem-pmem-ratio=falseを設定します。
6、AMにクライアントジョブステータスエラーを取得する：IOException
原因はAMのメモリ設定が小さすぎるためで、yarn.app.mapreduce.am.resource.mbを調整することで問題を解決し、頻繁にGCを行います。
7, c2c_mergeタスクがyarn上で遅く実行されます。
調査と分析の後、クラスタのアップグレードプロセスは、アプリケーションコードの変更を通じて、また、カーネルにアップグレードされるため、pagecacheのmmapファイルの使用に起因している頻繁に原因のうち、根本的な原因や18と32カーネルの違いを変更します。
8、IPV4とIPV6の違いは、長いと短いマシン名の問題とジョブデータのローカル低比率の問題によって引き起こされます。
yarnリソースマネージャーでは、長いマシン名のマシンと短いマシン名のマシンが表示されます。
hbaseクラスタは、すべての長いマシン名を示し、その理由は、その糸とhbaseは、マシン名の呼び出しメソッドを取得する同じではありませんが、結果はコンテナの優先順位ホストの一致の割り当てでresourcemanagerの結果、同じではありません一致し、最終的に任意の一致につながったとなりました。
マシン名の取得が異なる根本的な原因は、javaのipv6処理のバグとyarnスクリプトのバグの組み合わせであると分析されました。
解決策1：yarnスクリプトを修正し、communityjira/browse/YARN-2216問題を提出します。
解決策2：ラックを認識するようにクラスタを設定し、仮想ラックを1台ずつ設定するようにし、ラックマッチングによる任意のマッチングを回避します。
9は、プログラム1のその時点ではまだすぐにタスクのいくつかは、エラーを提出するために失敗したことがわかった低オンラインデータの問題を解決するためのプログラム2の一時的な使用の前に結論に達していないため、ローカル：最大ブロックの場所は、スプリットのために超えた
その理由は、1つのノードと1つのラックを設定した後、CombineFileInputFormatはブロックがどのラックに分散されているかによって分割されたブロックのローカションの情報を取得します。ラックの数はマシンの数に等しいため、ローカションの数はクラスタのデフォルトの設定よりも多くなります。取得されるローカリオンの数はクラスタのデフォルト構成を超えます：
mapreduce.job.max.split.locations=10で、yarn上で修正されたコードは、この設定値を超えると例外を投げるので、ジョブ投入は失敗します。
解決策1: mapreduce.jobs.max.split.locationsとクラスタノード数を一貫性を保つように増やします；
解決策2：JobSplitWriterをパッチ修正し、例外を印刷する設定値を超えた場合に警告ログを印刷するようにしました（アップグレード前と同じです）。
詳細は以下をご覧"article/detail/11707/193"
10. gcihが正常に動作しない
GCIH :./IH
うまく機能しない理由は2つあります：
- クラスタがyarnにアップグレードされた後、nmはttとは異なるジョブtempディレクトリと配布ファイルを管理し、GCIHが複数のmmapファイルgcih.datを生成する原因となります。
- 上記の問題を修正する過程で、タスク上の異なるディスクへのハッシュ、jvmクラスパスのロード順序が一貫していないことが判明し、その結果、GCIHが正常に動作しません。
解決策：GCIHのアップグレード
gcih.jarソフトリンクに対応するソース・ディレクトリにgcih.datを生成し、1つのジョブに1つしか存在しないようにし、gcih.jarのロード順序を調整し、プリロードに入れます。
11、クラスタリソースの使用率100%、ジョブはライブでハングしました。
クラスタルートが100%で動作しており、その下のサブキューが満杯でない場合（クラスタのリソースを共有競争させたいため、キューの最大利用可能リソースは適切に過剰に割り当てられています）、リデュースリソースを先取りするプロセスはトリガされません。
解決策
- 異なるキューで大きなタスクを実行することはできるだけ避けてください。
- rootが一杯になると、後続のパッチ修正が先取りをトリガーします。
プロセスの詳細な分析については、以下をご参照ください：///93
12, hbaseを書き込むロードタスクが時々スタックします。
その理由は、クラスタ内のノードがハングアップしたり、ネットワークに異常が発生した場合などに、hbaseclientが選択中に無線で待機してしまい、ロックが解除できないことがあるからです。
解決策:hbaseクライアントのコードでタイムアウトを設定してください。
具体的な原因の分析については、以下を参照"article/detail/9061/193"
13、クラスタは、上記のタスクが失敗しているノードの問題があり、その後の他のタスクも、このノードに割り当てられたコンテナになります。理由は、ヤーンとmr1ブラックリストのメカニズムが変更されたことです、mr1は、グローバルなブラックリストは、一度ブラックリストに追加された後続のタスクが割り当てられません、ヤーンブラックリストは、AMにある、つまり、タスクレベルは、AMのブラックリストに追加された現在のタスクがアップ割り当てられないことを確認することができますが、AMの他のタスクは、この情報を持っていないので、それはまだタスクに割り当てられます！.
解決策：NMがノードのヘルス情報をRMに報告するのを待ち、RMがクラスタからノードを削除します。
報告できなかった場合は、yarnでサポートされている周辺ユーザースクリプトを使用して、ヘルスチェックと報告を行うことができます。
詳細な分析については、以下をご覧ください：///93
蜂の巣関連：
1、結合が複数のジョブに分割される場合
発見された問題：ローダーがマルチテーブル結合を行う過程で、元のジョブがハイブで8つのジョブに分割され、元のジョブで3分かかっていた時間が30分になりました。
2, set mapreduce.map.tasksが有効になりません。
分析はHiveのInputFormatの問題です。
3、redisハイブジョブを2つのジョブに分割して書き込みます。
hiveのデフォルト設定では、マップ出力ファイルが小さすぎる場合、小さいファイルをマージするために新しいジョブを開始します。
解決策：hive.merge.mapfiles=falseを設定します；
まだ未解決の問題があります：
1) シングルディスクのioが100%になり、このタスクが遅くなるジョブがあります；
2) マシンに異常な問題が発生し、タスクがすべてローカライズ中で、ジョブが保留中で、再送信するためにキルオフすることしかできません；
3) ジョブやタスクが強制終了された後、ログも削除され、履歴からジョブの情報が見えなくなるため、トラブルシューティングが困難になります；
統一されたストレージは、モジュールのプラグインの設計は、ビジネスの様々な行の間のデータの冗長性を削減し、開発の重複を避けるため、同時に新しいプラットフォームADUMPのビジネスの様々な行の新たなニーズへの迅速な対応をサポートする3月末頃にオンラインになり、密接にクラスタのアップグレードのリズムに従って、オフラインのDUMPもすぐに2.0の時代に入力されます、楽しみにしてください！
