著者 | ホンユアン・ジュン

ガイド

この記事では、Baidu の垂直オフラインコンピューティングシステムの進化の方向を主軸とし、検索垂直オフラインコンピューティングシステムの開発で遭遇した問題とそれに対応する解決策を詳細に説明します。アーキテクチャの進化の過程では、「最良のアーキテクチャはない、最も適切なアーキテクチャのみが存在する」という原則が堅持され、さまざまな段階で遭遇する問題に対して適切な解決策が与えられてきました。特に過去10年間の超大規模システムアーキテクチャの更新では、複数のビジネスパーティのニーズに応えるシステム自体の汎用性や適応性、パフォーマンスの向上、安定性の向上、知性やその他の側面。読者がシステムの進化を理解する過程で何らかのインスピレーションを得られることを願っています。

全文は9127ワード、予想読了時間は23分です。

01 関連背景紹介

これまで、ユーザーが「百度クリック」を通じて取得した検索結果は、インターネットからクロールされた結果であり、「自然結果」とも呼ばれていました。ネットワーク情報がますます豊富になるにつれ、自然な結果ではユーザーのニーズを効果的に満たすことができなくなります。自然な検索結果では検索ニーズを満たせないという問題を解決するために、さまざまな垂直カテゴリの検索結果に対するソリューションが提案されており、一方ではユーザーにより良いコンテンツが提供され、ユーザーはインスタント検索の利便性を体験できます。その一方で、高品質のコンテンツ制作者がトラフィックを増やすのにも役立ちます。

ビジネス開発に伴い、標準および一般的なビジネス処理要件の変化に加え、カスタムコードの更新要件を持つ企業が増えています。カスタムデータ処理を通じて、製品を担当する学生は、ビジネスニーズに応じて元の受信データをカスタマイズし、元のデータを最終的な検索結果データに変換できます。一方で、一部の一般的なデフォルトの機能メカニズムにより、少数の垂直カテゴリの開発が制限されているため、企業は、ソートとリコールの効果を向上させるために、より多くのポリシーモデルロジック信号処理およびスコアリングメカニズムを導入したいと考えています。

これに関連して、企業はデータ処理とコンピューティングのためのフレームワークエンジンに対する要求をますます強くしており、その機能は徐々に垂直検索のオフライン処理プロセス全体に不可欠な部分になってきています。

02 計算機システムの進化過程

Baidu 検索システムのオフラインデータ処理は、タイムラインの開発段階の観点から次の段階を経ました。

a. 独自のオフライン処理システム: この段階では主に業務処理エントリの 0 から 1 の構築を実現します。全体として、完全なフレームワークシステムが形成されておらず、開発コストが高く、すべてのビジネスロジックが公共サービス内に混在しており、異なるデータが異なる構成を通じて異なるポリシーロジックを呼び出しています。

b. ビジネスオフライン処理アーキテクチャ: この段階では、統合されたサービスフレームワークと開発段階を備えたビジネスサービス処理フレームワークの完全なセットが最初に形成され、クラウドネイティブおよびサービス分離モデルが実現されます。

c. サーバーレスアーキテクチャ:この段階でビジネスのアクセス効率がさらに向上し、管理サービスから管理業務処理機能に移行し、機能を登録することで迅速なテストとオンライン化が可能になります。コンテナインスタンスの自動スケーリングをサポートしているため、ビジネスにおける利用効率が大幅に向上し、それに伴うリソースコストが大幅に削減されます。

d. データインテリジェンスアーキテクチャ：独自のサービス展開に基づいて、データ管理を同時に実現し、機能管理から需要管理へのさらなるアップグレード、多言語サービスフレームワークのサポートを実現し、さらなるコスト削減と効率の向上を実現します。

03 コンピューティングシステムコア設計のコアアイデアとコアの実装

各ステージの詳細な特性とコアの実装については、以下で詳しく説明します。

3.1 独自のオフライン処理システム

