過去 10 年間における機械学習の成長と成功は、主に膨大な量のデータと高度な計算能力の利用可能性によって促進され、驚異的でした。この急増はさまざまな分野のデジタル化によってもたらされ、ソーシャル メディアの投稿からオンライン トランザクションやセンサー データに至るまで、あらゆるデジタル データの爆発的な増加につながりました。

機械学習技術、特に深層学習の進歩により、より複雑で汎用性の高いモデルの開発が容易になりました。その結果、機械学習アプリケーションは遍在するようになり、医療、金融、運輸などの多くのセクターにわたって効率と機能の向上に貢献しています。

これらの大量のイベントベースのデータを操作し、イベント自体とそのコンテキスト（近くで起こっている他のイベント）から価値を引き出すことは依然として困難です。これをリアルタイムまたはストリーミングで行うのはさらに困難です。多くの場合、複雑な低レベル API を使用するか、SQL など、非常に異なる問題を解決するために設計された高レベルのクエリ言語の制限を回避する必要があります。

これらの課題に取り組むために、タイムラインと呼ばれる時間ベースのデータの新しい抽象化を導入します。タイムラインは時間とエンティティごとにデータを整理し、直感的でグラフィカルなメンタル モデルを備えたイベントベースのデータに理想的な構造を提供します。タイムラインを使用すると、メンタル モデルを問題領域に合わせることで時間に関する推論が簡素化され、それをどのように表現するかではなく、何を計算するかに集中できるようになります。

この投稿では、イベントベースのデータを整理して価値を直接抽出する自然な方法として、また機械学習やプロンプト エンジニアリングへの入力としてタイムラインを紹介します。タイムラインの概念、外部データ ストア (入力および出力) との相互作用、およびタイムラインを使用したクエリのライフサイクルについて詳しく説明します。

この投稿は、タイムラインの抽象化を中心に設計されたオープンソースのイベント処理エンジンであるKaskadaに関するシリーズの最初の記事です。続いて、Kaskada がタイムライン抽象化上で表現力豊かな時間クエリ言語を構築する方法、タイムライン データ モデルによって Kaskada が時間クエリを効率的に実行できるようにする方法、そして最後に、タイムラインによって Kaskada がイベント ストリーム上でどのように段階的に実行できるようになるかについて説明します。

時間の意味を理解する

SQL が世界を認識する方法のように、各種類のイベントを個別の順序付けされていないデータ テーブルとして扱う場合、多種多様なイベントを処理することは困難です。何がカーラに購入の動機を与えたのか、あるいは何がアーロンにメッセージを通じて他のユーザーと関わったのかを理解するのは困難です。

データを時間別、ユーザー別に整理することで、パターンを発見するのがはるかに簡単になります。アーロンは勝利後にメッセージを送信します。カーラは、損失が続いてイライラしたときに購入をします。また、ブラッドがプレーをやめた可能性があることもわかりました。

データを時間別、ユーザー別に整理することで、パターンを発見するのがはるかに簡単になります。アーロンは勝利後にメッセージを送信します。カーラは、損失が続いてイライラしたときに購入をします。また、ブラッドがプレーをやめた可能性があることもわかります。

イベントを時間別、ユーザー別に自然な方法で整理することで、パターンを特定することができました。この同じ構成により、イベントから計算された特徴値を表現し、それらを使用して機械学習モデルをトレーニングおよび適用したり、プロンプト内で使用する値を計算したりすることができます。

タイムラインの抽象化

時間についての推論 (たとえば、イベント間の因果関係など) には、単に順序付けされていないイベント データのセット以上のものが必要です。一時的なクエリの場合、抽象化の第一級の部分として時間を含める必要があります。これにより、イベントがいつ発生したか、イベント間の順序と時間について推論できるようになります。

Kaskada はタイムライン抽象化、つまり時間によって順序付けされ、エンティティごとにグループ化されたマルチセットに基づいて構築されています。タイムラインは、以下に示すように自然に視覚化されます。時間が x 軸に表示され、対応する値が y 軸に表示されます。 Ben と Davor の 2 人からの購入イベントを考えてみましょう。これらは、購入の時間と金額を反映する個別のポイントとして表示されます。これらは離散点を表すため、これらを離散タイムラインと呼びます。

タイムラインの時間軸は、計算結果の時間を反映します。たとえば、どの時点でも、「すべての購入の合計はいくらですか?」と尋ねる可能性があります。タイムライン上の集計は累積的です。イベントが観察されると、質問に対する答えが変わります。各値は次の変更まで継続するため、これらのタイムラインを連続タイムラインと呼びます。

SQL と比較して、タイムラインには、時間による順序付けとエンティティによるグループ化という 2 つの要件が導入されます。 SQL リレーション (順序なしマルチセットまたはバッグ) は順序なしデータに役立ちますが、タイムラインの追加要件により、因果関係を推論するのに理想的になります。タイムラインは時間データに対して、リレーションは静的データに対して同様です。

これらの要件を追加すると、タイムラインがすべてのデータ処理タスクに適合しないことになります。代わりに、イベントと時間を扱うデータ処理タスクによりタイムラインを適合させることができます。実際、ほとんどのイベント ストリーム (Apache Kafka、Apache Pulsar、AWS Kinesis など) は、キーによる順序付けとパーティション化を提供します。

出来事と時間について考えるとき、おそらくすでにタイムラインのようなものを思い浮かべているでしょう。時間についてのすでにの考え方と一致させることで、タイムラインは出来事と時間についての推論を簡素化します。時間と順序の要件を組み込むことにより、タイムラインの抽象化により、時間クエリで原因と結果を直感的に表現できるようになります。

