DEIM Forum 2023 2a-8-1

複合的ストリーム処理に対するトレーサビリティの研究
山田

真也†

北川

博之††

SalmanAhmed Shaikh†††

天笠 俊之††††

的野 晃整†††† 筑波大学大学院 理工情報生命学術院 システム情報工学研究群 〒 305-8573 茨城県つくば市天王台 1 丁目 1-1†† 筑波大学 国際統合睡眠医科学研究機構 〒 305–8575 茨城県つくば市天王台 1 丁目 1-1††† 産業技術総合研究所 人工知能研究センター 〒 135-0064 東京都江東区青海 2-4-7†††† 筑波大学 計算科学研究センター 〒 305–8577 茨城県つくば市天王台 1 丁目 1-1
E-mail: †yamada@kde.cs.tsukuba.ac.jp, ††kitagawa@cs.tsukuba.ac.jp,†††{shaikh.salman,a.matono}@aist.go.jp, ††††amagasa@cs.tsukuba.ac.jp
あらまし データ来歴（Lineage）とは分析結果の元になった入力データを提示することを指し，分析処理のトレーサ
ビリティを保証するため活用されている．しかし，近年の AI や機械学習モデルを用いた処理（AI/ML 処理）を伴う分析を考えると Lineage だけでは問題がある．これまで著者らは，AI/ML 処理を伴う複合的データ分析処理では単にLineage を提示するだけでなく，AI/ML 処理の分析結果の導出理由を説明する判断根拠も併せて提示する必要があることに着目し，拡張来歴について研究してきた．しかしながら従来の拡張来歴は静的なデータモデルである関係モデ
ルに基づいており，近年広く活用されているストリーム処理に対して適用できないという問題があった．そこで本稿
では，複合的ストリーム処理に対して拡張来歴を導出する枠組みについて説明する．
キーワード 拡張来歴，ストリーム処理，Apache ﬂink，AI
品ごとの Positive/Negative 数のカウントを行ったのち，最後

1 はじめにスマートフォンやセンサ等の IoT 機器の普及により，日々，膨大なストリームデータが生成されている．ストリームデータ
からリアルタイムに知識を抽出するために，ストリーム処理エンジンが広く用いられているが，そうして抽出されたデータや知識を信頼して活用するためには，データ分析のトレーサビリ
ティが不可欠である．そのためには分析処理の利用者になぜその分析結果が得られたかを説明することが重要である．
分析結果のトレーサビリティはこれまで，データベースシス
テム，科学ワークフロー，ビッグデータ処理システムなど様々な領域で研究が行われてきている [1], [2], [3]．その中でも，デー
タ来歴（Lineage）は分析結果のもとになった入力データを提示することを指し，特にデータベースの分野において研究が行われてきた [4], [5]．さらにストリーム処理を対象にした Lineage
導出システムの検討も始まっている [6], [7]．
近年，社会で活用されているデータ分析処理は AI や機械学
習モデルを用いた処理（AI/ML 処理）を伴うことが増えており，ストリーム処理においても同様の傾向がある．そうした複合的ストリーム処理では，AI/ML 処理の判断根拠が分析結果の導出理由を説明するために重要な情報であるため，従来の入力データのみを提示する Lineage だけでは十分にトレーサビリ
ティを保証することができない問題がある．ここで以下のような例を考える．
［例 1］ 図 1 はストリーム処理を用いたリアルタイムレビュー
分析を示している．この分析処理は 4 つの属性（製品 ID，顧客 ID，レビューコメント，タイムスタンプ）から構成されるタプルを受け取ると，タプルの検証，感情分類モデルの適用，製に分析結果を次のシステムに送信する．
ここであるユーザが分析結果 ⟨1, N egative, 3⟩ がなぜ導出されたのか知りたいと考えたとする．従来の Lineage を用い
ると，{⟨1, C001, “Wrong one . . .” , 10000⟩, ⟨1, C002, “Thistoy . . .”, 10005⟩, ⟨1, C003, “Some parts . . .” , 10010⟩} の 3
タプルをその分析結果の元になったデータとして提示することができる．しかしこの 3 つのタプルを提示するだけでは，なぜ感情分類モデルがそれらのタプルを Negative と判定したのか理解することができないという問題が生じる．つまりこのことは複合的ストリーム処理において，従来の Lineage だけではト
レーサビリティを保証することができないという問題を表している．
この問題を解決するために本研究では，感情分類モデルがなぜそれらのタプルのコメントを Negative と判断したのか説明するために，AI/ML 処理の判断根拠を併せて提示するというアプ
ローチをとる．具体的には「タイムスタンプが 10000 の入力タプ
ルは 1 ワード目に “Wrong” という単語があったため Negativeと判定し，10005 の入力タプルは 4 ワード目に “broken” という単語があったため Negative と判定し，10010 の入力タプル
は 4–5 ワード目に “not arrived” があったため Negative と判定した」という判断根拠の情報を，従来の Lineage と併せて提示することで複合的ストリーム処理におけるトレーサビリティの保証を可能にする．
著者らはこれまで AI/ML 処理を伴う複合的データ分析処理に対して，通常の Lineage に加えて AI/ML 処理の判断根拠を提示する拡張来歴について研究してきた [8], [9]．しかしながら従来の拡張来歴は，関係データやファイルデータのような静的なデータモデルを前提としており，動的なストリーム処理に対

製品ID

顧客ID

レビュー
コメント

タイム
スタンプ

製品ID

顧客ID

レビュー
感情

タイム
スタンプ

1

C001

Wrong one wasarrived, and…

10000

1

C001

Negative

10000

1

C002

This toy was
broken when…

10005

1

C002

Negative

10005

1

C003

Some parts were
not arrived.

10010

1

C003

Negative

10010

…

…

…

…

…

…

…

…

タプル入力

タプル検証

感情分類

カウント

製品ID

レビュー
感情

カウント

1

Negative

3

…

…

…

タプル出力

図 1 複合的ストリーム処理の例．感情分類モデルを用いたリアルタイムレビュー分析．点線で囲われているタプルは分析結果 ⟨1, N egative, 3⟩ の Lineage を表す．

して適用することができないという問題があった．

こうした背景から著者らは [8], [9] で従来の Lineage に加えてそうした背景から著者らは複合的ストリーム処理のトレーサ

AI/ML 処理の判断根拠を併せて提示する拡張来歴を提案した．

ビリティを保証するため，ストリーム処理を対象に拡張来歴を

しかしながら [8], [9] で提案した枠組みは静的データに対する問導出する枠組みを提案した [10]．本稿ではその内容に基づき複い合わせを対象としており，ストリーム処理には適用すること

合的ストリーム処理に対して拡張来歴を導出するシステムを説ができないという問題がある．

