Apache Spark によるストリーム処理

第27章. ストリーミング近似とサンプリング・アルゴリズム

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

ストリーム処理（ ）は、観測されたデータのサマリーを時系列で作成する際に、特別な難題を突きつける。ストリームの値を観測するチャンスは一度しかないため、境界のあるデータセット上では単純と思われるクエリでも、データストリーム上で同じ質問に答えようとすると困難になる。

問題の核心は、これらのクエリが、例えばデータセット全体を観察する必要があるような、大域的な要約や至上命題のような結果をどのように求めるかにある：

• ストリーム内のすべての異なる要素のカウント（要約）。

• ストリームの最も高いk個の要素（大域的至上点）

• ストリームの最も頻度の高いk個の要素（大域的な上位要素）。

当然ながら、データがストリームから送られてくる場合、難しいのはデータセット全体を一度に見ることである。この種のクエリは、ストリーム全体をストアし、それをデータのバッチとして扱うことで素朴に答えることができる。しかし、この保存方法は常に可能とは限らないばかりか、強引なアプローチでもある。後述するように、ストリームの主な数値や特性を反映した簡潔なデータ表現を構築することができる。この簡潔さには代償があり、それは返される答えの正確さで測られる。これらのデータ構造とそれを演算するアルゴリズムは、特定のエラー境界を持つ近似的な結果を返す。 ：

• 正確なアルゴリズムはより正確だが、非常にリソースを消費する

• 近似アルゴリズムは精度が落ちるが、余分なリソースコストをかけるくらいなら、多少精度が落ちても構わない。

このセクションでは、限られたリソースを使用して、ストリームで観測された要素に対するグローバルな疑問を時間経過とともに整理するのに役立つ、近似アルゴリズムとサンプリングテクニックの応用について研究する。 はじめに、大量のデータを前にして、リアルタイムのレスポンスとそのレスポンスの正確さとの間の緊張関係を探る。 次に、3つのカバーされた近似方法を理解するのに必要な、ハッシュとソートの概念を紹介する：

ハイパーログログ（HLL）

明確な要素をカウントする場合

カウントミンスケッチ（CMS）

要素の頻度カウント用

Tダイジェスト

観測要素の頻度ヒストグラムを近似する。

この章の最後に、様々なサンプリングメソッドの概要と、それらがSparkでどのようにサポートされているかを紹介する。

正確さ、リアルタイム、ビッグデータ

分散型 コンピューティングは、連続的に流れるデータを演算する場合、三角形の概念に制約されるという点で、しばしば特殊化されたものとみなされる：

• プロデューサの正確さ

• リアルタイムで計算が行われる

• ビッグデータの計算

これらの概念について詳しく見ていこう：

正確さ

第一に、厳密な計算とは、データから得られる質問に答える正確な数値結果を出す必要性の反映であると考えることができる。例えば、Webサイトから送られてくるデータを監視している場合、Webサイトが生成する対話、イベント、ログを分析することで、現在のユーザの数を理解したいと思うかもしれない。

リアルタイム処理

2つ目の側面は、分析の鮮度または遅延である。 この文脈では、遅延とは、データが最初に利用可能になった瞬間から、そこから何らかの洞察を得られるようになるまでの時間に関係する。 Webサイトの訪問者の例に戻ると、1日の終わりに、 ...