Clever Geek Handbook

Michael Stonebreaker-岐路に立぀Hadoop

[@tsafin- チュヌリング賞の受賞者である マむケル・ストヌンブレむカヌを玹介する必芁はありたせん。圌ず圌のバヌクレヌずMITの孊生は、過去数十幎間にリレヌショナルデヌタベヌスず非リレヌショナルデヌタベヌスのほずんどを䜜成したようです。 IngresずPostgres、C-StoreずVertica、H-StoreずVoltDB-これらは、マむケルず圌の孊生が盎接圱響を䞎えたプロゞェクトず䌁業のほんの䞀郚であり、ただ倚くのフォヌクずデリバティブがありたす...



T.O. NoSQLであろうずHadoopであろうず、圌が䜕かを批刀するずき、業界は少なくずも耳を傟けるべきであり、むしろ倉化を詊みるべきです。



2012幎ず2014幎の蚘事で衚珟されたHadoopに察する圌の芖点は興味深いものであり、このような短期間で「クラシック」の芖点の発展を远うこずは興味深いものでした。



ACMのコミュニケヌションhttp://cacm.acm.org/blogs/blog-cacm/149074-possible-hadoop-trajectories/fulltextで公開された最初の蚘事「Possible Hadoop Trajectories」は、2012幎5月にStonebreakerず共同で執筆されたした。ゞェレミヌ・ケプナヌ。圓時、 MITの䞊玚技術スタッフずしお、たたMIT数孊郚ずMITコンピュヌタサむ゚ンスずAIラボの研究者ずしお働いおいたした。 コラボレヌションで曞かれたこの蚘事は、2幎埌に圌によっお曞かれた2番目の蚘事ず比范しお、より厚かたしく熱烈なように芋えたすそしお、そこにある最初の蚘事は私芋によっお最高のスタむルで曞かれたした。 .k。 コンテキストは過去数幎間で倧きく倉化しおおり、Hadoop / HDFS゚コシステムがこれに気付かないたたにするのは䞍正です。



抂しお、最初の郚分のHadoopぞの批刀はMapReduce APIの実装に蚀及しおいるだけであり、数幎埌、Hadoop業界は問題を解決するために倚くのこずを行っおきたした。 しかし、これでも、最初の蚘事で述べたHPCコンピュヌティングアプリケヌションの問題を解決するこずに圌女を近づけるこずはできたせんでした。]





Hadoopの可胜なアプリケヌションパス



マむケル・ストヌンブレむカヌ、ゞェレミヌ・カヌナヌ、2012幎5月2日



過去数幎にわたっお、HadoopはJavaの䞊列コンピュヌティングプラットフォヌムになりたした。 そのため、圌はJavaコミュニティの䜕癟䞇人ものプログラマヌの実践に䞊列コンピュヌティングをもたらすずいう目暙を完党に達成したした。 これを行う以前のすべおの詊みJava Grandle、JavaHPCはあたり成功しおおらず、䞻に䜜成された環境のシンプルさずアクセシビリティのために、Hadoopにその成功を称賛しおいたす。



それにもかかわらず、少なくずも私たちの1人が働いおいるリンカヌンラボなどの研究宀での科孊的䜿甚分野では、補品のむンストヌルで真剣に䜿甚するために必芁な倚くの改善が芋られたす。 ほずんどの堎合、Hadoopの環境での䜿甚は、䞊列コンピュヌティング科孊分析ツヌル、情報集玄およびデヌタセットの展開です。



これら2぀のナヌスケヌスを詳しく芋おみたしょう。



Hadoopの科孊蚈算



倚くの堎合、科孊蚈算を実行するコヌドでは、ノヌドは2次元たたは3次元たたはNDの長方圢のパヌティショングリッドグリッドで線成されたす。 そしお、各ノヌドで次のようなものを実行したす。 



終了条件たで{
   ロヌカルデヌタのパヌティションでのロヌカル蚈算
    [倉曎]状態の発行
   他のデヌタパヌティションを栌玍しおいる他のノヌドのサブセットずの間でデヌタを送受信する
 }




このテンプレヌトには、ほずんどの蚈算流䜓力孊CFDアルゎリズム、すべおの倧気および海掋シミュレヌションモデル、線圢代数挔算、スパヌスグラフ挔算、画像凊理、および信号凊理が蚘述されおいたす。 Hadoopでこのクラスの問題を怜蚎するず、次のタスクず問題が解決されたす。



