開発効率が15倍になりました！将来のバッチストリーミングリアルタイムプラットフォームのアプリケーションプラクティス

要約：この記事は、GoodFutureのシニアデータプラットフォームエンジニアであるMaoXiangyiによって共有されており、主に教育業界でのバッチフロー統合の実践を紹介しています。内容は2部構成で、前編は未来のリアルタイムプラットフォームについての考え、後半は主に教育業界独自のデータ分析シナリオを共有しています。次の概要：
背景
良い未来T-ストリーミングリアルタイムプラットフォーム
K12教育の典型的なシーン分析の
見通しと計画

1.背景紹介

良い未来の紹介

Good Futureは、2003年にXueersiというブランドで設立された教育技術企業です。XueersiPeiyouとXueersi Online Schoolはこのブランドの派生物であると誰もが聞いています。2010年、同社は米国のNASDAQに上場しました。、2013年に社名をGoodFutureに変更。2016年、同社の事業範囲は1歳から24歳までのユーザーを対象としています。現在、同社の主な事業単位は、スマート教育、教育分野のオープンプラットフォーム、K12教育、海外留学です。

良い未来のデータにおける台湾のパノラマ

上の写真は、主に3つのレイヤーに分割された将来のデータセンターのパノラマビューです。

最初のレイヤーはデータ有効化レイヤーです
2番目のレイヤーはグローバルデータレイヤーです
3番目の層はデータ開発層です

まず、データ有効化レイヤー。これは主に、一部のデータツール、データ機能、主題分析システムなど、ビジネスインテリジェンスとスマートな意思決定のアプリケーションです。データツールには、主に埋め込みポイントデータ分析ツール、ABテストツール、大画面ツールが含まれます。データ機能分析には、主に将来のポートレートサービスと将来が含まれます。成長サービス、将来のユーザーサービス、新しいキャンパスのサイト選択サービス。主題分析システムには、主に事業運営の主題分析などが含まれます。

次に、グローバルデータレイヤー。グループ全体のすべてのビジネスユニットのデータを深く統合および統合し、さまざまなビジネスラインおよび製品ラインのユーザープールを開放し、グループ全体のデータを活性化することを望んでいます。具体的な方法はIDMappingです。これは、デバイスID、自然人、家族のIDマッピング関係を掘り下げ、さまざまな製品のユーザーデータを関連付けます。このようにして、大規模なユーザープールを形成できます。これは、ユーザーの権限を強化するのに便利です。

最後に、データ開発レイヤー。データ開発は、主にデータ統合、データ開発、データ品質、データサービス、データガバナンス、その他のサービスを含む一連のプラットフォームを通じて、グループ全体のすべてのデータ開発プロジェクトを実行します。今日共有するリアルタイムプラットフォームは、データ開発です。

2.良い未来のT-Streamingリアルタイムプラットフォーム

リアルタイムのプラットフォーム構築前の要求

リアルタイムプラットフォームの構築の開始時に、4つの重要な要求を整理しました。

最初の魅力は、複数のテナントとリソースの分離を提供することでリソースの使用率を向上させ、複数のビジネスユニット内の複数のクラスターの問題を解決できる統合クラスターを持つことです。
2番目の魅力は、より多くの開発者をカバーするために、プラットフォームを介したリアルタイムデータ開発のしきい値を下げることです。
3番目の魅力は、一般的なシナリオのソリューションを提供し、プロジェクトの再利用性を向上させ、各ビジネスユニットで同じシナリオの分析ツールの開発を回避することです。
4つ目の要件は、メタデータや血縁関係など、操作のライフサイクル管理をすべて実行することです。操作が異常になると、影響の範囲をすばやく分析して特定できます。

リアルタイムプラットフォーム機能の概要

当社のプラットフォームは、データ統合、データ開発、ジョブセキュリティ、リソース管理、データセキュリティ、その他の機能を含む、ワンストップのリアルタイムデータ分析プラットフォームになりました。

