1

私のプロジェクトは、ユーザーがそのデータを発見するための対話クエリを実装しています。ユーザーが選択できる列のリストがあるように、ユーザーはリストに追加してデータを表示します。Cassandra の現在のデータ ストアと、Spark SQL を使用してそこからクエリを実行します。

データ フローは、Spark ストアによって Cassandra に処理された後の生のログです。データは、20 を超える列と 4 つのメトリックを含む時系列です。現在、クラスタ キーに 20 を超えるディメンションがあるため、Cassandra への書き込みが非常に遅いため、テストしました。

ここでのアイデアは、Cassandra から Spark にすべてのデータをロードし、メモリにキャッシュすることです。API をクライアントに提供し、Spark Cache に基づいてクエリを実行します。しかし、キャッシュされたデータを保持する方法がわかりません。機能呼び出しshare objectを持つ spark-job-server を使用しようとしています。しかし、それが機能するかどうかはわかりません。

40 を超える CPU コアと 100 GB の RAM を備えたクラスターを提供できます。クエリするデータは約 100 GB と見積もっています。

私がすでに試したこと：

  • Alluxio に保存し、そこから Spark にロードしようとしますが、4GB のデータをロードするとき、Spark は最初に 2 つのことを行う必要があるため、ロードに時間がかかります。Alluxio からの読み取りには 1 分以上かかり、次にディスクへの保存 (Spark Shuffle) のコストがかかります。 2、3分以上。つまり、目標とする時間は 1 分未満です。8 つの CPU コアで 1 つのジョブをテストしました。
  • MemSQL に格納しようとしますが、コストがかかります。1日で2GBのRAMがかかりました。スケーリングしても速度が維持されているかどうかはわかりません。
  • Cassandra を使用してみますが、Cassandra は GROUP BY をサポートしていません。

それで、私が本当に知りたいのは、私の方向性が正しいかどうかです。目標をアーカイブするために変更できること (多くの group by、SUM、ORDER BY を持つ MySQL のようなクエリ) を API によってクライアントに返します。

4

1 に答える 1

3

DataFrame で明示的にcacheorpersistを呼び出すと、コンテキストがシャットダウンされるまでメモリ (および/または選択したストレージ レベルに応じてディスク) に保存されます。これは にも有効ですsqlContext.cacheTable。

したがって、Spark JobServer を使用しているため、(REST を使用して、またはサーバーの起動時に) 長時間実行されるコンテキストを作成し、同じデータセットに対する複数のクエリに使用できます。これは、コンテキストまたは JobServer サービスが終了するまでキャッシュされるためです。下。ただし、このアプローチを使用する場合は、このコンテキストで十分な量のメモリを使用できるようにする必要があります。そうしないと、Spark がデータの大部分をディスクに保存し、パフォーマンスに影響を与える可能性があります。

さらに、JobServer の Named Objects 機能はジョブ間で特定のオブジェクトを共有するのに役立ちますが、データを一時テーブルとして登録し ( )、df.registerTempTable("name")それをキャッシュする ( sqlContext.cacheTable("name"))場合は必要ありません。これらのジョブが同じコンテキストで実行される限り、ジョブ (sqlContext.sqlまたはを使用)。sqlContext.table

于 2016-05-16T13:06:22.747 に答える