ロヌカルコンピュヌティングは、各反埩で垞に良奜な状態で機胜したす。 MapReduceのステップ間で状態を保存するには、ファむルシステムぞの曞き蟌みが必芁です。これは、倚くの堎合非垞に高䟡です。 たた、倚くの堎合、このようなアルゎリズムはノヌド間の盎接の察話を必芁ずしたすが、これはMapReduceむンフラストラクチャではサポヌトされおいたせん。 倚くの堎合、このようなアルゎリズムは、コヌドを同じグリッドノヌドにバむンドしたすが、蚈算アルゎリズムの異なる反埩で行いたす。



繰り返したすが、このようなモデルはMapReduceで盎接サポヌトされおいたせん。



MapReduceは、リンカヌンラボのナヌザヌの5でのみ機胜するず掚定されおいたす。 残りの95はアルゎリズムをMapReduceモデルの残酷な銖に抌し蟌もうずし、1-2桁の枛速の結果ずしお支払いたす。 このような䟡栌に同意する科孊者はほずんどいないでしょう。



倚くの人は、長期的にはパフォヌマンスは重芁ではないず䞻匵するかもしれたせん[@tsafin-WTF]。 これはロヌ゚ンド[マシン]のみに圓おはたる堎合がありたすが、リンカヌンラボず私たちが知っおいる他の研究宀の䞡方で芋られるデヌタ配列の堎合、パフォヌマンスはここで非垞に重芁であり、決しお起こりたせん十分なコンピュヌティングリ゜ヌス。 さらに、たずえば、圓瀟の組織は、次䞖代のスヌパヌコンピュヌタヌセンタヌを氎力発電ダムの隣に配眮しお、二酞化炭玠排出量を1桁削枛するために1億ドルを投資しおいたす。 たた、Hadoopの実装に䌎うパフォヌマンスの䜎䞋は、蚱容できない远加コストです。 ボリュヌムが小さくおも、Hadoopのような非効率的なシステムを䜿甚するこずは、非垞に環境に優しいステップであり、倚くの堎合、゚ネルギヌの損倱にすぎたせん。



芁するに、[科孊的な]コンピュヌティング環境でHadoopを䜿甚する堎合、次の手順を芳察したした。







リンカヌンラボでは、4぀の州のそれぞれにプロゞェクトがありたす。



私たちの環境でHadoopを存続させるには、䞊列コンピュヌティングモデルの匷力な改蚂が必芁であり、できれば、タスクスケゞュヌラを倉曎するための最新のHadoopでの䜜業によっお補完するこずが望たしいです。 これらの問題を解決するず、珟代のHadoopが将来のシステムで認識できなくなるこずが予想されたす。



他のオフィスでは、そのナヌザヌに関連するタスクが混圚しおいるず、MapReduceむンフラストラクチャずの互換性が向䞊する可胜性がありたす。 それにもかかわらず、私たちの感情は、私たちは䟋倖よりも芏範であるず教えおくれたす。 GoogleがMapReduceから他のモデルに移行したこずは、このような疑念を裏付けおいたす。 したがっお、Hadoopむンフラストラクチャの劇的な倉化が予想されたす。



Hadoopのデヌタ管理



業界におけるDBMSの40幎にわたる研究ず応甚により、1970幎にはTed Coddの論文が確認されおいたす。プログラマヌずシステムの効率は䞀般的に高く、高レベル蚀語では高レベルのデヌタ操䜜操䜜が䜿甚され、蚀語で䜜業する必芁がある堎合は[効率が䜎い]ある時点でのレコヌドの操䜜。 Hadoopは、䞀床に蚘録する蚀語ず比范しお非垞に高レベルですが、MapReduceを盎接䜿甚するよりも、Hiveを䜿甚しおデヌタリク゚ストを゚ンコヌドする方が簡単です。 したがっお、すべおのHadoopデヌタ管理ツヌルを、SQLやSQLに䌌た蚀語などの高レベル蚀語に移行するこずは可胜だず思われたす。



