8. Streaming SQL

What Is Streaming SQL?

何十年もの間、私たちの業界では見つかっていなかったと言えるでしょう。
- 公平を期して言えば、データベース・コミュニティは、かなり以前から答えの99％を理解していました。
- 堅牢なストリーミング・セマンティックスの全範囲を網羅する、真に説得力のある包括的なストリーミングSQLの定義にはまだお目にかかったことがありません。
99.1%くらいの回答を出す予定
- いずれにせよ、この章で説明することのほとんどは、執筆時点ではまだ純粋に仮説に過ぎないことを、前もって指摘しておきたいと思います。
- この章とその後に続く章（ストリーミングジョインについて）は、ストリーミングSQLの理想的なビジョンを述べています。いくつかの部分はApache Calcite、Apache Flink、Apache Beamのようなシステムですでに実装されています。他の多くはどこにも実装されていません。
ここで紹介するストリーミングSQLのビジョンは、Calcite、Flink、Beamの3つのコミュニティが共同で議論した結果であることも強調しておきたい

Relational Algebra

ストリーミングがSQLにとってどのような意味を持つかを語るとき、SQLの理論的基盤である関係代数を念頭に置くことが重要である。
関係代数は、名前と型が付けられたタプルからなるデータ間の関係を記述するための数学的な方法です。
- 関係代数の中心はタプルの集合に関する関係そのものです。
- 古典的なデータベース用語では、関係はテーブルのようなもので、物理的なデータベーステーブル、SQLクエリの結果、ビュー（マテリアライズドまたはその他）など、名前と型が付けられたデータの列を含む行の集合である
関係代数のより重要な側面の1つは、その閉鎖性(closure property)である。関係代数の演算子を有効な関係に適用すると、必ず別の関係が生成される。言い換えれば、関係は関係代数の共通通貨であり、すべての演算子は関係を入力として消費し、出力として生成する。
歴史的に、SQLでストリーミングをサポートする多くの試みは、クロージャの特性を満たすには至りませんでした。ストリームを古典的な関係とは別に扱い、両者を変換する新しい演算子を提供し、どちらか一方に適用できる演算を制限しているのです。
- 新しい演算子を学び、適用できる場所とできない場所を理解し、同様に古い演算子についてもこの新しい世界での適用ルールを学び直さなければならないからです。さらに悪いことに、これらのシステムのほとんどは、堅牢な順序外処理のサポートや強力な時間的結合のサポート（後者については第9章で取り上げます）など、私たちが望むストリーミングセマンティックスの完全なスイートを提供するにはまだ不十分です。
- その結果、本当に広く採用された既存のストリーミングSQL実装の名前を挙げることは基本的に不可能であると私は主張します。
この状況を変え、真にストリーミングSQLを最前線に押し上げるために必要なのは、ストリーミングを関係代数自体の一流市民とする方法であり、標準の関係代数全体がストリーミングと非ストリーミングの両方の使用例において自然に適用できるような方法です。
- この事実を認識することで、まもなくわかるように、ストリームとテーブルの関係を明確に理解し、ナビゲートすることができるようになります。しかし、核となる代数は、両方の世界にきれいで自然に適用されるべきで、絶対に必要な場合にのみ、標準の関係代数を超える最小限の拡張を行います。

Time-Varying Relations

この章のポイント
- ストリーミングをSQLに自然に統合するための鍵は、
  - 関係代数のコアデータオブジェクトである「関係」を拡張し、「特定の時点のデータセット」ではなく、「時間経過によるデータセット」を表現することである
しかし、時間変化する関係とは何だろうか。まず、古典的な関係代数の観点から定義し、その後、ストリーム理論やテーブル理論との関係についても考えてみよう。
関係代数の観点からは、時変関係は古典的な関係が時間と共に変化したものである。
- ユーザーイベントからなる未加工のデータセットを想像してみよう。
- 時間の経過とともに、ユーザーが新しいイベントを生成すると、データセットは成長し進化し続ける。ある時点でそのデータセットを観察すれば、それは古典的な関係である。
- しかし、時間の経過に伴う集合の全体的な進化を観察するのであれば、それは時間変化する関係である。
- 例
  - 本書の他の例のように、モバイルゲームのユーザーごとのスコアなどである。
  - そして、この例のデータセットが、特定の時点（この場合は12:07）で観測されると、最終的に以下のような形になると仮定します。
```
12:07> SELECT * FROM UserScores;
-------------------------
| Julie | 7
| Frank | 3
| Julie | 1
| Julie | 4
-------------------------
```
- この関係において到着したデータがこれだけであったとすると、12時7分以降に観測したときには、先の表のような状態になる。しかし、もし私たちが12時1分にこの関係を観察していたとしたら、次のようになるはずです。
```
12:01> SELECT * FROM UserScores; -------------------------
| Name | Score | Time | -------------------------
| Julie | 7     | 12:01 |
-------------------------
```
- その後、12時3分にもう一度観測していれば、フランクのスコアとジュリーの2回目のスコアも到着しているので、関係は次のように発展していくだろう。
```
12:03> SELECT * FROM UserScores; -------------------------
| Name | Score | Time | -------------------------
| 12:01 |
| 12:03 |
| 12:03 |
```
この例から、このデータセットの時変関係がどのようなものでなければならないか、感覚をつかみ始めることができる
- それは時間の経過に伴う関係の全変化を捉えるものである。
- したがって、12:07以降に時変関係（TVR）を観察すると、以下のようになる。
- （仮想的なTVRキーワードの使用は、古典的な関係の標準的なポイントインタイムスナップショットではなく、時変関係全体を返すように問い合わせをしたいことを示すことに注意する）。

Untitled

時間的に変化する関係が、本質的に一連の古典的な関係（左から右、上から下の順）で構成され、それぞれが特定の時間範囲（定義上、これらはすべて連続する）の関係の全容を捉えていることがおわかりいただけると思います。
時変関係をこのように定義することの重要な点は、時変関係はどこから見ても、それぞれがバラバラの（しかし隣接した）時間範囲内に独立して存在する古典的関係のシーケンスであり、それぞれの範囲は関係が変化しなかった期間を表しているということである。
- これは、時間的に変化する関係に対して関係演算子を適用することは、対応するシーケンス内の古典的な関係に対して個別にその演算子を適用することと同じであることを意味するので、重要である
さらにもう一歩踏み込むと、それぞれが関連付けられた時間間隔を持つ関係の列（sequence)に関係演算子を個別に適用した結果は、必ず同じ時間間隔を持つ関係の列が対応することになる。
- 言い換えれば、その結果は対応する時間変化する関係である。この定義により、2つの非常に重要な性質が得られる。