スパークストリーミングの学習

Question

私は「スパークストリーミングの学習」という本を使用してスパークストリーミングを学習しています。本の中で私はDstream、RDD、ブロック/パーティションについて話しているセクションで以下を見つけました。

最後に、このスキーマにオーバー練りされた一つの重要な点は、受信インターフェースは、データ片のコレクション（思うアレイ）を提供し、データ・ソースに接続するオプションを有することです。これは、たとえば、一部の逆シリアル化の使用に特に関係します。この場合、レシーバはデータのパーティション分割を処理するためにブロックインターバル待機を行わず、コレクション全体がブロックにデータのセグメンテーションを反映しているとみなし、コレクションの各要素に対して1つのブロックを作成します。この操作は、確実に機能するためにブロック間隔とバッチ間隔の比でブロックを生成する必要があるため、データのプロデューサ側では必要です（すべてのバッチで正しい数のブロックを配信する）。しかし、優れたパフォーマンスを提供することができ、シリアル化のためにすぐに多くのブロックを利用できるようにする実装を提供しているユーザーもいます。

私は頭を叩いていて、著者が何を話しているのか分かりませんが、私は理解しなければならないと感じています。誰かがそれについて私にいくつかの指摘を与えることができますか？

Answer 1

開示：私は本の共著者です。

カスタムレシーバAPIには2つの作業モードがあります。作成側が1つのメッセージを1つのメッセージで配信するモードと、受信者が複数のメッセージをまとめて配信できるモード（バルク）です。

• 1メッセージ・アット・タイム・モードでは、Sparkはデータをバッファリングし、後で処理するためにブロックに集める役割を担います。
• バルクモードでは、バッファリングとグループ化の負担は生産側にありますが、一部のシナリオではより効率的です。

これはAPIに反映されます。

は

def store(dataBuffer: ArrayBuffer[T]): Unit 
    Store an ArrayBuffer of received data as a data block into Spark's memory. 

def store(dataItem: T): Unit 
    Store a single item of received data to Spark's memory. 

私はあなたに同意段落が複雑であり、我々が望むほど明確なメッセージを伝えていない可能性があること。私はそれを改善する世話をします。

ご意見ありがとうございます。