はじめに
先日、以下の記事を発表しました。
新しいテクノロジーに触れる時はいつでも楽しいものです。
中でも新しいプログラミング言語（のパラダイム）を学ぶことは、特別に楽しいことです。
ということで、まだまだ勉強中ですが、公式ドキュメントの学習過程の記録として、以下の記事をまとめてみました。特に、日本語に置き換えるにあたっての用法が固まっていない分野として、自分にとって受け止めやすいのは何か？という観点からの試みとなっています。
Fenlとは何か、については、下記の記事を参照ください。
本稿情報のソースとして、下記ドキュメントを参照ください。
時系列計算 Temporal Calculation
背景：イベントベースのデータの課題を解決する
Kaskada はイベントベースの計算エンジンです。
それでは「イベント」とは、なんでしょうか？それは、時間に関連付けられた世界に関するあらゆる事象です。例えば、製品の購入や、サービスへの課金などは、イベントの典型と言えるでしょう。
イベントベースのデータの多くは、時間の経過とともに変化します。このような時間の経過とともに変化する一連のイベントから値を計算するということは、あるターゲットの計算結果が、時間の経過に従って変化する、と捉えることができます。
従来のデータ処理システムは、「特定のユーザーが何件購入したか?」など、データセットの現在の状態に関する質問に答えるように設計されています。
このアプローチにはいくつかの欠点があります。特定の質問に対する答えは、いつ尋ねられるかによって変わり、質問できるのは「今」だけです。
このような制約は、これまで主流であった多くのユースケースにとっては合理的でしたが、機械学習モデルをトレーニングするための特徴量サンプルを構築するというユースケースには向いていない部分があります。
ここでの、典型的な錯誤は、過去に入手可能な情報を説明することを目的としたトレーニング サンプルを構築するために、「現在」知られている情報を誤って使用してしまうことです（ターゲット漏洩）。
従来の計算の表現方法は、上記の課題には役に立ちません。
SQL などのクエリ言語や DataFrame などのデータ処理インターフェイスは、(時系列ではなく) 表形式のデータに関する要求に答えるように設計されています。
「商品購入時点において、購入先のベンダーに対して何件の詐欺報告が提出されているか?」というような質問は、一見単純な質問のようにも見えますが、従来の計算の表現方法では、複雑なウィンドウ処理やパーティショニング操作が必要になる場合があります。
イベントベースのデータやイベントベースのモデルを操作する場合、時間は重要な役割を果たします。イベント履歴における特定時点の特徴値を計算する機能は、Kaskada の中核機能の 1 つです。
Fenlは、クエリ言語に時間の概念を取り入れて設計されています。
Fenl 式は、単一の値を計算するのではなく、時間の経過とともに変化する特定の計算の結果を記述する時間ストリームを生成します。
バリューストリーム
Fenl は、単一の値で質問に答えるのではなく、時間の経過とともに変化する答えを記述する一連の値を生成します。たとえば、「（このユーザーは）何回購入したか?」という質問に対する答えは、次の表のようになります。
この表は、2015 年に質問された場合の答えは「（このユーザーは）2 回購入した」となるが、2019年10月26日以降に、質問された場合は答えが「（このユーザーは）は4 回 購入した」となることを示します。
最終的な（現時点の）値に対するクエリ：final-results
質問に対する「最終的な(final)」回答、つまりすべての値が処理された後に生成される最後の回答を知ることは、しばしば重要になります。
Fenl は、こうしたユースケースに対する機能を提供します。この機能は、final-resultsと呼ばれます。結果の動作がfinal-resultsに設定されたクエリの結果は次のようになります。
Final クエリにより、クエリの「現在の」値を知ることができます。増分クエリとマテリアライザーションでは、常にFinal クエリが使用されます。
時間的に正しい結合
Fenl の中核機能の一つは、データセット間の時間結合を計算する機能です。
たとえば、「購入時に各購入ベンダーに対して何件の詐欺報告が提出されたか?」という質問（クエリ）が考えられます。
これは、以下の 1 行で書くことができます。
FraudReport | count() | lookup(Purchase.vendor_id)