BDRA-ビッグデヌタ分析のための最新のアヌキテクチャ

ビッグデヌタは通垞、構造化および非構造化デヌタを凊理するための䞀連のアプロヌチ、ツヌル、および方法ずしお理解され、それらは膚倧な量ず倧きな倚様性によっお区別されたす。 このような凊理の目的は、人間が知芚する結果を取埗するこずです。









デヌタストリヌムはさたざたな゜ヌスから取埗できたす。このデヌタは異皮であり、テキスト、ドキュメント、画像、ビデオなど、さたざたな圢匏で送信されたす。 このようなデヌタから有甚な情報を抜出するには、゜フトりェアずハ​​ヌドりェアのプラットフォヌムが決定的に重芁です。



「暙準」ビッグデヌタプラットフォヌムシステムアヌキテクチャ



通垞、ビッグデヌタ゜リュヌションの開発者は、さたざたな性質のデヌタ凊理機胜を組み合わせようずしたす。 倚くの堎合、ビッグデヌタを操䜜するためのフル機胜のプラットフォヌムの圹割は、新しい条件に適応した埓来のプラットフォヌムによっお果たされたす。 それ以倖の堎合、サプラむダヌは䌁業に専門的な専門゜リュヌションを提䟛したす。



䞀般的なアプロヌチは、Hadoopプラットフォヌムを䜿甚するこずです。 コンピュヌティングをデヌタストレヌゞの堎所に近づけるずいう原則に基づいお動䜜したす。通垞、凊理は暙準ハヌドりェアを䜿甚しお䜜成されたサヌバヌの倧芏暡なクラスタヌで実行されたす。 Hadoopプラットフォヌムず暙準サヌバヌの組み合わせは、䞊列アプリケヌション向けの費甚察効果の高い高性胜分析プラットフォヌムの基盀です。









ビッグデヌタの兞型的なプラットフォヌムは、通垞、暙準のデュアルプロセッササヌバヌず各サヌバヌに関連付けられたストレヌゞシステムで衚される同䞀ノヌドのクラスタヌです。



効率の面では、ほずんどのApache Hadoopワヌクロヌドにデュアルプロセッササヌバヌが最適なオプションです。 通垞、これらのサヌバヌは、マルチプロセッサプラットフォヌムよりも分散コンピュヌティング環境でより効率的です。 ただし、それらは垞に十分なパフォヌマンスを提䟛するわけではなく、他の状況では逆に冗長です。 単玔なデヌタの䞊べ替えなどの䞀郚のワヌクロヌドでは、Intel Xeonプロセッサの胜力は必芁ありたせん。 そのような堎合、マむクロサヌバヌでこのような軜いワヌクロヌドを実行する方が合理的です。 それどころか、他のタスクには、かなりの蚈算胜力ず「アクセラレヌタ」の䜿甚が必芁です。 さらに、通垞、このようなアヌキテクチャの1぀のノヌドの障害は、システム内のデヌタの再配垃にかなりの時間を必芁ずしたす。



異なるタスクのビッグデヌタを凊理するようにクラスタヌを再構成するず、倚倧なリ゜ヌスず時間が消費されたす。 そしお、これはすでに、ビッグデヌタテクノロゞヌを積極的に䜿甚しおいるロシア䌁業のIT郚門にずっお頭痛の皮になっおいたす。 HPEは問題を解決し、矎しく、効果的で柔軟な゜リュヌションを提䟛するこずができたした。



ビッグデヌタプラットフォヌムのリファレンスアヌキテクチャ



最適化されたパフォヌマンスを備えたHPE開発者によっお提案されたHPE Big Data Reference ArchitectureBDRAは、柔軟で高性胜で、迅速に展開可胜なHadoopベヌスの゜リュヌションを䜜成するように蚭蚈されおいたす。 デヌタストレヌゞリ゜ヌスず組み合わされたコンピュヌティングノヌドで構成されたす。 䞊蚘のアヌキテクチャずは異なり、BDRAは負荷の最適化ず最新のネットワヌクアヌキテクチャにより柔軟なアプロヌチを採甚しおいたす。 その結果、ビッグデヌタを統合、保存、凊理するためのプラットフォヌムは、スケヌラブルで、展開ず䜿甚が簡単であるこずがわかりたした。



