記事では、Alibaba のリアルタイム コンピューティング Blink の中核技術を明らかにしています。妥協せずに速度を実現するにはどうすればよいでしょうか。

[[218293]]

はじめに：この記事では主に、アリババのリアルタイムビッグデータと関連する機械学習技術、そしてこれらの技術がどのようにビッグデータのアップグレードを実現し、最終的にダブル11で優れた成果を達成するかについて説明します。

[[218294]]

Dasha は Alibaba のシニア テクニカル エキスパートで、Flink SQL のリアルタイム コンピューティングを担当しています。以前は米国の Facebook で働いており、Apache Flink コミッターでもあります。

Alibabaのリアルタイムコンピューティング

1999年以来、アリババは電子商取引プラットフォームから継続的に事業を拡大し、タオバオやTmallをベースとした電子商取引プラットフォーム、アリママ広告プラットフォーム、アントファイナンシャルアリペイ、アリババクラウド、ビッグエンターテインメントなど、金融、決済、物流、エンターテインメントの分野で数多くの製品を派生させてきました。今日、Alibaba は単なる電子商取引プラットフォームではなく、巨大なアプリケーション エコシステムとなっています。アリババは現在、世界最大の電子商取引プラットフォームであり、2016年度の収益は5,500億米ドルに達しました。 Alibaba プラットフォームには中国の人口の 3 分の 1 に相当する 5 億人のユーザーがおり、毎日 1,000 万人近くのユーザーが Alibaba プラットフォームを通じて取引を行っています。

アリババは巨大な商用航空母艦になりました。この航空母艦では、膨大な数のユーザーとアプリケーションが必然的に大量のデータを生成します。現在、アリババのデータ量はEBレベルに達し、日々の成長はPBレベルに達しています。リアルタイムコンピューティングの毎日のピークデータ処理量は1秒あたり1億に達します。今年のダブル11では、驚異的な毎秒4億7000万に達しました。

リアルタイム コンピューティングは Alibaba 内で広く使用されています。新しい経済の出現と発展、技術革新、ユーザーニーズの向上に伴い、リアルタイムコンピューティング機能に対するニーズが高まっています。その最大の利点は、リアルタイムで変化するデータに基づいてビッグデータ処理の状態と結果を更新できることです。次に、Alibaba におけるリアルタイム コンピューティングのアプリケーション シナリオを説明する 2 つの例を示します。

1. ダブル11大スクリーン

アリババは毎年ダブル11に貴重なデータを集約してメディアに発表しており、GMV大スクリーンもその一つです。 GMV 画面全体は典型的なリアルタイム計算であり、各取引データが集計されて画面に表示されます。全体のプロセスは、DataBase にデータを書き込むことから始まり、データをリアルタイムで処理して HBase に書き込み、大画面に表示するまでです。全体のプロセスのリンクは非常に長いです。アプリケーション全体には多くの課題があります。

1) 大画面表示には数秒の遅延が必要であり、1秒未満のリアルタイム計算遅延が必要である

2) Double 11の大量のデータを1つのジョブに集約する必要がある

3) Exactly-Onceはデータ計算の精度を維持する

4) システムは可用性が高く、遅延や利用不能が発生しない

このアプリケーション シナリオの SLA は非常に高く、第 2 レベルのレイテンシとデータ精度が求められますが、計算は複雑ではありません。次に、より複雑なアプリケーションを紹介します。

2. リアルタイム機械学習

機械学習には通常、特徴とモデルという 2 つの重要なコンポーネントがあります。従来の機械学習では、バッチ コンピューティングを使用して特徴を収集し、モデルをトレーニングしますが、更新頻度が低すぎるため、常に変化するデータを持つアプリケーションのニーズに適応できません。たとえば、ダブル11ショッピングフェスティバルの期間中は、商品の価格や活動のルールが通常時とはまったく異なるため、以前のデータに基づいたトレーニングでは最良の結果は得られません。したがって、特徴を収集し、モデルをリアルタイムでトレーニングすることによってのみ、より満足のいく結果を得ることができます。この目的のために、私たちはリアルタイム機械学習プラットフォームを開発しました。

