Why Flink + AI is worth looking forward to

昨年 11 月に開催された Flink Forward Asia 2019 で、Flink コミュニティは今後の開発の主な方向性をいくつか提案しました。その一つが AI の受け入れです [1]。実際、近年 AI は引き続き注目を集めており、さまざまなコンピューティングフレームワーク、モデル、アルゴリズムが次々と登場しています。ある意味では、このトラックは既にやや混雑していると言えます。そのような中で、Flink はどのように AI を受け入れ、ユーザーにどのような新たな価値をもたらすのでしょうか。Flink AI の強みと課題は何か。本記事では、これらの議論を通じて Flink AI の開発方向を分析します。

Lambda アーキテクチャ、ストリームバッチ統合と AI のリアルタイム性
Flink の AI における価値は、実際にはビッグデータにおける Lambda アーキテクチャ [2] とストリームバッチ統合という 2 つの概念に関わっています。Flink がリアルタイムビッグデータにもたらす価値は、AI にも同様に恩恵をもたらします。

ビッグデータの発展の歩みを簡単に振り返りましょう。Google の画期的な「三種の神器」[5] 論文の発表後、長い間ビッグデータ開発の主軸にはバッチコンピューティングのみが存在していました。その後、データの適時性の重要な役割が認識されるようになり、Twitter がオープンソース化したストリームコンピューティングエンジン Storm [6] が爆発的に普及し、Flink をはじめとするさまざまなストリームコンピューティングエンジンが次々と登場しました。コスト、計算精度、フォールトトレランス、そしてデータの適時性のバランスを考慮し、各企業はバッチコンピューティングとストリームコンピューティングを同じアーキテクチャに統合する Lambda アーキテクチャと呼ばれるソリューションを採用しました。

Lambda アーキテクチャはデータの適時性を解決する一方で、いくつかの問題も抱えています。中でも最も批判されるのが、システムの複雑さと保守性です。ユーザーは Batch Layer と Speed Layer のそれぞれにエンジンとコードのセットを維持し、両者の計算ロジックが完全に一致していることを保証する必要があります (図 1)。

この問題を解決するため、各コンピューティングエンジンはストリームバッチの統合に取り組み始め、同じエンジンのセットでストリーム処理とバッチ処理の両方を実行しようとしています (図 2)。数年の努力を経て、Spark [7] と Flink は現在の第一線の 2 大主流コンピューティングエンジンとなりました。Flink はストリームコンピューティングからバッチコンピューティングへと進出し、同じ標準 SQL 文でストリームとバッチをクエリして最終結果の一貫性を保証するという非常に典型的な成功例を達成しました [8]。一方 Spark は、バッチコンピューティングからストリームコンピューティングへ Micro Batch 方式でアプローチする Spark Streaming を提案しましたが、レイテンシ性能の面では常に劣っています。

ビッグデータの発展過程から見ると、Lambda アーキテクチャとストリームバッチ統合を推進してきた原動力は、リアルタイムデータです。それはデータから価値を引き出すことでもあります。AI のデータの適時性に対する要求はビッグデータと一致しており、リアルタイム AI も重要な開発方向となるでしょう。現在の主流 AI シナリオと技術アーキテクチャを観察すると、ビッグデータプラットフォームとの多くの関連性や類似点が見つかります。

現在の AI は大まかに、データ前処理 (データ準備 / 特徴量エンジニアリングとも呼ばれる)、モデルトレーニング、推論予測の 3 つの主要段階に分けられます。各段階における AI のリアルタイム要件と解決すべき課題を一つずつ見ていきましょう。ビッグデータのアーキテクチャとの比較のため、フローコンピューティングとバッチコンピューティングという 2 つのコンピューティングタイプが、すべてのデータベースのコンピューティングを 2 分し、何も漏らしていないと仮定します。AI の各段階も、シナリオに応じてそのいずれかに分類できます。

データ前処理 (データ準備 / 特徴量エンジニアリング)

データ前処理段階は、モデルトレーニングと推論予測の前工程です。多くの場合、これはビッグデータの問題と言えます。データ前処理の下流に応じて、データ前処理はバッチコンピューティングにもストリームコンピューティングにもなり得、コンピューティングタイプは下流と一致します。典型的なオフライントレーニング (バッチコンピューティング) とオンライン予測 (ストリームコンピューティング) のシナリオでは、トレーニングと予測の両方に同じ前処理ロジックが必要です (同じサンプル結合ロジックなど)。ここでの要件は Lambda アーキテクチャの要件と同じであり、ストリームバッチ統合エンジンが特に有利です。バッチジョブとストリームジョブに別々のエンジンを使用することを避け、ロジックの一貫性を保つ 2 組のコードを維持する手間を省けます。

モデルトレーニング

