ストリーミングレイクウェアハウスの強化、Hologres + Flink はエンタープライズレベルのリアルタイムデータウェアハウスを構築します

[ライブブロードキャストプレビュー] 99元のクラウド仮想マシン × 9元のクラウドネイティブアーキテクチャ√

1. Hologres+Flink、多くの顧客の Alibaba Cloud 上のリアルタイムデータウェアハウスの最初の選択肢

ビッグデータが大規模なものからリアルタイムなものに移行するにつれて、リアルタイムデータに対する需要は、インターネット、交通、メディア、金融、政府などのさまざまな分野に及んでいます。エンタープライズビッグデータプラットフォームにおけるリアルタイムコンピューティングの割合も増加し続けており、一部の業界では 50% に達しています。Hologres+Flink は、さまざまな種類の複雑なオープンソーステクノロジーコンポーネントを多くの豊富なエンタープライズレベルの機能に置き換え、複数のテクノロジースタックの学習、複数のクラスターの運用と維持、複数の場所でのデータの一貫性の維持などのコストを削減し、企業がビジネスやビジネスに集中できるようにします。コストを削減し、効率を向上させます。

Xiaohongshu OLAP シナリオでは、クリックハウスの代わりに Hologres が使用され、クエリのパフォーマンスが大幅に向上しました。レコメンデーションシナリオでは、Hologres+Flink を使用してユーザーの A/B グループテスト結果をリアルタイムで分析し、レコメンデーション戦略を調整します。リアルタイムで推奨モデルを更新します。
Xiaomai Technology は、Hologres+Flink を使用して数百億の広告のリアルタイムデータウェアハウスを構築し、高パフォーマンスの書き込み、非常に高速な複雑なクエリ、高可用性の分離などのニーズを満たすことで、ユーザー行動分析の 2 番目の達成を可能にします。 -レベルの応答を実現し、ビジネスニーズに迅速に対応します。
Kingdee Guanyi Cloud は、リアルタイムデータウェアハウスを Hologres+Flink にアップグレードし、データ遅延が 30 秒以上から数秒に短縮されました。Hologres の強力なリアルタイム分析と集計機能の助けにより、データ統計の遅延の問題は解決されました。全体的なリソースコストは 50% 削減されました。
TAL は当初、OLAP エンジンとして Kudu を使用し、データのロードと計算に Impala を使用していましたが、Kudu/Impala を Hologres に置き換えて、100 万レベルの書き込みとミリ秒レベルのクエリ機能を実現し、年間 100 万近くコストを削減しました。
Le Elements はテストを通じて、Presto と比較してパフォーマンスが 5 ～ 10 倍向上していることを発見しました。64 コアの Holgores は 96 コアの Presto クラスターを直接置き換えることができるため、データウェアハウスアーキテクチャをアップグレードして業務効率を 10 倍向上させました。倍以上。

ワンストップのリアルタイムデータウェアハウス Hologres

Hologres は Alibaba Cloud が自社開発したワンストップのリアルタイムデータウェアハウスであり、統合分析サービスアーキテクチャと統合データプラットフォームアーキテクチャを使用して 1 つのデータを実現し、多次元分析、オンラインサービス、レイクウェアハウスもサポートしていますGot を含む統合およびベクトル計算シナリオ:

多次元分析 (CK、Doris などと同じクエリシナリオの実装)

データの高性能リアルタイム書き込み、更新、クエリ、書き込み直後のクエリの実行、列ストレージと組み込みインデックスアクセラレーションのサポート

オンラインサービス (Hbase、Redis などと同じクエリシナリオを実装)

KV および SQL クエリ、超高 QPS での非主キークエリ、行ストレージをサポートし、高可用性機能を備えています。

レイクウェアハウス分析（Prestoと同じ対話型分析シナリオを実現）

データ移行は不要、MaxCompute とデータレイクのテーブルに対する第 2 レベルの対話型クエリ、およびメタデータの自動検出

ベクトル計算 (Faiss と同じベクトルクエリシナリオを実装)

DAMO Academy Proxima ベクトルエンジン、QPS およびリコールパフォーマンスが組み込まれており、オープンソースベクトルデータベースよりも数倍優れています。

エンタープライズレベルのリアルタイムデータウェアハウス機能

