部屋を横切っCtripのHadoopのアーキテクチャプラクティスを共有するこの記事では、それが全体のエンジンルームプロジェクト全体Ctripの中のHadoopの開発、背景を含め、将来のための変革とビジョンに関連した私たちの部屋と着陸の練習、全体のアーキテクチャの選択のアイデアは、私はあなたにいくつかを与えることを願っています啓発。
まず、床とCtripの中のHadoopの開発
CtripのHadoopのは、二倍の急成長、前年と比べて基本的には毎年、2014年から導入され、我々は、Hadoopのクラスタと最適化のパフォーマンスを変換するために多くのことを行っています。
1）現在、Hadoopの3セットに基づいて、初期の2019年、連邦、対応する名前空間にルートRPCに自己開発名前ノードプロキシを行うネームスペース4分割ノードの数十万人とのデータのHDFSストレージレベルPBホットとコールドストレージの分離を行うために、ユーザに対して透過的消去コードクラスタ、データがストレージ・リソースの半分の保存、PB ECクラスタの数十に移行されています。
2）オンラインとオフラインの糸クラスターのスイートの二組が連盟を行うレベル、ビルド、総15万+コア、3000万日+ Hadoopのジョブ、スパークの90％を計算します。オンラインクラスタ展開での2つの部屋、3つの部屋オフラインクラスター展開エンジンルームに配置されたすべての4つのノード。
第二に、部屋の向こうプロジェクトの背景
プロジェクトの背景を見てください。我々は2部屋AとB、Bのマシンの95％にHadoopのマシンを展開する前に 昨年末、Ctripの自己構築されたCの部屋、部屋B内のラックの数は、拡大を続けるする方法を物理的な限界に達していないながら。また、現在の成長率を算出して記憶され、2024年末までに予想されるクラスタサイズが万台、新しいマシンの購入を達するに従ってのみCの部屋に追加することができ、我々はマルチルームのアーキテクチャと展開能力を必要としています。システムたいビッグデータを学ぶために、あなたはケリJunyangを学ぶためにビッグデータ交換技術に参加することができます：522 189 307
この問題は、帯域幅の場合で再生する場合、帯域幅は、わずか2部屋、1ミリ秒でのネットワーク遅延を200Gbpsである10％のパケットロス率があるが、遅延は通常、10ミリ秒に達します。私たちは部屋の向こうネットワーク帯域幅の使用量を最小限にする必要があります。
2.1ネイティブHadoopのアーキテクチャの問題
ネイティブHadoopの問題を探してください。ネットワークIOは、オーバーヘッド主に二つの側面から、シャッフルは、読み取りと書き込みのHDFS。
1）次のネットワークへのフェッチステージ、ディスクに一時ファイルのシャッフル、MRとブラシスパークジョブの前に中間段階を見ていきます。エンジンルーム1、エンジンルーム内reducetask 2におけるマップタスクの割り当て場合、部屋は、クロストラフィックのオーバーヘッドを有することになります。
、異なるノードに保存されている3つのコピーをシーンを読み取るための2）第2のHDFSレベル、クライアントは最新のコピーノードから優先度の読み取り、名前ノードからソートされた距離に情報のコピーを取得します。ケースやクライアントの3つのコピーが部屋にいないときでも、読書室は、クロスネットワークIOのオーバーヘッドを持っています。シーンを書いて、それから、あなたが部屋の向こう2つのラックを選択すると、部屋の向こうがあるだろう、コピーのみを選択するとき、3つのコピーを2つのラックに配置されるアカウントに収納ラックレベルの戦略を取って、パイプライン書き込みを使用してHDFSネットワーク書き込みのオーバーヘッド。
2.2オプションプログラム
我々は2つのインフラストラクチャ・ソリューション、マルチルームとマルチルームマルチクラスタの単一のクラスタの両方の長所と短所を持っているダウン議論していました。
2.2.1マルチルームマルチクラスタ
マルチルームのマルチクラスタ方式の利点は、ソースコードを直接デプロイすることができ、変更する必要はありません。不利な点は以下のとおりです。
1）ユーザに対して透過的に、ユーザは、クラスタを提出するように指定、設定を変更する必要があります。
2）より高い操作および保守コストを、それぞれの部屋は別々のクラスタ、構成管理の問題があります。
3）最も重要なことは、第三の点は、データの一貫性を確保することは困難です。複数の部門場合は、アクセスするいくつかの一般的なデータのニーズが、唯一の部屋を横切って読み取ることができ、IOは保存できませんが、distcp場合、この部屋は、トラフィックのオーバーヘッドのこの部分を保存するためにいくつかのコピーを入れて、それが原因コピーします。異なる管理によって名前ノードは、データの問題を引き起こすことは正しくありません。
2.2.2マルチルーム、単一のクラスタ
マルチルームシングルクラスタアーキテクチャで見てみましょうが、欠点は、コアコードのロジックBlockManager移動するので、完全なテストと検証を行うために必要なリスクがあるだろう、Hadoopのソースコードを変更する必要があります。しかし、メリットは明白です。
1）ユーザに透過、ユーザーのニーズは、ストアのコピー、ない認知部屋に雇用を提出している心配することはありません。
2）運用・保守のシンプルな展開。
それは状態を管理するための名前ノードのコピーであるので3）、マルチルームコピーの一貫性を確保することが可能です。
主に第一及び第三の点の利点のために、我々は、マルチルームシングルクラスタソリューションの最終的な選択をユーザーの透明性と一貫性を確保したいです。
第三に、前進してみてください - オンラインとオフラインの断面の部屋混合
実際には、最初のマルチルームマルチクラスタソリューションのために、僕らはオンラインとオフライン使用してユニットプロジェクトを混合する前にされています。クラスタリソースがオフラインのブランクよりも、朝のピークにオフピーク昼間を果たしたときのシーン。逆にオンラインK8Sクラスタ、私たちは私たちの負担を軽減するためのコンピューティングリソースK8S朝を使いたいです。K8Sは、クラスタAとDの部屋、ないデータの局所性に展開しました。だから我々はいくつかのCPU集中を維持したいが、IO操作のではない非常に大きな圧力がオンラインクラスタに割り当てることができます。
私たちは、糸のクラスタを設定K8Sに配備、およびオペレーティングシステムリソースの肖像画、VCORE /メモリ操作を使用し、主に買収、シャッフル、HDFSは読み書きや他のメトリックのセットを開発します。一般的な投入されたジョブスケジューリングシステムのゼウスは非常に修正していないので、歴史や消費各ジョブのリソースの実行時間は、我々はjobidを重合ゼウスによると、過去のパフォーマンス多くの時間に基づいて、各ジョブのためのリソースの使用の傾向を分析し、収束しています。次のジョブは、ゼウスシャッフルボリュームとオンライン実行クラスタに割り当てられた作業の低い識字HDFS量を開始します。
さらに、2つの部屋間もオンラインのクラスタとして、私たちはラベルに従ってラベルは、部屋に対応するラベルは、それが動作しますFairSchedulerに基づいてスケジュールを開発しているだけで、アプリのすべての各ラベルの負荷、動的割り当て、タスクに属します固定ラベル、ありませんので、マシンルームのシャッフルトラフィック内で実行されます。プログラム行の後に8％計算された圧力のクラスタをオフに緩和することができます。
第四に、マルチルーム、単一のクラスタ・スキーム
私たちは、デフォルトのコンピュータ室に対応する部門、可能な限り同じ部屋でのデータの流れを計画しています。監視および制限ルーム帯域幅にわたってマルチルーム単一HDFSクラスタ、マルチルームマルチ糸クラスタ、自動データ移行ツールとワーク：このように、マルチルームシングルクラスタのアーキテクチャの変換は、4つの側面を含みます。
シングルルーム以上4.1 HDFSアーキテクチャ
HDFSの転換を初めて目には、私たちは部屋の認識を高め、ラック意識に、名前ノードのソースを変換し、NetworkTopologyは<部屋、ラック、データノード>トリプルを形成しました。クライアントようにブロックを読み取り、ノードの複製距離を計算した場合、確かに少ない部屋を横切るローカル部屋よりも、部屋は、ローカルリードデータに優先度を与えます。
また、我々はマルチルーム全体でコピー管理機能に名前ノードを増加させ、ディレクトリ番号のマルチルームコピーを設定することができ、例えば、アップクロス設定する余地がないため、エンジンルーム1部屋1または2部屋と、各セットの3枚のコピーにのみ3つのコピーを設定しますパスのコピーは、我々は、UGIに応じて対応する部屋を見つける、飼育係のメモリと対応するユーザのデフォルトの部屋のマッピング関係、書き込みファイルのaddBlock時間を維持マシンルーム内のノードを選択します。
使用停止またはコピー操作のコピー数が多いであろうノードオフは、簡単容易帯域幅がオフフックされている部屋を横切るように導くことができます。コピーのコピーは、帯域幅を減らすために部屋を横切って複製するソースノードと同じ部屋の宛先ノードを優先させて頂きますと、この点において、我々は、ロジックReplicationMonitorスレッドを修正しました。
部屋の永続全体で情報パスのコピーのために、我々は待機時間のすべてのレコードの設定変更、セクションの新しいコピーで部屋の向こうfsimage、メタデータのみ、フェイルオーバー・スイッチの一部の保存ので、名前ノードにコピーを保存するために部屋を横切ってEditlogオペアンプを高めますまた、他の外部依存関係をロードすることはできません。
4.2変換バランサ・ムーバー・EC
このようバランサとしてHDFS変換、の他の側面がありますが、我々は複数インスタンスの配備をサポートし、各バランサは、IPリストの範囲を拡大するために、各部屋にはデータのみがIPのこの部屋のデータノードのバランスをとる再生されます。ムーバはとても適切なノードを選択するために、クライアント上の部屋の配置ポリシー間でディレクトリのコピーに従い、リハビリテーションの必要性で、クライアント側での選択先レプリカ・ノードであるため、ムーバーのために、我々はまた、マルチルーム複数インスタンスの配備をサポートしています。
ポイントは、ここで注意する実際の移行ネットワークIOは、これら2つのノードで発生しているので、同じ部屋にそのプロキシノードとターゲット・ノードを確保しようとすると、です。また、私たちはHadoopの3に基づく新しいCの部屋の消去コードクラスタセットを展開し、寒さは過去の履歴データ移行の一部となり、部屋を横切って変換を実行するコードのない部分はありません、私たちのEC移行プログラムはされていることが移行されますECデータBUクラスタにCの冷室に移行します。
補正ツール - クロスFSCKの4.3コピー
我々は複数の名前空間を持っているので、HDFSの部屋のバージョン間で、他のナノ秒のコピーを配置、グレー、グレースケールのプロセス上のNSラインである私たちは部屋を横切って感じることができるクロスIDCのfsckツールを開発しましたので、エンジンルームの大きさを考慮されていません配置されていない修正するには、設定ポリシーが正しくコピーします。
情報のコピーを読むために停止する必要が、getBlockLocations RPC要求の多くを生成しますので、我々は待機名前ノードからの読み出し要求を変更します、それがアクティブな名前ノードのRPC呼び出しのreportBadBlocksと一致しないことが判明した場合、BlockManagerは間違ったコピーを削除し、新しいを再選択しますコピー。この操作は比較的重いですので、我々はコールの数を制御し、クライアントRPCの制限を追加したので、インパクトは、HDFSのピーク時間あるでしょう。
以上の4.4マルチルームクラスタ糸
糸の変換で見てみましょうが、我々は、独立して糸クラスタ内の各部屋ののResourceManagerプロキシの自己啓発を展開し、それがユーザーとコンピュータルームの間のマッピングを維持し、この情報は名前ノードを共有され、各メモリとzookeperですA。
糸クライアントを変更し、利用者から提出された糸のジョブは最初rmproxyを通過した後、対応する糸クラスタに提出します。このようなタスクは、唯一のアプリケーションすべて一つの部屋のスケジュールで、部屋シャッフルを横断しません。あなたがエンジンルームに対応するユーザアカウントを切り替えたいとクラスタにも非常に便利であるならば、それはすぐにすべてのrmproxyに飼育係で通知されます、マッピング関係メモリを変更します。
すべてrmproxyがハングアップされた後糸Clientで、ローカルにダウングレード戦略、定期的なキャッシュの完全なマッピング関係をやっている間rmproxyは、互いに独立して、マルチ・インスタンスをデプロイすることができ、クライアントはその時にローカルルートが対応するクラスタに提出することができます。
アドホック分析レポートや計算を行うためにSparkthriftサービス、さきがけ、ハイブサービスの広範な使用。このサービスの居住者は、展開の各セットは、クライアントが直接変換後のJDBC対応倹約サービス、アクセスrmproxy介して接続される前に、ユーザーが開始rmproxyで対応する余地を取得します、各部屋に改装を行っていますサービスJDBC URLは、接続は、これはまた、ユーザーに対して透過的です。
第五に、自動化移行ツール
ノードCの部屋はBU-への自動移行をしようとすることを望んで、それは長いプロセスであり、マイグレーションを占める計画へのコンピューティングおよびストレージ容量に応じて必要であるので徐々に足しの到着によって購入されますので>アカウントサイズの移行、我々は次の4つのステップに分け、移行プロセスをコーマ：
1）バルクBUは、ハイブを開始マイグレーションに対応するアカウントに配置された（最初に3：0、すなわち、部屋Bの3部、C室0部）
2）ユーザDB及びホームディレクトリアカウントに応じて順次配置されたハイブ3：3、部屋Cにデータをコピー
口座番号とキューCの部屋に3）移行
4）流量は、B（0の室、回復室のコンピューティングおよびストレージリソースを横切って観察された：3）
これは、移行ポイントの間にそのいくつかの時間をノート：
1）部屋の向こう移行プロセスは、ネットワーク帯域幅の多くを過ごすことになり、あなたは低いピーク時のクラスタで実行する必要があり、我々は午後11時〜10時の間にあり、他の回は、自動的に移行を一時停止しますが、それ以外の場合は、オンラインレポートとETLジョブに影響を与えますSLA。
2）であっても、日中の移行、また1もプレイした場合、部屋を横切ってデータにアクセスするいくつかのETLとアドホッククエリのニーズがあるでしょう、日中の帯域幅が減少し、その後、他の一方で、圧力名前ノード自体を減少させるために処理、移動の速度を制御することです必要がありますまた、パフォーマンスへの影響を持つことになります。私たちは、部屋とトラフィック測定基準を越えUnderReplicatedBlocksの名前ノードのリアルタイム監視を移行しますが、これらの値を動的に移動速度に従って調整されます。
異なるStorageType含む移行HDFSルーム利用可能な容量を監視3）リアルタイムオフフックディスクを防ぎます。いくつかのハイブDBライブラリディレクトリセットHDFSクォータは、移行の設定3のためにも、あります：3クォータとエラーの上に、我々は自動的に一時的にクォータを増加し、その全体的な移行クォータの完了は、バック転送後。
2、各部屋を二つに置く：原因であることがより依存BU〜4）パブリックライブラリテーブルは、あなたが先に時間のマルチルームのコピーを設定する必要があり、アクセス権を持って、私たちは、ホワイトリスト機能は、通常、2に設定し、手動で設定することができています。
第六に、部屋の帯域制限が監視渡っ＆
いくつかのBUの練習台には、それが使用する共通テーブルとして扱われます、我々は、識別されるように、複数のコピーの部屋の向こう設定ポリシーを必要としています。現在のHDFSの流れが鳴りときに加えて、監査ログ、無dfsclientアクセスデータノード、データ伝送データノードのデータノードおよび監査情報の実際の流量が、私たちは実際のパスとブロックアクセスのこの部分を見て必要な情報、さらなる分析のためのデータ、条件の下で、優先度の高いジョブを優先し、SLAジョブの優先順位に従って、特定の保護手段を提供するサービスの必要性を制限する帯域幅リソースを取得します。
この点で、私たちは、一方、レコードの交通情報サービスを制限し、制限レポート流れdfsclientとデータノードのコードに制限サービスへのパスを読み書きするために部屋を横切ってリアルタイムに埋もれサービス、読み書きするブロックサイズ、ゼウスジョブIDおよびその他の情報を開発しましたES串にHDFSとデータ分析を行うには、他の一方で、再び電流容量やジョブ、またはスリープ後の期間の優先度に応じて部屋を横切って、読み取りおよび書き込み操作の実施を継続するためには、リリースに、クライアントがサービスを制限する許可を得るかどうかを決定します適用しよう。
2：あなたが情報の実際の流れ、オフラインデータ分析をしたら、表2のこの部分のコピー数を設定するには、部屋の向こう自動と手動の方法を組み合わせて、他のBUをたくさん読んでされているテーブルを知ることは容易です。部屋を横切ってリード要求を設定した後、ブロックは、元の20％に低下しました。部屋全体の帯域幅がダウンして、元の10％になりまし再生することが判明し、そして。
VII。まとめと今後の計画
要約すると、本論文では、部屋を横切ってHadoopのCtripの実践を紹介し、次の大きな変革を行いました。
1）シングルルームHDFSクラスタ対応、部屋の反対側の設定をコピーします
実現糸フェデレーションに基づいて計算2）スケジューリングRMプロキシ
3）リアルタイムの自動化されたストレージとコンピューティング移行ツール
サービスを監視、限定4）クロスフローエンジンルーム
現在、システム全体が部屋の帯域幅のトラフィック全体で、6ヶ月安定した動作、移動、雇用の40％と、新たな保管室に計算されたデータの50％のためにオンラインだったことも管理可能で、移行の正規化は、ユーザーが完全に把握する必要がありません。
さらにリファイン地区レベルに期待して、コピーは、今表面上に設けられている物理ストレージの通常の量よりも多く支払うことになる、2つの4つのコピーを：将来は、我々は、最も一般的なパスが2に設定され、移行のどのインテリジェントなアカウントを決めることができるように願っています川下事業の大半うち分析が唯一の最後の日または週のパーティションに依存しているため。だから、一度時間をかけて、ストレージのオーバーヘッドを削減するために戻ってパーティションの歴史の3枚のコピーに設定することができます。最後に、HadoopのECに基づいて部屋の向こうの変換は、クラスタ3に適用され、また、部屋を横断する能力をサポートしています。