明するが，1) 導出手法をより理解しやすい例の使用，2) 導出
アルゴリズムの詳細な説明の追加，3) Traversal 時間に関する実験データの追加，4) 従来の分析結果のより適切な統計的手法を用いた比較 の 4 点で拡張を行っている．本稿で説明するシス
テムは，ストリーム処理に対して Lineage 導出を行うフレーム
ワーク GeneaLog をベースとした．Apache Flink 上で実行される複合的ストリーム処理に対して拡張来歴を導出するプロト
タイプシステムの開発を行い，プロトタイプシステムを用いた評価実験を行った．実験では本稿で説明したシステムがレイテ
ンシ／スループットの点で非常に小さいコストで拡張来歴を導出することを示す．
本稿の構成は以下の通りである．まず 2 節で関連研究について説明する．次に 3 節で本稿が使用するストリーム処理モデルと GeneaLog の説明を行い， 4 節でストリーム処理に対して
拡張来歴を導出する手法を説明する．そして 5 節でプロトタイ
プシステムを用いた評価実験の結果を示す．最後に 6 節で結論と今後の課題を述べる．

2. 2 ストリーム処理における来歴研究ストリーム処理に対して来歴を導出する枠組みの研究はまだ十分に行われていない．初期の研究として [14] は，出力ストリームにどの入力ストリームが貢献しているのかを提示することができるが，提示可能な来歴の粒度が非常に粗いという問題がある．そのためこの手法では，どのタプルが分析結果に貢献したのか提示することはできない．[15] はタプルのタイムスタ
ンプに基づいて元になった入力タプルを提示する研究であるが，全てのオペレータに対して入力タプルと出力タプルの対応関係を表すルールを定義する必要がある．しかしながら，実行する分析処理に応じて多様なオペレータが組み合わせられる近年のストリーム処理において，全ての入出力関係をあらかじめ定義
することは容易でない．

[6] と [7] はよりモダンなストリーム処理エンジンに対して
Lineage を導出する研究である．Ariadne [6] は処理を記述する
各オペレータを拡張し，導出されるタプルに元になったタプルを識別するアノテーションを付与することで Lineage を求める

2 関連研究枠組みである．しかしながら [7] でも示されているように，タプルに付与されるアノテーションのサイズがタプルに貢献し

2. 1 データベース問い合わせにおける来歴研究
これまでデータベース問い合わせの来歴を導出する手法がいた入力タプルの数に比例するため，分析処理によっては非常に大きなオーバヘッドが発生することがある．そうした背景からくつも提案されている [5], [11], [12]．[5], [11] は関係データモデ

GeneaLog [7] ではタプルにアノテーションを付与する際，アノルでモデル化された問い合わせに対して，タプルレベルの来歴

テーションのサイズを，入力タプル数に依存しない固定サイズを導出する研究である．[5] は Tracing Query と呼ばれる逆クエにする手法を提案した．さらに評価実験を通して GeneaLog がリを用いて分析結果の Lineage を求める手法であり，[11] は全

Ariadne より小さいオーバヘッドで Lineage を導出することをての入力タプルに識別子を事前に割り当て，識別子を分析結果示した．このことから本稿の手法の実装は GeneaLog に基づいまで継承することで元になったタプルを提示する手法である．

ている．GeneaLog の概要については次節で説明する．

より一般的な問い合わせに対する来歴研究も存在しており，[12]は XQuery に対して来歴を導出する枠組みを提案している．さらに MapReduce や Spark のようなビッグデータ処理システ
ムにおける来歴を対象とするものも存在する [3], [13]．しかし

3 ストリーム処理モデルと Lineage
3. 1 ストリーム処理モデル

ながらこれらの枠組みは単に分析結果の元になった入力データ

ストリーム S は無限長のタプルのシーケンスで構成され，タプを提示するもので，AI/ML 処理を伴う複合的データ分析処理

ル t はタイムスタンプ τ と属性値をもつ (t = ⟨τ, a1 , . . . , am ⟩)．

に対して十分なトレーサビリティを保証することができない．

ストリーム処理はノードがオペレータ，エッジがデータフロー

…
…

…

Sourceオペレータの
出⼒タプル
U1

…

<latexit sha1_base64="F7IJMlZsGyqyBuQIFEqkCZ4Jw2Y=">AAACZnichVFNSwJBGH7cvsw+tCIKukhi2EXGkIpOUpeOfuQHmMjuNtriurvsroJJfyDomodOBRHRz+jSH+jgPyg6GnTp0Ou6ECXVO8zMM8+8zzvPzEiGqlg2Y12PMDI6Nj7hnfRNTc/M+gNz8zlLb5gyz8q6qpsFSbS4qmg8ayu2yguGycW6pPK8VNvr7+eb3LQUXTuwWwYv1cWqplQUWbSJykTE9XIgxKLMieAwiLkgBDeSeuAWhziCDhkN1MGhwSasQoRFrYgYGAziSmgTZxJSnH2OU/hI26AsThkisTUaq7QquqxG635Ny1HLdIpK3SRlEGH2xO5Yjz2ye/bCPn6t1XZq9L20aJYGWm6U/WfLmfd/VXWabRx/qf70bKOCbcerQt4Nh+nfQh7omyedXmYnHW6vsWv2Sv6vWJc90A205pt8k+LpS/joA2I/n3sY5Daisc1oPBUPJXbdr/BiBauI0HtvIYF9JJGlc6s4xwU6nmdhVlgUlgapgsfVLOBbCMFPuLyKTw==</latexit><latexit sha1_base64="I5epLVbt3LLr0r5HxpCJj+9o5Us=">AAACZnichVFNSwJBGH7cvsw+tCIKukhi2EXGkIpOUpeOfuQHmMjuNtriurvsroJJfyDomodOBRHRz+jSH+jgPyg6GnTp0Ou6ECXVO8zMM8+8zzvPzEiGqlg2Y12PMDI6Nj7hnfRNTc/M+gNz8zlLb5gyz8q6qpsFSbS4qmg8ayu2yguGycW6pPK8VNvr7+eb3LQUXTuwWwYv1cWqplQUWbSJykSk9XIgxKLMieAwiLkgBDeSeuAWhziCDhkN1MGhwSasQoRFrYgYGAziSmgTZxJSnH2OU/hI26AsThkisTUaq7QquqxG635Ny1HLdIpK3SRlEGH2xO5Yjz2ye/bCPn6t1XZq9L20aJYGWm6U/WfLmfd/VXWabRx/qf70bKOCbcerQt4Nh+nfQh7omyedXmYnHW6vsWv2Sv6vWJc90A205pt8k+LpS/joA2I/n3sY5Daisc1oPBUPJXbdr/BiBauI0HtvIYF9JJGlc6s4xwU6nmdhVlgUlgapgsfVLOBbCMFPur2KUA==</latexit>

(a)

(b)

S
S

U1
Next

U1

U2

Aggregateオペレータの
出⼒タプル

S

…

Mapオペレータの
出⼒タプル

U1
Next

R

…

R

S

R

S

R

図 3 貢献グラフ…

…