オープンソースコンポーネントとは異なり、エンタープライズレベルのリアルタイムデータウェアハウスは、企業がデータを継続的、安定的かつ効率的に使用し、データウェアハウスを維持できるように、さまざまなリソースの分離、データセキュリティ、機敏な運用とメンテナンス、その他の機能を迅速に実現できるように支援する必要があります。オンラインでリアルタイムに実行されるビッグデータプラットフォーム。Hologres は、リソースの分離、データ暗号化、データの非感作化、災害復旧、データのバックアップとリカバリ、IP ホワイトリスト、データガバナンス、データリネージなどのエンタープライズレベルの豊富な機能を備えています。

負荷絶縁

複数のコンピューティングインスタンスは、マスター/マルチスレーブモデルを形成し、ストレージを共有し、コンピューティングリソースを分離して、書き込みと読み取りの分離、クエリとサービスの分離を実現します。障害管理、障害が発生したノードの高速かつ自動回復をサポートし、Pangu の 3 つのコピーは信頼性の高い冗長ストレージを提供します。

エンタープライズレベルの運用と保守

特定の自己運用および保守機能を備えており、クエリ履歴やメタデータテーブルなどの運用および保守診断情報が組み込まれており、ユーザーはクエリ履歴やテーブルのメタデータに基づいた豊富な監視およびアラームインジケータを提供し、システムのボトルネックとリスクを迅速に特定できます。ポイントを獲得し、自己操作性を向上させます。

データセキュリティ