このフレームワークは、垂直カテゴリーの全体的な開発が初期段階にあった 2018 年より前に適用されました。この段階でのビジネスの主な要件は、元のビジネスデータを直接オンラインにできることです。アーキテクチャの主なエネルギーは、一般的なビジネス機能の構築に焦点を当てています。ビジネスが徐々に深化するにつれて、少数の企業がカスタム処理の必要性を徐々に進化させていることがわかりました。

当時のビジネスニーズに従って、最終的にオリジナルのデータ処理モジュールからビジネスデータ処理システムが派生しました。現在のデータ処理方法は統一されたハンドラー処理方法を使用していますが、もちろんこの処理は必須ではなく、ほとんどの企業では依然としてカスタム処理を必要としません。ビジネス間のデータ分離はまったくなく、このアーキテクチャの中心的な意味は、ビジネスにカスタム処理機能をゼロから提供することです。下図に示すように、現時点ではコンピューティングシステムにはコンピューティングエンジン部分のみが含まれており、他のシステムはまったく構築されていません。システムの詳細については、以下で詳しく説明します。

3.1.1 サービスの特徴

この時期のビジネスには主に 2 つの特徴があります。

ほとんどの企業にとって、最も重要な核となる魅力は、一般的な機能の構築です。
個々のビジネスの場合、少量の単純なカスタム処理のニーズがあります。

したがって、この時点の核心は主に業務処理入口の問題を解決することです。

3.1.2 コア設計

初期バージョンのオフラインアーキテクチャモジュールは、下図の青い部分に示すように、非常にシンプルです。ビジネスの発展に伴い、ビジネスカスタム処理のニーズを満たすために、統合データ処理モジュールが主にビジネスカスタム処理ロジックを処理するレッドデータチャネルが導入されました。

上の図にあるように、灰色の部分はビジネスの外層がアクセスするデータシステムであり、当初は XML、POST、データキューモードのみでした。青色の部分は、ビジネスをカスタマイズしていない場合の元のデータフレームコードです。赤い部分は、ビジネスのカスタマイズ要件のために導入されたフレームワークモジュールです。

ユーザーデータプロキシ: 主にビジネスデータのアクセス方法に適応し、データプロトコルを均一化するためのもので、主に異なるユーザープロトコルのRPCでデータベース構築層でデータを変換するために使用されます。

ユーザーの一般ニーズ：主にユーザーの共通ニーズの統一処理と、ビジネスの写真やビデオの変換処理、ビジネスユーザーのバージョン管理、ユーザーのコアメカニズムなど、さまざまなビジネスのさまざまな構成に応じた機能処理。

統合データ処理モジュール：主にユーザーデータの処理と処理を統合し、接続されているすべてのビジネスデータのデータ処理のエントリを提供します。

3.2 ビジネス処理アーキテクチャ

前述したように、3.1 アーキテクチャの核となる価値は、カスタム処理機能を 0 から 1 まで構築することです。しかし、ビジネスの急速な発展に伴い、カスタム処理機能を必要とするビジネスがますます増えています。ビジネス向けカスタム加工の需要は当初の1桁から10倍に急拡大。したがって、カスタム開発における使いやすさと安定性というビジネスのニーズを満たすために、元の 3.1 集中処理モードがサービスフレームワークモードにアップグレードされました。一般に、現段階のコンピューティングシステム構築は、基本的にサービス層とビジネス層の 2 つの層で構成されています。

ビジネス層: ビジネスは基本的にプラットフォーム、基本的なサービス管理を通じて実現できます。

サービス層: 新しいサービスフレームワークが効率的なビジネス開発をサポートできるように、コンピューティングエンジンをリファクタリングします。

システムの詳細については、以下で詳しく説明します。

3.2.1 サービスの特徴

3.1 の前世代システムの数十のビジネスカスタマイズ要件は同じモジュールで開発され、統一された方法でオンラインで実行されていたため、遭遇した主な問題は次のとおりです。

効率性: ビジネスは同じモジュール内で開発されますが、ビジネス開発のプロセスとオンラインで競合が発生したり、オンラインのキューの問題が発生したりするため、全体的な有効サイクルが比較的長くなります。

安定性: この種のビジネストラフィック混合モードの分離が不十分なため、単一のビジネスの問題がすべてのビジネスに影響を与えることがよくあります。