このリアルタイム機械学習プラットフォームは、主にリアルタイム特徴計算とリアルタイムモデル計算の 2 つの部分で構成されています。このシステムには、次のような多くの課題もあります。

1) 機械学習にはさまざまな指標の収集が必要であり、多くのデータソースが存在する

2) ユーザーディメンションや製品ディメンションなどの複数のディメンション。次元の重ね合わせやデカルト積によって、膨大な量のメトリックと膨大な状態が生成されます。

3) 機械学習は計算が複雑でCPUを大量に消費する

4) 一部のデータはステートに保存できず、外部ストレージが必要となり、外部IOが多くなります。

3. リアルタイムA/Bテスト

ユーザーのクエリも継続的に変化する可能性があります。典型的な例は、リアルタイム A/B テストです。

アルゴリズム エンジニアは、モデルをチューニングする際に複数のモデルを使用します。モデルによって計算モードや計算方法が異なり、計算結果も異なります。したがって、リアルタイム データにサブスクライブするさまざまなクエリが頻繁に発生します。結果が生成されると、ユーザー フィードバックに基づいてモデルが反復され、最終的に最適なモデルが得られます。 A/B テストの課題は、アルゴリズム エンジニアが多くのメトリックを計算することが多く、すべてのメトリックをリアルタイムでカウントすると多くのリソースが無駄になることです。

この課題に対処するために、A/B テスト フレームワーク開発プラットフォームを設計しました。これは、アルゴリズム エンジニアが関心を持つメトリックを同期し、集約して収集し、Druid エンジンに送信するために使用されます。このように、アルゴリズム エンジニアはさまざまなジョブの要件に応じて Druid にデータをクリーンアップし、Druid 上のさまざまなメトリックに対して統計分析を実行して、最適なアルゴリズム モデルを見つけます。

要約すると、リアルタイム コンピューティングは Alibaba 内で次のような課題に直面しています。

1) 巨大なビジネス、複数のシナリオ、多数の機械学習要件、これらすべてが非常に複雑な計算ロジックにつながる

2) データ量が多く、演算回数が多いため、リアルタイムコンピューティングマシン全体の規模が非常に大きい

3) 高いスループット要件を満たしながら、低レイテンシとデータ精度を確保する

Flinkの選択と最適化

上記の課題に対処するために、私たちは多くのコンピューティング フレームワークを調査し、最終的に次の理由から Flink を選択しました。

1. Flinkは状態をうまく導入・設計しており、結合などの状態に基づく複雑な論理計算もうまく記述できる。

2. Flink は Chandy-Lamport アルゴリズムを導入しており、そのサポートにより、Exactly-Once が実現され、低レイテンシで高いスループットを実現できます。

しかし、FlinkにはStateやChandy-Lamportアルゴリズムなどにまだ多くの欠陥があります。このため、AlibabaはBlinkというプロジェクトを開発しました。

Blink はオープンソースの Flink と Alibaba Improvement を組み合わせたもので、主に次の 2 つの部分に分かれています。

1. ブリンクランタイム

ストレージ、スケジューリング、コンピューティングを含め、Flink を使用する場合、各社はストレージ、スケジューリング、基盤となる最適化において多くの違いがあります。Alibaba の Blink も、ランタイムに対して多くのパーソナライズされた最適化を行っています。このレイヤーは Apache Flink コミュニティと統一するのが難しいため、Blink Runtime と呼んでいます。

2. フリンクSQL

ネイティブ Flink には比較的低レベルの DataStream API しかなく、ユーザーは使用時に大量のコードを設計して実装する必要があります。また、DataStream 自体にも設計上の欠陥があります。ユーザーの使用を容易にするために、Alibaba チームはストリーム コンピューティング用の Flink SQL を設計し、コミュニティにリリースしました。 Blink SQLではなくFlink SQLと名付けられているのは、SQLユーザーAPIの面でBlinkとFlinkがコミュニティで完全に統一されているためです。また、Apache Flinkの機能のほとんどはAlibabaによって貢献されているため、Flink SQLはBlink SQLであり、特に大きな違いはありません。