対して Lineage を導出する State-of-the-art の枠組みで，各オS<latexit sha1_base64="MMDwUVGHCc6Xdw9DdWDdkgsukxk=">AAACZnichVFNSwJBGH7cvsw+tCIKukhi2EXGkIpOUpeOfuQHmMjuNtriurvsroJJfyDomodOBRHRz+jSH+jgPyg6GnTp0Ou6ECXVO8zMM8+8zzvPzEiGqlg2Y12PMDI6Nj7hnfRNTc/M+gNz8zlLb5gyz8q6qpsFSbS4qmg8ayu2yguGycW6pPK8VNvr7+eb3LQUXTuwWwYv1cWqplQUWbSJykTk9XIgxKLMieAwiLkgBDeSeuAWhziCDhkN1MGhwSasQoRFrYgYGAziSmgTZxJSnH2OU/hI26AsThkisTUaq7QquqxG635Ny1HLdIpK3SRlEGH2xO5Yjz2ye/bCPn6t1XZq9L20aJYGWm6U/WfLmfd/VXWabRx/qf70bKOCbcerQt4Nh+nfQh7omyedXmYnHW6vsWv2Sv6vWJc90A205pt8k+LpS/joA2I/n3sY5Daisc1oPBUPJXbdr/BiBauI0HtvIYF9JJGlc6s4xwU6nmdhVlgUlgapgsfVLOBbCMFPvL6KUQ==</latexit>(c)
図 2 ストリーム処理フローの表記． (a) 論理表記． (b) 物理表記．

(c) Send (S) / Receive (R) オペレータの導入．

ペレータが生成する全てのタプルにメタデータを追加する．そして Lineage を求める際にはこのメタデータを手がかりに，元になった入力タプルを導出する．Lineage を導出するためには
このメタデータをセットするようにオペレータを拡張する必要があり，これを Operator instrumentation と呼ぶ．これからの DAG 構造として表すことができ，オペレータは 1（またはGeneaLog の概要を説明する．

2）入力ストリームを受け取ると 1 出力ストリームを出力する．

メタデータ: 全てのタプルに追加されるメタデータは，Type,

ストリーム処理を構成するオペレータはいくつも存在するが，U1, U2, Next の 4 つの属性で構成されるデータオブジェクト

それらは 3 種類に分類できる [7]．1 つ目は I/O で，具体的なオである．Type はメタデータが生成されたオペレータを識別す

ペレータしては Source と Sink オペレータがこれに該当する．

る属性である．U1，U2，Next はポインタで，オペレータの出

これらのオペレータは，ストリーム処理に対して外部のシステ

力タプルに貢献したオペレータの入力タプルを指す．

ムからデータを取り込む，または外部のシステムにストリーム

Operator Instrumentation: GeneaLog で拡張された処処理結果を送信する役割を持つ．2 つ目は Transformer で，具理フローの各オペレータは，単にタプルを処理するだけでなく，体的には Map や Filter，Union，Aggregate，Join オペレータ

処理結果の Lineage が求められるようメタデータを適切にセッが該当する．ここで Aggregate や Join オペレータは，入力ストする必要がある．ここでは Aggregate オペレータを例にとっトリームをウインドウに分割し，それぞれのウインドウごとにて説明を行う．

集約/結合処理を実行するようなオペレータを指している．3 つ［例 2］ ウインドウに含まれるタプル tin1 , . . . , tinn を受け取

目は Send と Receive オペレータで，これらはスレッド間でタると tout を返す Aggregate オペレータを考える．Lineage 導

プルをやり取りするために用いられる．

出のために拡張された Aggregate オペレータは，通常の集約結

図 2(a) は，2 つの Source オペレータ，3 つの Transformer，

果を求めると同時に下記のように入力／出力タプルのメタデー

1 つの Sink オペレータで構成されるストリーム処理を表していタをセットする．

る．この表記はストリーム処理を論理的に記述したもので，本（ 1 ） tout .T ype = Aggregation

稿ではストリーム処理の論理表記と呼ぶ．しかしストリーム処（ 2 ） tout .U 1 = tinn ，tout .U 2 = tin1

理が実際にストリーム処理エンジン上で実行されるとき，各オ（ 3 ） tini .N ext = tini+1 (i = 1, . . . , n − 1)

ペレータは複数のオペレータインスタンスに展開され，それぞ他のオペレータに対する Operator instrumentation は，基れが並列に処理を行う．図 2(b) は展開されたオペレータインス

本的に Type と元になった入力タプルに U1 と U2 ポインタを

タンスを表しており，ストリーム処理の物理表記と呼ぶ．ストセットするよう拡張する．詳細は [10] を参照いただきたい．

リーム処理エンジンではスレッドが処理の実行単位になり，図

貢献グラフを用いた Lineage 導出: Operator instrumenta-

中の四角が 1 スレッドを指している．実行するストリーム処理

tion で拡張されたストリーム処理の分析結果 t は，直前のオペが複数スレッドで実行される場合には，タプルをスレッド間でレータにおける入力タプルを， t のメタデータに含まれるポイ

やり取りする必要がある．そのために Send オペレータがスレッ

ンタで参照することができる．さらにその入力タプルもまた，

ドの最後のオペレータの後ろに挿入され，Receive オペレータ

直前のオペレータにおける入力タプルをポインタで参照できる．

がスレッドの先頭に挿入される (図 2(c))．Send と Receive オ

そのため Lineage はタプルのポインタを再帰的に辿ることで得ペレータはタプルをスレッド間でやり取りする際，タプルのシることができる．例えば図 1 に示したストリーム処理の分析結

リアライズ／デシリアライズも併せて行う．

果は，図 3 のように，タプルがノード，ポインタがエッジのグ

3. 2 GeneaLog
本節で，本稿の拡張来歴導出手法や実装のベースになっている GeneaLog [7] を説明する．GeneaLog はストリーム処理にラフ構造を得ることができる．これを貢献グラフと呼ぶ．図 3の下のノードは分析結果 (⟨1, N egative, 3⟩) を表し，そこからポインタでつながるノードは Map（感情分類）オペレータの出力タプル，一番上のノードは Source オペレータの出力タプル（分析処理における入力タプル）を表している．そのため貢献グラフを用いて Lineage を求めるためには，辿ったタプルのType が Source になるまで再帰的にグラフを辿ればよい．
クラスタ環境における Lineage 導出: クラスタ環境のように導出したのかを提示することができるようになる．

Reasoning lineage を提示するためには，AI/ML 処理の設計
者が AI/ML 処理結果の判断根拠をシステムに登録するための機能を提供している必要がある．そこでプロトタイプシステム

1 つのストリーム処理が複数のスレッドにまたがって実行されの実装では，AI/ML 処理の設計者が AI/ML 処理結果の判断るケースで Lineage を導出する際には，スレッド間通信につい根拠を簡単に登録するためのインタフェースを提供しており，ても考慮する必要がある．タプルが異なるスレッドに送られた

その詳細は 4. 2 節で述べる．

