Hadoop：あるべきかどうか？

親愛なる読者の皆さん、こんにちは！



少し前に、Hadoopフレームワークに関するOreille の基本的な本の翻訳を公​​開しました。







現在、編集者は、この本の新しい第4版を翻訳するか、既存の本を印刷するか、難しい選択に直面しています。



そのため、2013年にThoughtworksブログに掲載されたアナンダクリシュナスワミによる記事の翻訳を公開することにしました。著者は、Hadoopを使用するのが適切で、不要な場合を分析しようとしています。



この資料が興味深く、論争を引き起こし、Hadoopでの作業の印象を共有し、調査に参加することを願っています。







Hadoopシステムは、多くの場合、組織が問題に決定的に対処するのに役立つユニバーサルフレームワークとして位置付けられています。 「ビッグデータ」または「分析」に言及するだけで、すぐに適切な答え「Hadoop！」を見つけます。 ただし、Hadoopフレームワークは、非常に特定のクラスの問題を解決するように設計されています。 それ以外の場合、軽度で不完全なものにすることです。Hadoopを使用することは明らかな間違いです。 データ変換（広義-ETL操作-「抽出、変換、ロード」）はHadoopを使用して大幅に最適化されますが、ビジネスに以下の5つのプロパティの少なくとも1つがある場合は、Hadoopを使用しないでください。 。



1.ビッグデータへの渇望



多くの企業は、自由に使えるデータが「大」のステータスを引き出すと信じていますが、残念ながら、ほとんどの場合、この推定値は過大評価されています。 調査記事「クラスターの購入で解雇された人はいません」では、「大」と広く信じられているデータ量を評価できます。 著者は、Hadoopシステムはテラバイトおよびペタバイトのデータボリュームを処理するために作成されたものの、ほとんどの実用的な問題を解決するために、入力データボリュームは100 GBを超えていないと結論付けています（Microsoft＆Yahooのジョブサイズの中央値は14 GB未満で、タスクの90％ Facebookは100 GBをはるかに下回っています。 したがって、この記事の著者は、必要に応じてHadoopが動作するインフラストラクチャを水平方向にスケーリングするのではなく、インフラストラクチャの一時的な垂直スケーリング用に別のサーバーを割り当てることが適切であると考えています。



自問してください：



•数テラバイト以上のデータがありますか？

•安定した非常に大量のデータフローがありますか？

•どのくらいのデータを操作しますか？



2.インライン



ジョブを送信する場合、Hadoopの最小遅延は約1分です。 したがって、システムは販売注文に応答して推奨事項を提供するのに1分以上かかります。 非常に忠実で忍耐強いクライアントのみが60秒以上画面を見て、回答を待ちます。 または、リストに既にある各要素（Hadoopを使用してアプリオリ）の関連要素を事前計算し、サイトまたはモバイルアプリケーションに保存された結果への即時（2番目）アクセスを提供できます。 Hadoopは、このような予備計算のための優れたエンジンであり、ビッグデータでの作業を簡素化します。 もちろん、この種の典型的な応答が複雑になるほど、結果の完全な予測はあまり効果的ではありません。



自問してください：



•プログラムの応答速度に関するユーザーの期待は何ですか？

•どのタスクをパッケージに結合できますか？



3.電話への回答が届きます...



Hadoopは、リクエストへのリアルタイムの応答を必要とする場合に使用するためのものではありません。 map-reduceサイクルを通過するジョブもシャッフルサイクルに時間がかかります。 これらの両方のサイクルの期間は無制限です。その結果、Hadoopに基づくリアルタイムアプリケーションの開発は非常に複雑です。 ボリューム加重平均価格を考慮した取引は、システムがトランザクションを完了するために運用上の対応を必要とする実用的な例です。



アナリストはSQLなしではできません。 Hadoopは、データセットへのランダムアクセスにはあまり適していません（クエリからMapReduceジョブを実際に生成するHiveでも）。 GoogleのDremelアーキテクチャ（そしてもちろんBigQuery）は、巨大な行セットで数秒以内の自発的なクエリをサポートするように特別に設計されています。 ただし、SQLを使用すると、テーブル間の関係を作成できます。 他の有望な代替案は、カリフォルニア大学のサメの開発、バークレー大学のAmpLabの開発、およびホートンワークスによって実装されたスティンガーのイニシアチブです。



自問してください：



•ユーザー/アナリストはデータとどの程度密接に対話する必要がありますか？

•テラバイトのデータとの対話性が必要ですか、それとも情報のごく一部のみが必要ですか？



そのため、Hadoopはバッチモードで動作します。 これは、新しい情報を追加するときに、タスクがデータセット全体を再度選別する必要があることを意味します。 したがって、分析の期間が長くなります。 データスニペット-単なる更新または小さな変更-をリアルタイムで取得できます。 多くの場合、ビジネスはこれらのイベントに基づいて決定を下す必要があります。 新しいデータがシステムにどれだけ速くダウンロードされても、Hadoopはバッチモードで処理します。 おそらく将来、この問題はYARNの助けを借りて解決されるでしょう。 TwitterのStormソリューションはすでに人気があり、手頃な価格の代替品です。 StormとKafkaなどの分散メッセージングシステムを組み合わせることで、ストリーミングの集約とデータ処理のための多くの可能性が提供されます。 ただし、ストームは負荷分散に非常に欠けていますが、YahooのS4にはこの機能があります。



