Kaskadaが新しいクエリ言語の創造から始めた理由〜イベント、タイムライン、

はじめに

先日、以下の記事を発表しました。

新しいテクノロジーに触れる時はいつでも楽しいものです。

まだまだ勉強中ですが、公式ドキュメントの学習過程の記録として、以下の記事をまとめてみました。

本稿情報のソースとして、下記ドキュメントを参照ください。

新しいクエリ言語が生み出された理由

Kakada開発チームは独自の言語を実装するのではなく、既存の言語に基づいて構築する方法を見つけるために繰り返し試みてきました。そして彼らが発見したのは、基本的な抽象化が必須であるということでした。

SQL はテーブルに格納されたスタティックなデータへの問い合わせであり、SQL をクエリ言語として使用すると、自然表現からテーブルへの不可逆変換が強制されます。

SQL以外にもクエリ言語は存在し、
Gremlin がグラフに、PromQL が時系列データの操作に広く用いられているのには理由があります。
つまり、これらのクエリ言語は、クエリ対象のデータに合わせた基本的な抽象化を採用しているからです。

Kaskada開発チームは：

• イベント データについて推論するための最も適切な抽象化はタイムラインであると考え、この考えに基づいてクエリ言語を構築しました。
• タイムラインは、「バルクとストリーミング」などの実装の詳細を漏らすことなく、生のイベント フィードの豊富さをキャプチャするものです。
• タイムラインは timeseries よりも一般的ですが、timeseries 操作と互換性があります。
• タイムラインは時間を明示的にモデル化するため、テーブルほど一般的ではありません（テーブルよりも特殊な要件に応えるものです）。これにより、操作できるデータの種類が制限されますが、連続的および一時的な関係をより自然に表現できるようになります。

タイムラインには、時間を視覚的に理解するのに役立つ、おなじみの便利な「幾何学的抽象化(geometric abstraction)」が含まれています。

Invisibility. Software is invisible and unvisualizable. Geometric abstractions are powerful tools. The floor plan of a building helps both architect and client evaluate spaces, traffic flows, and views. Contradictions become obvious, omissions can be caught. Scale drawings of mechanical parts and stick-figure models of molecules, although abstractions, serve the same purpose. A geometric reality is captured in a geometric abstraction.("No Silver Bullet —Essence and Accident in Software Engineering"
Frederick P. Brooks, Jr. )

不可視。 ソフトウェアは目に見えず、可視化することもできません。 幾何学的抽象化は強力なツールです。 建物の平面図は、建築家とクライアントの両方がスペース、交通の流れ、眺望を評価するのに役立ちます。 矛盾が明らかになり、漏れが見つかる可能性があります。 機械部品の縮尺図と分子の棒線図モデルは、抽象化されていますが、同じ目的を果たします。 幾何学的な現実は幾何学的な抽象化の中に捉えられます。

タイムラインと Timeseries との関係

時系列データベースは、時系列データを操作する一般的な方法です。timeseries は、それぞれが異なる時間に関連付けられた一連の値を取得します。ほとんどの場合、時系列データは基準となる間隔 (秒や分など) に基づいて編成されています。このように事前定義されたタイムシリーズデータは、ある種の操作に役立ちます。たとえば、標準 SQL を使用する場合よりも、何も起こらなかった時間間隔を推論するのが簡単です。

秒単位や分単位のような基準を前提とする場合の欠点は、ソース データが このようなtimeseries 形式の前提に準拠していない場合があることです。timeseries は、多くの場合、各時間間隔でのイベントの発生をカウントすることによって生成されます。そして、瞬間的なイベントからウィンドウ集計への変換時に情報が失われることが起こり得ます。

タイムラインは timeseries に似ており、それらは、どちらも異なる時間に関連付けられた値を扱います。違いは、タイムラインは任意の数の値を記述し、標準間隔に依存しないことです。この意味で、時系列はタイムラインの特殊なケース（「標準間隔」のすべての時点でイベントが記録されているタイムラインというケース）であるといえます。

Kaskada は、タイムラインを時系列に変換するための操作を提供します。たとえば、イベント タイムラインPurchaseを毎日のイベント数の時系列に変換するには、次のようにします。

Purchase | count(since(daily()))

「イベントデータ」の例にはどのようなものがあるか?

「イベント」とは、特定の時間に関連する世界に関するあらゆる事実です。イベントは、次のような単純な観察を記録します。

アリスは、3 月 23 日木曜日 16:54:04 UTC にテニス ボールを購入しました。

イベントは事実であるため、強力です。それらは時間が経っても変わりません。アリスは購入をキャンセルするか、返金のためにテニス ボールを返品することができますが、これによって元の購入の事実は変わりません。

イベントはさまざまな方法で生成されます。

• ユーザーのクリック、スワイプ、ページビュー、フォームの操作
• アプリケーションログ
• 外部サービスからのコールバック
• 可変データ ストアからの変更データ キャプチャ (CDC) イベント
• ストリーミング コンピューティング ジョブの出力

イベントが発生したときにそれを収集することで、アプリケーションは世界の変化に即座に対応できます。

なぜ、イベントから直接計算するのか?

イベントは多くの場合、使用する前に前処理が必要な「生」データとして扱われます。あなたは、生のイベントを正規化、フィルタリングし、使いやすいテーブルのセットに集約するために、多数の ETL 操作を経たデータを扱うことに慣れているかもしれません。このタイプのデータ処理は、一貫したビジネス ロジックを確保し、「正しい」データの操作を開始するのに必要な時間を最小限に抑えるのに役立ちます。

残念ながら、この方法にはいくつかの欠点がある可能性があります。

• 事前集計では、元のデータよりも細かい時間解像度で結果が生成されることが多く、多くのリアルタイム データ アプリケーションはこの粒度に依存しています。多くの場合、過去数分または数秒間に何が起こったかを知ることが重要です。昨日何が起こったかを知るだけでは十分ではありません。

• ETL と前処理パイプラインは、何が重要で何が重要でないかを決定することになることがよくあります。これらの決定はパイプライン作成時の優先順位を反映しますが、最終的には新しいソリューションを反復して構築することが困難になる可能性があります。

• 「クリーンな」テーブルを操作するということは、通常、大規模なデータセットを共有してコラボレーションすることを意味します。課題は、そのデータの意味を理解する必要があるときに起こります。ビットのバケットを共有する場合、それを生成するために使用されるビジネス ロジックではなく、セマンティクスが失われることがよくあります。

Kaskada は、実務者が生のイベントを実用的なデータに変換するために必要なクリーニング操作の完全なセットを記述できるように設計されています。コード共有によるコラボレーションにより、出力がどのように定義されているかを理解しやすくなり、それらの定義を反復することが容易になります。