場合，そのタプルの U1，U2 ポインタは入力タプルを指し示す
ポインタとして無効になるという問題がある．なぜならば U1と U2 はタプルを送信したスレッドが持つメモリ領域を参照す

4. 2 拡張来歴の導出
本節では GeneaLog をベースに拡張来歴を導出するシステム

るポインタであるが，その領域はタプルを受け取ったスレッドの説明を 1) 追加メタデータ， 2) Operator instrumentation，から参照することができないからである．これを解決するため

3) 拡張貢献グラフを用いた拡張来歴導出の 3 つに分けて行う．

に，GeneaLog では Explicit アプローチと Implicit アプローチの 2 つを提案しているが，本研究では Implicit アプローチを採用しており，以下の説明もそれに基づいている．

Send と Receive オペレータはスレッド間でタプルをやり取りするためのオペレータである．Implicit アプローチでは Send
オペレータがタプルを送信するとき，まず送信タプルの Typeを “REMOTE” にセットする．そして送信タプルの貢献グラフを辿り送信タプルの Lineage を求めた上で，送信タプルとLineage をシリアライズして送信する．Receive オペレータではタプルと Lineage を受け取ると，下記で示すようにタプルのメタデータをセットし，貢献グラフを再構築する．

Receive オペレータが，タプル tout とその入力タプル集合（Lineage） ts1 , . . . , tsn を受け取る場合を考える．このとき，Receive オペレータは下記のように tout のメタデータをセットし，貢献グラフを再構築する．そして tout が次のオペレータに説明を簡単にするため，本稿では AI/ML 処理は Map オペレー
タのみで実行すると仮定しているが，実際には説明する手法はその他のオペレータで AI/ML 処理が実行されても拡張来歴を導出可能である．
追加メタデータ: 拡張来歴を導出するために，新しいメタ
データ RL を従来のメタデータに追加する．RL は Reason-

ing lineage object 集合を指すポインタである．前述したように
Reasoning lineage object は 4 つの属性 (OPid, Input, Output,
Reason) で構成されるデータオブジェクトであり，Reasoning
lineage の構成要素である．
Operator Instrumentation: RL は Map 処理で AI/ML
処理が実行されるとき，他のメタデータと同様に下記のようにセットされる．

Instrumented Map: 入 力 タ プ ル tin を 受 け 取 り，tin に
AI/ML 処理を適用したのち tout を返す Map オペレータを考える．tout .v は AI/ML 処理によって導出された分析結果を送られる．
（ 1 ） tout .U 1 = tsn ，tout .U 2 = ts1

表し，そのときの判断根拠を REASON を表記する．このと（ 2 ） tsi .N ext = tsi+1 (i = 1, . . . , n − 1)

き Map オペレータは下記のように出力タプルのメタデータを

4 ストリーム処理における拡張来歴（ 1 ） tout .T ype = M ap

セットする．
（ 2 ） tout .U 1 = tin

4. 1 定義（ 3 ） tout .RL = {⟨M ap, tin , tout .v, REASON ⟩}本節ではストリーム処理における拡張来歴を定義する．分析

実装システムは，AI/ML 処理の判断根拠を RL に登録するた

結果 t の拡張来歴とは，Source lineage と Reasoning lineage

めのインタフェースをストリーム処理の開発者に提供していの 2 種類の Lineage のペアのことである．Source lineage とる．このインタフェースを利用することで，ストリーム処理フは分析結果 t の導出に貢献した入力タプルの集合のことであローの開発者は次の 1 行を Map オペレータの関数定義に追加

り，これは従来の Lineage と同じものを指す．一方，Reasoning

するだけで，AI/ML 処理実行時の判断根拠を登録することがlineage とは分析結果 t を導出したときの AI/ML 処理の判断できる．

根拠オブジェクト（Reasoning Lineage Object, RLO）の集合のことである．具体的には RLO は 4 つの属性で構成される：OPid，Input，Output，Reason．OPid は AI/ML 処理を実行// t_in/t_out: Map オペレータの入力/出力タプル// output/reason: AI/ML 処理の実行結果/判断根拠
Reason.registerReasonInfo("Map", t_in,

し判断根拠を生成したオペレータを指す識別子で，Input とOutput はそれぞれオペレータの入力タプルと出力タプルを指す．Reason は入力タプルからなぜ AI/ML 処理が出力タプルを導出したのかの説明を保存する属性である．例えば，図 1 に示したストリーム処理の分析結果 ⟨1, N egative, 3⟩ の拡張来歴は図 4 になる．Reasoning lineage を用いることで，どのオペ
レータがどの入力データからどのような判断根拠で分析結果をoutput, reason, t_out);
拡張来歴を求めるために，Send と Receive オペレータの拡張も併せて行う．Send オペレータは Lineage の代わりに拡張来歴を求め送信し，Receive オペレータは従来のメタデータのセットに加えて RL に Reasoning lineage object 集合を登録す
る処理を追加で行う．

893h Map, h 1, C001, “Wrong one . . . ”, 10000 i, >
>
>
>
>
>
68
9 >
>
7
Negative, “1st word is ‘Wrong’.” i>
6< h 1, C001, “Wrong one . . . ”, 10000 i = >
>
>
<
=7
6
7
h Map, h 1, C002, “This toy . . . ”, 10005 i,
6 h 1, C002, “This toy . . . ”, 10005 i
7,
6:
7
Negative,
“4th
word
is
‘broken’.”i;>>
6 h 1, C003, “Some parts . . . ”, 10010 i
>
>
7
>
>
>
4
5
h Map, h 1, C003, “Some parts . . . ”, 10010 i, >
>
>
>
>
:
;
Negative, “4–5th words are ‘not arrived’.” i2<latexit sha1_base64="h8dnq1k6lHr9SEesGo5nuhEKeSw=">AAAFgHicpVJNb9NAEJ02BEr4aAoXBJcVUUmR0rAuLaCeKnrhAup3K9VVunYmjlVn11pvgoqVA1f+AAdOIKEKcYHfwIU/wKE/AXEsEhcOjJ2Uqi1tgjqWd2ffznt+O2snDPzIcL47MJg5lz1/Yehi7tLlK1eH8yPXViLV1C4uuypQes0REQa+xGXjmwDXQo2i4QS46mzNJvurLdSRr+SS2Q5xoyE86dd8VxiCKiOZm4zCDrBm1tPRjnMp4qDny9gIpxkI3Y6DdgceswMhvQDtu8wqsVnOadzcXNVKekxJZHZVmahYLDGLUyT1er/etk+QmEgklup+xIzaPqww1Z/C/URhUTWQhUKb6JCG9W8XKKt/T8ds7Xt1Y7dL/9mCpyIsnaUnpX039SgULsYWNtrP0KO7aWGiYUWGPVe6yqg3HcFiuVjs1ZMTXPXb5l6mJk39wJSj1RbKM7jq/+p6+hofn+pai5jQyDalMpRo2q8edXjKT5DrJBu5Sr7AyzwNdjyxukkBujGn8jtgQxUUuNCEBiBIMJQHICCiZx0s4BAStgExYZoyP91HaEOOuE2qQqoQhG7R6NFqvYtKWieaUcp26SsBvZqYDEb5N/6B7/Gv/CP/zn+fqBWnGomXbZqdDhfDyvCrG4u/erIaNBuoH7BO9WygBo9Srz55D1MkOYXb4bdevN5bnF4Yje/wd/wH+X/Ld/kXOoFs/XTfz+PCG0guwDra7uPJykTZelCenJ8szDzuXsUQ3ILbMEb9fggz8ATmYBnczMvMTuZT5nN2MDuWvZe1OqWDA13OdTgU2ek/YHd+pg==</latexit>