したがって、アーキテクチャは完全なサービスフレームワークを構築し、企業はサービスフレームワークに基づいて独自のビジネスコードを構築して、効率と安定性の観点から上記の問題を解決できます。

効率性: サービスの開発と立ち上げのプロセスは完全に分離されており、サービスの開発と立ち上げのプロセス中にビジネスが妨げられることはなく、全体的なサービスの立ち上げサイクルが数日から数時間に短縮されます。

安定性: 各ビジネスサービスの実行ロジックが完全に独立したアプリを持つため、ビジネスの安定性が大幅に向上し、ビジネス間の相互影響がなくなります。

3.2.3 コア設計

ビジネス処理フレームワーク: 企業が独自のビジネス処理機能を実装できるデータ処理フレームワークを構築します。

タスクプラットフォーム: 各タスクの登録、アップグレード、管理はタスクプラットフォームを通じて管理できます。

統合ゲートウェイ: すべてのデータの統合入口、上流データの統合受信、データの転送と配信。

ビジネスAPP : 各ビジネスは独自の独立したサービスアプリを持っています. 各ビジネス開発はフレームワークの独立したブランチ開発に基づいています. オンラインは各ビジネスが別々にオンラインになり、ビジネス処理のサービストラフィックも完全に分離されます.

3.3 サーバーレスアーキテクチャ

上記 3.2 で述べたように、システムの分離の問題は解決され、ビジネスの急速な発展により、数十から数百のビジネスアプリケーションが増加しました。ビジネスがパンク状態に発展すると、サービスフレームワークの形式ではビジネス開発のニーズを満たせなくなります。

サーバーレスアーキテクチャは次の図に示されています. 現時点では, コンピューティングシステムの全体的なレイアウトは比較的完成しています. 前世代のコンピューティングアーキテクチャと比較して, ビジネス層に含まれるプロセス全体が最適化されるだけでなく, 完全な機能も提供されます.サービス層はアーキテクチャの設計と多重化を十分に考慮し、制御層を増やしてシステムトラフィックのリソースを動的にスケジュールするインテリジェントスケジューリングの機能を強化します。

システムの詳細については、以下で詳しく説明します。

3.3.1 ビジネスの特徴と問題解決

ビジネス学習コスト: 多数の新しいビジネスアクセスを開発する必要があるため、フレームワーク自体の学習コストは数日かかり、新しいビジネスアクセスと開発にかかる時間は基本的に週レベルです。

リソースを節約する方法: サービスの数が多いと、アプリの急速な拡張も起こります。接続されている数百台のマシンが使い果たされ、リソースのボトルネックに達しました。現在のリソース量では、サービスの急速な拡張をサポートできません。

3.3.3 コア設計

アプリケーション層: 基本的なサービスアーキテクチャを目指して、ビジネスアクセスと開発からその後のデバッグとテスト、サービスがオンラインになった後の監視に至るまで、さまざまなクラウドサービスがビジネスに公開されています。

サービス層: 全体のアーキテクチャの基礎となる部分であり、これをベースにアプリケーション層が開発される、システム全体の根幹を成す部分であり、システム全体の中核となるフレームワークに属します。

スケジューリング層：トラフィックパターンに応じた拡張・縮小により、後続サービスの自動運用を確保します。

以下では、サービス層の主な内容に焦点を当てます。サービス層には、主にビジネス用の 2 つの部分が含まれます。

非常に抽象的なビジネスフレームワーク: これはコアフレームワークの基礎であり、新しい開発パラダイムを提供し、その後のインテリジェントなスケジューリングのための優れた基盤を築きます。

再利用性の高い基本サービス: 強力で豊富なバックエンドサービス機能をカプセル化し、低コストでビジネスの再利用をサポートし、開発コストを削減し、安定性を向上させます。同時に、強力なオーケストレーション機能も提供し、単純なものから複雑なものまでのビジネス開発を低コストでサポートします。

極めて抽象的なビジネスフレームワーク