自問してください：



•データの「有効期限」とは何ですか？

•ビジネスは、着信データからどれくらいの速さで収益を上げる必要がありますか？

•ビジネスがリアルタイムで変更または更新に対応することはどれほど重要ですか？



センサーからのリアルタイム広告または追跡データには、リアルタイムストリーミング入力処理が必要です。 しかし、Hadoopまたはそれに基づいて実装されたツールが唯一の選択肢ではありません。 たとえば、最近のIndy 500レースでは、RAMに保存されたSAPのHANAデータベースが、MATLABとともにMcLarenのATLAS分析ツールで使用され、レース中にモデルを実行し、テレメトリーに応答しました。 多くのアナリストは、Hadoopの将来は双方向性とリアルタイムの作業に関連していると考えています。



4.お気に入りのソーシャルネットワークのアカウントを閉鎖したばかり



Hadoopと特にMapReduceは、コンテキストや暗黙的な関係を失うリスクなしにキーと値のペアに分解できるデータを扱うのに最適です。 暗黙的な関係はグラフ（エッジ、サブツリー、子および親の関係、重みなど）にあり、そのような関係はすべて特定のノードに存在することはできません。 したがって、グラフを操作するためのほとんどのアルゴリズムでは、各反復でグラフを完全または部分的に処理する必要があります。 MapReduceでは、これはしばしば不可能または非常に困難です。 さらに、ノードごとにデータをセグメント化するための戦略の選択に問題があります。 メインのデータ構造がグラフまたはネットワークである場合、おそらくNeo4JやDexなどのグラフデータベースを使用する方が良いでしょう。 また、GoogleのPregelやApacheのGiraphなど、新しい開発に精通することもできます。



自問してください：



•データの基本構造は、データ自体と同じくらい重要だと言えますか？

•データ構造に関連する必要な情報は、データそのものと同じかそれ以上ですか？



5. MapReduceモデル



一部のタスク/タスク/アルゴリズムは、単にMapReduceプログラミングモデルに適合しません。 これらのクラスの問題の1つは、すでに上記で説明されています。 結果を計算するための作業の中間段階の結果を知る必要があるタスクは、このような問題の別のカテゴリーです（学術的な例はフィボナッチ数列の計算です）。 一部の機械学習アルゴリズム（たとえば、勾配降下法または最大化期待値に基づく）もMapReduceパラダイムに完全には適合しません。 これらの問題のそれぞれを解決するためにさまざまな研究者によって提案された特定の最適化戦略/オプション（グローバル状態、参照用のデータ構造の転送など）がありますが、それらの実装はまだ複雑で直感的ではありません。



自問してください：



•会社は、非常に具体的なアルゴリズムまたは主題指向のプロセスに真剣に注意を払っていますか？

•適用されたアルゴリズムがMapReduceに適合している場合、または適合していない場合、技術部門は分析をより適切に処理しますか？



さらに、データセットが大きすぎない、またはデータの総量が大きいが、このセットは数十億の小さなファイルで構成されているような実用的なケースを考慮する必要があります（たとえば、多くの画像ファイルを見て、特定の数字を含むファイルを選択する必要があります）連結しやすい。 前述のように、タスクが「分割および集計」のMapReduceパラダイムに適合しない場合、Hadoopを使用してこのような問題を解決するのは疑わしい作業です。



そのため、Hadoopが最適なソリューションではない場合を検討したので、Hadoopを使用するのが適切な場合について説明しましょう。



自問してください：



あなたの組織は...

1.膨大な量のテキストログから情報を抽出しますか？

2.構造化されていないデータまたは構造化されていないデータのほとんどを便利な体系化された形式に変換しますか？

3.データセット全体の処理に関連するタスクを解決し、夜間に操作を実行します（クレジット会社での日中の操作がクレジット会社で処理される方法と同様）。

4.単一のデータ処理後に行われた結論に依存するため、次の目的のデータ処理まで有効です（たとえば、取引日の終了時よりも頻繁に変化する為替相場の値には適用されません）。



そのような場合、Hadoopにほぼ確実に注意を払う必要があります。



Hadoopモデルにうまく適合する多くのビジネスタスクがあります（ただし、そのようなタスクを解決することはかなり重要なことです。 原則として、このようなタスクは、大量の非構造化データまたは半構造化データの処理になり、内容を要約するか、またはシステムの他のコンポーネントが後で使用するために行われた観測を構造化形式に変換します。 このような場合、Hadoopモデルが役立ちます。 収集したデータに、対応する値の識別子として簡単に機能できる要素が含まれている場合（Hadoopではこれらはキーと値のペアと呼ばれます）、そのような単純な関連付けを複数の集計オプションに一度に使用できます。



したがって、最も重要なことは、利用可能なビジネスリソースを明確に理解し、解決しようとしている問題を理解することです。 これらの考慮事項と上記の推奨事項が、ビジネスに最適なツールを正確に選択するのに役立つことを願っています。



これはまさにHadoopになりそうです。