-1日に100万件以上のツイートがあり、サーバーにはそれらを処理する時間がありません。 したがって、クラスターにHadoopをインストールし、処理を分散する必要があります。
これは計算量の多い感傷的な分析でしたので、1つのサーバーには大量のツイートを処理するのに十分なCPUが実際にはなかったと信じることができました。
-すでに処理されたデータをどうするつもりですか？
-ほとんどの場合、前と同じようにMySQLに追加するか、削除することもあります。
「そして、あなたは間違いなくHadoopを必要としません。」
私の元同僚は、Hadoopでの分散コンピューティングについて最初に話した人とは程遠いものでした。 そして、このプラットフォームが発明され開発された理由について完全な誤解を見たたびに。
一般的に、データ処理ではいくつかの典型的な状況が発生し、それぞれに独自のアプローチとツールがあります。 主なものを検討してください。
アクティブデータのスポット処理
私たち全員が対処しなければならない最も一般的なシナリオは、「アクティブな」データ-ユーザーに関する情報、製品のリスト、記事へのコメントなどの保存です。 -頻繁に変更できるすべてのもの。 この場合、データをポイントごとに処理できるようにしたい-インデックスによって目的のオブジェクトを取得し、処理してからロードし直します。 これは、ほとんどのDBMSが提供する機能です（リレーショナルとNoSQLの両方）。
スケーリングの場合、ここでの主な問題は、データベースに保存されるデータの最大量で発生します。 ただし、使用するDBMSが分散構造をサポートしていない場合でも、アプリケーションレベルでパーティション分割することで問題を簡単に解決できます。
リアルタイムのストリーム処理
ただし、ストレージではなくデータ処理に重点が置かれる場合があります。 これはまさに、センチメンタル分析に関与した私の前の同僚が直面した状況です。 彼はリアルタイムでツイートを受信し、それらを分析して、動的に生成されたチャートに結果を表示する必要がありました。 1日100万件のツイートは問題ではありませんでした。結局、UTF16エンコードを使用した場合、1億4000万文字または280MBを超えません。 問題は、これらのツイートのリアルタイム分析でした。
幸いなことに、ほとんどのストリーミングアルゴリズム（ツイートのセンチメンタル分析、累積統計の収集、 オンライン機械学習など ）は、作業に独立した 小さなデータを使用します。 これにより、単純に計算ノードを追加し、それらの前にロードバランサーを配置するだけで、処理の並列化が簡単になります。
最も単純なケースでは、メッセージブローカー（ RabbitMQやZeroMQなど ）がバランサーとして機能し、より複雑な場合は、 Stormなどの既製のフレームワークを使用してストリーム処理を行うことができます。 同時に、データ処理を直接実行するメインコードは、単一サーバーバージョンと比較して実質的に変更されていません。
履歴データのバッチ処理
アクティブおよびストリーミングに加えて、もう1つの重要なデータタイプがあります-履歴、つまり かつて生成されたものであり、変更される可能性が低いもの。 これには、イベントログ、財務指標、特定の日のドキュメントインデックス、および実際には過去の特定のポイントに関連付けられたデータが含まれます。 ほとんどの場合、そのようなデータは大量に蓄積され、アナリストがビジネス上の問題を解決するために使用します。 ここでの特徴的な機能は、処理時に必要なデータがすでに収集され、多くのサーバーに配置されていることです（データが1つのサーバーに収まる場合は、 それほど大きくありません ）。
過去6か月間の大規模なスーパーマーケットチェーンでのすべての購入に関するデータがあるとします。 これらのデータを分析します。各スーパーマーケットの平均効率、保持されたアクションの効果、購入した商品と他の多くの指標との相関関係を計算します。 これらのパラメータの計算に妥当な時間がかかるように、データを使用して作業を整理する方法は？
すべてのデータを分散Oracleデータベースにロードし、アクティブなデータベースと同じように操作できます。 ただし、この場合、アプリケーションサーバーはデータベースからデータを順次取得し、各レコードを順次処理しますが、これは非常に非効率的です。
ストリーミング処理用のパイプラインを構成して、アプリケーションサーバー間の負荷を分散することもできます。 しかし、遅かれ早かれ、処理ノードとデータノード間の通信チャネルに遭遇します。
通信チャネルをオーバーフローさせずに負荷を分散する唯一の方法は、ノード間のデータの移動を最小限にすることです。 このため、処理されたデータが存在するマシン上でローカルに最大の計算を実行する必要があります。 MapReduceパラダイムとHadoopのすべての根底にあるのは、 データの局所性の原則です 。
MapReduceの詳細
通常、各MapReduceタスクは、マップフェーズとリデュースフェーズの2つのフェーズで構成されます。 実際、すべてがやや複雑です：最初に、データが分割に分割され、次にそれらのそれぞれに対してマップ関数が実行され、次に結果がソートされ、結合され、再びソートされ、最後にリデュース関数が渡されます。 ただし、パラダイムの基本的な考え方を説明するのはmap and reduceです。
マップ機能を適用する段階で、ローカルで実行できるすべての作業が実行されます。 たとえば、ローカルで1行あたりの単語数をカウントしたり、CSVファイル内の1つのレコードのメトリックを計算したり、ツイートを分析したりできます。 Mapは、透過的な並列化と通信チャネルへの最小負荷を提供します。
ただし、ほとんどのタスクの1つのローカルマップでは不十分です。テキスト全体の単語数を計算するには、各行に単語数を追加し、メトリックの平均値を計算するには、CSVファイルから各レコードの結果を収集する必要があります。 これがまさにreduce関数の目標です。 同時に、ネットワークを介して送信されるデータの量が大幅に削減されます（ローカルリデュースとして機能する結合機能）が非常に役立ちます。
では、同僚が感傷的なツイート分析にHadoopを使用するのはなぜ間違っていたのでしょうか？ 結局、既に述べたように、マップフェーズでは、縮小フェーズを完全に無視して、各ツイートを個別に分析できます。 インフラストラクチャがすべてです。 まず、ツイートを計算ノードに転送する必要があるため、データの局所性の利点が失われます。 第二に、Hadoopはオンライン処理にあまり適していません。作業はデータパケットを使用して実行されるため、最初にツイートを収集してからMapReduceタスクを実行する必要があります。 マップタスクを構成して、ソースからツイートを継続的かつ無限に読み取るように設定した場合でも、Hadoopは、しばらくすると失敗としてタスク全体を強制終了します。 そして、第三に、Hadoopが高速だと聞いた場合、パフォーマンスはデータの移動を最小限に抑えることで達成されることに注意してください。一方、MapReduceジョブ自体は、特に少量のデータで、オーバーヘッドコスト（起動JVM、バックアップタスクの実行、中間結果のディスクへの書き込みなど）。
したがって、適切なツールを適切なタスクに使用すれば、満足するでしょう！