一時的なクエリにタイムラインを使用する

タイムラインは、Kaskada で一時的なクエリを構築するために使用される抽象化ですが、データは Kaskada の外部で開始および終了します。入力からタイムライン、そして最終的に出力までのデータの流れを理解することが重要です。

すべてのクエリは 1 つ以上の入力データ ソースから始まります。ストリームに到着するイベントやテーブルに保存されたイベント、あるいはテーブルに保存されたファクトなど、各入力は、各イベントの時間などの重要なコンテキストを失うことなくタイムラインに変換できます。

クエリ自体は一連の操作として表現されます。各操作により、タイムラインからタイムラインが作成されます。最終操作の結果はクエリの結果として使用されます。したがって、クエリは、離散的または連続的なタイムラインを生成します。

クエリの結果はタイムラインであり、シンクに出力される場合があります。シンクに書き込まれる行は、タイムライン内の変更を反映する履歴、または特定の時点の値を反映するスナップショットである場合があります。

タイムラインの入力

クエリが実行される前に、各入力はタイムラインにマップされます。ストリームやテーブルからのイベント、あるいはテーブル内のファクトなど、すべての入力は、イベントがいつ発生したかなどの重要な時間情報を失うことなく、タイムラインにマッピングできます。イベントは個別のタイムラインになり、イベントの発生時に各イベントからの値が発生します。事実は連続的なタイムラインとなり、各事実が適用された時間を反映します。タイムラインはあらゆる種類の時間入力をロスレスで表現することにより、クエリが入力の種類ではなく計算に集中できるようにします。

タイムラインの出力

クエリの実行後、結果のタイムラインを外部システムに出力して使用する必要があります。各宛先のシンクにより、シンクと宛先に応じた詳細でデータ書き込みの設定が可能になります（「このコネクタのドキュメント多くのための）。

タイムラインをデータ行に変換するには、生成される行数に影響するいくつかのオプションがあります。

1. 範囲内の変更履歴全体、またはある時点の値のスナップショットのみを含めます。
2. 一定時間後に発生したイベント (変更) のみを出力に含めます。
3. 特定の時刻までのイベント (変更) のみを出力に含めます。

変更の完全な履歴は、長期にわたるユーザーの価値観のパターンを視覚化または特定するのに役立ちます。対照的に、特定の時点のスナップショットは、オンライン ダッシュボードや類似のユーザーの分類に役立ちます。

特定の時間以降のイベントを含めると、宛先にその時点までのデータがすでに存在する場合、または以前のポイントが無関係な場合、出力サイズが削減されます。これは、クエリを再実行してデータ ストアに具体化する場合に特に便利です。

特定の時点までのイベントを含めると、出力サイズも制限され、ポイントインタイムのスナップショットを選択できるようになります。インクリメンタル実行では、現在時刻よりわずかに前の時刻を選択することで、遅延するデータ処理が軽減されます。

「変更日」オプションと「最新日」オプションは両方とも、増分実行で特に役立ちます。これについては、次の記事で説明します。

歴史

履歴 (タイムライン内のすべてのポイントのセット) は、過去のポイントを気にする場合に役立ちます。たとえば、これは、各ユーザーの値が時間の経過とともにどのように変化するかのパターンを視覚化または識別するために必要になる場合があります。履歴は、モデルの作成に使用するトレーニング サンプルを出力する場合に特に役立ちます。

任意のタイムラインを履歴として出力できます。離散タイムラインの場合、履歴はタイムライン内のイベントの集合です。連続的なタイムラインの場合、履歴には値が変化するポイントが含まれており、事実上変更ログとなります。

スナップショット

スナップショット (特定の時点での各エンティティの値) は、最新の値だけを知りたい場合に役立ちます。たとえば、ダッシュボードを更新したり、モデル提供に接続するために機能ストアにデータを入力したりする場合です。

任意のタイムラインをスナップショットとして出力できます。個別のタイムラインの場合、スナップショットには、その時点で発生している各イベントの行が含まれます。連続タイムラインの場合、スナップショットには各エンティティの行が含まれ、その時点でのエンティティの値が含まれます。

結論

このブログ投稿では、イベントベースのデータから ML モデルを作成する際の時間的特徴の重要性を強調しました。イベントの時間的および時間的コンテキストは、活動のパターンを確認するために重要です。この投稿では、イベントと時間的コンテキストの操作を可能にするタイムラインの抽象化を紹介しました。タイムラインは時間とエンティティごとにデータを整理し、マルチセットと比較してイベントベースのデータにより適した構造を提供します。

タイムラインの抽象化はストリーム処理における自然な進歩であり、時間と因果関係をより効果的に推論できるようになります。また、入力から出力までの時間クエリ内のデータ フローを調査し、タイムラインを外部システムに出力するためのさまざまなオプションについても説明しました。

Kaskada は、一連のスナップショットに表形式 (静的) クエリを適用するのではなく、履歴 (変更ストリーム) を操作します。これにより、スナップショットに含まれるデータのみを操作するのではなく、スナップショット間の時間を操作することが自然になります。タイムラインを主な抽象化として使用すると、イベントベースのデータの操作が簡素化され、ストリームとテーブル間のシームレスな移行が可能になります。

あなたはできる始める今日は独自の時間クエリを試してみます。 Slack コミュニティに参加するタイムラインの抽象化についてのご意見をお聞かせください。今後の投稿では、Kaskada クエリ言語と、表現力豊かな一時クエリにおけるその機能について詳しく説明します。

Ben Chambers および Therapon Skoteiniotis 著、DataStax