データ統合に関しては、データベース、埋め込みデータ、サーバー側のログデータの統合をサポートしています。データ統合の効率を向上させるために、多くの一般的なテンプレートジョブを提供しています。ユーザーは、データ統合を迅速に実現するために構成するだけで済みます。
データ開発に関しては、FlinkSQLジョブ開発とFlinkJarパッケージホスティングの2つのジョブ開発方法をサポートしています。FlinkSQL開発では、多くのUDF関数が組み込まれています。たとえば、UDF関数を使用してディメンションテーブルを実装できます。参加し、ユーザー定義のUDFもサポートし、UDFのホットリロードを実装します。さらに、血液システムの構築を容易にするために、ジョブ開発プロセス中にユーザーのメタデータ情報も記録します。
ジョブのセキュリティ面では、ジョブステータスの監視、異常アラーム、ジョブ失敗後の自動開始をサポートしています。ジョブが自動的に開始されると、開始可能なチェックポイントバージョンが自動的に選択されます。同時に、複数のクラスター間のジョブの切り替えもサポートされます。
リソース管理に関しては、プラットフォームのマルチテナンシーをサポートしています。各テナントは、分離にネームスペースを使用し、さまざまなビジネスユニット、さまざまなユーザー、さまざまなバージョンのFlinkクライアントの分離を実現し、コンピューティングリソースの分離を実現します。
データセキュリティに関しては、役割権限管理、テーブルレベル権限管理、操作監査ログクエリなどの機能をサポートしています。

上記は私たちのプラットフォームの機能です。私たちはビジネスに力を与えると同時に、プラットフォームがシンプルで使いやすく、安定していて信頼できることを望んでいます。

リアルタイムプラットフォームのバッチストリーム統合

次に、プラットフォーム構築のいくつかのプラクティスについて説明します。最初はバッチストリーム統合です。

まず、バッチフロー統合とは何かを明確にしましょう。

バッチストリームフュージョンは2つの概念に分けることができます。1つはFlinkによって提案されたバッチストリームフュージョンです。具体的な理解は、Flink SQLがバッチデータだけでなくストリームデータにも作用できることです。計算エンジンの一貫性を確保することにより、結果データが削減されます。違いは、これは技術レベルでのバッチフロー統合です。内部で提案するもう1つの概念は、アーキテクチャレベルでのバッチフロー統合です。具体的な運用方法は、Flinkジョブを通じてデータウェアハウスのODSレイヤーのリアルタイム性を確保し、時間レベルと分レベルのスケジューリングを提供することで、リアルタイムのデータ分析を改善することです。

なぜアーキテクチャにバッチフロー統合を提案するのですか？業界の発展には主に2つの傾向が見られます。

最初の傾向は、データ統合のリアルタイムおよびコンポーネント化です。たとえば、FlinkはHiveを統合し、Flink CDCは継続的に改善および強化されているため、データ統合を行うと非常に簡単になります。
2つ目の傾向は、Kudu + impala、Alibaba CloudのHologres、Hucang統合ソリューションなどのリアルタイムOLAPエンジンがますます成熟していることです。

これらの2つの傾向により、ユーザーはリアルタイムデータの開発が容易になり、ユーザーはSQL自体に注意を払うだけで済みます。

上の図に示すように、3種類のリアルタイムデータウェアハウスがあります。1つはHiveに基づいており、1つはリアルタイムOLAPエンジンに基づいており、もう1つはKafkaに基づいています。その中で、青い線は、ODSレイヤーをリアルタイムで具体的に実現したものです。リアルタイムデータをHive、リアルタイムOLAPエンジン、そしてもちろんKafkaに書き込むことができる統合ツールを提供します。このツールは比較的簡単に使用できます。MySQLデータ同期の場合、ユーザーはデータベース名とテーブル名を入力するだけで済みます。

ODSレイヤーのリアルタイムツールを使用すると、Hive、リアルタイムOLAPエンジン、およびKafkaでリアルタイムデータウェアハウスを構築できます。