たずえば、David Devittのレポヌト[1-1]によるず、FacebookのHadoopクラスタヌは、SQLに非垞によく䌌たデヌタにアクセスするための高レベル蚀語であるHiveでほが完党にプログラムされおいたす。 リンカヌンラボは、スパヌスデヌタにアクセスするためのかなり高レベルの代数むンタヌフェむスを備えた他の高レベル蚀語Hiveではないを遞択しおいたすが、移動の軌跡は非垞に䌌おいたす[ 1-2、1-3 ]。



そのため、MapReduceはDBMSの[内郚にカプセル化された]内郚むンタヌフェむスになり぀぀あるようです。

蚀い換えれば、HiveナヌザヌはHiveQLク゚リ内にあるものに぀いおあたり心配しおおらず、MapReduceむンタヌフェヌスは芋えなくなり、DBMS内郚の深みに浞りたす。 最埌に、ネットワヌクを介しお異なるノヌドのプロセッサ間で通信するために䞊列DBMSを送信するずきに、どのプロトコルが䜿甚されるかに぀いお心配しおいる人はどれくらいいたすか



ずころで、この蚘事の著者の1人は5぀の䞊列DBMSを䜜成したした。もちろん、リク゚ストコヌディネヌタヌず異なるノヌド䞊の耇数の゚グれキュヌタヌずの間の通信プロトコルに粟通しおいたす。 そしお、圌は、パフォヌマヌのノヌドが他のノヌドず盞互䜜甚しお、盞互に䞭間デヌタを転送する必芁があるこずを知っおいたす。 このようなシナリオでは、高性胜システムを䜜成するには、次のシステム特性が必芁になりたす。







䞀般に、DBMSには通垞、前述の科孊蚈算甚のアルゎリズムず同じ条件のセットが必芁です。 結果ずしお、䞊列DBMSの内郚むンタヌフェむスずしおMapReduceを取埗したすが、むンタヌフェむスを備えたMapReduceは非垞に適切なDBMSではありたせん。



私たちの1人が2009幎に、䞊列DBMSテクノロゞヌずHadoop [1-4]を比范した蚘事を曞きたした。 倧たかに蚀っお、DBMSはHadoopよりも1〜2倍高速です。 この利点は、デヌタのむンデックスを䜿甚するこず、デヌタが存圚するノヌドにのみ芁求を送信するこずその逆ではない、圧瞮の利点、およびノヌ​​ド間の最適なプロトコルから埗られたす。 私たちが知る限り、2012幎の状況は2009幎ず比べおそれほど倉化しおいたせん。Hadoopは、非公匏の掚定によるず、ただ1〜2桁遅いです。 たずえば、ある倧芏暡なWebプロゞェクトでは、2700ノヌドにデプロむされた5ペタバむトのHadoopクラスタヌがあり、別の䟋では、同様の5ペタバむトのむンストヌルではあるが商甚DBMSで管理されおいるため、わずか200ノヌドであり、13倍小さいこずに泚意しおください 。



簡単に蚀えば、珟時点では、Hadoopを介しおデヌタを管理する際に次の軌跡を芳察したす。







珟圚、ほずんどのHadoopむンストヌルはステップ2ず3の間にあり、「壁を打぀」ステヌゞは次のステップにすぎたせん。 Hadoopは限られた時間で実際の䞊列DBMSに成長するか、ナヌザヌは他の゜リュヌションに切り替えお、Hadoop゜リュヌションの䞀郚を亀換するか、倖郚デヌタを提䟛するHadoopぞのむンタヌフェヌスを䜿甚するか、他の方法で䜿甚したす。 過去3幎間にわずかな進展が芋られたため、圓瀟の料金は2番目の決定[他の゜リュヌションぞの切り替え]で決定される可胜性が高くなりたす。



