Google DataflowとApache Spark
私はGoogle DataflowおよびApache Sparkを調査して、ビッグデータ分析のビジネスニーズに最適なソリューションを決定しています。
sparkプラットフォームにSpark SQLとMLlibがあり、構造化データのクエリと機械学習を行うことができます。
Google Dataflowプラットフォームに対応するソリューションはありますか？
特定のユースケースを少し拡張できると助かります。 「ビッグデータ分析」に関して何を達成しようとしていますか？短い答え...それは依存します:-)
ここでは、Google Cloud Dataflow v。SparkおよびHadoop MRに関連して考慮すべきいくつかの重要なアーキテクチャポイントを示します。
リソース管理：Cloud Dataflowは完全にオンデマンドの実行環境です。特に、Dataflowでジョブを実行すると、リソースはオンデマンドでそのジョブにのみ割り当てられます。ジョブ間でのリソースの共有/競合はありません。 SparkまたはMapReduceクラスターと比較すると、通常はXノードのクラスターをデプロイしてからジョブを送信し、ジョブ間でノードリソースを調整します。もちろん、これらのクラスターを構築したり分解したりすることはできますが、Dataflowモデルは、リソース管理に関連するハンズフリーの開発者向けのものです。リソースの使用をジョブの要求に合わせて最適化したい場合、Dataflowはコストを制御し、リソースのチューニングをほとんど忘れる強固なモデルです。マルチテナントスタイルのクラスターが必要な場合は、Dataflowなどのオンデマンドクラスター管理機能を提供するGoogle Cloud Dataprocを検討することをお勧めしますが、MR、Spark、PigなどのクラスHadoopワークロードに重点を置いています。
インタラクティブ性：現在 Cloud Dataflowはインタラクティブモードを提供していません。ジョブを送信すると、作業リソースは送信されたグラフにバインドされ、データの大部分は必要に応じてリソースに読み込まれます。 Sparkは、メモリRDDを介してクラスターにデータをロードし、動的にクエリを実行する場合に適しています。課題は、データサイズとクエリの複雑さが増すにつれて、devOpsを処理する必要があることです。ここで、ほとんどのクエリをSQL構文で表現できる場合は、BigQueryを確認することをお勧めします。 BigQueryは、Dataflowの「オンデマンド」の側面を提供し、ペタバイトなどの大量のデータに対してインタラクティブにクエリを実行できるようにします。 BigQueryに関する私の意見の最大の利点は、データサイズを処理するためのハードウェアの割り当てについて考えたり心配したりする必要がないことです。データサイズが大きくなるにつれて、ハードウェア（メモリとディスクのサイズ）の構成について考える必要がなくなります。
プログラミングモデル：Dataflowのプログラミングモデルは、従来のMapReduceモデルと比較して機能的に偏っています。 APIプリミティブに関して、SparkとDataflowの間には多くの類似点があります。考慮事項：1）Dataflowの主要なプログラミング言語はJavaです。 Python SDKが開発中です。 Dataflow Java SDKはオープンソースであり、Scalaに移植されています。今日、Sparkには、GraphX、ストリーミング、Spark SQL、およびMLを使用して、より多くのSDKサーフェスを選択できます。 2）Dataflowは、バッチおよびストリーミングベースのDAG開発用の統合プログラミングモデルです。目標は、バッチモデルとストリーミングモデル間を移動する際の複雑さとコストの切り替えを取り除くことでした。同じグラフをどちらのモードでもシームレスに実行できます。 3）現在、Cloud Dataflowは収束/反復ベースのグラフ実行をサポートしていません。 MLibなどの機能が必要な場合は、Sparkが適しています。これが今日の状況です。
ストリーミングとウィンドウ処理：データフロー（統合プログラミングモデルの上に構築）は、ストリーミング用の非常に信頼性が高く、耐久性があり、スケーラブルな実行環境になるように設計されています。 DataflowとSparkの主な違いの1つは、Dataflowを使用すると、実際のイベント時間と比較して、グラフへの到着時間でデータを処理するだけでデータを簡単に処理できることです。イベント時間または到着時間に基づいて、データを固定、スライド、セッション、またはカスタムウィンドウにウィンドウできます。 Dataflowには、遅延到着データの処理方法を制御できるトリガー（Windowsに適用）も用意されています。分析のニーズを満たすために、正確性制御のレベルでダイヤルするネットネット。たとえば、100個のEdgeノードとやり取りするモバイルゲームがあるとします。これらのノードは、ゲームプレイに関連して2番目に10000のイベントを作成します。ノードのグループがバックエンドストリーミング分析システムと通信できないとします。 Dataflowの場合-そのデータが到着したら、クエリの正確さのニーズに関連してデータを処理する方法を制御できます。 Dataflowは、ストリーミングジョブを実行中にアップグレードする機能も提供します。たとえば、変換の論理的なバグを発見したとします。既存のウィンドウ表示状態を失うことなく、飛行中のジョブをアップグレードできます。あなたがあなたのビジネスを運営し続けることができるネットネット。
Net-net：-本当に主にETLスタイルの作業（フィルタリング、シェーピング、結合など）を行っている場合、またはバッチスタイルのMapReduce Dataflowは、最小限のdevOpsが必要な場合に最適なパスです。
-MLスタイルのグラフを実装する必要がある場合は、Sparkパスに移動してDataprocを試してください-MLを実行していて、最初にETLを実行してトレーニングデータの実装をクリーンアップする必要がある場合DataflowおよびDataprocとのハイブリッド-対話性が必要な場合Sparkは確かな選択ですが、SQLでクエリを表現できる/できる場合はBigQueryもそうです-ETLジョブまたはMRジョブを処理する必要がある場合ストリーム、Dataflowは確かな選択です。
それで...あなたのシナリオは何ですか？
私は両方を試しました：
Dataflowはまだ非常に新しく、MLを使用してMLを実行するための「すぐに使える」ソリューションではありません（変換にアルゴリズムを実装できたとしても）。プロセスデータをクラウドストレージに出力し、後で別の方法で読み取ることができます。ツール。
Sparkが推奨されますが、クラスターを自分で管理する必要があります。ただし、適切な代替手段があります：Google Dataproc
sparkを使用して分析ツールを開発し、1つのコマンドでクラスターにデプロイできます。dataprocは、構成を微調整する必要なくクラスター自体を管理します。
Spark、DataFlowを使用してコードを作成しました。考えてみます。
Spark/DataProc：ETLでspark（Pyspark）をたくさん使用しました。SQLや任意のプログラミング言語を使用できます。多くの関数が使用できます（ウィンドウ関数を含む）。データフレームを作成して変換を書き込むと、変換が非常に高速になります。データがキャッシュされると、Dataframeでのすべての操作が高速になります。
GCSにHive外部テーブルを構築するだけです。次に、SparkをETLに使用して、データをBig Queryにロードします。これはバッチ処理用です。
ストリーミングでは、sparkストリーミングを使用して、データをBigクエリにロードできます。
さて、クラスタがすでにある場合は、Googleクラウドに移行するかどうかを検討する必要があります。多くのクラスター管理を心配する必要がないため、Data proc（Google Cloud Hadoop/Spark）オファリングの方が優れていることがわかりました。
DataFlow：Apacheビームとして知られています。ここでは、Java/Pythonまたはその他の言語でコードを記述できます。任意のフレームワーク（Spark/MR/Flink）でコードを実行できます。これは統合モデルです。ここでは、バッチ処理とストリームデータ処理の両方を実行できます。
グーグルは現在mapreduceとsparkの両方のプログラミングモデルを提供しています。 Cloud DataFlowおよびCloud DataProcそれらはそれぞれ