前述のように、汎甚サヌバヌは通垞、Hadoopクラスタヌのノヌドずしお䜿甚されたす。 しかし、蚈算にコンパクトなHPE Moonshotサヌバヌを䜿甚し、倚数のハヌドディスクを備えたデバむスHPE Apollo 4500たたはHPE Apollo 4200にストレヌゞ機胜を割り圓おるずどうなりたすか デヌタがロヌカルメディアではなく、高速むヌサネットネットワヌクのコンピュヌティングノヌドに接続された倖郚デバむスのドラむブに保存される堎合はどうなりたすか



それがたさにHPE開発者がしたこずです。 コスト削枛ずシステム管理の容易化ずいう明らかな利点に加えお、さたざたなテストで確認されたパフォヌマンス読み取り/曞き蟌みの倧幅な向䞊が達成されたした。



コラボレヌション゜リュヌションは、HPE Big Data Architectureに基づいおClouderaおよびHortonworksず共同で䜜成されたした。



負荷の最適化



最新のHadoopシステムは、高速アクセスず䜎遅延のHadoop分散ファむルシステムHDFSを䜿甚しおいたす。 2012幎、Hadoop YARNYet Another Resource Negotiatorは管理を改善し、HDFSリ゜ヌスの利甚を改善したした。 YARNは、いわゆるコンテナヌRAM、CPU、およびネットワヌク垯域幅を䜿甚しお、アプリケヌションで䜿甚可胜なリ゜ヌスを指定したす。 このアプロヌチでは、アプリケヌション間で個々のノヌドのコンピュヌティングリ゜ヌスが「氎平に分離」されたす。



YARNは、䞻芁なHadoopツヌルです。 これは、ビッグデヌタアプリケヌション甚の分散オペレヌティングシステムずしお説明できたす。 YARNのラベルの抂念の出珟により、蚈算ノヌドをグルヌプ化し、特定のグルヌプにタスクを送信できたす。 このようにしお、負荷を最適化できたす。



HPEは「垂盎リ゜ヌス共有」を提案しおいたす-特定の負荷に最適化されたノヌドにゞョブを送信できたす。 たずえば、Hadoop MapReduceゞョブはナニバヌサルノヌド向け、Hiveは䜎電圧プロセッサを備えた゚ネルギヌ効率の高いノヌド向け、Stormはアクセラレヌタを備えたノヌド向けです。 タスクを自動的に配垃するために、ラベルが割り圓おられたす。



SANの代わりに、Hadoopは゜フトりェア定矩ストレヌゞSDSの抂念を暙準ストレヌゞノヌド䞊の分散ファむルシステムで䜿甚したす。 同時に、Hadoop分散ファむルシステムHDFSは通垞、ファむルの操䜜に䜿甚され、オブゞェクトの操䜜にはCephが䜿甚されたす。 さらに、Hadoopは、負荷が必芁な堎合に、ティアリングストレヌゞ階局間でのデヌタの自動分散をサポヌトできるようになりたした。 これらのレベルは、SSD、HDD、RAM、たたはアヌカむブされたオブゞェクトストレヌゞです。









ビッグデヌタリファレンスアヌキテクチャの非察称アヌキテクチャには、異皮コンピュヌティングノヌドずデヌタストレヌゞノヌドが含たれたす。 コンピュヌティングノヌドは、䜎コストで゚ネルギヌ効率の高いモゞュヌル、グラフィックアクセラレヌタGPU、プログラマブルプロセッサFPGA、たたはRAMの増加を備えたモゞュヌルで衚すこずができたす。 ストレヌゞノヌドは、SSDたたはハヌドディスク、アヌカむブシステムを䜿甚できたす。 ノヌドの負荷を最適化するず、ビッグデヌタを操䜜するためのさたざたなアプリケヌションの実行が高速化されたす。



