本記事はこちらのブログを参考にしています。
翻訳にはアリババクラウドのModelStudio(Qwen)を使用しております。
アリババクラウドのオープンソースビッグデータチームによる最新技術「Flash」の紹介
本記事は、アリババクラウドの上級ディレクターであり、オープンソースビッグデータ部門の責任者である王峰（ニックネーム：Mowen）氏が、Apsara Conference 2024のオープンソースビッグデータセッションで行ったプレゼンテーションに基づいています。主要なトピックは以下の通りです：
- Apache Flinkはストリーム処理の事実上の標準となった
- Flashのコア技術
- Flashのパフォーマンス向上
- アリババグループ内でのFlashのビジネス応用
今日は、アリババクラウドのオープンソースビッグデータチームが開発したリアルタイムコンピューティングの最新技術について共有します。この技術とは、「Flash」というネイティブでベクトル化されたストリーム処理エンジンです。Apache Flinkと完全に互換性があり、次世代のストリーム処理を象徴するものです。開発の動機、コア技術、現在の成果、そしてアリババグループ内での成功事例について説明します。
1. Apache Flinkはストリーム処理の事実上の標準となった
アリババはApache Flinkの初期採用者であり、その提唱者でもあります。私たちはストリーム処理において10年以上の経験を積み重ねてきました。初期のストリーム処理エンジンとして、Hadoop時代に登場したApache Stormがありました。画期的ではありましたが、特に状態管理において限界がありました。ステートレスな性質が原因で、正確性が求められるデータ処理シナリオでの効果が制限されていました。その後、バッチ処理エンジンであるApache SparkをベースにしたApache Spark Streamingが登場しました。Apache Spark Streamingはマイクロバッチモデルを使用してストリーム処理を提供しましたが、このモデル固有のマイクロバッチ処理によりレイテンシが増加し、パフォーマンスとスループットに影響を与えました。さらに、Apache Spark Streamingは正確なストリーム処理セマンティクスを完全に実現できませんでした。
Flinkは、ストリーム処理における多くの長年の課題を解決しました。Flinkは低レイテンシ、高スループット、ステートフルな計算をネイティブでサポートし、複雑なイベント時間や順序外のデータを効果的に処理できるため、リアルタイムデータ分析の強力なソリューションとなっています。2014年にApache Software Foundationに参加して以来、Apache Flinkは過去10年間で進化を遂げ、ストリーム処理の事実上の標準となりました。
Apache Flinkのコアアーキテクチャは、簡単な図で説明できます。Apache Flinkはストリーム実行エンジンであり、バッチ処理とストリーム処理を統合しています。単一の実行エンジンを使用して、ストリームデータとバッチデータの両方を処理できます。さらに、Apache Flinkはストリーム処理とバッチ処理のための統一APIを提供し、開発を簡素化しています。そのAPIエコシステムにはSQL、Java、Pythonが含まれており、開発者の生産性をさらに向上させています。
近年、Apache Flinkの技術アーキテクチャは大幅に進化しました。例えば、リアルタイムデータ同期のためにFlink Change Data Capture (CDC)が台頭し、データ同期と統合におけるApache Flinkの採用が広がっています。また、Apache Flinkは古典的な機械学習タスクにも広く使用され、堅牢で成長しているエコシステムを持っています。さらに、Apache FlinkはKubernetesとシームレスに統合され、コンテナ化とクラウドネイティブデプロイメントを完全に採用しています。Apache Flinkは、さまざまなデータストアを結びつける強力なコネクタとして機能し、ビッグデータのランドスケープを構成する多様なデータストアを統合します。しかし、Flink自体に深く入り込む前に、基本的な疑問を考え直しましょう：すべてのビッグデータはどこから来るのでしょうか？データの保存と管理はビッグデータ処理の第一歩です。データは通常、データベース、メッセージキュー、データレイク、またはデータウェアハウスに保存されます。ただし、データは流れることで初めて価値を生み出します。Apache Flinkは、オープンソースビッグデータエコシステム全体において重要な役割を果たしています。その最大の価値は、さまざまなデータソース間でのリアルタイムデータストリーミングを可能にすることです。Flink Connectorはさまざまなタイプのデータソースを接続でき、Flinkはビッグデータエコシステム全体の中心的な橋渡しとなっています。Apache Flinkのエコシステムは成熟しており、包括的です。Apache Flinkは異なるストレージシステム間でのデータのエクスポートと移動を促進し、これが現在のビッグデータランドスケープにおけるApache Flinkの役割を示しています。
ご覧のように、堅牢なアーキテクチャと活気あるエコシステムにより、Apache Flinkは商業的にもオープンソースコミュニティ内でもストリーム処理の事実上の標準となっています。アリババはApache Flinkの初期採用者であり、2016年以来、アリババグループ内でApache Flinkが展開され、eコマース、物流、旅行、地図などの多様な事業部門や業界で利用されています。近年、中国国内のインターネット、金融、物流、運輸、自動車などのさまざまな業界でApache Flinkの採用が急速に拡大しています。国際的には、北米、ヨーロッパ、東南アジアなどでもApache Flinkが広く認知され、採用されており、グローバルなストリーム処理標準として確立されています。2023年には、Apache Flinkが優れたストリーム処理モデル設計と広範な業界採用を称えられ、SIGMOD Systems Awardを受賞しました。この受賞は、Apache Flinkがストリーム処理の事実上の標準であることを再確認するものです。アリババクラウドはApache Flinkを利用してリアルタイムコンピューティング製品を強化し、ユーザーに高度なサービスを提供しています。
では、なぜFlashという次世代のベクトル化ストリーム処理エンジンを開発したのでしょうか？その答えは、まずApache Flinkが事実上の標準となっていることです。ユーザーのニーズは必然的にFlinkとの互換性を求めます。これにより、ユーザーは特定のプラットフォームに縛られず、Flinkがサポートするさまざまな上流および下流
Flashエンジンのコア技術と設計
したがって、私たちは2年前にこのプロジェクトを開始し、ネイティブなApache Flinkエンジンを開発しました。長年にわたり、私たちのチームはApache Flinkの技術開発において主要な貢献者であり続けてきました。ベクトル化計算を統合し、C++のパフォーマンス上の利点をApache Flinkの計算モデルに取り入れることでハードウェアの利用を最大化する可能性があることを認識しました。これがFlashエンジンの誕生につながりました。2年間の開発を経て、大幅な改善を達成し、正式にFlash 1.0をリリースしました。
2. Flashのコア技術
Nexmarkベンチマークによると、Flash 1.0はオープンソースのApache Flinkと比較して5倍から10倍のパフォーマンス向上を示しています。これが今日のFlashエンジン発表の背景です。次に、Flashのベクトル化ストリーム処理エンジンのコア技術設計について詳しく説明し、オープンソース版と比べてなぜこれほど顕著なパフォーマンスの利点があるのかを説明します。
この図はFlashのコアアーキテクチャを示しています。青いコンポーネントはオープンソースのFlinkフレームワークを表しており、APIや分散ランタイムを含み、すべて完全にオープンソース互換性を維持しています。オレンジ色のコンポーネントは新たに導入されたネイティブランタイムカーネルです。SQL API、Table API、およびSQLオプティマイザを保持することで、FlinkタスクとFlink SQLとの完全な互換性を維持しています。また、一部のFlink Javaランタイム機能も保持し、まだネイティブに対応していない演算子のフォールバック実行を提供し、シームレスな移行を確保しています。エンジンのコアデザインは、Leno統合層、Falcon演算子層、ForStDB状態保存層という3つの主要な層を中心に構築されています。Falconはベクトル化計算を提供し、ForStDBはベクトル化された状態保存を提供します。これら3つの層により、FlashはJavaベースのApache Flinkランタイムよりも大幅に高いパフォーマンスを実現しています。
2.1 Leno層
LenoはApache SparkにおけるGlutenと同様に、Apache Flinkの分散フレームワークからストリーミングネイティブランタイムを切り離し、ネイティブ演算子の独立したデプロイメントを可能にします。Lenoはユーザーが送信したSQLクエリに基づいてネイティブ実行計画を生成します。Flinkプランナを利用して、SQLクエリ内のすべての演算子にネイティブ対応があるかどうかを判断します。該当する場合、完全なC++ベクトル化実行計画が生成されます。そうでない場合は、Java実行計画にフォールバックします。この層は主にフレームワークの統合に焦点を当てており、Javaとネイティブ実行環境間のブリッジとして機能します。
2.2 Falconベクトル化演算子層
Flashのコアデザインは、Falconベクトル化演算子層とForStDB状態保存層を中心に展開します。まず、ベクトル化演算子層について説明します。この層ではC++を使用してベクトル化演算子とメモリ最適化を実装し、すべての計算がベクトル化された方法で行われることを保証します。Apache Flinkでは、演算子はステートレスまたはステートフルに分類されます。フィルタやストリーム処理での文字列プロセッサなどのステートレス演算子は状態を保持しません。一方、集約やストリーム結合で使用されるステートフル演算子は状態の維持が必要です。
Falcon層では、多数の組み込みデータ型、時間関数、文字列処理関数をC++で再実装しています。すべての演算子はベクトル化方式で動作し、計算効率が向上します。アリババグループ内の内部ストリーミング分析ワークロードの分析に基づき、Flashエンジンは現在、80％以上のユースケースをカバーできています。これは大部分の計算および算術ロジックをカバーしていることを意味します。私たちは残りの演算子を積極的に開発し、より幅広いストリーム処理要件に対応しようとしています。
Falconベクトル化演算子層がJavaベースのFlinkよりも優れている理由を説明します。SIMD命令を活用してデータ並列性を実現します。ストリーム処理は概念的にはレコードごとに個別に処理されますが、その基盤となる実装ではバッファ内のバッチデータを使用します。上流ノードはバッチ（例えば1,000レコード、約32KB）を処理し、それをネットワークバッファとして下流に送信します。下流での処理も1,000レコード単位で行われます。これらの1,000レコードを処理する具体的なバッチサイズ（10、100、または1,000など）はアルゴリズムの特性によって異なります。
SIMD命令を活用することで、複数のレコードを同時に処理でき、文字列解析や比較のような単一レコード操作でも高速化を実現します。ベクトル化によりすべてのデータを同時に比較できるため、計算効率が大幅に向上します。これはバッチ処理の利点と並行します。このアプローチをApache Flinkに適用することで、頻繁に使用される組み込み関数、特に文字列および時間処理に関する関数を最適化しました。これらの最適化により、数十倍から数百倍のパフォーマンス向上が得られました。これはC++の利点とベクトル化実行による効率向上の両方に起因します。
注目すべきもう一つの特徴は、ユーザー定義関数（UDF）のサポートです。アリババグループ内では、ストリーム処理が広く使用されており、80％以上のユースケースでUDFが必要です。UDFのサポートがない場合、多くのユースケースを実装することはできません。例えば、Veloxのようなオープンソースのバッチ処理エンジンはUDFに遭遇するとJavaランタイム環境に頼る傾向があり、ユーザーコードの最適化を妨げます。UDFサポートの重要性を認識し、私たちは最初からこれを優先しました。私たちのアプローチでは、Java UDFであってもベクトル化計算を利用でき、UDFにJavaランタイムへの
ForStDB Mini と Flash エンジンの紹介
ForStDB Mini は、PV（ページビュー）や UV（ユニークビジター）などの統計向けに設計されたインメモリストアです。このシステムは、すべてのデータアクセスに対してベクトル化されたインターフェースとバッチ出力を活用し、スループットを向上させます。そのパフォーマンスは、大規模なハッシュインデックスに似た最新のインデックス構造に依存しており、SIMD を使用して単一および並列検索を可能にします。これにより、従来のキーバリューストアよりも大幅なパフォーマンスの優位性を持ち、特に Java 環境ではオープンソースの Apache Flink のインメモリストレージバックエンドを上回る性能を発揮します。C++ で完全に構築され、アリーナベースのメモリプール管理が採用されているため、Java ベースのソリューションと比較して優れたメモリ効率を実現しています。これにより、本番環境で利用可能な高性能なステートストレージソリューションとなっています。
Pro バージョンは、非常に大規模なステートデータセットを管理する必要があるため、より大きな課題に直面しています。これらのデータセットは、メモリだけでなくディスクストレージも必要です。ステートデータが利用可能なメモリを超えた場合、パフォーマンスに大きな影響を与える可能性があります。そのため、非同期 I/O 機能を導入し、既存のベクトル化とバッチ処理と並行して非同期操作を可能にしました。また、Log-Structured Merge-Tree (LSM) アーキテクチャをカスタマイズ・最適化し、ストリーム処理の特性を活用しています。この非同期 I/O と並列処理の組み合わせにより、ステートデータへのアクセスが加速され、全体的な効率が向上します。非同期実行が導入された場合、ストリーム処理におけるデータ順序の維持は新たな重要な課題となります。従来のキーバリューストアとは異なり、データポイント間の関係が厳密に強制されない場合でも、ストリーム処理では k-v アクセスの順序が必要です。当社のフレームワークは、ストリームデータのバッチ処理と順序付けを保証すると同時に、高い処理効率も確保します。これらの課題に対応することで、ForStDB のステートストレージの利点と Falcon オペレータ層を組み合わせ、大幅なパフォーマンス改善を達成しました。
Flash のパフォーマンス向上
パフォーマンス評価には、オープンソースの Nexmark ベンチマークを使用しました。Nexmark は、GitHub で広く認識されているストリーム処理ベンチマークです。Alibaba Cloud 上で実行される Flash 1.0 と最新のオープンソース版 Apache Flink 1.19 を比較しました。オープンソース版 Apache Flink は Elastic Compute Service (ECS) インスタンスにデプロイされ、ユーザー管理環境をシミュレートしましたが、Flash 1.0 は同じ数のコンピュートユニット（CU）を使用して完全に管理されたサーバーレスプラットフォーム上で実行されました。これにより、ハードウェアリソースが同等の公平な比較が確保されています。入力レコード数が 1 億件および 2 億件のデータセットを使用して、異なるストリーム処理規模をシミュレートしました。1 億件のデータセットは小～中規模を表し、ステートサイズが小さく、ForStDB Mini でのテストに適しています。一方、2 億件のデータセットは大規模を表し、ステート管理にディスクスプライオーバーが必要となるため、ForStDB Pro を使用しています。両方の規模で、オープンソース版 Apache Flink と比較して 5 倍以上のパフォーマンス向上が観察され、特に小規模データセットでは 8 倍以上に達しました。これらの結果は再現可能です。テスト環境、方法論、およびデータセットは公開されており、今後はハンズオンによる検証の機会も提供されます。
冒頭で述べたように、Apache Flink はストリーム処理において広く認められた事実上の標準エンジンであり、ストリームとバッチの統合を得意としています。その実行エンジンは、ストリーム処理からのパフォーマンス最適化を活用してバッチ計算にも大きな利点をもたらします。TPC-DS ベンチマークを使用して ECS インスタンス上で 10 TB のデータセットでバッチパフォーマンスをベンチマークしました。一貫したテスト環境と手順を維持しながら、オープンソース版 Apache Flink 1.19 と Apache Spark 3.4 を当社製品と比較し、同じ数の CU を使用しました。結果は、当社製品がバッチ処理シナリオでもオープンソース版 Apache Flink と Apache Spark を 3 倍以上上回ることを示しています。これらの結果は再現可能かつ検証可能です。これらのストリームおよびバッチ処理ベンチマークは、純粋なオープンソースソリューションと比較して C++ ベクトル化 Flash エンジンの著しいパフォーマンスとコスト効率の利点を示しています。
Alibaba Group 内での Flash のビジネスアプリケーション
理論的およびベンチマークの結果に加えて、Alibaba の本番環境における Flash エンジンの実世界でのビジネスアプリケーションについて共有します。今年の初めから、Flash エンジンは継続的なオンライン改良と反復を通じて Alibaba 内で徐々に展開されてきました。9 月までに、Flash は Alibaba 内で 10 万 CU 以上の実験サービスをカバーしています。本番トラフィックは、Tmall、Cainiao、Lazada、Fliggy、AMAP、Ele.me など、Alibaba の主要なビジネスシナリオをカバーしています。ビジネスアプリケーションには、ユーザーの PV および UV 統計、ビジネスインテリジェンス（BI）、広告パフォーマンス監視、個別のリアルタイム推奨、注文および物流追跡などのシナリオが含まれます。結果として、参加しているビジネスユニットのコストが 50% 削減されました。完全に展開されれば、大幅なリソース節約が実現されるものと確信しています。この新しいエンジンは、堅牢な理論設計に基づいており、ラボテストと説得力のある本番結果によって検証されています。したがって、私たちはこの技術を Alibaba Cloud でローンチし、中小企業やクラウドネイティブ企業を支援できることを楽しみに