現在、AI トレーニング段階は基本的にバッチコンピューティング (オフライントレーニング) で静的モデル (Static Model) を生成するプロセスです。これは、現在のモデルの大半が独立同分布 (IID) の統計法則に基づいて実装されているためです。つまり、大量のトレーニングサンプルから特徴量とラベルの間の統計的相関を見つけ出します。これらの統計的相関は通常急激に変化しないため、あるバッチのサンプルでトレーニングしたデータは、同じ特徴量分布を持つ別のバッチのサンプルにも適用できます。ただし、このようなオフラインモデルトレーニングで生成される静的モデルには、いくつかの問題がある可能性があります。

まず、サンプルデータの分布は時間とともに変化する可能性があります。この場合、オンライン予測時のサンプル分布とトレーニングサンプルの分布にずれが生じ、モデル予測の効果が低下します。そのため、静的モデルは通常再トレーニングが必要であり、これは周期的なプロセスでも、サンプルとモデルの予測効果をモニタリングして判断することもできます (なお、このモニタリング自体が典型的なストリームコンピューティング要件であることに注意してください)。

さらに、いくつかのシナリオでは、予測段階のサンプル分布がトレーニング段階で未知の場合があります。たとえば、Alibaba の独身の日、微博のホット検索、高頻度取引など、サンプル分布が予測不能に変化するシナリオでは、モデルを迅速に更新してより良い予測結果を得ることが非常に大きな価値を持ちます。

したがって、理想的な AI コンピューティングアーキテクチャでは、モデルをタイムリーに更新する方法を考慮する必要があります。ストリームコンピューティングはこの点でも独自の強みを持っています。実際、Alibaba は既に検索レコメンデーションシステムでオンライン機械学習を使用しており、独身の日などのシナリオで良い成果を上げています。

推論予測

推論予測の環境とコンピューティングタイプは比較的豊富で、バッチ処理 (オフライン予測) とストリーム処理が含まれます。ストリーム処理による予測は、大まかにオンライン予測とニアライン予測に分けられます。オンライン予測は通常ユーザーアクセスのクリティカルパスにあるため、レイテンシに対する要件はミリ秒レベルときわめて高いです。ニアライン予測の要件はやや低く、通常サブ秒レベルから秒レベルです。現在、大部分のネイティブストリーム処理エンジンはニアラインのデータ前処理と予測のニーズを満たせますが、オンラインのデータ前処理と予測は通常、極めて低いレイテンシを満たすために予測コードをアプリケーションに直接書き込む必要があります。そのため、ビッグデータエンジンがオンライン予測シナリオで使用されることはまれです。この点において、Flink の Stateful Function [9] は独自のイノベーションです。Stateful Function の本来の目的は、Flink 上でいくつかのステートフルな関数を通じてオンラインアプリケーションを構築することで、これにより超低レイテンシのオンライン予測サービスを実現できます。このように、ユーザーはオフライン、ニアライン、オンラインのすべてのシナリオで、同じコードセットと同じエンジンを使用してデータ前処理と予測を行えます。

まとめると、機械学習の各主要段階において、リアルタイム AI に対する重要な要件があることがわかります。では、どのようなシステムアーキテクチャがこうした要件を効果的に満たせるのでしょうか。

Flink と AI のリアルタイムアーキテクチャ
現在最も典型的な AI アーキテクチャの例は、オフライントレーニングとオンライン推論予測の組み合わせです (図 3)。

前述の通り、このアーキテクチャには 2 つの問題があります。

モデル更新のサイクルが通常比較的長いこと。

オフラインとオンラインの前処理で 2 組のコードを維持する必要がある可能性があること。

1 つ目の問題を解決するには、リアルタイムトレーニングのリンクを導入する必要があります (図 4)。

このリンクでは、オンラインデータは推論予測に使用されるだけでなく、リアルタイムでサンプルを生成し、オンラインモデルトレーニングにも使用されます。このプロセスでモデルは動的に更新されるため、サンプルの変化によりよく適合できます。

純粋なオンラインリンクも純粋なオフラインリンクも、すべての AI シナリオには適していません。Lambda の考え方と同様に、両者を組み合わせることができます (図 5)。

同様に、システムの複雑さと運用性の問題 (前述の 2 つ目の問題) を解決するため、データ前処理部分でストリームバッチ統合エンジンを使用し、2 組のコードの維持を避けたいと考えます (図 6)。それだけでなく、データ前処理と推論予測がオフライン、ニアライン、オンラインのレイテンシ要件をサポートする必要があるため、Flink の使用は非常に適した選択肢です。特にデータ前処理において、Flink の包括的で完全なストリームとバッチの両方に対する SQL サポートは、開発効率を大幅に向上させます。