図 4 分析結果 ⟨1, N egative, 3⟩ の拡張来歴

Sourceオペレータの
出⼒タプル

null

U1

Mapオペレータの
出⼒タプル

U1
Next
RLO1

U1

Aggregateオペレータの
出⼒タプル

null

null

U1

入力: 分析結果のタプル tout
出力: tout の拡張来歴

Next
RLO2

アルゴリズム 1 拡張来歴の導出

RLO3

U2
null

図 5 拡張来歴のための拡張貢献グラフ

1: キュー q を {tout } で初期化し，visited と SL，RL を空集合で初期化．
2: while q に要素があるとき do3:t = q.dequeue()4:

if t.RL ̸= null かつ t.RL.size > 0 then5:

RL = RL ∪ {t.RL}

6:

if t.T ype が Source then

拡張貢献グラフを用いた拡張来歴導出: メタデータとして RL7:を加えたことで従来の貢献グラフに RL が追加される．具体的

8:には，図 1 の分析結果 ⟨1, N egative, 3⟩ の貢献グラフは，図 59:のように従来の貢献グラフに RL ポインタが追加されたような

10:

データ構造になる．これを拡張貢献グラフと呼ぶ．
この拡張貢献グラフに対して，アルゴリズム 1 を適用する

SL = SL ∪ {t}else if t.T ype が Map thenenqueueIf N otV isited(t.U 1, q, visited)
else if t.T ype が Join thenenqueueIf N otV isited(t.U 1, q, visited)11:

enqueueIf N otV isited(t.U 2, q, visited)

12:
13:

else if t.T ype が Aggregate または REMOTE then

ことによって拡張来歴を求めることができる．このアルゴリズ

14:

ttmp = t.U 2

ムは，RL が Reasoning lineage object を参照していない場合

15:

while T rue donull 値を取ることを仮定している．enqueueIf N otV isited は

16:

enqueueIf N otV isited(ttmp , q, visited)

タプル，キュー q ，タプル集合 visited を受け取ると，タプル

17:

if ttmp == t.U 1 thenが visited に含まれているかを確認し，もしタプルが visited18:に含まれていなければ（そのタプルにまだアクセスしたことが19:

なければ），キューにタプルをエンキューする関数である．またbreakttmp = ttmp .N ext

20: return [SL, RL]

タプルが既に含まれていた場合には何も行わず，そのまま処理がアルゴリズムに戻ってくる．このアルゴリズムは GeneaLog⟨1, C003, ..., 10010⟩，⟨1, C002, ..., 10005⟩，⟨1, C001, ..., 10000⟩のものに基づいており，拡張来歴を求めるための拡張は 4 行の 3 タプルがあり，それらの Type はすべて Source である．そ目，5 行目である．ここではアクセスしたタプルが Reasoningのためこれらは 7 行目で SL に追加され，その後 q は空であlineage object を持っていればそれを RL に追加する処理を行

るから SL と RL が返される．結果として拡張来歴が導出さなっている．この拡張によってアルゴリズムは拡張来歴を導出れ，その内容は図 4 に示したものとなる．

することができるようになる．
［例 3］ ア ル ゴ リ ズ ム 1 を 用 い て ，図 1 の 分 析 結 果⟨1, N egative, 3⟩ （ 対 応 す る 拡 張 貢 献 グ ラ フ は 図 5）の
拡 張 来 歴 を 求 め る 様 子 を 説 明 す る ．ま ず 1 行 目 で q を{⟨1, N egative, 3⟩} で 初 期 化 し ，他 変 数 は 空 集 合 で 初 期 化
す る ．す る と q に は 要 素 が あ る た め ，3 行 目 で t =5 実験

本節では Flink 上に実装したプロトタイプシステムを用いたクラスタ環境における性能評価の結果を述べる．

5. 1 データセット⟨1, N egative, 3⟩ となる．t の RL は null であり t.T ype は実験ではストリームデータとして，Amazon レビューデー

Aggregate で あ る た め 13 行 目 に 移 り，19 行 目 ま で の 処

タ [16] に基づいた 2 種類のデータを使用した．Amazon レビュー

理 の 間 で q に int3 = ⟨1, C003, N egative, 10010⟩，int2 =データは Amazon の商品 ID とそのレビューコメントなどが記⟨1, C002, N egative, 10005⟩，int1 = ⟨1, C001, N egative, 10000⟩

録されているデータセットである．事前の調査で Amazon レがエンキューされる．次に 2 行目に戻ると t = int3 となり，このビューデータには商品の出現回数や入力タプルサイズの点で，タプルは RL が RLO3 を指しているため 5 行目で RL に RLO3

データに偏りがあることがわかっていた．そこでデータの偏りを追加する．その後 8 行目に制御が移り，⟨1, C003, ..., 10010⟩

による実験結果への影響を排除するために，元の Amazon レが q にエンキューされる．int2 と int1 についても同様に行う

ビューデータを修正した人工データセットと元の Amazon レと，RLO2 と RLO1 が RL に追加される．その時点で q にはビューデータをそのまま使用するリアルデータセットを用意した．人工データセットでは商品 ID が一様分布に従い，全ての実験はクラスタ環境で実行した．クラスタは 2 ノード Apache

入力タプルのサイズが同じになるようにした．

Flink クラスタ（1 ジョブマネージャー，1 タスクマネージャー）

5. 2 複合的ストリーム処理フローと AI/ML 処理の実装
実験の複合的ストリーム処理フローは，レビューコメントをと 3 ノード Apache Kafka クラスタ（1 Zookeeper，2 ブローカノード）で構成され，各ノードは 128 GB メモリと 10 CPU
コアを持つ．

受け取るとそのコメントが Positive か Negative かを判定する
感情判定 AI/ML 処理を活用する．実際にはリアルタイム処理

5. 4 人工データを用いた評価実験

フローとウインドウ処理フローの 2 つの処理フローを用いて実人工データを用いた実験では入力データや処理フローの特性験を行った．どちらの処理フローも，Apache Kafka から入力

が性能に与える影響を検証するために，リアルタイム処理フ

タプルを受け取り，Kafka に分析結果を送信する．

