問題タブ [snappydata]

SnappyData v0.5

私の目標は、SnappyData インストールの /bin ディレクトリから "spark-shell" を開始し、SnappyData ストア内の既存のテーブルに対して Scala コマンドを発行することです。

私は SnappyData ストア、ロケーター、およびリードと同じホスト上にいます (もちろん、それらはすべて実行されています)。

これを行うには、こちらのドキュメントに従ってこのコマンドを実行しています。

spark-shell を使用してクラスターに接続する

~/snappydata/bin$ spark-shell --master local[*] --conf snappydata.store.locators=10.0.18.66:1527 --conf spark.ui.port=4041

ストアにスパークシェルを作成しようとすると、次のエラーが発生します。

[TRACE 2016/08/12 15:21:55.183 UTC GFXD:error:FabricServiceAPI tid=0x1] サーバーの起動中に XJ040 エラーが発生しました: java.sql.SQLException(XJ040): データベースの起動に失敗しました
詳細については、原因を参照してください。java.sql.SQLException(XJ040): データベース 'snappydata' の起動に失敗しました。詳細については原因を参照してください。com.pivotal.gemfirexd.internal.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:124) で com.pivotal.gemfirexd.internal.impl.jdbc.Util.newEmbedSQLException(Util.java:110) で com.pivotal .gemfirexd.internal.impl.jdbc.Util.newEmbedSQLException(Util.java:136) com.pivotal.gemfirexd.internal.impl.jdbc.Util.generateCsSQLException(Util.java:245) com.pivotal.gemfirexd.internal で.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:3380) com.pivotal.gemfirexd.internal.impl.jdbc.EmbedConnection.(EmbedConnection.java:450) com.pivotal.gemfirexd.internal.impl.jdbc. EmbedConnection30.

原因: com.gemstone.gemfire.GemFireConfigException: ロケーター サービスに接続できません (タイムアウト = 5000 ミリ秒)。操作がタイムアウトしたか、ロケーターが存在しません。ロケーターの構成リストは「[dev-snappydata-1(null):1527]」です。com.gemstone.gemfire.distributed.internal.membership.jgroup.GFJGBasicAdapter.getGemFireConfigException(GFJGBasicAdapter.java:533) で com.gemstone.org.jgroups.protocols.TCPGOSSIP.sendGetMembersRequest(TCPGOSSIP.java:212) で com.gemstone .org.jgroups.protocols.PingSender.run(PingSender.java:82) at java.lang.Thread.run(Thread.java:745)

私はドキュメント ( http://snappydatainc.github.io/snappydata/streamingWithSQL/ ) を読んでいて、kafka で作業するときにトピック名の後にあるパラメーター ":01" が何を意味するのか知りたいと思っていました。これはパーティション番号ですか、それともサーバーが使用しているスレッドの数ですか?

例: 「トピック 'streamTopic: 01 '

これがどこかに言及されていたら申し訳ありませんが、私はそれを見つけることができませんでした.

デフォルトのバケット数は 113 です。なぜですか? なぜ110ではないのですか？バケット ロジックは、特定の「割り切れる」値でパフォーマンスが向上しますか。

バケットが少ない SnappyData には多くの例があります。何故ですか？デフォルトの 113 より少ないバケットを使用することを決定したロジックは何ですか?

より少ない選択の意味は何ですか？より多くのバケツはどうですか？各バケットでデータを探している Spark SQL クエリで多くのログが記録されています。バケットを増やすと、クエリのパフォーマンスが低下しますか?

時系列データを収集し、snappydata ストアに保存したいと考えています。何百万行ものデータを収集し、タイムスライス/範囲全体でクエリを実行したいと考えています。

これが私がやりたいクエリの例です：

そこで、従来の PRIMARY KEY 列ではなく、TIME 列に PARTITION BY COLUMN を配置したいと考えています。私がよく知っている Cassandra DB などの他のテクノロジでは、パーティション キーで時間列を使用すると、パーティションが直接示され、多くの分散ノードではなく、単一のノードでタイムスライスのデータを取得できます。

パフォーマンスを向上させるには、このテーブルの「時間」列でパーティション分割する必要があると思います。

これは、効率的なタイム スライス クエリのためにパーティション分割する正しい列ですか、それとも year_num、month_num、day_num、hour_num 列、および PARTITION BY COLUMN のような列をさらに作成する必要がありますか?次に、次のようなクエリを実行します。これにより、クエリを特定のパーティション ノードに集中させることができますか?:

20 個の SnappyData ノードがあるとします。

そして、私はこのようなテーブルを持っています:

example_timeseries_table

そして、私はクエリを作成します：

SnappyData は 20 個のノードすべてを呼び出し、結果を収集してから応答を返しますか? もしそうなら、このタイプのクエリを作成する方法をどのように改善しますか? 「foo」をPARTITION列にするために、テーブルを別の方法で設計する必要がありますか?

ドキュメント ( http://snappydatainc.github.io/snappydata/streamingWithSQL/ ) を読んで、この項目について質問がありました:

「共同パーティショニングによるシャッフルの削減: SnappyData を使用すると、入力キュー (Kafka ソースなど) で使用されるパーティショニング キー、ストリーム プロセッサ、および基礎となるストアはすべて同じにすることができます。これにより、レコードをシャッフルする必要性が劇的に減少します。」

Kafka を使用していて、キー (単一値) を使用してトピック内のデータを分割する場合。この単一のキーを kafka から、スナッピー テーブルで識別される複数のパーティション キーにマップすることは可能ですか?

複数のキーを単一のキーに変換する何らかのハッシュはありますか?

シャッフルを減らすことの利点は大きいと思われ、ここでベスト プラクティスを理解しようとしています。

ありがとう！