まず第一に、あなたの質問は、あなたがビッグデータによって何を意図しているのかをより明確に定義する必要があります.
実際、ビッグデータは、さまざまなサイズの問題を指すバズワードです。私はビッグデータを、データサイズまたは計算時間が「ハードウェアの抽象化が壊れる」ほど大きい問題のカテゴリとして定義する傾向があります。つまり、単一の汎用マシンでは、計算とメモリを集中的に管理しないと計算を実行できません。 .
したがって、データがビッグ データになるスケールのしきい値は不明確であり、実装に影響されます。あなたのアルゴリズムはハードドライブの帯域幅に制限されていますか? メモリに足を踏み入れる必要がありますか？不必要な二次コストを回避しようとしましたか? キャッシュ効率などを改善するための努力はありましたか。
中規模で大規模な機械学習の課題 (最大 250 百台のコモディティ マシン) を実行してきた数年間の経験から、分散インフラストラクチャを必要とするように見える多くの問題は、問題が表現されている場合、実際には単一のコモディティ マシンで実行できると強く信じています。正しく。たとえば、小売業者向けの大規模データについて言及しています。私はこの正確なテーマに数年間取り組んできましたが、少しの最適化を提供して、すべての計算を 1 台のマシンで実行することができました。私の会社は、非常に大規模な小売業者からのすべてのデータの 1 年分を 50GB 以内に保存できるようにする単純なカスタム データ フォーマットに取り組んできました。たとえば、次をご覧ください。https://github.com/Lokad/lokad-receiptstream
私の経験からすると、分散アーキテクチャに頼らずに済むように、アルゴリズムとメモリを最適化することに時間を費やす価値があります。実際、分散アーキテクチャには 3 倍のコストがかかります。まず第一に、強い知識要件。第 2 に、コードの複雑なオーバーヘッドが大きくなります。最後に、分散アーキテクチャにはかなりのレイテンシ オーバーヘッドが伴います (ローカル マルチスレッド分散を除く)。
実践者の観点からすると、特定のデータ マイニングまたは機械学習アルゴリズムを 30 秒で実行できることは、効率化の重要な要素の 1 つです。シーケンシャルであれ分散であれ、一部の計算に 10 分かかる場合よりも、新しいアイデアをすばやく反復してすばやくテストすることがはるかに複雑になるため、集中力と効率が急速に低下する傾向があることに気付きました。多くの分散フレームワークによって導入されるレイテンシ オーバーヘッドにより、必然的にこの効率の悪いシナリオに陥ります。
問題の規模が非常に大きく、1 台のマシンでは実行できない場合は、独自のフレームワークを構築するのではなく、既製の分散フレームワークを使用することを強くお勧めします。最もよく知られているフレームワークの 1 つは MapReduce 抽象化で、Apache Hadoop から利用できます。Hadoop は 10,000 ノードのクラスターで実行できますが、これはおそらく必要以上のものです。ハードウェアを所有していない場合は、Amazon MapReduce などを通じて、Hadoop クラスターの使用を「レンタル」できます。
残念ながら、MapReduce の抽象化は、すべての機械学習計算に適しているわけではありません。機械学習に関する限り、MapReduce は厳格なフレームワークであり、多くのケースでこのフレームワークに適応することが困難または非効率的であることが証明されています。
– MapReduce フレームワークは、それ自体が関数型プログラミングに関連しています。Map プロシージャは、各データ チャンクに個別に適用されます。したがって、MapReduce フレームワークは、一部のデータ チャンクへの Map プロシージャの適用が、前提条件として他のデータ チャンクへの同じプロシージャの結果を必要とするアルゴリズムには適していません。言い換えれば、MapReduce フレームワークは、異なるデータ間の計算が独立しておらず、特定の年表を課す場合には適していません。
– MapReduce は、map および reduce ステップの単一実行を提供するように設計されており、反復呼び出しを直接提供しません。したがって、反復処理を伴う多数の機械学習問題 (期待値最大化 (EM)、信念伝播など) には直接適していません。これらのアルゴリズムを MapReduce フレームワークに実装するということは、ユーザーは、結果の取得と複数の反復のスケジュールを編成するソリューションを設計する必要があることを意味します。これにより、前の反復の削減フェーズが完了した後に各マップの反復が開始され、各マップの反復が開始されます。前の反復の削減フェーズによって提供された結果が供給されます。
– ほとんどの MapReduce 実装は、本番環境のニーズと堅牢性に対応するように設計されています。その結果、フレームワークの主な関心事は、ハードウェア障害を処理し、計算結果を保証することです。したがって、MapReduce の効率は、これらの信頼性の制約によって部分的に低下します。たとえば、計算結果のハードディスクへのシリアル化は、かなりコストがかかる場合があります。
– MapReduce は非同期アルゴリズムには適していません。
MapReduce フレームワークへの疑問は、このユーザーにとってより複雑になるという代償を払って、より多くの制御と自由がフレームワークのユーザーに委ねられる、よりリッチな分散フレームワークにつながりました。これらのフレームワークの中で、GraphLab と Dryad (どちらも計算の直接非巡回グラフに基づく) がよく知られています。
結果として、「フリーサイズ」のデータストレージソリューションが存在しないなど、「フリーサイズ」のフレームワークは存在しません。
Hadoop から始めるには、Tom White 著『Hadoop: The Definitive Guide』を参照してください。
大規模なフレームワークが機械学習の要件にどのように適合するかに興味がある場合は、私の博士号の第 2 章 (英語) に興味があるかもしれません。 /74/47/68/ANNEX/texfiles/PhD%20Main/PhD.pdf
対処したい特定の課題 (アルゴリズムの種類、データのサイズ、時間とお金の制約など) についてより多くの洞察を提供していただければ、より具体的な回答を提供できる可能性があります。
編集 : 興味深いと思われる別のリファレンス :機械学習のスケールアップ