Hiveリアルタイムデータウェアハウスの場合は、 Flinkを使用してリアルタイム増分データをODSレイヤーに書き込み、タイミングマージスクリプトを提供して増分データと履歴データをマージし、ODSレイヤーのデータが最新かつ最大であることを確認します。コンプリート。エアフローの時間レベルのスケジューリング機能により、ユーザーは時間レベルのデータウェアハウスを取得できます。
Kudu / HologresのようなリアルタイムOLAPエンジンの場合、最初にオフラインデータをHiveからリアルタイムOLAPエンジンにインポートし、次にFlinkを使用してリアルタイム増分データをODSレイヤーに書き込みます。書き込み方法をお勧めします。アップサートなどの機能により、ユーザーは純粋なリアルタイムデータウェアハウスを入手できます。エアフローの分レベルのスケジューリング機能により、ユーザーは分レベルのデータウェアハウスを取得できます。
Kafkaに基づいてリアルタイムのデータウェアハウスを構築することは非常に古典的なアーキテクチャであり、開発コストは比較的高くなります。数秒で更新する必要がある分析シナリオを除いて、ユーザーに使用することはお勧めしません。もちろん、2021年には、Flinkバッチストリーミング統合ソリューションも実装して、リアルタイムデータウェアハウス全体をより簡単にしながら、より多くの選択肢をユーザーに提供します。

上記は、バッチストリーム統合に関する私たちの考え方と実践です。このアーキテクチャレベルのバッチストリーム統合により、以前は1か月のリアルタイム要件を作成する必要がありましたが、現在は2日でほぼ完了することができます。リアルタイムデータを開発するためのしきい値を大幅に削減し、データ分析の効率を向上させます。

リアルタイムプラットフォームODSレイヤーリアルタイム

リアルタイムODSレイヤーの実行方法について説明します。

ODSレイヤーデータをリアルタイムにするには、2つの問題を解決する必要があります。1つはオフラインデータの初期化であり、もう1つは増分データの書き込み方法です。オフラインデータインポートの方が優れています。データソースがMySQLの場合、DataXまたはSparkジョブを使用してMySQLデータの全量をHiveにインポートでき、リアルタイムの増分データを書き込むには2つの手順が必要です。1つ目はこのステップは、MySQL binlogをKafkaに収集することであり、2番目のステップは、Flinkジョブを使用してKafkaデータをHiveにインポートすることです。このように、ODSレイヤーのリアルタイムの問題を解決するには、オフライン初期化ジョブ、増分データ収集ジョブ、および増分データ書き込みジョブが必要です。つまり、3つのジョブが必要です。

私たちのプラットフォームでは、ODSレイヤーの3つのジョブをカプセル化し、均一にスケジュールしました。ユーザーは、データベース名とテーブル名を入力するだけで、ODSレイヤーのリアルタイム作業を完了できます。

上記は、バッチストリームフュージョンでのリアルタイムODSレイヤーの実現プロセスです。

リアルタイムプラットフォームFlinkSQL開発プロセス

また、FlinkSQLのジョブカプセル化という別の方法もあります。プラットフォームでのFlinkSQL開発の全体的なプロセスを見てみましょう。

データソースのデータは、左からマクスウェルや運河などのツールを使用してカフカに収集されますが、カフカで収集された元のデータ形式は均一ではないため、カフカでデータを均一にフォーマットする必要があります。デフォルトでは、埋め込みポイントデータ形式、運河データ形式、およびマクスウェルデータの分析をサポートします。また、ユーザーがデータ分析のためにJarパッケージをアップロードすることもサポートし、分析から取得した標準化されたデータが再びKafkaに送信されます。

次に、Flink SQLジョブを使用して、Kafkaデータを消費し、SQLスクリプトを開発します。ここでのSQLスクリプト開発は、ネイティブFlink SQLスクリプト開発とは少し異なります。ネイティブSQLスクリプト開発ユーザーは、ソース情報とシンク情報を書き込む必要があります。当社のプラットフォームでは、ユーザーは特定のSQLロジックを記述するだけで済みます。

ユーザーがSQLを書き込んだ後、SQLジョブ情報をパッケージ化されたFlink SQL実行ジョブに送信し、最後に、パッケージ化されたSQLエンジンを介してFlinkクラスターに送信されたジョブを実行します。パッケージ化の方法については後で紹介します。