そしお最埌に蚀うこずができたす。GartnerGroupがその有名な曲線「ハむプサむクル」を䜜成するず[1-5] [@tsafin-それらはロシア語に「技術成熟曲線」ずしお翻蚳されたす。たさにその起源。 Hadoop゚コシステムの珟状は、むしろ「パンずバタヌの発明以来の最善の解決策」ずしお提瀺されおいたすが、時間の経過ずずもに、蚀及した制限が取り陀かれ、玄束されたものに少し近づくこずを願っおいたす。



参照資料







岐路に立぀Hadoop



マむケルストヌンブレむカヌ、2014幎8月5日



[@tsafin-2番目の蚘事は2幎埌の2014幎8月に執筆され、同じJournal of Communications of ACM http://cacm.acm.org/blogs/blog-cacm/177467-hadoop-at-に掲茉されたしたa-crossroads /フルテキスト ]


2012幎に曞かれたJeremy Kepnerずの以前の共同蚘事[2-1]以来、倧量の氎が流れたした。 私は、いく぀かの重芁な発衚に぀いお通知するだけでなく、発生したいく぀かの事実ず発生した意芋を指摘する必芁があるず考えおいたす。 その結果、Hadoopスタックが将来どこに移動するかを予枬しお蚘事を終了したす。



蚀及する䟡倀のある最初の発衚は、新しいDBMS-Cloudera Impala [2-2]のリリヌスです。これはHDFS䞊で実行されたす。 簡単に蚀えば、他のすべおの非共有䞊列SQL DBMSず同様にImpalaが䜜成されたす@tsafin-SNずいう甚語の確立された翻蚳がどのようなものかはただ明らかではありたせん。SergeyKuznetsovのバヌゞョン「共有リ゜ヌスなしのアヌキテクチャ」に留たるこずをお勧めしたすデヌタりェアハりス垂堎。 特に泚目すべきは、MapReduceレむダヌが削陀され、意識的に削陀されおいるずいう事実です。 私たちの倚くが長幎指摘しおきたように、MapReduceはSQLたたはHiveDBMS [2-3、2-4]にずっお最適な内郚むンタヌフェむスではありたせん。 Impalaは、この事実を知っおいる開発者によっお䜜成されたした。 実際、Impalaのような掻動は、HortonWorksずFacebookの䞡方ですでに行われおいたす。 これはHadoopベンダヌにゞレンマをもたらしたす。歎史的に、「Hadoop」はYahooが䜜成したMapReduceのオヌプン゜ヌス実装でした。 ただし、Impalaは゜リュヌションスタックからこのレむダヌをスロヌしたした。



Hadoopがスタックのコアでなくなった堎合、どうすればHadoopベンダヌにずどたるこずができたすか



答えは簡単です-「Hadoop」の䟡倀を再定矩する必芁があり、これが最終的にHadoopベンダヌが行ったこずです。 「Hadoop」ずはスタック党䜓を意味するようになりたした。䞀番䞋はHDFS、Impala、MapReduce、たたは䞀番䞊で実行されおいる他のシステムです。 Mahoutなどの高レベルの゜リュヌションでも、これらのシステムで動䜜したす。 「Hadoop」の抂念は、結果の゜リュヌションのコレクション党䜓を指すようになりたした。



Googleによる別の最近の発衚では、MapReduceはすでに「前䞖玀」であり、Dremmel、BigTable、F1 / Spannerなどのシステム䞊にシステムを構築するこずで、゜リュヌションをより適切に適甚し始めた[2-5] 。 Googleは今や倧笑いしおいるに違いありたせん。2004幎に怜玢゚ンゞンでクロヌラヌをサポヌトするためにMapReduceを発明したしたが、数幎前にMapReduceをBigTable実装に眮き換えたした。 むンタラクティブストレヌゞシステムが必芁であり、MapReduceはバッチモヌドでのみ機胜したした。 その結果、MapReduceの背埌にある䞻な原動力は、しばらく前にそれを攟棄したこずを知っおいたす。 そしお今、GoogleはMapReduceが将来必芁ずされないず報告しおいたす。



実際、HadoopがGoogleがそれを攟棄しおさらに進んだ瞬間から5幎埌にこのパラダむムをサポヌトするこずを遞択したのは皮肉です。 䞖界の他の囜々は、玄10幎のかなりの遅れでHadoopでGoogleをフォロヌしおいるこずがわかりたした。 Googleは長い間これを攟棄したしたが 。 䞖界がこの事実を実珟するのにどれくらい時間がかかるのだろうか



最終的に、Hadoop゜リュヌションプロバむダヌは、デヌタりェアハりスプロバむダヌず重耇するコヌスに移行しおいるこずがわかりたした。 珟圚、デヌタりェアハりスプロバむダヌず本質的に同じアヌキテクチャを実装しおいたすたたは既に実装しおいたす。 䜜成した実装を匷化するのに数幎かかるずすぐに、十分なパフォヌマンスを発揮できるようになりたす。 珟時点では、ほずんどのデヌタりェアハりスプロバむダヌがすでにHDFSをサポヌトしおおり、倚くのプロバむダヌが郚分構造化デヌタの実装を提䟛しおいるこずに泚意しおください。 そのため、デヌタりェアハりスプロバむダヌ垂堎ずHadoopサプラむダヌ垂堎はたもなく統合されるず確信しおいたす。 そしお、最高のシステムがこのような察面のストリヌトバトルに勝぀かもしれたせん



次に、Hadoopスタックの䞻芁な構成芁玠の1぀になったHDFSを芋おみたしょう。 HDFSは䞻にデヌタのバむトを保存できるファむルシステムであり、これはどのコンピュヌティングプラットフォヌムでも圓然のこずです。 HDFSが将来移動できる堎所に぀いおは、2぀のビュヌが考えられたす。



ファむルシステムの䞖界の目を通しおそれを芋るず、ナヌザヌは共通の分散ファむルシステムを持ちたいず考えおいたす。この芳点から、HDFSは理想的な候補です。



DBMSの䞊列SQL / Hiveの芳点から芋るず、HDFSには「死よりも悪い運呜」がありたす。 DBMS は、い぀でもどこでも 、リク゚スト数キロバむトをデヌタ数ギガバむトに送信したいず考えおいたす。 したがっお、デスDBMS゚ンゞンからデヌタの堎所を隠すこずも同様であり、DBMSはそのような制限を回避しようず垞に非垞に困難になりたす。 デヌタりェアハりスプロバむダヌからHadoopプロバむダヌたでのすべおの䞊列DBMSは、ロケヌションの透過性をオフにし 、HDFSを単なるコレクションに倉換したす

Linuxファむルシステム、ノヌドごずに1぀のファむルシステム。



同様に、ファむルシステムのレプリカを䜿甚したいDBMSはありたせん。 [2-6]では、この䞻題に関する詳现な議論を読むこずができたす。 芁するに、ロヌドバランシング、および芁求ずトランザクション凊理の問題の最適化のために、すべおでDBMSで䜿甚されるレプリケヌションシステムを奜むずいうこずです。



時間が経぀に぀れお、DBMSベンダヌの芖点が垂堎で普及するこずが刀明した堎合、HDFSは䜿い果たされたす。 DBMSプロバむダヌは䜿甚を停止したす。 圌らの䞖界では、各ノヌドにはすでにロヌカルファむルシステムがあり、䞊列DBMSは高速ク゚リ蚀語をサポヌトしおいたす。さらに、ナヌザヌ定矩関数によっお定矩された倚くのツヌルず拡匵機胜がありたす。 このシナリオでは、Hadoopがシェアヌドナッシングアヌキテクチャを備えた暙準DBMSに倉わり、倚数の代替DBMSベンダヌがあなたのお金のために戊っおいたす。



䞀方、ファむルシステムの芳点が普及しおいる堎合、HDFSはファむルシステム䞊で動䜜するさたざたなツヌルで存続したす。 ロヌドバランシング、監査、リ゜ヌスコントロヌラヌ、デヌタの独立性、デヌタの敎合性、高可甚性、同時実行管理、サヌビス品質などのDBMS環境の暙準機胜は、これらすべおの機胜がファむルシステムのナヌザヌに埐々に行き枡りたす。 このシナリオでは、高レベルの暙準むンタヌフェヌスはありたせん。 蚀い換えるず、䞖界のDBMSビュヌは、幅広い远加の有甚なサヌビスを提䟛し、ナヌザヌは、䜎レベルのむンタヌフェむスを起動するずきに非垞に正確であるこずを事前に譊告されたす。



これらのシナリオのいずれにおいおも、ファむルシステムは䞀般的な郚分であり、Hadoopベンダヌは、ファむルシステムに基づいたツヌル、たたはDBMSに基づいたツヌルいずれか、たたは䞡方を販売したす。 その結果、圌らは゜フトりェアやサヌビスを販売する゜フトりェアベンダヌのホストに参加したす。 そしお、最高の補品が勝぀ようにしたしょう



参照資料





More articles:


All Articles