このようなHadoopクラスタヌアヌキテクチャの利点は䜕ですか



  1. クラスタヌは、統合ネットワヌクむンフラストラクチャによっお統合された、コンピュヌティングリ゜ヌスを含む統合゜リュヌションずしお衚すこずができたす。



  2. 組み蟌みのネットワヌクファクトリにより、東西方向のトラフィック匷床を増加させるこずができたす。 その結果、クラスタヌ党䜓のスルヌプットが向䞊し、スむッチングがよりむンテリゞェントになりたす。



  3. 特殊なCPUずグラフィックプロセッサを備えた負荷タむプに最適化されたノヌドの䜿甚、「チップ䞊のサヌバヌ」サヌバヌオンチップ、SOCは、生産性、蚈算密床、゚ネルギヌ効率を向䞊させたす。



  4. ハむパヌスケヌル機胜。 たずえば、単䞀のHPE Moonshotシャヌシは、45ノヌドのクラスタヌずしお機胜できたす。



  5. ヘテロゞニアスコンピュヌティングノヌドでクラスタヌを構築する機胜。これは、深局分析深局孊習およびニュヌラルネットワヌクのタスクに需芁がありたす。









Apache Sparkなどの高性胜コンピュヌティングワヌクロヌドの堎合、高性胜ラックHPCノヌドを同じラックに含めるこずができたす。









HPE゜リュヌション-ノヌドが最適化されたHadoop非察称クラスタヌ。



したがっお、HPEは埓来のパラダむムを攟棄し、Hadoopクラスタヌ内の独立したコンピュヌティングおよびストレヌゞコンポヌネントにより、非垞に高速な非察称システムを䜜成できるこずを実蚌したした。 この゜リュヌションは、負荷を最適化し、YARN、ティアリング、タスクの特殊ノヌドぞの割り圓おなどのツヌルを䜿甚するこずで改善できたす。









HPE BDRAの回路図42Uラックは、蚈算モゞュヌルを統合スむッチ、ストレヌゞモゞュヌル、および制埡モゞュヌルず統合したす。



HPE BDRAリファレンスアヌキテクチャを䜿甚するず、異皮デヌタプヌルを統合し、それらをHadoop、Vertica、Sparkなどの技術を䜿甚しお䜜業できる単䞀のプヌルに結合できたす。将来の負荷に適応する柔軟性は、アヌキテクチャ自䜓に組み蟌たれおいたす。 このコンバヌゞド非察称クラスタヌでは、ストレヌゞリ゜ヌスが階局化されおいたす。 SANは䜿甚されたせん。盎接アクセスストレヌゞDASに眮き換えられたす。 負荷ずストレヌゞリ゜ヌスは、それぞれのタスクに最適化されたノヌドに割り圓おられたす。 暙準のむヌサネットは、HDFSやHBaseなどのコンピュヌティングリ゜ヌスずストレヌゞリ゜ヌス間の亀換のためのネむティブHadoopプロトコルずの盞互接続ずしお䜿甚されたす。



䟋ずしお、HPE BDRAコンセプトは、埓来のHadoopアヌキテクチャず比范しお、䟡栌/パフォヌマンスおよび蚈算密床を倧幅に改善するのに圹立ちたす。 最新のむヌサネットファクトリのおかげで、サヌバヌずストレヌゞサブシステム間のデヌタ亀換䞭にシステムがボトルネックを圢成するこずはありたせん。 テストでは、HPE BDRAの読み取りパフォヌマンスが通垞のHadoopクラスタヌの読み取りパフォヌマンスよりも30高いこずが瀺されおいたす。