上記は、プラットフォームでのFlink SQL開発のプロセスです。プラットフォームは、Flinkジョブ自体の開発と送信に加えて、ジョブに関連するさまざまな入力および出力スキーマ情報も保持します。たとえば、ビジネスデータベーステーブルのスキーマ情報、統合処理後のスキーマ情報、データ出力テーブルのスキーマ情報は、これらのレコードを通じて、後で問題をトラブルシューティングするときに、操作の詳細と影響の範囲をすばやく分類できます。

リアルタイムプラットフォームFlinkSQL開発プロセス

プラットフォームでFlinkSQLジョブを開発するには、次の3つの手順のみが必要です。

最初のステップは、Kafkaのトピックが登録されているかどうかを確認することです。登録されていない場合、ユーザーは手動で登録する必要があります。登録が完了したら、トピックデータを解析し、フィールド情報を保存します。
2番目のステップは、ユーザーがSQLを記述できるようにすることです。前述のように、ユーザーは特定のSQLロジックを記述するだけでよく、ソースとシンクの情報は記述できません。
3番目のステップは、ユーザーがデータを出力する場所を指定することです。これで、プラットフォームは、計算されたデータをHive、Holo、およびその他のストレージに同時に書き込むなど、複数のシンクストレージデバイスを同時に指定できるようになりました。

上記の3つのステップを構成することにより、ユーザーはジョブを送信できます。

次に、その方法について説明します。実行プロセス全体を2つのステージと10のステップに分割しました。
最初の段階はジョブ準備段階であり、2番目の段階はSQL実行段階です。

運用準備段階

最初のステップで、ユーザーはページデータのSQLおよびシンク情報を指定します。
2番目のステップはSQLの解析と検証のプロセスです。ユーザーがSQLを送信すると、SQLを解析して、SQLで使用されるソーステーブルとUDFがプラットフォームに登録されているかどうかを確認します。
3番目のステップは、テーブルを作成することを推測することです。最初にユーザーのSQLを使用し、次にSQLの戻り結果を取得し、結果データに基づいていくつかのテーブル作成ステートメントを生成し、最後にプログラムを使用して、ターゲットシンクストレージに自動的に移動してテーブルを作成します。
4番目のステップは、Flink SQLスクリプトファイルをアセンブルして、Source、SQL、およびSinkの3つの要素を含むスクリプトファイルを取得することです。
5番目のステップであるジョブの送信では、FlinkSQLファイルを独自の実行エンジンに送信します。

SQL実行フェーズ

最初のステップは、StreamTableAPIを初期化し、connectメソッドを使用してKafkaソースを登録することです。Kafkaのソース情報では、データ解析ルールとフィールドスキーマ情報を指定する必要があり、メタデータに基づいて自動的に生成されます。
2番目のステップは、StreamTableAPIを使用して、SQLで使用されるディメンションテーブルとUDF関数を登録することです。UDF関数には、ユーザーがアップロードしたUDF関数が含まれます。
3番目のステップは、StreamTable APIを使用してSQLステートメントを実行することです。ビューがある場合は、ビューを実行することもできます。
4番目のステップはより重要なステップです。StreamTabAPIをDataStreamAPIに変換します。
5番目のステップは、DataStreamに基づいてSink情報を追加することです。

上記は2段階の実行プロセスです。第2段階では、ユーザーのSQLジョブが実際に実行されます。

リアルタイムプラットフォームのネイティブジョブとテンプレートタスク

上記では、Flink SQLジョブを開発して実行する方法を共有しました。次に、プラットフォームのJARパッケージタイプのジョブサポートについて説明します。

当社のプラットフォームでは、ユーザーがJARパッケージジョブを自分でアップロードし、プラットフォームで管理できるようにサポートしています。同時に、一般的なシナリオでのコードの再利用性を向上させるために、Maxwellによって収集されたbinlogをHive、Kudu、Holoなどのストレージデバイスに直接書き込むためのサポートや、Alibaba Cloud SLSログをさまざまなものに書き込むためのサポートなど、多くのテンプレートジョブを開発しました。 OLAPエンジン。

リアルタイムプラットフォームハイブリッドクラウド展開ソリューション