ローとウインドウ処理フローのそれぞれに対して，データの特リアルタイム処理フローは以下に示すオペレータで構成され性や処理パラメータの組み合わせを複数試すことで多角的な評

る：Source-Map-Filter-Map-Sink．入力タプルを受け取ると，価を行った．具体的には，以下の 3 つの特性を変化させた際のそのコメントが Positive か Negative かを判定する分析を行う．

レイテンシとスループット，Traversal 時間を測定した．

はじめの Map オペレータは，文字列型入力タプルを Java オブジェクトのタプルに変換する．Filter オペレータは直前の Mapで変換された際に欠損値を持つタプルを削除するが，実際には
ここで削除されるタプルはほとんどなかった．2 つ目の Map•

ダミー感情判定モデルの処理コスト：実行時のアイドル

時間を変更．Light：アイドル無し，Heavy：200 ms．

•

入力タプル長：レビューコメントの長さを変更．Short：

1 byte, Long：35,094 bytes．

オペレータは感情判定処理を実行し，タプルに Positive または•Negative を割り当てる．

3 つの特性の組み合わせを x/x/x のように表記し，それぞウインドウサイズ：Small：1 秒，Large：100 秒．

一方，ウインドウ処理フローは以下のオペレータで構成されが処理コスト，入力タプル長，ウインドウサイズに対応してれる：Source-Map-Filter-Map-Aggregate-Sink．リアルタイム

いる．例えば H/L/S は，処理コスト Heavy，入力タプル長

処理フローの分析の内容に加えて，商品ごとに Positive/Neg-

Long，ウインドウサイズ Small を表す．またリアルタイム処

ative なコメントの数をカウントする分析を行う．そのため

理フローにおけるウインドウサイズは「-」で表記する．

Aggregate オペレータでは，商品 ID ごとにウインドウ内のPositive/Negative なコメントをカウントする処理を行う．

図 6 は人工データを用いた評価実験のレイテンシと Traversal
時間を，図 7 はスループットを表している．図中の ** と * は，

感情判定 AI/ML 処理に関して，今回の実験では 2 つの実装

SAL を Baseline または Lineage と比較したときにそれぞれ有を用意した．まず 1 つ目は人工データを用いた実験で使用する，

意差 1 % もしくは 5 % で統計的な差があることを示している．

ダミーの感情判定モデルを用いた実装である．ダミーの感情判

図 6 の Traversal 時間のバーにおける ** もしくは * の上には，定モデルは，処理時間の変動を抑えることで安定した実験結果

SAL の Traversal 時間が Lineage の Traversal 時間と比較してを得ることを目的にしており，入力データを受け取ると事前に何倍になったかを示している．なお Baseline 手法では Lineage

定義した固定時間処理をアイドルしたあと，Positive の分析結を求めるための Traversal 時間が発生しないため，Traversal 時

果と固定長文字列を判断根拠として返す．2 つ目はリアルデー

間は示していない．差の有無の確認には Welch の t 検定 [18] をタを用いた実験で使用する，IBM が提供している実際のモデ用い，必要に応じてボンフェローニ補正を適用した結果に基づル [17] を用いた実装である．

いている．

ここまでに説明したデータセットと処理フロー，感情判定モ

まずリアルタイム処理フローを用いた結果について説明する．

デルの実装を組み合わせて以下の実験を行った：人工データをレイテンシとスループットに関しては感情判定モデルの処理用いた 2 つの処理フローの実験（ダミー感情判定モデル使用）

コストが大きいとき，拡張来歴の導出によって発生するオーバと，リアルデータを用いた 2 つの処理フローの実験（IBM のヘッドは非常に小さいことが示された．図 6(a)，7(a) の処理コ

感情判定モデル使用）．

ストが大きい場合を見ると，レイテンシは H/S/- ，スループッ

5. 3 比較手法と比較指標
各実験では 3 つの比較手法を評価した：1) Lineage を導出しないケース（Baseline, Base）, 2) GeneaLog を用いて Lineage
のみ導出するケース（Lineage, Lin）, 3) 拡張来歴を導出するケース（SAL）．SAL が本稿で説明した手法である．
比較指標としてはレイテンシとスループットに加え，拡張来トは H/L/- のとき統計的な差があるもののその差は非常に小さい．実際 H/S/- の SAL のレイテンシは Baseline と比較して 1.0002 倍，Lineage と比較して 1.0001 倍であり，H/L/- の

SAL のスループットは Baseline の 0.98 倍，Lineage の 0.99倍である．またモデルの処理コストが大きいとき，レイテンシ
全体に対する Traversal 時間の割合は非常に小さいことも示された．これらの理由はダミーの感情判定モデルの処理コストが歴導出時の貢献グラフを辿るためにかかる時間（Traversal 時

大きい時，モデルの処理時間が全体の処理時間のほとんどを占間）の 3 つを用いた．レイテンシと Traversal 時間は実験を 1

め，拡張来歴を求めるための追加処理にかかるオーバヘッドが回実施した際に出力された分析結果の平均値を使用し，スルー
プットは 5 回実験を行った時の平均値を使用している．なお

相対的に小さくなったからと考えられる．一方で処理コストが小さいときは，レイテンシやスループットの性能が大きく低下

**
処理時間 [s]

**

**

1E-1

**
+54%

1E-3

**

1E-5

+106%

*

**

+90%

1E-7
Base

Lin

SAL

Base

Lin

L/S/レイテンシ**
処理時間 [s]

**

**

1E+2

SAL

Base

Lin

H/S/-

SAL

H/L/-

Traversal時間<latexit sha1_base64="F7IJMlZsGyqyBuQIFEqkCZ4Jw2Y=">AAACZnichVFNSwJBGH7cvsw+tCIKukhi2EXGkIpOUpeOfuQHmMjuNtriurvsroJJfyDomodOBRHRz+jSH+jgPyg6GnTp0Ou6ECXVO8zMM8+8zzvPzEiGqlg2Y12PMDI6Nj7hnfRNTc/M+gNz8zlLb5gyz8q6qpsFSbS4qmg8ayu2yguGycW6pPK8VNvr7+eb3LQUXTuwWwYv1cWqplQUWbSJykTE9XIgxKLMieAwiLkgBDeSeuAWhziCDhkN1MGhwSasQoRFrYgYGAziSmgTZxJSnH2OU/hI26AsThkisTUaq7QquqxG635Ny1HLdIpK3SRlEGH2xO5Yjz2ye/bCPn6t1XZq9L20aJYGWm6U/WfLmfd/VXWabRx/qf70bKOCbcerQt4Nh+nfQh7omyedXmYnHW6vsWv2Sv6vWJc90A205pt8k+LpS/joA2I/n3sY5Daisc1oPBUPJXbdr/BiBauI0HtvIYF9JJGlc6s4xwU6nmdhVlgUlgapgsfVLOBbCMFPuLyKTw==</latexit>

(a)

**

**

**

1E+0
1E-2

+32%

-29%

**

+35%

**

*

+72%

1E-4