BlinkRuntime コア最適化復号化

1. 展開とモデルの最適化

最適化には次の点が含まれます。

1) 大規模展開の問題を解決する。 Flink では、クラスターにはすべてのジョブを管理する JobMaster が 1 つだけあります。ジョブの数が増え続けると、単一のマスターではより多くのジョブを処理できなくなり、ボトルネックが発生します。そのため、各ジョブに独自のマスターが存在するようにアーキテクチャを再構築しました。

2) 初期の Flink では、TaskManager が多くのタスクを管理していました。タスクに問題が発生すると、TaskManager がクラッシュし、他のジョブに影響を及ぼしていました。各ジョブに独自の TaskManager を持たせることで、ジョブの分離を強化します。

3)ResourceManagerを導入します。 ResourceManager は JobMaster と通信してリソースをリアルタイムで動的に調整し、最適なクラスターの展開を実現します。

4) これらの最適化は、YarnCluster だけでなく、Mesos およびスタンドアロンのデプロイメントにも適用されます。

これらの作業により、Flink を大規模なクラスター展開に適用できるようになります。

2.増分チェックポイント

リアルタイム コンピューティングでは、コンピューティングの状態を維持するために継続的なチェックポイントが必要です。 Flink の初期のチェックポイント設計には欠陥がありました。チェックポイントが発生するたびに、古い状態データがすべて読み取られ、新しいデータとマージされ、ディスクに完全に書き込まれていました。状態が拡大し続けると、チェックポイントが実行されるたびに読み取りと書き込みに必要なデータの量が非常に大きくなります。 つまり、ジョブのチェックポイント間隔を非常に大きく設定する必要があり、1 分未満にすることはできません。チェックポイント間隔が長いほど、フェイルオーバー時のロールバック計算が大きくなり、データの遅延が深刻になります。

チェックポイント間隔を短縮するために、増分チェックポイント設計を提案しました。要約すると、チェックポイント中は増分状態変更データのみが保存されます。各履歴チェックポイントのデータは保存されているため、後続のチェックポイントでは異なるデータをストレージに格納するだけで済みます。このように、チェックポイントが作成されるたびに更新する必要があるデータの量は非常に少なく、チェックポイントは数秒以内に完了できるため、フェイルオーバーによって発生する可能性のある遅延が大幅に削減されます。

3. 非同期IO

多くの場合、データを外部ストレージに保存する必要があるため、計算プロセス中にネットワーク IO を介してデータを読み取る必要があります。従来の方法では、Sync-IO 読み取り方式が使用されます。データ要求を発行した後、結果が返された後にのみ次のデータ要求を開始できます。この方法では、CPU がネットワーク IO 要求が返されるのを待つことが多いため、CPU リソースが無駄になります。 Sync-IO は CPU リソースの使用率が最大化されるのを防ぎ、CPU あたりの計算スループットに大きな影響を与えます。コンピューティングのスループットを向上させるために、非同期マルチスレッドによるデータ読み取りを可能にする Async-IO データ読み取りフレームワークを設計しました。

各データ要求が送信された後、次のデータ要求を送信する前にデータが返されるのを待つ必要はありません。外部ストレージからデータ要求が返されると、コンピューティング システムはコールバック メソッドを呼び出してデータを処理します。データ計算で順序を維持する必要がない場合は、データが返された後にすぐに計算されて送信されます。ユーザーがデータ計算の順序を維持する必要がある場合、最初に到着したデータをバッファを使用して一時的に保存し、先頭のデータがすべて到着した後にバッチで送信します。 Async-IO を使用すると、設定されたバッファ サイズに応じてコンピューティング スループットが数十倍から数百倍に増加し、ユニットの CPU 使用率と全体的なコンピューティング パフォーマンスが大幅に向上します。