ハイブリッドクラウド展開計画とプラットフォームテクノロジーアーキテクチャについて話します。

私たちのプラットフォームは現在、Alibaba Cloudコンピュータールームと自作コンピュータールームへのジョブの送信をサポートしており、2つのコンピュータールーム間でジョブを切り替えることができます。この機能を持つために？

今年の初め、流行の発生に伴い、インターネットオンライン教育が大量のトラフィックに殺到しました。トラフィックの急増に対応するために、春のフェスティバルの期間中、緊急配備用とオンライン用に数千台のマシンを購入しました。その後、流行が安定した後、これらはマシンの使用率は比較的低く、この問題を解決するために、当社のプラットフォームはハイブリッドクラウド展開スキームをサポートしています。ピーク時には、ジョブをAlibaba Cloudに移行して独自のクラスターで実行できるため、リソースを節約できます。また、柔軟な拡張を保証します。

リアルタイムプラットフォームテクノロジーアーキテクチャ

次に、プラットフォームの技術アーキテクチャについて説明します。

私たちはフロントエンドとバックエンドを分離するプロジェクトです。フロントエンドはvue + elmentuiを使用し、サーバーはスプリングブートを使用します。異なるコンピュータールームに、バックエンドサービスインスタンスを展開します。タスクは、主に転送層のnginx + luaを介してさまざまなコンピュータールームに送信されます。プラットフォームでのタスクの送信、一時停止、およびオフライン操作はすべて、主にシェルスクリプトであるドライバーレイヤーを介して行われます。最後はクライアントです。クライアントでは、Namespace / User / Flinkバージョンを分離しました。

3.K12教育の典型的な分析シナリオ

リニューアル事業紹介

特定のケースについて話しましょう。このケースは、ユーザーがビジネスを報告し続けるK12教育業界の典型的な分析シナリオです。
最初に更新についてお話しします。更新とは、繰り返し購入することを意味します。ユーザーは1年コースを購入しました。ユーザーは2年コースを購入することを期待しています。ユーザーがコースを購入できるように、更新期間は集中しており、それぞれが約1週間、年に4回続きます。

更新サイクルが比較的集中しており、時間が比較的短いため、毎回更新ビジネスを行う教師にとって、リアルタイムの更新データの需要は特に緊急です。

この目的のために、さまざまなビジネスユニットの更新アクションをサポートするための一般的な更新ソリューションを作成しました。リアルタイム更新にはいくつかの課題があります。

最初の課題は、ユーザーの注文が更新であるかどうかを計算することです。ユーザーの履歴内のすべての注文に依存する必要があります。つまり、計算に参加するには履歴データが必要です。
2番目の課題は、ある注文の変更が他の注文の変更に影響を与えることです。これはノックオン効果です。たとえば、ユーザーに5つの注文があり、注文番号345が更新ステータスになっているとします。ユーザーが注文番号3をキャンセルした場合、注文4と5の更新ステータスを再計算する必要があります。
3番目の課題は、ディメンションが頻繁に変更されることです。たとえば、午前中のユーザーのブランチスクールのステータスは北京、午後のブランチスクールのステータスは上海、午前の講師は張山、午後の講師はLiSiです。頻繁に変更されるディメンションはリアルタイムで要約されます。データは課題をもたらします。

履歴データ、順序変更のノックオン効果、および頻繁に変更されるディメンションに依存しているため、これらの課題は、個別に見ると何の問題もなく、まとめるとさらに興味深いものになります。

リアルタイム更新ソリューション

まず、アーキテクチャ全体について説明します。バッチストリームフュージョン方式を使用して実行します。1行は分レベルのリアルタイム更新データ計算で、もう1行は第2レベルのリアルタイム更新データ計算です。計算されたデータはMYSQLに配置され、大画面やBIビルボードに使用されます。

最初に青い線を見てください。オフラインデータをHiveからKuduにインポートします。オフラインデータはすべて計算された注文幅テーブルです。次に、Flinkジョブを使用して、新しく追加された注文を広いテーブルに作成し、Kuduに書き込みます。これにより、Kuduは最新かつ最も完全なデータを取得できます。4分間のスケジューリングにより、分レベルのリアルタイム更新データを提供します。