きめ細かいアクセス制御ポリシー、BYOK データストレージの暗号化とデータの感度解除、データのバックアップとリカバリをサポートし、RAM、STS、独立したアカウントなどの複数の認証システムをサポートし、PCI-DSS セキュリティ認証に合格しています (PCI-DSS は現在世界の最も厳格かつ最高レベルの財務データセキュリティ基準）。

データガバナンス

リアルタイムのデータ処理はコストの増加につながりますが、Hologres はさまざまなタイプのデータ使用に関するログ情報を含むテーブル情報を提供します。誰かがデータを使用しているかどうか、またそのデータが何回使用されたかを知ることは、企業がコストをより適切に管理できるようにするのに便利です。

2. Hologres と Flink の緊密な統合

Hologres+Flink の組み合わせは、アリババグループ内で長年にわたるリアルタイムシナリオの磨き上げを経て検討された最良のアーキテクチャです。たとえば、Taotian ユーザー成長チームは 3 ～ 5 分のポートレート分析を約 10 秒に改善することに成功し、CCO カスタマーサービスチームはデータ分析効率が 10 倍に増加すると、Taocai の年間コストは数百万削減されます。長年の蓄積を経て、Hologres+Flink の製品機能は徐々に相互補完され、Flink のリアルタイム計算を中心に、リアルタイムデータウェアハウス Hologres を中心に複数の製品利用パスが形成されています。 Flink のテーブル; 処理されたデータは Flink を通じて処理できます。結果は Hologres に書き込まれます。Hologres は Flink で使用できる binlog を提供します。Hologres Catalog は、メタデータサービス、データベース全体の同期、SchemaEvolution などをサポートしています。これらについては後で詳しく紹介します後で。

リアルタイムディメンションテーブルルックアップ

Hologres は、Flink のリアルタイムディメンションテーブルとして、他のディメンションテーブルと比較して次の利点があります。

ディメンションテーブルの 100 万 RPS クエリ。非常に高い RPS クエリをサポートすることで、1 秒あたり数億の単一クエリに簡単に到達でき、社内ビジネスによっては数千万、数億のクエリに到達する場合もあります。
ディメンションテーブルはリアルタイムで更新できます。ディメンションテーブルとその一部のフィールドを更新して、運用とメンテナンスの難しさを軽減し、効率を向上させることができます。
1対Nポイントスキャン(プレフィックススキャン)をサポートします。1 対 1 のクエリだけでなく、1 対多のクエリもサポートします。たとえば、保険の顧客のうち、どの保険に加入しているかを ID カードに基づいて確認する必要があります。その人は複数の保険契約に対応している可能性があり、ホログレスはこの種のペア N クエリもサポートできます。
InsertIfNotExist がサポートされています。これは非常に特殊な機能です。一般的なディメンションテーブルをクエリすると、見つかった場合は値が返され、見つからなかった場合は空が返されます。ただし、Hologres はクエリで値が見つからない場合に値を挿入し、結果を返します。挿入された値。これは主に、渋滞中の正確な UV シーンの問題を解決するために使用され、RoaringBitmap イメージングソリューションを通じて、数千億のポートレート分析を数分から数秒に短縮できます。

高性能のリアルタイム書き込みおよび更新

Flink+Hologres の組み合わせは、高性能のリアルタイム書き込みをサポートします。右側は 1 年前の測定データですが、今年はさらに高くなるはずです。128CU 構成では、書き込みテーブルに主キーがない場合、1 秒あたり約 230 万のエントリを書き込むことができますが、書き込みテーブルに主キーがある場合、主キーの競合により新しい行が破棄され、 1 秒あたり最大 200 万件のエントリを書き込むことができます。一般的に、テーブルの更新にはバックチェックが必要であり、データ量が増加すると更新パフォーマンスが低下します。Hologres は、すでに書き込みが行われている場合でも、1 秒あたり 700,000 アイテムの更新パフォーマンスを達成できます。には、更新するデータテーブルが 20 億あります。この種のリアルタイムの書き込みと更新のパフォーマンスは、Flink のような大量の更新と削除を行う場合に非常に適しています。

Hologres は強力な更新機能を備えていますが、広いテーブルの部分的な更新もサポートし、Flink のマルチストリーム結合をある程度置き換え、非常に詳細な最適化も行っています。たとえば、上流のデータビジネスでは、1 時に作成されたデータと 1 時 5 分に作成されたデータが順序が狂うことがあります。1 時 5 分に作成されたデータが前のデータをカバーすることを期待します。データは営業時間に基づいているため、前のデータを後のデータで上書きする必要があります。ただし、計算リンク全体の不確実性のため、1 時 5 分のデータが先に到着し、1 時のデータが後に到着する可能性があります。ブラインドで直接書き込むと、1 時のデータが 1 時 5 分のデータに上書きされます。ただし、Hologres ではこのようなカバーは行わず、上流側が故障した場合でも最新のデータを保存し、上流側と下流側のデータの整合性を確保します。

最後に、Flink からまだリリースされていないバージョン 1.19 で、Hologres は固定コピーと呼ばれるモードを導入しました。右の図と比較して、このモードは書き込みパフォーマンスが向上し、CPU リソースをより節約します。

マルチストリームのマージ

先ほどのディメンションテーブルの結合に加えて、ストリームコンピューティングのもう 1 つの問題点はデュアルストリームの結合です。各パスで完全な状態を保証する必要がある場合、理論的には非常にコストがかかります。私たちのソリューションはデュアルストリーム結合を完全に置き換えるものではありませんが、ユーザーポートレートシナリオの場合、たとえば明確な ID があり、この既存の ID に基づいて複数のストリームのデータを関連付けたいと考えています。このシナリオでは、Hologres はデュアルストリーム結合を簡単に置き換えて、このような低コストの関連付けを実装できます。

ポートレートのシナリオでは、ユーザーのポートレートや製品のポートレートを記述する必要がありますが、これにはさまざまな側面があります。たとえば、ユーザーの場合、閲覧の習慣は何か、履行の習慣は何なのか、返品の習慣は何なのかなど、この顧客をさまざまな側面から見ることができ、その後、ユーザーの肖像画を描いて、彼がどのタイプのユーザーに属するかを判断する必要があります。分類するときは、まず間違いなくこのユーザーに関するすべての情報を知りたいと考えます。すべてのユーザー情報をまとめるための粒度としてユーザー ID を使用し、それを分類器に渡して、ユーザーがどのカテゴリに属するかを分類して決定したいと考えています。これは、ユーザーポートレートの非常に古典的な使用法です。

Hologres 製品が追加される前は、Flink はデュアルストリーム結合を実行するためにのみ使用できましたが、Flink はこのような広いフィールドを形成するために使用され、異なる次元には異なるフィールドがありました。ただし、Hologres に参加した後は、Hologres で広いテーブルを構築するのと同じになり、このテーブルの主キーはユーザー ID であり、異なる Flink タスクが異なるフィールドを書き込みます。これは、1 つのタスクが行全体を書き込むという意味ではなく、各タスクが独自のフィールドの一部のみを書き込み、同じテーブルに異なるフィールドがあることを意味します。この場合、Hologres のローカル更新機能を使用することは、異なる次元のユーザーデータを自動的に関連付けることと同じです。

Hologres は上記のパフォーマンスを備え、binlog もサポートしているという点で他のデータウェアハウス製品に比べて有利です。この広いテーブルのフィールドが変更されると、ビンログはデータの行全体を吐き出し、ビンログに表示します。その後、Flink がバイナリログに接続し、この行のデータがわかります。最新の状況は何ですか? ? このユーザーのポートレートを再計算できます。

Flink のデータソースとしての Hologres

Hologres の段階的な更新、および Flink と組み合わせた binlog を利用することで、リアルタイムのユーザーポートレートを実現でき、コストを大幅に削減できます。一方、Hologres を Flink のソーステーブルとして使用すると、Flink はストリームモードとバッチモードの両方でテーブルデータを読み取ることができます。また、完全な増分統合読み取りなどの変更をカスタマイズしたり、ストック部分を増分的にのみ読み取ることもできます。

メタデータの自動検出と更新

Hologres は Flink のカタログにも接続されており、メタデータを直接読み取ることができ、スキーマの進化を含む Flink の create table as および create database as 構文を適切に適応させることができます。

3. Hologres+Flink はエンタープライズレベルのリアルタイムデータウェアハウスを構築します

リアルタイムデータウェアハウスを構築するにはどうすればよいですか? オフラインデータウェアハウスの構築には、非常に標準的な手法体系があり、データが受信されると、ODS レイヤー、DWD レイヤー、DWS レイヤー、ADS レイヤーのレイヤーごとに処理され、各レイヤーはスケジュールされたスケジューリングによって完了します。タスクの。

リアルタイムデータウェアハウスでは、データウェアハウスの観点から見ると、階層的な要件が必ず存在します。より有用なソリューションを形成するにはどうすればよいでしょうか? リアルタイムデータウェアハウスの階層化の問題を解決するにはどうすればよいでしょうか? これらの問題を解決できれば、データウェアハウスのさまざまなレベル間でデータが自由に流れることができるようになります。以下は、特定のリアルタイムデータウェアハウス階層化スキームの概要です。

従来のリアルタイムデータウェアハウス階層化ソリューション 1: ストリーミング ETL

最初で最も古典的なデータウェアハウスの階層化スキームは、Flink で処理して Kafka に渡すことです。処理の各層は Kafka に渡され、次に処理されて、Flink を通じて Kafka の次の層に書き込まれます。最後に、データウェアハウスの層に書き込まれます。 Flink 計算を介してファイルを作成します。KV エンジンは、外部の世界にサービスを提供します。ウェアハウスの概念が理解されておらず、データウェアハウスデータ処理のレイヤーしか存在しないため、人々はこれをデータウェアハウスの階層化とは考えないことがあります。

Flink+Kafka ソリューションには非常に深刻な問題があります: Kafka データの各レイヤーは Flink によって使用され、他のことはほとんど実行できません。もちろん、Presto を使用して Kafka データソースに接続することもできます。データにエラーがあるかどうかをクエリしますが、役に立つのはそれだけです。したがって、一般的には、以下の別のリアルタイムデータウェアハウスに接続し、すべての開発データをリアルタイムデータウェアハウスに同期することが一般的です。データのクエリとデータの分析を行う場合は、リアルタイムデータウェアハウスを使用してから、Kafka を使用してください。これは古典的なアーキテクチャであり、非常に成熟しています。しかし、その欠点は、さまざまな同期データのコピーを 2 つ保存する必要があるため、多くのリソースを消費し、処理リンク全体も非常に複雑であること、中間データ Kafka に関する問題のトラブルシューティングが容易ではないこと、およびデータ修正が面倒であることです。場合によっては、アップストリームがフィールドを追加し、ダウンストリームがさらに多くのフィールドを変更する必要があるため、スキーマの動的な変更に対応することが困難になります。

従来のリアルタイムデータウェアハウスレイヤ化ソリューション 2: スケジュールされたスケジューリング

2 番目の方法は、オフライン方法を使用することです。Flink はデータのクリーニングと関連付けを担当し、クリーニングされた詳細データはリアルタイムでリアルタイムデータウェアハウスに書き込まれ、DWD レイヤーが形成されます。次に、DWS/ADS レイヤーが高頻度スケジューリング (分レベル) によって構築され、分レベルの増分更新を実現します。

利点は、ソリューションが成熟していてシンプルであり、コストが低いことです。しかし、その欠点は適時性が低いことです。なぜなら、Flink によって書き込まれるデータは実際には非常にタイムリーですが、タスクを頻繁にスケジュールするのは実際には難しいからです。5分調整など、さらに下に調整すると難易度が一気に上がりますので。データの量が多い場合、データを 5 分で実行できず、増分スケジュールのみが可能な場合があり、より複雑になるためです。したがって、実際の使用では多くのユーザーが時間単位のスケジューリングを選択することが多く、リアルタイムデータウェアハウスは準リアルタイムデータウェアハウスに退化します。

従来のリアルタイムデータウェアハウス階層化ソリューション 3: マテリアライズドビュー

3 番目のソリューションはマテリアライズドビューです。実際、これは本質的に前の 2 つのソリューションを組み合わせたものです。Flink はデータのクリーニングと関連付けを担当します。クリーニングされた詳細データはリアルタイムでリアルタイムデータウェアハウスに書き込まれ、DWD レイヤーが形成されます。リアルタイムデータウェアハウスのマテリアライズドビューを通じて DWS または ADS を処理します。現在、誰もが提供する製品機能は基本的にバッチ具体化モードで実行されており、基本的にスケジュールタスクがシステムに統合されています。Hologres ではリアルタイムマテリアライゼーションも行っており、これはグループ内ですでに利用されており、将来的にはパブリッククラウドに公開される予定ですが、この種のリアルタイムマテリアライズドビューにはまだ比較的大きな技術的課題があります。

上記 3 つのデータウェアハウス分割ソリューションを分析した後、Kafka を Hologres に完全に置き換え、行と列の共存を使用して保存すると、Flink と Hologres 間のデータ転送が実現できます。統合されたアーキテクチャに基づいて、データウェアハウスの各層のデータのクエリと変更が可能であり、Flink と Hologres の強力なリソース分離機能が使用され、システム全体が本番環境で高可用性になります。以下に、Flink+Hologres をベースとしたストリーミングウェアハウスソリューションの詳細を紹介します。

Hologres+Hologres のストリーミングウェアハウスソリューション

すべての Kafka を Hologres に置き換え、KV を Hologres に置き換え、リンク全体で、Flink から書き込まれたデータを Hologres に直接転送できます。行と列の共存テーブルには、行用と列用の 2 つのデータのコピーが同時に保存されます。2 つのコピーは追加の管理オーバーヘッドなしで強い一貫性があり、シナリオによってはパフォーマンスが向上する場合もあります。以前の Kafaka アーキテクチャと比較して、Flink+Hologres には次の利点があります。

従来の中間層のKafkaデータの確認・更新・修正が困難であった問題を解決し、層ごとに確認・修正が可能です。
中間層のデータは Flink だけが利用するだけでなく、誰もが確認することができ、外部サービスを直接提供したり、OLAP/オンラインサービスやその他の利用と連携したりすることもできます。
アーキテクチャが統一され、運用保守コストが削減され、業務効率が向上し、モデルが統一されます。

Flink+Hologres のストリーミングウェアハウスソリューションに基づいて、リアルタイムデータウェアハウス Hologres は主に 3 つのコア機能を提供します。

Binlog は、テーブル更新イベントの Binlog 公開機能をサポートしています。Flink を介して Hologres Binlog を使用して、データウェアハウスレベル間の完全なリンクのリアルタイム開発を実現し、階層ガバナンスの前提を満たしながらデータ処理のエンドツーエンドの遅延を短縮します。。
行と列の共存により、Flink と Hologres 間のデータ送信が実現され、各層のデータのクエリと変更が可能になります。
強力なリソース分離、複数の計算間のリソース分離、書き込みと読み取りの分離、クエリとサービスの分離を実現します。

図に示すように、アーキテクチャ図で Flink ストリーミングがマークされている場所では、リアルタイムデータ処理リンク全体で Hologres SQL を記述する必要はなく、データ処理リンク全体が完全に FlinkSQL によって表されます。FlinkSQL と Hologres SQL の構文は比較的異なりますが、データウェアハウスの各レイヤーのストレージを同時にクエリして再利用できます。

適用例: 顧客のリアルタイムデータウェアハウスのアップグレードパス

この顧客は物流の顧客であり、その中核事業は倉庫を中心に展開しています。データウェアハウスのビジネスシナリオは比較的複雑で、主な事業は次の 3 つのカテゴリに分類されます。

リアルタイム放送。入庫、出庫、配送などの内容をリアルタイムに中継するためには、高いセキュリティが必要です。
高性能で継続的なサービスを必要とするリアルタイムの倉庫業務が数多くあります。
さまざまな共通指標センターとセルフサービス分析には、多次元の OLAP 分析と柔軟性が必要です

上記 3 つのビジネスの下で、顧客のリアルタイムデータウェアハウスには約 350 のタスクがあり、数万 CU のリアルタイムコンピューティング規模を使用しています。同時に、いくつかの重要なタスクも調整されます。たとえば、P2 以上のタスクがタスクの 70% 以上を占める場合があり、ビジネスシナリオにとってリアルタイムが非常に重要であることがわかります。次に、ビジネスデータのリアルタイムスループットが高く、1 日の平均フロー書き込み量は 1 秒あたり 2,000 万です。ピーク時には1秒あたり6,000万レコードに達し、毎日1秒あたり50万件以上の出力結果が生成され、全体のデータ量は約数百TBに達します。

リアルタイムデータウェアハウス 1.0 - コストを 70% ～ 120% 削減

この顧客は Hologres と Flink の初期の顧客であり、2020 年には Hologres が商用化の年にあり、顧客は OLAP エンジンを置き換えるためにのみ Hologres を使用しています。処理には下からKafkaとFlinkが使用され、処理が完了したデータはそれぞれ物流業務システムとOLAPクエリシステムで使用するために二重に書き込まれる必要があり、前者のデータは保証性が高いです。失敗すると倉庫全体に影響が及び、経営が混乱してしまいます。顧客は初期の段階でも Hologres 製品に疑問を抱いていたため、重要なサービスの KV チェック機能を外部に提供するよう Lindorm に 1 通の手紙を書き、社内に OLAP の柔軟な分析を提供するよう Hologres に別の手紙を書きました。これは顧客が採用した最も初期のアプローチであり、主に OLAP エンジンを置き換え、Hologres の強力な書き込みおよびクエリパフォーマンスを利用し、主にコストを 70% ～ 120% 削減します。

リアルタイムデータウェアハウス 2.0 - 開発効率が 100% 向上

2022 年までに、ホログレスの Binlog 製品機能は多くのお客様に使用されるようになり、一定期間慣れた後、お客様はホログレスの製品に対する信頼をさらに深めるようになります。同時に、Hologres はマスター/スレーブインスタンスを開始しました。1 つのデータには 1 つ以上のインスタンスがあり、インスタンスは同じデータを完全に共有できます。コンピューティングリソースも強力に分離されているため、顧客はリアルタイムデータウェアハウスアーキテクチャを次のようにアップグレードしました。 2.0。

最下位レベルから、MaxCompute はオフラインデータ処理を実行し、Flink は Hologres マスターインスタンスに書き込み、次にサブスクライブし、二次消費を実行してから書き戻して、ループを形成します。すべての顧客クエリはスレーブインスタンスを通じて外部に提供され、物流業務の選択などの高保証タスクであっても、多くのリソースを必要とするが保証レベルが比較的低い OLAP 分析タスクであっても、複数のスレーブ間で分離することができます。リソースの分離を確保します。リンク全体では、Flink と Hologres が閉ループを形成し、Hologres は統合された外部データサービスを提供するために使用されます。

顧客の観点から見ると、読み取りと書き込みの分離、同じ都市での災害復旧、ストレージ内の複数のコンピューティングリソースの分離が実現され、可用性とコストのより良いバランスが実現されました。顧客自身の障害統計は 6 から 0 に減少し、全体のストレージ容量は数百 TB 減少し、全体的な開発効率が大幅に向上しました。

リアルタイムデータウェアハウス 3.0 - パフォーマンスが 100% ～ 200% 向上:

2023 年に Hologres は、マスター/スレーブインスタンスのアップグレードバージョンであるコンピューティンググループインスタンスを開始しました。マスター/スレーブインスタンスには計算間の強力な分離という利点がありますが、最大の問題は、各インスタンスに独立した入り口があることです。日中に 2 つのスレーブインスタンスを使用する場合、ビジネスが忙しくない夜間にこれを削減したい場合、それを実現するのは難しく、ビジネスを再解放する必要があります。

コンピューティンググループインスタンスはマスター/スレーブインスタンスとみなすこともできますが、その上に統合された入り口があります。コンピューティンググループの追加またはコンピューティンググループへの名前の変更には、変更は必要ありません。コンピューティンググループの追加には、管理者がルーティングルールを構成することのみが必要です。このルーティングルールは、新しいコンピューティンググループを指すことができます。そのため、クラスメートや業務部門が新たな業務を追加する必要があるが、この際、計算グループを追加するだけで業務ルールを装備することと同等となり、操作は非常に簡単である。

この場合、すべての顧客は外部サービスを提供するコンピューティンググループインスタンスに置き換えられます。コンピューティンググループは手動で作成または破棄できます。コンピューティンググループは、ビジネスの柔軟なリソース要件を満たすために、垂直方向にスケールアップまたはスケールダウンし、水平方向に増減できます。ビジネスの分離とタスクの分離により、サーバーレス化を図りながら柔軟性を維持できるため、お客様はビジネスパフォーマンスを 100 倍向上させることができます%-200%。%。

Hologres+ リアルタイムデータレイク

今お話ししたのはリアルタイムデータウェアハウスであり、現在お客様が使用している最も成熟したアーキテクチャでもあります。ストリーミングレイク倉庫の需要の高まりに伴い、現在のテクノロジーは主に2つの開発方向に分かれています。一方では、Paimon のような新しいストリーミングデータレイクストレージを含むデータレイクストレージがあり、レイクへのデータの入力がより簡単かつ効率的になります。次に、クエリ分析レベルで、Presto や Hologres などの効率的なクエリ分析エンジンを使用して、より優れたデータクエリの高速化を実現します。Hologres は、Hudi、Delta、ORC、Parquet、CSV、SequenceFile、および OSS に保存されているその他の形式のデータの読み取りと書き込みを直接高速化できます。今年は Paimon とより詳細な協力を行い、ストリーミングレイクウェアハウス分析を行うことができますレイヤモデリングにより、開発、運用、保守のコストが削減され、データのサイロ化が解消され、ビジネス上の洞察が可能になります。

フローレイクウェアハウスの階層モデリング

先ほど説明したデータウェアハウスの階層化に戻りますが、Hologres と Paimon は両方ともストリーミングアクセス機能を備えています。ストリーミングレイクウェアハウスが Hologres+Paimon に基づいて階層化されている場合、データウェアハウスの各層は企業のストレージコストとビジネスの適時性に応じて柔軟に調整できます。

データストレージ Paimon、クエリ高速化のための Hologres: 分レベルの適時性と第 2 レベルの OLAP パフォーマンスを提供

たとえば、適時性に影響されない一部の ODS レイヤーデータの場合、データは Paimon に保存され、クエリを高速化するために Hologres が使用されます。Hologres は比較的低コストで分レベルの適時性を提供でき、Paimon と組み合わせると、クエリを高速化するために、パフォーマンスの最適化と改善も継続的に行っています。

データは Paimon から Hologres に書き込まれます。第 2 レベルの適時性と究極の OLAP パフォーマンスを提供します。

たとえば、比較的高いクエリパフォーマンス要件を持つ一部の ADS レイヤーの場合、データを Hologres に直接入力でき、これを Flink と組み合わせることで、第 2 レベルの適時性と究極のクエリパフォーマンスを実現できます。クエリ時間は数十ミリ秒になる場合があります。コストは比較的高くなりますが、パフォーマンスははるかに高速になります。

Flink と深く統合してエンタープライズレベルのリアルタイムデータウェアハウスを構築する場合でも、Paimon と組み合わせてストリーミングレイクウェアハウスを探索および最適化する場合でも、Hologres は進化の過程で常にリアルタイムシナリオに焦点を当ててきたことがわかります。リアルタイムデータウェアハウスのパフォーマンスと可用性を継続的に向上させ、ユーザーエクスペリエンスを向上させます。Hologres は、ワンストップのリアルタイムデータウェアハウスのコンセプトを通じて企業の複雑なデータウェアハウスアーキテクチャを置き換え、リアルタイムデータウェアハウスをよりクリーンで使いやすく、効率的なものにし、企業の継続的なコスト削減とデジタル変革の加速を支援したいと考えています。アップグレード中。

元のリンク

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