前述の Blink ランタイムの最適化はすべて Apache Flink コミュニティに提供されたものであることは言及する価値があります。

Flink SQLのコア機能を解読する

1. アリババはApache Flink SQLの研究開発作業の80%を完了した

現在、Apache Flink SQL の機能の 80% は、Alibaba のリアルタイム コンピューティング チームによって提供されており、これには 200 件の提出と約 10 万行のコードが含まれます。 Flink SQL を使用する理由は、基盤となる API がユーザーの移行とオンライン起動に大きな不便をもたらすことがわかったためです。では、なぜ SQL を選択するのでしょうか?主な理由は次のとおりです。

1) SQL は非常に一般的な記述言語です。SQL は、ユーザーがジョブ要件を非常に便利に記述するのに適しています。

2) SQL は比較的優れた最適化フレームワークを備えているため、状態管理やパフォーマンスの最適化などの複雑な設計を気にすることなく、ビジネスロジックの設計に集中することができ、使用の敷居が大幅に下がります。

3) SQL は理解しやすく、さまざまな分野の人々に適しています。 SQL をよく使用するユーザーには、多くのコンピュータプログラミングの知識は必要ありません。製品設計から製品開発まで、あらゆる人が SQL の使い方をすぐに習得できます。

4) SQL API は非常に安定しており、組織をアップグレードしたり、コンピューティング エンジンを変更したりしても、ユーザーのジョブを変更することなく継続的に使用できます。

5) 一部のアプリケーション シナリオでは、ストリーミング更新とバッチ検証が必要です。 SQL を使用すると、バッチ コンピューティングとストリーム コンピューティングのクエリを統合できます。実際にクエリを実装すると、同じ結果になります。

2. ストリーム処理とバッチ処理

バッチ処理を備えた統合ストリーム コンピューティング SQL を設計するには、ストリーム処理とバッチ処理の違いを理解する必要があります。両者の主な違いは、ストリーム処理のデータは無限であるのに対し、バッチ処理のデータは限られていることです。この本質的な区別は、さらに 3 つのより具体的な区別につながります。

1) ストリーム処理は終了することなく継続的に結果を生成しますが、バッチ処理は最終結果を返して終了するだけの場合が多いです。たとえば、バッチ コンピューティングを使用して 11 月 11 日の取引金額をカウントする場合は、すべての購入者が費やした合計金額の計算を開始し、その日のすべての取引が完了した後に最終値を取得する必要があります。ストリーム処理では、リアルタイムのトランザクション量を追跡し、結果をリアルタイムで計算および更新する必要があります。

2) ストリーム コンピューティングでは、フェイルオーバーが発生した場合にすぐに再開できるように、チェックポイントを実行してステータスを保持する必要があります。ただし、バッチ コンピューティングでは、入力データが永続的に保存されることが多いため、状態を保持する必要はありません。

3) ストリーミング データは常に更新されます。たとえば、購入者が費やした合計金額は常に変化しますが、バッチ データは 1 日に費やされた合計金額であり、固定されており変化しません。ストリーム データ処理は最終結果を事前に観察するもので、変更のために事前に計算された結果を取り消す必要があることがよくありますが、バッチ コンピューティングではそうではありません。

3.クエリ構成

上記の違いはユーザーのビジネス ロジックには関係しないため、これらの違いは SQL の違いに反映されません。私たちは、これらの違いは単に仕事の異なる属性であると考えています。ストリーム コンピューティングの結果をいつ生成するか、ステータスをどのように保持するかなど、ストリーム コンピューティングに固有のいくつかのプロパティを記述するために、ユーザーが構成可能なクエリ構成を設計しました。これは主に次の 2 つの部分で構成されます。

1) レイテンシーSLA

データ生成から表示までの遅延を定義します。たとえば、ダブル 11 ショッピング フェスティバル中の大画面での遅延は秒単位です。ユーザーはニーズに応じてさまざまな SLA を設定できます。当社の SQL システムは、SLA 要件に応じて最適な最適化を行い、ユーザーのニーズを満たしながら最高のシステム パフォーマンスを実現します。

