私が知る限り、sparkは、cassandraから読み込むときに、最大1つのタスクをcassandraパーティションごとに使用します。残念ながら、私は非常にアンバランスな(初期のテーブルデザインが悪い)いくつかのパーティションをcassandraに持っています。そのデータを新しいテーブルに読み込む必要があります。これはホットスポットを処理するために設計されていますが、通常のスパーク・アベニューを使用すると効果的に機能しません。私は永遠に動作するいくつかのタスク(10+)を残して、それらのいくつかの巨大なパーティションキーに取り組んでいます。パーティションホットスポットを持つcassandraデータを読み出すためにsparkを効果的に使用するにはどうすればよいですか?
スケールの考え方を示すために、これはサイズが約1.5TBで、レプリケーションファクタが3の5台のサーバーにまたがっています。ノードあたり〜500GB。
他のアイデアは大歓迎ですが、単にCSVにダンプするのはおそらく現実的な選択肢ではありません。
マテリアライズドビューの作成は、これまでのところ行われていません。それは完全に長すぎます。少なくとも3.0.8では、作成中に監視がほとんどまたはまったくありません。
で可能です。また、DF.groupBy( 'partitionKey).count.describeというスパークを行うこともできます。このディストリビューションで配布されるはずです。パーティションキーは実際には最初のクラスタリングキーのプレフィックスです。このアプローチはさらに簡単になります。 私はこれをspark-cassandra-connectorの欠陥の何かに見ています。それに取り組むための標準的な方法を見つけることは面白いでしょう。 – Loki
問題は、Cの分布を知らなくても、カットオフポイントを確立する場所を知る方法がありません。 Cassandraにおおよその統計情報があるまでは、自動的に行うことはあまりありません。しかし、ポイントはあなたが全体を読む前にスライスとユニオンを行うことです。 – RussS