最初のオレンジ色の行を見ると、この行には2つのFlinkジョブがあります。1つはETLジョブで、もう1つは更新ジョブです。

ETLジョブは、静的ディメンションのスプライシングと更新ステータスの計算を担当します。静的ディメンションのスプライシングでは、MySQLに直接アクセスし、JVMにキャッシュします。更新ステータスの計算は、履歴データに依存する必要があります。ETLジョブはすべての注文データをJVMにロードします。特定の実装方法は、partitioncustomメソッドをカスタマイズして、すべての履歴データと各ダウンストリームをスライスすることです。タスクはフラグメントのデータをキャッシュします。データをメモリにロードすることで、Flinkのリアルタイム計算を大幅に高速化します。

ETL Jobによって計算されたデータには2つの出力があります.1つはKuduに出力され、Kuduのデータが最新で完全であることを確認します.2つのデータはKafkaであり、Kafkaには現在の注文の変更を記録するトピックがありますどの注文または寸法が変更されたかに関する情報。

Kafkaの背後にあるプログラムはUpdateJobです。これは、影響を受ける注文またはディメンションを処理し、MySQLの関連する統計データを直接変更するために特に使用されます。

このように、2つのFlinkジョブを通じてリアルタイムの更新計算を実現します。

肝心なのは、リアルタイムのディメンションデータ変更の処理です。ディメンション変更データはKafkaに送信され、Flinkは、ディメンション変更によって影響を受けるデータ統計を確認するための処理に使用され、最後に影響を受ける注文をに送信します。影響を受けるトピックは、更新ジョブによって再計算されます。

上記は、リアルタイム更新の全体的なソリューションです。教育業界の誰かがこの共有を聞いた場合は、それを参照できます。

リアルタイムレポートの安定性保証

このユニバーサルソリューションが公開された後の保証を見てみましょう。

最初の保証はリモートアクティブ-アクティブです。AlibabaCloudと自社構築のコンピュータールームの両方に一連の更新手順を展開しました。いずれかが異常な場合は、フロントエンドインターフェイスを切り替えることができます。両方のコンピュータルームのプログラムがハングアップした場合、プログラムを最初から開始し、10分しかかかりません。
2番目の保証はジョブの障害耐性です。2つのFlinkジョブがあります。これらの2つのジョブは、データの精度に影響を与えることなく、いつでも停止および開始できます。もう1つのポイントは、すべての注文データをJVMにキャッシュすることです。データの量が急増した場合、JVMメモリのオーバーフローを心配することなく、ETLプログラムの並列処理を変更するだけで済みます。
3番目の保証はジョブの監視です。ジョブの失敗後の異常な警告と自動プルアップ、およびコンシューマーデータの遅延警告をサポートします。

上記のセーフガード措置により、リアルタイムの更新手順は数回の更新サイクルを経ており、比較的安定しており、非常に心配です。

4.展望と計画

上記の内容は、現在のビジネスおよび将来の技術ソリューションの詳細です。要約すると、マルチテナンシーによる各ビジネス部門のリソース分離を実現し、バッチストリーム統合アーキテクチャソリューションによってリアルタイム分析を解決し、ODSレイヤーを通じてOLAPへのリアルタイムデータソースを解決します。データ統合の問題、Flink SQLパッケージングによるリアルタイムデータ開発のしきい値の引き下げ、テンプレートタスクによる一般的なシナリオソリューションの提供、ハイブリッドクラウド展開ソリューションによるリソースの弾力的な拡張の解決、およびリアルタイム更新ソリューションによる同じシナリオのデータ分析のカバー。

最後に、私たちのビジョンと計画を見てください。次に、バッチストリームの統合をさらに深め、ハイブリッドクラウドの展開を強化し、データ分析の適時性と安定性を向上させます。アルゴリズムプラットフォームのリアルタイム、データアプリケーションのリアルタイムをサポートし、データの意思決定の適時性を向上させます。

元のリンク

この記事はAlibabaCloudのオリジナルのコンテンツであり、許可なく複製することはできません。