ビジネスフレームワークは、FaaS レイヤーとビジネスコードのキャリアとして、ビジネスロジック全体のコードフレームワークです。フレームワーク自体はデータフローセマンティクスを維持し、有向非巡回グラフ (DAG) データフローのビジネス関数コードを呼び出します。ビジネスフレームワークは、有向非巡回グラフデータストリームのリアルタイムコンピューティングです。同社の基本的なデータストリームフレームワークに基づいて、完全なストリーミングコンピューティングセマンティクスをサポートします。ビジネスフレームワークは、ビジネスシナリオに必要な機能と組み合わせて構築されます。

上図の左側がユーザーの実際の実行コードで、関数のインターフェース定義の場合、入力パラメータ、戻り値ともにDict型となっています。ビジネスのコードロジックは関数に直接実装されており、変更が必要なデータについては、上図に示すように、ルートディレクトリの下にタイムスタンプフィールドを追加し、更新された結果をダウンストリームに渡します。

ビジネス側は開発コストの低いスクリプト言語（Pythonなど）で開発し、基本的なサービスフレームワークはC++で実装し、データ圧縮やバッチ処理、データの事前配布などの仕組みと組み合わせることで、ビジネス側のシステム構築を簡素化することができます。サービスフレームワークの開発とサービスパフォーマンスの最適化。サービスのパフォーマンスと開発コストのバランスは、アーキテクチャレベルでの最適化戦略によって達成されます。

再利用性の高い基本サービス

ビジネスが依存するバックエンドサービスには、マルチメディア永続サービス、データストレージサービス、ポリシー計算など 10 のサービス機能が含まれており、すべてのサービスアーキテクチャのサポート目標は、シンプルな構成と少量のコードによるサービスアクセスです。

アーキテクチャの一般的な機能: インデックス処理 (反転インデックス、順方向インデックス、ベクトルインデックス)、データレビュー (政治的機密データ/ポルノデータの識別とフィルタリング)、マルチチャネル配信、データデータベース構築、その他の機能を含みます。

企業との共同研究開発機能：低品質データフィルタリング機能（データクリーニング/正規化/データ重複排除/カテゴリスプライシングの実装）、複数のデータ融合、データ品質スコアリング計算（品質スコアリング/不正行為の特定/素材スコアリング）。

同社の強力な基本機能に基づいて、マルチメディア処理サービス（内部リンクへの外部リンク/OCR/透かし計算/繰り返し画像計算/被写体認識/ビデオダンピングなど）、自然言語処理サービス、データ降下サービスを提供します。

サポートされている基本サービス (BaaS サービス) には、シンプルで安定していること、および社内の他の高品質機能と完全に統合されていることという2 つの主な特徴があります。ユーザーは、SDK 呼び出し、オペレーターの再利用、およびデータストリームの再利用を通じて、機能を直接再利用できます。サービスの導入と管理は必要ありません。サービスの使いやすさと安定性は、検索センターによって処理されます。あらゆるサービスバックエンドを 1 か所で閉じることができるため、複数のサービスチームとの頻繁な通信とビジネス処理が回避され、ビジネス使用コストが大幅に削減されます。通常、最初のビジネスアクセスにはいくつかの単純な機能 (たとえば、一部のフィールドの情報の変更) のみが必要で、ほとんどのビジネスは、当社が提供するプラットフォームベースの開発テンプレートを使用して直接開発できます。しかし、徐々に業務を深化させ、徐々に利用していくにつれて、例えば検索センターのある業務では、数十の機能を組み合わせて深いカスタマイズを施したデータシステムを構築するなど、徐々にビジネスは複雑化していきます。

3.4 データインテリジェンスのアーキテクチャ

上記3.3で述べたように、サービスアクセス効率の問題は大幅に解決され、トラフィックの拡大縮小に応じてリソース利用効率が大幅に節約され、ビジネスアプリの数は数千にまで増加しました。効率、コスト、サービス品質に対してより高い要件を提示しています。これまでに、オフラインコンピューティングシステムを命令型コンピューティングシステムから宣言型コンピューティングシステムへ完全に変革するために、ビジネス層、ロジック層、サービス層、制御層の4層アーキテクチャを構築してきました。