**

1E-6
Base

Lin

SAL

Base

L/S/S

Lin

SAL

Base

Lin

H/S/S
レイテンシ

SAL

Base

Lin

H/L/S

SAL

H/S/L

Traversal時間<latexit sha1_base64="I5epLVbt3LLr0r5HxpCJj+9o5Us=">AAACZnichVFNSwJBGH7cvsw+tCIKukhi2EXGkIpOUpeOfuQHmMjuNtriurvsroJJfyDomodOBRHRz+jSH+jgPyg6GnTp0Ou6ECXVO8zMM8+8zzvPzEiGqlg2Y12PMDI6Nj7hnfRNTc/M+gNz8zlLb5gyz8q6qpsFSbS4qmg8ayu2yguGycW6pPK8VNvr7+eb3LQUXTuwWwYv1cWqplQUWbSJykSk9XIgxKLMieAwiLkgBDeSeuAWhziCDhkN1MGhwSasQoRFrYgYGAziSmgTZxJSnH2OU/hI26AsThkisTUaq7QquqxG635Ny1HLdIpK3SRlEGH2xO5Yjz2ye/bCPn6t1XZq9L20aJYGWm6U/WfLmfd/VXWabRx/qf70bKOCbcerQt4Nh+nfQh7omyedXmYnHW6vsWv2Sv6vWJc90A205pt8k+LpS/joA2I/n3sY5Daisc1oPBUPJXbdr/BiBauI0HtvIYF9JJGlc6s4xwU6nmdhVlgUlgapgsfVLOBbCMFPur2KUA==</latexit>(b)

1000000

**
**

**
**

10000
100
1

L/S/Baseline<latexit sha1_base64="F7IJMlZsGyqyBuQIFEqkCZ4Jw2Y=">AAACZnichVFNSwJBGH7cvsw+tCIKukhi2EXGkIpOUpeOfuQHmMjuNtriurvsroJJfyDomodOBRHRz+jSH+jgPyg6GnTp0Ou6ECXVO8zMM8+8zzvPzEiGqlg2Y12PMDI6Nj7hnfRNTc/M+gNz8zlLb5gyz8q6qpsFSbS4qmg8ayu2yguGycW6pPK8VNvr7+eb3LQUXTuwWwYv1cWqplQUWbSJykTE9XIgxKLMieAwiLkgBDeSeuAWhziCDhkN1MGhwSasQoRFrYgYGAziSmgTZxJSnH2OU/hI26AsThkisTUaq7QquqxG635Ny1HLdIpK3SRlEGH2xO5Yjz2ye/bCPn6t1XZq9L20aJYGWm6U/WfLmfd/VXWabRx/qf70bKOCbcerQt4Nh+nfQh7omyedXmYnHW6vsWv2Sv6vWJc90A205pt8k+LpS/joA2I/n3sY5Daisc1oPBUPJXbdr/BiBauI0HtvIYF9JJGlc6s4xwU6nmdhVlgUlgapgsfVLOBbCMFPuLyKTw==</latexit>

H/S/Lineage

H/L/SAL

スループット [/s]スループット [/s]図 6 (a) リアルタイム処理 (b) ウインドウ処理 におけるレイテンシ／ Traversal 時間

1000000

**
**

**

10000
100
1

L/S/S
Baseline

(a)

H/S/S

H/L/S

Lineage<latexit sha1_base64="I5epLVbt3LLr0r5HxpCJj+9o5Us=">AAACZnichVFNSwJBGH7cvsw+tCIKukhi2EXGkIpOUpeOfuQHmMjuNtriurvsroJJfyDomodOBRHRz+jSH+jgPyg6GnTp0Ou6ECXVO8zMM8+8zzvPzEiGqlg2Y12PMDI6Nj7hnfRNTc/M+gNz8zlLb5gyz8q6qpsFSbS4qmg8ayu2yguGycW6pPK8VNvr7+eb3LQUXTuwWwYv1cWqplQUWbSJykSk9XIgxKLMieAwiLkgBDeSeuAWhziCDhkN1MGhwSasQoRFrYgYGAziSmgTZxJSnH2OU/hI26AsThkisTUaq7QquqxG635Ny1HLdIpK3SRlEGH2xO5Yjz2ye/bCPn6t1XZq9L20aJYGWm6U/WfLmfd/VXWabRx/qf70bKOCbcerQt4Nh+nfQh7omyedXmYnHW6vsWv2Sv6vWJc90A205pt8k+LpS/joA2I/n3sY5Daisc1oPBUPJXbdr/BiBauI0HtvIYF9JJGlc6s4xwU6nmdhVlgUlgapgsfVLOBbCMFPur2KUA==</latexit>

H/S/L

SAL

(b)

図 7 (a) リアルタイム処理 (b) ウインドウ処理 におけるスループット

した．SAL のレイテンシは Baseline の 8.4 倍，Lineage の 1.6倍だった．この時の SAL の Traversal 時間は SAL のレイテン
シのうち約 52%を占めており，このことは拡張来歴を求めるた

スループット [/s]イテンシに関しては処理コストが大きい場合でも入力タプル長が長い場合，レイテンシへの影響は非常に小さいが，入力タプ
ル長が短い場合は性能差が現れる結果となった．またスループッ
い場合は拡張来歴を導出したとしても性能の低下がほとんど見と比べて Traversal 時間が長くなることが示された．
人工データを用いた実験では，処理コストが小さい場合には

Base

Lin

SAL

Window
Traversal時間

20
10
0
Realtime

Window
LineageSAL

図 8 リアルデータを用いた性能評価られなかった（図 7(b) ）．H/L/S のケースで統計的な差は見間の割合は非常に小さく，多くの場合で SAL の方が Lineage

SAL

30

Baseline

トはリアルタイム処理フローの場合と同様，処理コストが大き

コストの大小に関わらずレイテンシ全体に占める Traversal 時

LinRealtime

ように拡張来歴の追加情報を導出する SAL の方が Lineage とLineage の 1.03 倍となった．Traversal 時間に関しては，処理

**

1E-5

レイテンシ

次にウインドウ処理フローを用いた際の結果を説明する．レ

**
+31%

**

Base

比べて，Traversal 時間が長くなることを示した．

さい場合は，SAL の L/S/S のレイテンシが Baseline の 2.8 倍，

+30%

1E-3

考えられる．加えて Traversal 時間に関しては，図 6(a) で示す

倍でその差は非常に小さい．一方，感情判定の処理コストが小

**

1E-1

めの追加処理が性能に大きく影響を与えることを示しているとられたが，この時の SAL のスループットは Baseline の 0.996

**

1E+1

処理時間 [s]倍となり，スループットは Baseline の 0.14 倍，Lineage の 0.72

拡張来歴を求める際のオーバヘッドが大きくなる結果になった．
しかし本研究で想定しているような AI/ML 処理の処理コストは一般に大きいため，実際に本研究が使用される状況においては拡張来歴を求める際のコストはそれほど問題にならないと考えられる．

