はじめに：平安生命は、保険業界のリーディングカンパニーとして、技術革新にこだわり、データビジネスの両輪とよりオープンなアプローチをコンセプトに、高まるデータ分析・活用需要に応え、より深いサービスを目指しています。データの価値を探求し、ビジネスデータの利用効率を確保し、ビッグデータ製品システムを継続的にアップグレードすることを目標としています。平安生命は2022年からオープンソースのリアルタイムデータウェアハウス「Apache Doris」を導入し、これをベースにOLAP技術スタックを統合し、統合されたデータ開発とサービスを通じて、元のシステムのデータ「アイランド」を打破し、データの量を削減した。需要の開発コストとビジネス需要の配信サイクルの加速を実現し、より高いデータの適時性とクエリの応答性に対するビジネス側の要件を満たし、最終的にリリースを最大化するための、よりオープンで柔軟、スケーラブルなエンタープライズレベルの管理および分析ビッグデータ製品システムを形成します。企業が「大規模な」ビジネスの成長から「洗練された」効率改善へ変革できるよう支援します。
著者: Du Tianmin、平安生命ビッグデータアーキテクト | Sun Shun
保険事業の継続的な拡大は、企業のデジタル戦略革新と切り離せないものです。平安生命は、「ワンストップ サービス」の概念を堅持し、サービス品質の向上にデータを活用しています。2005 年には、ビジネス システム データを Oracle に集中的に保存し、ビジネス ニーズに基づいてデータ レポートを作成するためのオフライン データ ウェアハウスを確立しました。データ マートは、レポート作成を迅速化するために、生命保険のさまざまなビジネス テーマに合わせて構築されています。
ビッグデータ時代の到来により、従来のデータベースではパフォーマンスのボトルネックが発生し、Oracle ベースのデータ ウェアハウスでは大量のデータのストレージ、処理、アプリケーションのニーズを満たすことができなくなりました。そのため、平安生命は 2016 年に生命保険を確立するために Hadoop を導入しました。ビッグデータプラットフォーム。過去 10 年間にわたるビッグデータ テクノロジーの探究の中で、平安生命は、データ品質の向上、ビジネス データ分析の効率化、データ価値の実現の加速を目的として、ビッグ データ プラットフォームに基づいたデータ ミドル プラットフォームを構築し、ビジネスを完全に保護するためにデータ ガバナンス システムを導入し、データを効率的に使用し、データの生産性を向上させます。データ アプリケーション層では、複数のオープンソースのビッグ データ処理および分析コンポーネントが導入され、実際のビジネスの分析ニーズに基づいて複数のデータ アプリケーション システムが開発され、ビジネス ユーザーの分析と意思決定をサポートします。
デジタルインテリジェンス時代の到来により、データの価値の重要性がより深く認識されている現在、データの価値を深掘りすることが新たな目標となっています。このような背景のもと、平安生命は技術革新にこだわり、高まるデータ分析・活用需要にオープンなアプローチで対応しており、ビッグデータ商品システムの高度化は重要なステップとなっている。
データ アプリケーションの効率をさらに向上させ、複数のコンポーネントに起因する運用、保守、使用コストを削減するために、平安生命は 2022 年からオープンソースのリアルタイム データ ウェアハウス Apache Doris を導入し、複数のデータ アプリケーション システムをアップグレードし、統合 OLAP をベースにしています。 Apache Doris エンジン レイヤー テクノロジー スタック。Apache Doris の導入により、元のシステムのデータ「孤立島」が平安生命のビッグデータ製品システムに組み込まれ、データ開発とアプリケーション層のクエリ サービスが統合され、需要開発コストが削減され、ビジネス ニーズの提供サイクルが加速され、ビジネスを満たすことができます。より高いデータ適時性とクエリ応答性の要件を満たすために、データ価値の解放を最大化するために、よりオープンで柔軟かつスケーラブルなエンタープライズレベルの管理および分析ビッグデータ製品システムが形成されます。
この記事では、ビッグ データ製品システムにおけるアプリケーション システムの反復アップグレードのエクスペリエンスを深く調査し、データ開発およびサービス指向プラットフォームにおける平安生命の革新的なアプリケーション プラクティスを共有し、Apache Doris の非常に高速な分析と統合統合の使用方法を紹介します。企業の業務効率化に貢献する機能を搭載し、効率的な経営意思決定を実現し、事業の「拡大」から「洗練」の効率化への変革を実現し、データドリブンなデジタルトランスフォーメーションにより保険会社の質の高い発展を推進します。
初期のビッグデータ製品システムの概要
初期のビッグ データ 製品システムは上の図に示されており、データ フロー プロセスは主にオフラインとリアルタイムの 2 つのリンクに分かれています。
- オフライン データは、Sqoop および ETL ツールを通じてアクセスされ、MapReduce、Spark、または Tez コンピューティング エンジンの助けを借りて、データはさらに処理、変換され、レイヤーごとに処理されます。オフライン データ ウェアハウスは、Hive に基づいて構築され、それぞれ PostgreSQL、Presto、Druid、HBase、Clickhouse、Kylin のさまざまなコンポーネントがオフライン データ クエリと取得をサポートしています。
- リアルタイム データは、Kafka メッセージ キューを通じてリアルタイムで書き込まれ、Flink を使用して計算および処理され、計算されたインジケーターの結果は PostgreSQL に保存されます。オフライン データと関連付けられたクエリは、上流のアプリケーション層のリアルタイム分析をサポートします。 。
平安生命は、実際の分析ニーズに基づいて、経営層向けのレポート分析システム、本社業務担当者向けのアドホッククエリシステム、多次元分析など、さまざまなビジネスグループの意思決定分析をサポートするさまざまなデータ活用システムを開発してきました。第一線のビジネス担当者向けのシステムと、本社および支店のマーケティング担当者向けのクラウドセレクションシステム。
さまざまなアプリケーション システムでは、分析プロセス中の OLAP パフォーマンスに対して次のようなさまざまな要件があります。
- レポート分析システム: 経営者は、パノラマレポート分析を通じて稼働データを調査し、各ラインの業務運営を理解して、ビジネスの洞察、問題の場所、傾向の予測、およびビジネス全体の概要をサポートする必要があります。管理者がデータを表示する場合、レポート出力の適時性とクエリ速度に対する高い要件が求められます。通常、単一のレポート ページには数千または数百のインジケーター計算が含まれます。この場合、OLAP は高い同時実行性と低遅延の応答をサポートできる必要があります。 . レポートの応答時間を 100 ミリ秒以内に制御します。
- 即席のクエリ: 本社の運用担当者は、視覚的な分析を通じて生命保険金請求、引受、保存、その他のデータの結果を直観的に表示する必要があります。これにより、運用担当者はデータをより深く理解し、タイムリーなビジネス上の意思決定を行うことができます。このシナリオでは、リアルタイムで柔軟なデータ クエリが事業者の主な需要であるため、OLAP はタイムリーなデータ更新と迅速な応答のニーズを満たす必要があります。
- 多次元分析システム：経営現場の現場担当者が指標データを基に多次元分析を行い、経営計測指標を多角的に検討することで、より詳細な経営データ分析を支援します。このシナリオは、企業で最も一般的なアプリケーション シナリオです。フロントライン ビジネスのクエリ トラフィックの 90% が処理され、毎日のデータ クエリのアクセス数は数十万に達します。バックエンドのデータ計算と高速化が必要です。複雑なインジケーターの二次開発。
- 群衆選択システム: 本社および支店のマーケティング担当者は、顧客データを要約および計算して、生命保険ユーザーの属性、ユーザーの行動、ユーザーの消費などの次元ラベルを形成する必要があります。マーケティング担当者は複数のタグを使用して潜在的なユーザー グループを見つけ、生命保険商品をより正確に配置して宣伝します。したがって、柔軟な開発と関連するクエリ タグ データがマーケティング担当者の主な要求となります。
初期のアプリケーションの問題点
初期のアーキテクチャは、複数の OLAP コンポーネント (Presto、PostgreSQL、Hive、Kylin、Druid、Clickhouse、HBase など) に基づいてコンピューティング、ストレージ、およびクエリ サービスを提供するため、ビジネス要件を満たすことはできますが、複雑なアーキテクチャと長いリンクにより必然的に操作が増加します。コスト、学習コスト、およびシステム間のマルチソース データの一貫性は保証できません。
さらに重要なことは、ユーザー数の増加とビジネス シナリオの多様化に伴い、データ書き込み効率、クエリの適時性、バックエンドの安定性が徐々に保証されなくなり、ビジネス分析の効率に影響を与えることが多くなってきていることです。次に、読者にアーキテクチャのアップグレードに関する新しい視点をもたらすことを期待して、上記のビジネス アプリケーションの問題点、選択プロセス、および対応するソリューションを詳細に分析します。
01 レポート分析システム
初期の頃、このアプリケーション シナリオは主に Hive と PostgreSQL に基づいてサポートされており、ビジネス全体のデータが ETL によってクリーンアップおよび処理されると、データ全体が Hive に保存されました。レポートを迅速に表示するという管理者のニーズを満たすために、開発者はまず複数回のデータ処理とクリーニングを実行し、次に結果を事前に集計することで計算された指標データを PostgreSQL にインポートします。
この方法は低レイテンシーのクエリ応答の要件を満たすことができますが、インジケーター結果の計算を複数ラウンド行うと、データ処理リンクが長くなり、データを 14 個の PostgreSQL ライブラリに分割して保存することによって発生するストレージ コストなど、さまざまなコストが重畳されます。冗長性とリソースのコストの増加、オフサイト集計とレポートのカスタマイズされた開発に起因する開発コストの増加、PostgreSQL とアプリケーションの相互使用に起因する運用保守コストの増加など。
02 アドホッククエリ
初期のアドホック クエリ シナリオは複数のコンポーネントでサポートされており、その中で Hive はオフライン データの階層ストレージを担当し、PostgreSQL はインジケーター結果データの保存に使用され、Presto は Hive 内のデータをクエリするためのクエリ エンジンとして機能します。ただし、ビジネス クエリは PostgreSQL のインジケーター データに大きく依存しているため、インジケーターが事前に計算されないと、すべてのクエリのプレッシャーが Presto に引き継がれ、リソースの無駄やクエリ応答の遅延などの問題が発生しやすくなります。同時に、システムの権限管理が不明確であり、事業者間のリソース分離制限がないため、すべての事業者が Hive の最下層のデータをクエリできるため、一時テーブルが多すぎる、クエリタスクの同時実行数が多すぎる、などの問題が発生します。リソースの先取り。
03 多次元解析システム
初期段階では、このシナリオでは Druid コンポーネントを使用して、ディメンションおよびインジケーターのストレージ クエリ サービスを提供していました。ビジネス データの急増中、プラットフォームは派生障害やシステム障害が発生しやすくなります。Druid ノードの再起動には 24 時間かかることがよくあります。システムの再起動時間が長いため、ビジネスの中断に大きなリスクが生じます。
同時に、Druid には、関連するクエリや細かい重複排除がサポートされていないなど、クエリのパフォーマンスに一定の制限があります。クレームとユーザー データを結合するクエリ シナリオでは、ビジネス担当者は、クエリのニーズを満たすために必要なデータを広いテーブルに形成することしかできず、ユーザー データの詳細な重複排除に直面した場合、Druid コンポーネントの機能を変更することしかできません。これらの制限により、クエリが複雑になるだけでなく、多くの人的資源、学習、開発、その他のコストが消費されます。
04 群衆選択システム
初期のシステムは、タグの計算とストレージを提供するために HBase に依存し、クラウド選択のためのクエリ エンジンとして Clickhouse と Kylin に依存していました。タグ構築プロセス中、HBase は主キーを介してのみクエリを実行でき、セカンダリ インデックスをサポートしていないため、データの取得に複雑なクエリ ステートメントと条件を使用できません。開発者は主キーを介してタグ クエリを設計および実装する必要があるため、発達の難しさと複雑さ、セックス。同時に、HBase には、数値や日付などの複雑なデータ型を処理できないこと、より詳細な追跡呼び出しを実行できないことなど、拡張機能に一定の制限もあります。タグ クエリ プロセス中に、システムが 200 人の同時クエリ要件に直面したとき、Clickhouse は負荷に耐えられないことが多く、事前に集計された Cube インデックスを通じてクエリのプレッシャーを共有するために Kylin を使用する必要がありました。ただし、2 つのコンポーネントが一緒にサービスを提供する場合、Clickhouse と Kylin 間の連携における柔軟性の欠如が、現在のシステムの最大の問題点の 1 つとなっています。Array フィールドのクエリを例にとります。Clickhouse は Array をサポートしていますが、Kylin はサポートしていません。関連フィールドのクエリに関しては、バックエンドに大きく依存して、データがどのデータベースにあるかを手動で判断し、クエリ リクエストを Clickhouse に送信します。さらに、どちらのコンポーネントも複数テーブル関連のクエリをサポートできず、柔軟な数値範囲選択も提供できません。
ビッグデータ製品システムコンポーネントの選択と考え方
前述のアプリケーションの問題点の中で、コンポーネントが多すぎると、データ ストレージの冗長性やデータの不整合などの問題が発生しやすいことを見つけるのは難しくありません。開発者は、コンポーネント間のデータ フローを統合するために、前後の導関数を実行する必要もあります。これにより、開発、運用、保守のコストが増加します。さらに、コンポーネント間でデータが孤立する現象がさらに悪化し、データ間の相関関係や共有が失われます。これに基づいて、OLAP テクノロジ スタックを統合し、プラットフォーム間のデータ読み取りをオープンにし、日々の分析シナリオのニーズをカバーし、効率的な派生と非常に高速な分析を実現できる、包括的で柔軟なコンポーネントを選択したいと考えています。さらに、データ ガバナンスをより体系的に行うために、導入されたOLAP コンポーネントがインジケーターやラベルなどの次元データの統合的な計算と保存をサポートし、API を使用して上流のアプリケーション層に統合されたクエリ サービスを提供することも期待されています。。
調査と選択の結果、図に示すように、Apache Doris はアップグレードのニーズに非常に適していることがわかりました。通常のビジネス シナリオをカバーし、書き込みとクエリのパフォーマンス要件を満たすだけでなく、統合されたアーキテクチャに基づいてアーキテクチャの複雑さを大幅に軽減できます。 Apache Doris に基づくテクノロジー スタックにより、運用とメンテナンス、開発と使用のコストが削減され、アーキテクチャのパフォーマンスが最大化されます。したがって、平安生命は、Apache Doris をベースにした新しいアーキテクチャへのアップグレードの旅を開始しました。
ビッグ データ製品システムは、Apache Doris の統合と統合の進化の軌跡に基づいています。
Apache Doris が導入される前、ビッグ データ製品システムは、データ ストレージ、計算、およびクエリ サービスを提供するためにさまざまな OLAP コンポーネントに依存していました。Apache Doris の導入後、平安生命保険は、OLAP エンジンの統合に基づいて Apache Doris クラスタ上に統合インジケータおよびラベル設計プラットフォームを構築し、「上下操作用の 1 つのテーブル」を形成し、運用指標管理システムを改善しました。 API インターフェイスを介して直接接続し、アプリケーション層は複数のシナリオに統合されたデータ サービスを提供します。
01 エンジンの最適化: Apache Doris に基づいた OLAP テクノロジー スタックを段階的に統合します。
現在、平安生命は Apache Doris を使用して HBase、PostgreSQL、Presto、および Druid コンポーネントを置き換え、インジケーター ラベルの計算と保存を統合し、レポート分析、アドホック クエリ、および多次元分析アプリケーションをサポートし、管理レポート アプリケーションを開始しました。システム、本社、および最前線の運用担当者向けの視覚分析システム。同時に、平安生命は、Apache Doris のさまざまなデータ ソースへの適応も完了し、さらに Clickhouse および Kylin コンポーネントを置き換えました。今年 11 月には、Apache Doris がオンラインになり、マーケティング代理店の群衆選択システムの制作に使用される予定です。
Apache Doris は、データ ストレージ、コンピューティング、クエリ サービスを同時に提供するシステムを提供し、複数回のデータ計算によって引き起こされる開発の繰り返しやストレージの冗長化の問題を回避するだけでなく、より柔軟できめ細かい効率的なクエリを可能にします。分析。Ping An Life は、アプリケーションの開始後、次のようなメリットを実現しました。
- さまざまなリソースのコストを削減: Apache Doris の豊富なデータ モデルを使用すると、データは事前集計と要約を複数回行う必要がなく、データ処理プロセスが大幅に簡素化され、運用とメンテナンスのコストが削減され、元の 14 個の PostgreSQL データベースのリソース コストの圧力。
- 開発とクエリの効率向上: インジケーターとラベルのデータを統合して開発することで、コストが削減されるだけでなく、ビジネスの納期も短縮され、開発サイクルが当初の 2 週間から 1 日に短縮され、効率が 14 倍に向上します。Apache Doris の導入後、Doris の支援によりクエリ レベルの権限が設定され、ビジネス担当者はデータ ADS レイヤーのデータにのみアクセスできるようになり、データ ウェアハウス内のテーブルの相互使用の問題が解決され、パフォーマンスが向上しました。 Doris の支援により、インデックス データの再利用率と使用効率が優れています 高い同時実行パフォーマンスは、レポート分析および多次元分析シナリオにおける第 2 レベルおよびミリ秒レベルのクエリ応答要件を満たし、クエリ速度は最大 5 -10回。
- データ サイロの打破とクローズド ループ管理の実現: Apache Doris は、統合テクノロジー スタックの利点を利用して、さまざまなアプリケーション システムにおけるデータ サイロ現象を打破し、より包括的なデータ、より粒度の細かい次元クエリをビジネス スタッフに提供し、洗練されたクエリを実現します。分析、一貫したビジネス洞察の観点、およびクローズドループのデータ管理により、企業全体が生命保険事業の方向性をより正確に把握できるようになります。
02 セマンティックおよびサービス層の最適化: Apache Doris に基づく統合インジケーターおよびラベル サービス
OLAP テクノロジー スタックを統合した後、平安生命はさらに統合セマンティック レイヤーを導入して、複雑なクエリ ステートメントを逆アセンブルおよび変換し、SQL ステートメントの実行効率を簡素化および高速化して、データ サービス API アクセスを利用してさまざまなビジネス アプリケーション レイヤーを接続しました。
この方式では、平安生命のグローバルデータが収集・アクセスされた後、ドリスデータウェアハウスに入り、業務担当者がバックグラウンドでドラッグ＆ドロップによるセルフサービスの指標ラベルデータの定義と自動計算を実現し、生成されたSQLが管理者に送信されます。ドリスADSレイヤー。このうち、複雑な複数テーブル関連のクエリが含まれる場合、SQL ステートメントはセマンティック レイヤーでフィルタリングされ、単純な実行ステートメントが生成されます。共通 API サービスの助けを借りて、Doris ライブラリ内のデータが呼び出され、顧客業務、エージェント、ポリシー、製品、請求などにおけるビジネス分析のニーズを均一にサポートします。現在、平安生命は、統合されたサービス指向プラットフォームに基づいて 1 日に数百万件のデータ呼び出しをサポートしており、各レポートのクエリ応答時間は 200 ～ 300 ミリ秒であり、複数のシナリオで非常に高速で統合されたデータ サービスを実現しています。
この時点で、平安生命はデータ設計からデータ サービスに直接移行し、企業間での冗長な開発と再利用を効果的に回避し、ビジネス配信サイクルを短縮し、クエリ応答時間を短縮しました。高い凝集性と低い結合性をベースにした統合サービス プラットフォームにより、ビジネス ニーズの変化にタイムリーに対応するクエリ分析が可能になり、企業内外のデータのスムーズな流れが保証されます。
まとめと今後の予定
ワンストップ データ ポータルは、平安生命のビッグ データ 製品システムの最初から最後までの目標であり、 Apache Doris に基づいて、複数の OLAP テクノロジー スタックを統合し、ラベルとインジケーターの開発と管理を標準化し、統合されたデータ サービスを共同で提供します。ビジネス アナリストがセルフサービスのデータ探索を実行できるため、技術担当者への依存が軽減されると同時に、さまざまなデータ リソースに簡単かつ迅速にアクセス、分析、視覚化することで、効率的かつ低コストのデータ配信が可能になります。
将来的に、平安生命は、Apache Doris レイクとウェアハウスの統合のアプリケーションをさらに拡張し、データ レイクのクエリと分析のために Presto の代わりに Doris を使用し、データと計算がレイクとウェアハウスの間を自由に流れることができるようにする予定です。同時に、Apache Doris マルチテナントおよびリソース分離ソリューションが導入され、アプリケーション システム間の負荷分散パフォーマンスが向上し、高いタスクの同時実行性、大量の CPU メモリ使用量、および派生プロセス中のクエリ パフォーマンスのブロックのリスクが回避されます。クラスタ上でのマルチユーザー データ操作のリスクを軽減します。クラスタに障害が発生した場合、クラスタ リソースはより合理的な方法で各アプリケーション システムに割り当てられます。
最後に、平安生命への継続的な技術サポートと平安生命のデジタルでインテリジェントな変革プロセスを加速させてくれたFeilun Technology チームに非常に感謝しています。この時点で、あらゆるレベルのビジネス担当者はデータ分析の効率を加速し、企業がタイムリーに問題を発見して解決できるよう支援することで業務効率を向上させることができ、経営陣は膨大なデータを通じて市場の傾向や顧客のニーズを洞察し、ビジネス上の意思決定を推進することができます。 。
平安生命は今後も保険業界の変革プロセスを推進し、より多くのビジネスチャンスと商品イノベーションをもたらすとともに、Apache Dorisのコミュニティ構築に引き続き参加し、関連する成果をコミュニティに還元して価値共有を実現していきます。
Alibaba Cloudが深刻な障害に見舞われ、全製品が影響(復旧) Tumblr がロシアのオペレーティングシステムAurora OS 5.0 を冷却新しいUIが公開 Delphi 12とC++ Builder 12、RAD Studio 12多くのインターネット企業がHongmengプログラマーを緊急採用UNIX時間17 億時代に突入しようとしている (すでに突入している) Meituan が兵力を募集し、Hongmeng システム アプリの開発を計画Amazon が Linux 上の .NET 8 への Android の依存を取り除くために Linux ベースのオペレーティング システムを開発独立した規模はFFmpeg 6.1「Heaviside」がリリースされました