3.4.1 サービスの特徴

効率化ビジネスの反復開発のほとんどは、いくつかの分野を対象としていますが、現在のビジネス学生は、開発するサービスのトポロジ全体を理解する必要があります。
ビジネスの開発と反復が複雑で深く耕されているため、ビジネス開発者はサービスの開発と実行の効率を向上させるために多言語開発を行っています。
包括的な理解なしに、ビジネスはどのようにして新しいカテゴリへの迅速なアクセスと迅速な反復を達成できるのでしょうか。
計算エンジンは実行効率が高く、より少ないリソースを使用してより多くのサービスリソースを計算および実行します。
ビジネス上の問題を迅速に特定して発見し、自動的に処理できるかどうか。

3.4.2 核となるアイデア

設計思想の観点から見ると、現在のシステムアーキテクチャは前世代のアーキテクチャの拡張です。

データ管理: 元のサービス管理に加えて、列計算の基礎を築くために包括的なデータ管理が導入されています。
オーケストレーション機能: 元のビジネス手動オーケストレーションの機能機能を、デマンド宣言型自動オーケストレーションの機能まで拡張します。
サービス処理: 非常に効率的なサービス処理機能は、さまざまなビジネス開発者の効率的な開発効率をサポートし、全体的な計算を行計算から列計算に移行し、全体的な計算の再利用を向上させます。
制御機能: 元の自動スケーリング機能をインテリジェントな制御機能に拡張し、問題の自動識別、自動配布、自動分析、自動処理を実現します。

アーキテクチャ全体の中核となる設計コンセプトは、大まかに言うと、多層の抽象化と層状の再利用です。

3.4.3 コア設計

現段階のコア設計は、完全な 4 層アーキテクチャの抽象化機能を示しています。

アプリケーション層: ビジネスに直接表示される関連サービス。データアクセスからサービス運用までのビジネスの全サイクルの各段階におけるさまざまなアプリケーションが含まれます。

論理層: オーケストレーション層とも呼ばれます, 元のビジネス要求表現を実際のオンラインサービスに変換する責任があります. ビジネスはコードレスプラットフォームを通じて独自の関数セットを選択し, 対応するデータマッピング関係を送信します. 提供された関数とデータバインディング関係は、ビジネスのカスタム関数とマッピング関係に変換されます。

サービス層: コンピューティングシステムの中核。実際のビジネスコンピューティングはこの層で実行され、主にコンピューティングエンジンとサービスアーキテクチャの 2 つの部分で構成されます。ロジック層のオーケストレーション結果を上向きに受け取ってサービスを実行し、基本信号を下向きに制御層の入力として提供します。

制御層: インテリジェントスケジューリングとインテリジェント制御の 2 つの部分で構成されます。インテリジェント制御は主に、ビジネスインデックスデータを自動的に受信することにより、インテリジェント制御を通じてサービスの安定性を確保します。一方、インテリジェントスケジューリングは、データトラフィックに応じて自動スケーリングするだけでなく、ビジネスに応じてトラフィックも調整します。サービス関係再利用し、ビジネスの二重カウントを削減します。

以下では、いくつかの基幹システム (上図の青い部分など) の設計について説明します。

要件の式ロジック

要求ロジックの表現の核心は、ユーザーの元の機能要件を、実際のオンラインサービスの演算子、構成、および関係の表現にどのように変換するかです。最も原始的なユーザー入力は 2 つの部分で構成されます。

ビジネスデータ: ビジネスデータは機能の最小単位に分割する必要があり、後続のオペレータは構成変換とサービスバインディングの列計算を実行します。ここで述べたことは少し口先であり、実際には、本質的にはビジネスデータの元の Proto またはデータスキーマを登録するだけです。

関数セット: 関数セットは、ユーザーが直接使用するシステムによって提供されるデフォルトのテンプレートの関数セットにすることも、プラットフォームを通じてユーザーがカスタマイズするセットにすることもできます。各関数には指定された受信機能があることに注意してください。画像などのパラメータ計算の場合は画像の URL を渡す必要があり、ベクトルの計算の場合は生データとベクトルパラメータなどを渡す必要があります。関数が完了すると、指定できる対応する出力結果が表示されます。