5. 5 リアルデータを用いた評価実験
リアルデータを用いた評価実験では，IBM が提供するネット

ワークベースの感情判定モデルと，元の Amazon レビューデー
タを使用した．感情判定モデルの処理コストは前節の処理コスト Heavy に相当し，元の Amazon レビューデータのタプルサ[2]

イズには Short〜Long の範囲で様々なサイズのタプルが存在している．またウインドウサイズは 1 秒ウインドウを使用した．
そのため本実験は，リアルタイム処理フローでは前節の H/S/-[3]と H/L/-，ウインドウ処理フローでは H/S/S と H/L/S に対応している．

[4]

図 8 が実験の結果である．本実験は前節の処理コスト Heavyの場合に対応しているため，リアルタイム処理フローではレイ
テンシ，スループットの両方で非常に小さいコストで拡張来歴[5]が導出でき，レイテンシに占める Traversal 時間は非常に小さいという結果になった．レイテンシで統計的な差は見られたも[6]のの，その時の SAL のレイテンシは Baseline の 0.996 倍 で，ほとんど影響ないことが示された．
またウインドウ処理フローにおけるスループットや Traversal[7]

時間の傾向はリアルタイムの場合と同様となった．一方 SAL のレイテンシは SAL は Baseline の 3.6 倍，Lineage の 1.9 倍 になるという結果となった．これは元の Amazon レビューデータ

[8]

ではサイズ小のタプルの割合が大きいため，前節の処理コスト
大，タプルサイズ小の時と同様の傾向が現れたと考えられる．
[9]

6 結

論

本稿では AI/ML 処理を伴う複合的ストリーム処理において，従来の Lineage に加えて AI/ML 処理の判断根拠を提示する，[10]

拡張来歴導出手法の説明を行った．さらにシステムを最新手法である GeneaLog に基づいて Apache Flink 上に実装し，偏り[11]のない人工データとリアルデータを用いた評価実験の結果を示した．実験結果から，説明した手法は AI/ML 処理のコストが大きい場合には小さなコストで拡張来歴が導出可能である傾向[12]を示した．今回説明した枠組みによって，AI/ML 処理を伴う
複合的ストリーム処理の分析結果として得られるデータの信頼性を一層高められることが期待される．
今後の課題としては，より多様なデータセットや処理フロー[13]における評価実験の実施や，現実のストリーム処理アプリケー
ションへの適用，Apache Flink 以外のストリーム処理エンジ[14]ンでの実装が挙げられる．さらに，導出された拡張来歴の情報をデータベース等を用いて永続化かつクエリ可能にするシステ
ムの提案も重要なトピックである．

謝

[15]

辞

本研究の一部は，JSPS 科研費 (JP19H04114，JP20K19806，[16]

JP22H03694)，JST CREST (JP-MJCR22M2)，NEDO(JPNP20006)，AMED (JP21zf0127005)，SKY 株式会社共同研究，JST 次世代研究者挑戦的研究プログラム (JPMJSP2124)
による．

[17]

文

献

[1] Melanie Herschel, Ralf Diestelkämper, and Houssem
Ben Lahmar. A survey on provenance: What for? what[18]

form? what from? The VLDB Journal, 26(6):881–906,
2017.
Susan B. Davidson and Juliana Freire. Provenance and scientiﬁc workﬂows: Challenges and opportunities. In Proceedings of the 2008 ACM SIGMOD International Conference
on Management of Data, page 1345–1350, 2008.
Sherif Akoush, Ripduman Sohan, and Andy Hopper.
Hadoopprov: Towards provenance as a ﬁrst class citizen inmapreduce. In 5th USENIX Workshop on the Theory andPractice of Provenance, 2013.
Y. Cui and J. Widom. Practical lineage tracing in data
warehouses. In Proceedings of 16th International Conference on Data Engineering, pages 367–378, 2000.
Yingwei Cui, Jennifer Widom, and Janet L. Wiener. Tracing the lineage of view data in a warehousing environment.
ACM Trans. Database Syst., 25(2):179–227, 2000.
Boris Glavic, Kyumars Sheykh Esmaili, Peter Michael Fischer, and Nesime Tatbul. Ariadne: Managing ﬁne-grained
provenance on data streams. In Proceedings of the 7th ACM
International Conference on Distributed Event-Based Systems, page 39–50, 2013.
Dimitris Palyvos-Giannas, Vincenzo Gulisano, and Marina
Papatriantaﬁlou. Genealog: Fine-grained data streaming
provenance in cyber-physical systems. Parallel Computing,89, 2019.
Masaya Yamada, Hiroyuki Kitagawa, Toshiyuki Amagasa,
and Akiyoshi Matono. Augmented lineage: Traceability ofdata analysis including complex udfs. In Database and Expert Systems Applications, pages 65–77, 2021.
Masaya Yamada, Hiroyuki Kitagawa, Toshiyuki Amagasa,
and Akiyoshi Matono. Augmented lineage: traceability ofdata analysis including complex udf processing. The VLDB
Journal, 2022.
Masaya Yamada et al. Streaming augmented lineage: Traceability of complex stream data analysis. In Information Integration and Web Intelligence, pages 224–236, 2022.
Todd J. Green, Grigoris Karvounarakis, and Val Tannen.
Provenance semirings. In Proceedings of the Twenty-Sixth
ACM SIGMOD-SIGACT-SIGART Symposium on Principles of Database Systems, page 31–40, 2007.
J. Nathan Foster, Todd J. Green, and Val Tannen. Annotated xml: Queries and provenance. In Proceedings of theTwenty-Seventh ACM SIGMOD-SIGACT-SIGART Symposium on Principles of Database Systems, page 271–280,
2008.
Matteo Interlandi et al. Titian: Data provenance support
in spark. In Proceedings of the VLDB Endowment International Conference on Very Large Data Bases, volume 9,
page 216–227, 2015.
Nithya N. Vijayakumar and Beth Plale. Towards low overhead provenance tracking in near real-time stream ﬁltering.
In Provenance and Annotation of Data, pages 46–54, 2006.
Min Wang et al. A time-and-value centric provenance modeland architecture for medical event streams. In Proceedingsof the 1st ACM SIGMOBILE International Workshop on
Systems and Networking Support for Healthcare and Assisted Living Environments, page 95–100, 2007.
Jianmo Ni, Jiacheng Li, and Julian McAuley. Justifying
recommendations using distantly-labeled reviews and ﬁnegrained aspects. In Proceedings of the 2019 Conference on
Empirical Methods in Natural Language Processing and the
9th International Joint Conference on Natural Language
Processing (EMNLP-IJCNLP), pages 188–197, 2019.
MLX. Text Sentiment Classiﬁer. https://www.ml-exchange.org/models/max-text-sentiment-classifier.
Bernard L Welch. The generalization of student’s problem
when several diﬀerent population varlances are involved.
Biometrika, 34(1-2):28–35, 1947.