さらに、システムの複雑さをさらに低減するため、Flink はモデルトレーニングプロセスでも一連の取り組みを行っています (図 7)。

ストリームバッチ統合アルゴリズムライブラリ Alink

昨年の FFA 2019 で、Alibaba は Flink ベースの機械学習アルゴリズムライブラリ Alink [10] をオープンソース化し、段階的に Apache Flink に貢献して Flink ML Lib として Apache Flink とともにリリースする計画を発表しました。オフライン学習アルゴリズムに加え、Alink の大きな特徴は、ユーザーにオンライン学習アルゴリズムを提供し、Flink がリアルタイム AI でより大きな役割を果たせるようにすることです。

Flink 上のディープラーニング (flink-ai-extended [11])

現在人気のあるディープラーニングフレームワーク (TensorFlow、PyTorch) を Flink に統合するのを支援します。ディープラーニングのアルゴリズム開発者以外のユーザーも、Flink ベースの完全な AI アーキテクチャを実現できるようにします。

ストリームバッチ統一の反復セマンティクスと高性能実装

AI トレーニングにおける反復収束はコアとなる計算プロセスです。Flink は初期からネイティブ反復を使用して反復計算の効率を保証してきました。ユーザーがより良いアルゴリズムを開発し、コードを簡素化し、運用効率をさらに向上させるため、Flink コミュニティはストリームとバッチの反復セマンティクスを統一するとともに、反復パフォーマンスをさらに最適化しています。新しい最適化により、反復ラウンド間の同期オーバーヘッドを可能な限り回避し、異なるバッチのデータと異なるラウンドの反復を並行して実行できるようにします。

もちろん、完全な AI アーキテクチャには、前述の 3 つの主要段階に加え、さまざまなデータソースとの連携、既存の AI エコシステムとの連携、オンラインでのモデルとサンプルのモニタリング、その他の各種周辺サポートシステムなど、完了すべき多くのタスクがあります。Alibaba のリアルタイムコンピューティング責任者 Wang Feng (花名：墨問) が FFA 2019 の基調講演で示した図 (図 8) は、これらの作業の多くをうまくまとめています。

Flink コミュニティもこの方向性に取り組んでいます。一般的に、これらの AI 関連の作業は「補完」「改善」「革新」の 3 つのカテゴリに分類できます。現在進行中の作業の一部を以下に挙げます。一部は AI と直接関係がない場合もありますが、Flink がリアルタイム AI にさらに良く貢献することに影響を与えます。

補完：他社にあって自社にないもの

Flink ML Pipeline [12]：ユーザーが機械学習用の完全なコンピューティングロジックを便利に保存し、再利用できるようにします。

Flink Python API (PyFlink [13])：Python は AI のネイティブ言語であり、PyFlink はユーザーに AI で最も重要なプログラミングインターフェイスを提供します。

ノートブック統合 [14] (Zeppelin)：ユーザーの AI 実験にフレンドリな API を提供します。

ネイティブ Kubernetes サポート [15]：Kubernetes と統合し、クラウドネイティブベースの開発、デプロイ、運用保守をサポートします。

改善：他社より優れているもの

コネクタの再設計と最適化 [16]：コネクタ実装を簡素化し、コネクタエコシステムを拡大します。

革新：他社にないもの

AI Flow：ビッグデータ + AI のトップレベルのワークフロー抽象化と、フローコンピューティングを考慮したサポートサービス (まもなくオープンソース化)。

Stateful Function [9]：オンラインアプリケーションに匹敵する超低レイテンシのデータ前処理と推論予測を提供します。

その中には、コネクタエコシステムを充実させてさまざまな外部データソースに接続するような、人気のあるビッグデータエンジンとしての Flink 自体の機能もあります。他方は Flink 外のエコシステムプロジェクトに依存する必要があり、中でも重要なのが AI Flow です。AI Flow はリアルタイム AI アーキテクチャに由来しますが、エンジン層で Flink に縛られず、トップレベルのストリームバッチ統一ワークフロー抽象化に注力し、異なるプラットフォーム、異なるエンジン、異なるシステム間でリアルタイム AI を実現するための環境サポートを提供することを目的としています。紙面の都合上、ここでの詳細は省略し、別の機会にご紹介いたします。

おわりに

Apache Flink はシンプルなストリームコンピューティングのアイデアから出発し、今日多くの人に恩恵をもたらす人気のあるリアルタイムコンピューティングのオープンソースプロジェクトに成長しました。このプロセスは、Flink コミュニティの数百人のコードコントリビューターと数万のユーザーなしには実現できませんでした。Flink は AI の分野でも大きな違いを生み出すことができると考えており、より多くの方々に Flink コミュニティに参加いただき、リアルタイム AI の価値を共に創造し、共有していくことを歓迎します。