ユーザーの元の入力を取得した後、アーキテクチャは2 層の論理マッピングを通じて元のユーザー要件をオンラインサービス展開情報に変換します。

需要表現サービス: ユーザーの本来の需要を機能的なテンプレートの組み合わせに変換します。この段階では、元の演算子とデータがユーザー構成に従ってバインドされ、元のユーザーの抽象的な要件がデータを含む演算子のセットにインスタンス化されます。

デマンドオーケストレーションサービス：事業者自身の依存関係とデータ依存関係の血縁関係を表現・組み合わせることにより、データを持つ事業者をN個の有向非巡回グラフに構築する。

全体的な要求表現をコードレスで表現でき、関数セット✖️データセットの記述方法を記述し、2層論理マッピングの変換と組み合わせることで、元のユーザーの宣言的要求を直接オンラインサービス関係やシステム構成に変換できます。とサービスビジネスデータの関係表現を通じてオペレータの位相関係を自動的に推定し、95%以上の機能を全自動で設定・実現可能もちろん、個別に変換できないサービスもあり、低コストで表現でき、マニュアルインターフェースも提供します。

計算エンジンの実装

コンピューティングエンジン層のコアコンポーネントは、グラフコンピューティングエンジンと多言語オペレーター実行エンジンの 2 つの部分に大別されます。

Graph Computing Engine : 主に制御されるビジネストポロジの表現関係を有向非巡回グラフで表現します。

オペレーター実行エンジン: 主にビジネスの実際のビジネス機能の実行を制御します。言語が異なれば、関数の実装も異なります。たとえば、Python、GoLang、C/C++ はすべて独自の実行エンジンを持っています。

以下に 2 つの部分について詳しく説明します

グラフコンピューティングエンジンの実装: 実装の中心的な機能は、有向非巡回グラフの表現をサポートするフレームワークを実装することです。C++ を使用して実装されます。下図の部分の青い部分は、有向非巡回グラフのフレームワーク実装です。もちろん、私たちのフレームワークの基礎となる実装は、さまざまなデータの表現をサポートしています。
ローカルキュー式: 図の左下は単純なトポロジ式です. トポロジ関係はローカルロックフリーキューを介して直列に接続されます. 各キューの下にビジネスオペレータがマウントされます. ビジネスオペレータがデータの処理を完了した後,オペレーターのトポロジー構成管理は、下流のローカルキューに分散され、最後のオペレーターの場合、すべてのデータ結果が処理され、リモートキューのプロデューサーに出力されます。左側にあるのは、フレームワーク内の一般的な関数です。

スレッド管理: 各ビジネスオペレータは、デフォルトでマルチスレッド分散モードに設定されています (ビジネスオペレータが単一スレッドのみをサポートしている場合は、スレッド数を 1 に設定できます)。

分散モード: データ消費分散モードのデフォルトは、ラウンドロビン分散、固定 KEY 分散 (順序保持を実現するため)、および消費容量に応じた分散です。

データ圧縮: これは、デフォルトで一般的なデータ圧縮方法をサポートし、オプションのスループット最適化方法であり、LZ4、Gzip、Snappy などの一般的な圧縮アルゴリズムをサポートします。

リモートキューの表現: それぞれの大きな青いボックスは特定のインスタンスを表し、リモートキューはインスタンス間の対話に使用されます。各インスタンスにビジネスオペレーターが 1 つしかない場合、この対話方法はリモートキューの表現方法に似ています。
混合表現: より多くの使用法が混合されます。巨大なトポロジは複数のサブトポロジに分割されます。各サブトポロジはローカルキューを使用して表現され、サブトポロジはリモートキューを使用して表現されます。
多言語エンジン実行層: 言語実行層の全体的な枠組みは、言語ごとに異なる実装モードがあり、コンパイル済み、インタープリター済み、ネイティブ C++ の 3 つの部分に大別されます。