2) 状態保持/TTL

ストリーム コンピューティングは停止することはありませんが、ストリーム データの状態を長期間保持する必要はほとんどありません。長期間保持すると、必然的にストレージが浪費され、パフォーマンスに大きな影響を与えます。したがって、より優れたコンピューティング パフォーマンスを得るために、ユーザーが適切な TTL (有効期限) を設定できるようにしています。

クエリ構成を通じて、ストリームとバッチのいくつかの異なるプロパティについて説明します。次に、ストリーミング SQL をどのように設計するかについて引き続き検討する必要があります。

4. ダイナミックテーブル

この問題の鍵となるのは、バッチ処理では SQL がテーブルに対して動作するが、ストリーミング データにはテーブルが存在しないことです。したがって、時間の経過とともにデータが変化する動的なテーブルを作成します。動的テーブルはストリームの別の形式であり、二重性を備えています。つまり、データの一貫性を損なうことなく相互に変換できます。次に例を示します。

図に示すように、左側は入力ストリームです。データごとに動的テーブルを生成し、Changelog を使用してテーブルの変更を送信します。これら 2 つの変更後、入力ストリームと出力ストリームのデータは一貫性を保ちます。これは、Dynamic-Table の導入によってセマンティクスとデータが失われないことが証明されます。

動的テーブルの概念により、従来の SQL をストリームに適用できます。 Dynamic-Table は仮想的に存在し、実際のストレージを実装する必要がないことに留意してください。別の例を見てみましょう。

図に示すように、入力ストリームがある場合に継続的なクエリを実行します。ストリームは動的テーブルとして理解されます。動的クエリは、動的テーブルに基づいて新しい動的テーブルを生成します。新しく生成された動的テーブルが必要な場合は、ストリームを引き続き生成できます。ここでは、継続クエリ集計計算が追加されたため、左側と右側のストリームが変更されています。つまり、動的テーブルの導入により、ストリームに対して継続的な SQL クエリを実行できるようになります。

5. ストリームSQLは不要

上記の説明から、Dynamic-Table を使用すると、新しいストリーミング SQL セマンティクスを作成する必要がないことがわかります。したがって、ストリーミング SQL は不要であるという結論に達しました。 ANSI SQL は、Stream SQL のセマンティクスを完全に記述できます。ANSI SQL の標準セマンティクスを維持することは、Flink SQL を構築するための基本原則です。

6. ANSI SQL関数の実装

上記の理論的基礎に基づいて、ストリーム コンピューティングに必要ないくつかの ANSI SQL 関数 (DML、DDL、UDF/UDTF/UDAF、結合、取り消し、ウィンドウ集約など) を実装しました。これらの関数に加えて、Flink SQL が優れたクエリ パフォーマンスを備えながらユーザーのさまざまなクエリ ニーズを満たすことができるように、多くのクエリ最適化も行いました。次に、そのいくつかを簡単に紹介します。

1) 参加する

ストリームと動的テーブルは二元的です。SQL ステートメントはテーブル結合のように見えますが、実際はストリーム結合です。

たとえば、Inner Join の実装原理は次のとおりです。データは入力の両側の任意のストリームから来ます。最初に来た一方のデータは State に格納され、もう一方の State は Joining キーに従って照会されます。存在する場合は結果が出力されます。存在しない場合は出力されません。もう一方のデータが来るまで結果は生成されません。

つまり、2 つのストリームには 2 つの状態があります。一方のストリームのデータが到着すると、そのデータは保存され、もう一方のストリームのデータが到着するまで待機します。すべてのデータが到着すると、内部結合によって結果が生成されます。 2 つのストリームを結合するだけでなく、ストリームと外部テーブル間の結合も導入しました。当社の機械学習プラットフォームは、大量のデータを HBase に保存します。HBase でデータをクエリする操作は、実際には外部テーブルに接続することです。通常、外部テーブルを結合するには 2 つのモードがあります。