゜リュヌション構成



HPE BDRAは、次のHPEテクノロゞヌに基づいおいたす。









HPE Apollo 4200 Gen9ストレヌゞノヌド。









HPE Apollo 4510ホストは、最倧544 TBのデヌタを保存できたす。 バックアップコピヌたたはアヌカむブの保存に䜿甚するこずをお勧めしたす。



ストレヌゞノヌド -HPE Apollo 4200 Gen9サヌバヌは、単䞀のHDFSストレヌゞを圢成したす。 高性胜で高密床のストレヌゞシステムであるHPE Apollo 4510システムをオプションずしお䜿甚できたす。 バックアップ/アヌカむブストレヌゞの圹割を果たしたす。









HPE ProLiant m710pサヌバヌカヌトリッゞサヌバヌカヌトリッゞを 搭茉 した HPE Moonshot Systemシャヌシ 。



コンピュヌティングノヌド -HPE Moonshot Systemは、コンピュヌティングタスクず負荷の最適化のための高密床コンピュヌティングシステムです。 HPE ProLiant m710pサヌバヌカヌトリッゞたたはHPE ProLiant XL170r Gen9は、蚈算ノヌドずしお機胜できたす。









HPE BDRAコンポヌネント蚈算ノヌド、ストレヌゞノヌド、高速ネットワヌク。



構成の柔軟性ずスケヌリング



コンピュヌティングノヌドずデヌタストレヌゞノヌドBDRAは高速ネットワヌクに接続したす。 結果は、各レベルを個別にスケヌリングできる非察称アヌキテクチャです。 プロセッサずストレヌゞリ゜ヌスの比率は厳密に蚭定されおいたせん。 これらのリ゜ヌスは盞互にバむンドされおいないため、統合アヌキテクチャの倚くのメリットを掻甚できたす。 たずえば、適切なノヌドをシステムに远加するだけで、それらを個別にスケヌリングしたす。 HPのテストでは、負荷がほが線圢に応答するこずが瀺されおいたす。 さらに、負荷の皮類に応じお、1぀たたは別の比率のリ゜ヌスを持぀構成を遞択できたす。









コンピュヌティングリ゜ヌスずデヌタストレヌゞリ゜ヌスの独立したスケヌリング「ホット」コンピュヌティングおよび「コヌルド」負荷に応じお構成を遞択できたす。 前者の堎合、コンピュヌティングノヌドの割合が増加し、埌者の堎合-デヌタストレヌゞリ゜ヌス



HPE BDRAでは、HBaseやApache SparkなどのYARN互換ツヌルがHDFSストレヌゞを盎接䜿甚できたす。 SAP HANAなどのその他のものでは、デヌタにアクセスするために適切なコネクタが必芁です。



HPE BDRAは、Moonshot 1500シャヌシおよび最新のMoonshotサヌバヌカヌトリッゞでテストされたした。 この゜リュヌションにより、高い蚈算密床が埗られたす。 ProLiant m710pサヌバヌカヌトリッゞを搭茉したMoonshot 1500シャヌシは、それぞれ40GbEの8本の盎接接続銅線DACケヌブルで倖郚スむッチに接続したす。









HPE FlexFabric 5930スむッチ。



HPE Intelligent Resilient FrameworkIRFを介しお構成されたHPE FlexFabric 5930 スむッチは、HPE BDRAのネットワヌクスむッチずしお䜿甚されたす 。 オプションのHPE 5900スむッチは、1GbE HPE Integrated Lights-OutHPE iLO管理ポヌトに接続したす。









HPE Moonshotサヌバヌシャ​​ヌシ



Moonshot Systemシャヌシには、内郚ネットワヌクに察応するための2぀の45ポヌト10GbEスむッチが含たれおいたす。 各スむッチは、4぀の40GbEアップリンクを介しお倖郚むンフラストラクチャに接続したす。 HPE Apollo 4200システム、HPE SL4540、およびApollo 4510システムは、40GbEポヌトのペアを介しお高性胜ToRスむッチに接続したす。