解釈: 最も典型的な実装は Python です。これは、過去に学生が使用していたお気に入りの開発言語の 1 つでもありました。上の図の上部で、左側の灰色の部分は C++ 開発部分、右端の黄色の部分はビジネスコード、中央の部分は C++ から Python への対話エンジンの呼び出しです。このメソッドの本質は、C++ 開発エンジンが PyBind を使用して指定されたインターフェイスサービスインタープリターを実装し、指定されたデータのシリアル化および逆シリアル化メソッドに従って動作し、関数が呼び出されたときにリアルタイムでそれを Python Dict に変換することです。

コンパイル型: Golang の典型的な使用法。Python の実装と同様に、左側の灰色の部分は C++ によって開発された部分、右端の黄色の部分は Golang ビジネスコード、中央の部分は C++ から Golang への対話エンジンです。Golang の実装は Python よりも少し複雑です。本質はネイティブ CGO をユーザーインターフェイスとして使用することです。ユーザーインターフェイス層を統合するために、実際には 2 つの部分に分かれています。左半分は Python と直接対話します。 C++、および C++ の直接実装は、ネイティブ C++ を次の形式に変換する役割を果たします。基になる C 型の関数ポインターが呼び出しを行います。右半分は Golang を使用して実装し、ネイティブにシリアル化された関数をビジネス構造に逆シリアル化し、実際の呼び出しを行う役割を果たします。

ネイティブ C++ : C++ もコンパイルされることに奇妙に思う人も多いと思いますが、すでにコンパイル済みの実装モードが存在します汎用性を考慮して、データ転送プロセス中にシリアル化と逆シリアル化の操作が必ず実行されます。ネイティブ C++ では、実装プロセス中にすべてのシリアル化および逆シリアル化操作を完全に破棄し、データはローカルでキューに入れられます。転送されるのは完全にビジネスデータポインター (シリアル化されたデータではありません) であり、各ビジネスオペレーターは、データ処理プロセスにおける元のデータポインター (単純なマップ実装メソッドが多数あります) 対応する列のデータ項目を取得するため、プロセス全体がロックフリーで非常に効率的です。ここでの最適化の中心となるアイデアは、データチェーンの処理プロセスです。ジッパー上の各オペレータは、同じ入力と出力を共有します。各演算子は実際には同じインターフェイスを持つ関数であるため、関数ポインターの組み合わせを自由に調整して、異なる処理チェーンを形成できます。たとえば、リクエストはモデル A によってソートされ、リクエストはモデル B によってソートされます。それらは前のシーケンスの演算子を共有でき、最後の演算子のみが異なります。連鎖処理に基づいて、演算子を同じ基本クラスインターフェイスまたはラムダ式を継承する派生クラスにすることもできます。ファクトリモデルなどのいくつかのプログラミング手法と組み合わせることで、処理チェーンの調整を動的に構成し、スクリプト化することができます。ビジネスのシングルオペレーター、分岐のある通常の純粋なデータ項目、およびマルチノードトポロジコンピューティングを実行する場合、単一のコンピューター (シングルスレッド/オペレーター) は数十万の処理能力に達することができると測定されています。

新しいコンピューティングエンジンの実装により、前世代のコンピューティングシステムの使用法と完全な互換性があり、頻繁に使用されない機能が簡素化され、複雑なトポロジの実行方法が最適化されます。ビジネス層では、多言語と効率的な実行方法をサポートし、旧ビジネスの再配置のためのデータフレームの平均計算効率が5〜10倍に向上し、ターゲットを絞ったビジネス開発効率がさらに向上します。ビジネスフレームワークの構築。

インテリジェント制御の実現

自動問題分析エンジンは、インテリジェント制御システム全体の頭脳です。上流の観測から提供される生データを受信し、自動分析と意思決定を実行し、システムが提供する自己修復機能によって処理します。自動化された問題分析エンジンの中心的なアイデア: RD の学生が歴史の中で発生した問題と解決策を見つけることができれば、それらをシステムルールと事後分類に変換できます。そうすれば、次に問題が発生したときに、人間の介入は必要ありません。ルールエンジンの中核となる分析プロセスは 2 段階です。