a) 検索方法。ストリーミング データが到着するとすぐに外部テーブルがクエリされ、結果が取得されます。

b)スナップショット方式。ストリーミング データが到着すると、スナップショットのバージョン情報がすぐに外部ストレージ サービスに送信され、データが照会され、外部テーブル ストレージはバージョン情報に基づいて結果を返します。

私たちが設計したストリームを外部テーブルに関連付ける機能は、新しい構文を導入せず、SQL-2011 標準に完全に準拠して実装されていることは注目に値します。同じクエリはバッチ計算にも適用されます。

2) 撤回

再現率はストリームコンピューティングにおいて重要な概念です。例を挙げて説明しましょう。単語の頻度を計算する

単語の頻度の計算とは、すべての英語の単語の頻度を数え、最後に頻度に応じて異なる頻度の異なる単語の数を数えることを指します。たとえば、統計の初期状態に Hello World Bark という 3 つの単語のみがあり、各単語が 1 回だけ出現する場合、単語頻度の最終結果は出現頻度が 1 の単語が 3 つある (他の出現頻度の単語はない) ということになります。そのため、結果テーブルには「1-3」という 1 つの行のみが含まれます。単語が継続的に更新され、Helloが追加されると、Helloの出現頻度が2回になるため、単語頻度結果テーブルに新しいデータ行「2-1」を挿入します。

明らかに、2 回出現する単語は 1 つなので、結果「2-1」は正しいのですが、1 回出現する単語の数は間違っており、3 ではなく 2 である必要があります。この問題の根本的な原因は、ストリーム コンピューティングの出力結果が計算の事前観測であることです。データが継続的に更新されると、計算結果は必然的に変化します。そのため、以前の結果を取り消して更新された結果を送信する必要があります。そうしないと、データ結果が不正確になります。上記の例では、Hello の頻度が 1 から 2 に変わると、結果テーブルに行「2-1」を挿入するだけでなく、行「1-3」の更新操作を元に戻す必要があります。

いつ取り消すか、いつ取り消さないかは、SQL クエリ オプティマイザーによって完全に決定されることに注意する必要があります。ユーザーはこれをまったく意識する必要はありません。ユーザーは、SQL を通じてビジネス計算ロジックを記述するだけで済みます。図に示すように、最初のシナリオでは撤回は必要ありませんが、2 番目のシナリオでは撤回が必要です。撤回は、ユーザーではなく最適化フレームワークによって完全に決定されます。これは、SQL を使用し、SQL の自然な最適化フレームワークを活用することの利点を大いに示しています。

3) ウィンドウ集約

ウィンドウ集約は、Flink SQL の重要な機能です。図に示す例では、データの統計を 1 時間ごとに集計します。このタンブル ウィンドウに加えて、スライディング ウィンドウとセッション ウィンドウもサポートしています。将来的にはユーザー定義ウィンドウもサポートされる予定です。

4) クエリの最適化

新しい機能の追加に加えて、クエリの最適化も数多く行いました。たとえば、マイクロバッチ処理。マイクロバッチ処理を行わないと、各データの処理には複数の IO 読み取りと書き込みが伴います。マイクロバッチ処理を使用すると、わずか数回の IO 操作で数千のデータを処理できます。さらに、フィルター/結合/集計プッシュダウンと TopN 最適化も多数実行しました。次の例は TopN 最適化について説明しています。

上に示したように、売上高の上位 3 つの都市を取得したいと考えています。ユーザー クエリには、次の 2 つの基本的な実装があります。

a) 1 つの方法は、データが来ない場合に保存されているすべての都市を並べ替え、最初の 3 つの都市を抽出することです。この設計では、データの更新ごとにすべての都市が再配置されるため、必然的に多くのコンピューティング リソースが浪費されることになります。

b) クエリ オプティマイザーはクエリ ステートメントを自動的に識別し、計算を最適化します。実際の実行プロセスでは、上位 3 つの都市を継続的に更新するだけで済みます。これにより、計算の複雑さが大幅に軽減され、パフォーマンスが向上します。