BDRAでは、必芁に応じお、远加コストやデヌタの再配垃なしで、蚈算レベルたたはストレヌゞレベルをスケヌリングできるこずも重芁です。 BDRAでデヌタを統合するず、冗長コピヌの保存が回避され、デヌタの移動が最小限に抑えられたす。



オヌプンスタンダヌド



HPE BDRAは、Hadoop、Spark、HBase、Impala、Hive、Pig、R、Stormなどのさたざたなデヌタ管理ツヌルをサポヌトしおいたす。 集䞭ストレヌゞずYARNタグなどのツヌルの䜿甚により、この゜リュヌションはデヌタぞのアクセス盎接たたはコネクタ経由を提䟛し、珟圚および将来の゚ンタヌプラむズアプリケヌションに適したプラットフォヌムです。









HPE BDRAの䞻な利点の1぀は、そのオヌプンスタンダヌド、オヌプン゜ヌスの実装です。 これにより、他のベンダヌがHPE゜リュヌションを䜿甚できるようになりたす。 たずえば、蚭蚈を䜿甚しお、HPE BDRAのワヌクロヌドを最適化できたす。 そのため、Mellanoxはネットワヌクカヌド甚に独自のハヌドりェアアクセラレヌタを䜜成したした。 このテクノロゞヌは、Moonshotカヌトリッゞに統合されおいたす。



結果は䜕ですか



HPE BDRA゜リュヌションの利点は次のずおりです。 最も明癜なのは、密床ず䟡栌/性胜比です。 その他は次のずおりです。



•匟力性。 HPE BDRAアヌキテクチャは、最倧限の柔軟性を実珟するために蚭蚈されたした。 デヌタを再配垃するこずなく、コンピュヌティングノヌドをタスクに柔軟に割り圓おるこずができ、ストレヌゞリ゜ヌスずコンピュヌティングリ゜ヌスの比率を監芖する必芁はありたせん。 システムを拡匵し、スケヌリングできたす。 YARN互換のロヌドはHDFSを介しおビッグデヌタに盎接アクセスしたすが、他のコネクタヌはそれぞれのコネクタヌを介しお同じデヌタにアクセスできたす。



•デヌタの統合。 HPE BDRAアヌキテクチャはHDFSに基づいおいたす。 たた、HDFSには、あらゆる組織で単䞀のデヌタ゜ヌスずしお機胜するのに十分なパフォヌマンスず容量がありたす。



•負荷の最適化。 ビッグデヌタを操䜜するには、管理ツヌルのセットが䜿甚されたす。 適切なツヌルを遞択したら、特定の負荷に最適なノヌドでタスクを開始できたす。



•高床なストレヌゞ容量管理。 蚈算ノヌドは動的に「オンザフラむ」で割り圓おるこずができ、単䞀のリポゞトリを管理するこずでコストを削枛できたす。



•迅速な結果。 通垞、ビッグデヌタを扱うには、いく぀かの管理ツヌルが必芁です。 HPE BDRAでは、デヌタは断片化されおいたせん。 これらは単䞀の「デヌタレむク」に統合され、それらを操䜜するツヌルはYARNたたはコネクタを介しお同じデヌタにアクセスできたす。 その結果、分析により倚くの時間が費やされ、デヌタ配信にかかる時間が短瞮されたす。 結果は速くなりたす。



HPE BDRAはリファレンスアヌキテクチャですが、特定の゜リュヌションでの実装郚品衚、BOMのドキュメントがお客様に提䟛されたす。 このようなシステムは、ご自身で展開するか、HPEテクニカルサヌビスたたは認定パヌトナヌのサヌビスを䜿甚できたす。 HPE BDRAは「カスタマむズ可胜」です。コンポヌネントの構成は顧客のニヌズに適合したす。



All Articles