フェーズ 1 : 従来の構成可能なルールエンジンの構成 (上図の右上隅の黄色の部分)、複数のコレクションインデックス項目の論理関係 (AND または NOT) を構成します。ここでは主に問題の基本的な分析機能が使用されます。、ルールがトリガーされるかどうかを判断します。

フェーズ 2 : この基本的な分析の結果に基づいて、関数実行後の解析が実行されます (これは主に複雑な問題の解析を補足するものです)。最後に、実行エンジンが返された結果に従って関数を実行します。

問題分析エンジンの実行結果は以下のとおりです。

前提条件: 開発者は、処理ロジックルール (およびルールが依存するデータ項目 (必須)) とコールバック関数 (オプション) を構成する必要があります。
データパーサー: データパーサーは主にデータの元の抽出を担当し、次の 3 つのステップに分かれています。

a. 構成分析: 開発者が構成したデータ情報に従ってロジックの実行が分析されます。

b. データ抽出: 解析された構成に従って、データインターフェイスを通じて取得でき、統合インターフェイスからの構成情報に従って、必要な情報をさまざまなメディアから抽出できます。

c. データの正規化: ルールマネージャーが使用できるように、さまざまなメディアの生データを統一データ形式に正規化します。

ルールマネージャー: ルールマネージャーは主にコアロジック分析作業を担当します。この作業は次のステップに分かれています。

a. ルール分析: 開発者が設定したルールロジックに従って、元の設定情報が元のルールツリーに解釈されます。

b. 計算の実行: データパーサーによって提供されるデータ結果と構成された関数ルールに従って、それぞれ計算を実行します。計算プロセスで最も重要なのは、ルール構成を支援する 5 つの基本機能と数十の一般的な論理計算を提供する基本アナライザーです。

c. ルール論理演算：上位層で解析されたルールツリーと各データ項目の計算結果に従って論理演算を実行し、実行結果に従って高度なデータアナライザを実行するかどうかを決定し、判定結果が真の場合、設定に従ってポスト関数が処理されます。

高度なデータアナライザ：図に示すように2つのモードがあり、結果を判断できる単純な基本的な分析については、デフォルトの処理関数をそのまま使用してデータ拡張を行い、正確に表現できない単純な論理ルールについては、開発者がポストをカスタマイズできます。分析機能では、元のデータと基本計算の計算結果をパラメータとして渡し、開発者は処理されたデータを通じて分析ロジックを明確に記述するだけで済みます。
アクションエグゼキューター: アナライザーの実際の実行エンジンであり、ルール操作の結果に含まれるパラメーターに従って動的に調整されます。

インテリジェント制御システムの構築により、月次レベルで数万件の異常トラブルを分析・処理し、自動復旧の割合が全体の95％以上を占め、通常のトラブルの深刻化を防ぎます。

04 結論と展望

この記事全体では、オフラインコンピューティングシステムの開発を主軸としており、遭遇する問題とその解決策が全文にわたって説明されています。特に、現在の新世代アーキテクチャの中核は、データ + 機能を中心とした宣言型設計であり、効率的なコンピューティングエンジンとインテリジェントな設計と組み合わせて、オフラインコンピューティングシステム全体をさらに改善します。実際、過去の多くの問題は設計において解決されてきましたが、依然として不完全な部分があり、もちろん現在の効果は最終的な理想状態には程遠く、いくつかのシステム機能は継続的に磨き上げ、アップグレードする必要があります。

- 終わり -

推奨読書

Dujia編集アプリのMMKVアプリケーション最適化実践

Baidu のエンジニアが解読戦略を分析

Baidu のエンジニアが強力な化学を分析

統合権限管理サービスの設計・開発について語る

Baidu APP iOS 端末パッケージサイズ 50M の最適化演習 (5) HEIC 画像と無駄なクラスの最適化演習

Baidu の垂直型オフラインコンピューティングシステムの開発の歴史

01 関連背景紹介

02 計算機システムの進化過程

03 コンピューティングシステムコア設計のコアアイデアとコアの実装