Alibaba リアルタイム コンピューティング アプリケーション

私たちは、ストリーム コンピューティング SQL をベースにした 2 つのコンピューティング プラットフォームを開発しました。

1. Alibaba Cloud ストリームコンピューティング開発プラットフォーム

1つは、Alibaba Cloudのストリームコンピューティングプラットフォーム（streamCompute）で、ユーザーはプラットフォーム内でSQLを記述し、デバッグすることができます。デバッグが正しく行われた後、ユーザーはこのプラットフォームを使用して、Alibaba Cloud クラスターにジョブを直接公開してデプロイし、デプロイが完了した後にオンラインでテストおよび操作することができます。したがって、このプラットフォームは、開発、デバッグ、オンライン展開、運用と保守を統合し、すべてのリアルタイムコンピューティングのニーズを統合し、ユーザー開発とオンライン起動の効率を大幅に加速します。 2017年のダブル11ショッピングフェスティバルの期間中、アリババグループのリアルタイムコンピューティングジョブのほとんどがこのプラットフォームを通じてリリースされたことは注目に値します。今年9月から、パブリッククラウドやプライベートクラウドを含むAlibaba Cloudを通じて、外部の企業にこのプラットフォームを公開し、Alibabaのリアルタイムコンピューティング機能を利用できるようにします。

2. アリババのリアルタイム機械学習プラットフォームポルシェ

アルゴリズム開発者が機械学習タスクを開発しやすくするために、視覚的なセルフサービス開発と操作をサポートするアルゴリズム開発者向けの Flink SQL と Hbase に基づくオンライン機械学習プラットフォーム Porsche を設計および実装しました。上の図に示すように、Porsche プラットフォーム IDE では、ユーザーは視覚的にコンポーネントをキャンバスにドラッグし、コンポーネントのプロパティを構成し、完全な計算 DAG を定義できます。この DAG は SQL に変換され、最終的に実行のために Blink に送信されます。さらに、ポルシェ プラットフォームは、今年のダブル 11 でも注目を集めた Tensorflow もサポートしていることも特筆に値します。このプラットフォームは、アルゴリズムを学ぶ学生が SQL の使い方を学ぶコストを節約するもので、現在は一般向けにのみ公開されています。

ダブル11リアルタイムコンピューティングの概要

上の図は、Alibaba のリアルタイム コンピューティング アーキテクチャを示しています。最下層は数千台の物理マシンで、その上に均一に配置されたリソース管理とストレージがあり、その次に Blink Runtime と Flink SQL が続きます。ユーザーは StreamCompute と Porsche プラットフォームを通じてジョブを送信します。現在、Alibaba では数百人のエンジニアと 1,000 近くの Flink SQL ジョブがサポートされています。上記は、アリババのリアルタイムコンピューティングの現状です。

リアルタイムコンピューティングの助けにより、アリババはダブル11ショッピングフェスティバルで1682億元という輝かしい売上を達成しました。リアルタイムコンピューティングの貢献は主に以下の側面に反映されています。

1. 今年のダブル 11 ショッピング フェスティバルでは、インターネット史上最大の同時実行が記録されました。1 秒あたり数十万件の取引と支払いのリアルタイム集計統計はすべて、Blink コンピューティングによって実現されました。

2. 100億のデータを3分1秒で表示するには、データベースベースの高いスループット能力だけでなく、リアルタイムコンピューティングの速度も必要です。

3. アルゴリズムプラットフォームは、アルゴリズムエンジニアが優れた検索と推奨結果を達成し、全体的なGMVの増加を達成するのに役立ちました。

つまり、リアルタイム コンピューティングは、Alibaba 社内の多様なニーズを満たすだけでなく、GMV も向上させます。私たちは、Blink のリアルタイム コンピューティング機能を Alibaba Cloud のリアルタイム コンピューティング プラットフォーム (StreamCompute) を通じて Alibaba 以外のすべての企業に輸出し、そのメリットを享受してもらいたいと考えています。以上が今回の共有内容です。皆様ありがとうございました。