ビッグデータ運用保守（小米科技のビッグデータ運用保守管理システムの構築と実践）

少し前に、Yunqiカンファレンスに出席し、「 Xiaomiのビッグデータ運用保守管理システムの構築と実践」について皆さんと共有する機会をいただきました。トピックは2つの部分に分かれています。最初の部分では、ビッグデータの運用と保守のデジタル変革に関連する内容について話し、運用と保守レベルを簡素化し、究極の効率を生み出す方法を見ていきます。パート 2 では、Xiaomi のビッグ データの技術的アーキテクチャを紹介し、Xiaomi が大量データの課題にどのように対処しているかを理解していただきます。

サービスの位置付け

皆様の理解を助けるために、まずは Xiaomi サービスのアーキテクチャについて簡単に説明しましょう。ビジネスアーキテクチャ全体は、クラウド コンピューティングの階層化モデルに従って、Iass 層、Pass 層、Sass 層の 3 つの層に分かれています。 Xiaomi のインフラストラクチャレイヤーは、 IDC、パブリック クラウド、ネットワーク、その他のリソースを含むハイブリッド クラウドです。 Xiaomi の SaaS 層には、携帯電話 * IOT * 自動車などの戦略的事業だけでなく、インターネットや電子商取引など数百の事業ラインも含まれます。パス層のメンバーとして、ビッグデータは下位の基本リソースに接続し、上位のビジネスのデータニーズを満たし、オフラインレポートやリアルタイムデータウェアハウスなどのさまざまなシナリオベースの機能を提供し、ビジネスがデータ資産を蓄積し、全体的なデータ効率を向上させるのに役立ちます。同時に、ビッグデータはグループのデジタル基盤であり、極めて重要な役割を果たしています。

ビッグデータサービスアーキテクチャ

Xiaomi のビッグデータ サービス全体は x86 と ecs に基づいており、下から上にデータ収集層、データ ストレージ層、データ コンピューティング層、データ プラットフォーム層の 4 つの層に分かれています。

• データ収集層: 主に、独自開発の LCS と Talos に代表されるメッセージ キューの組み合わせを使用して実装されます。この部分については、次の共有でも詳しく説明します。

• データ ストレージ層: ファイル ストレージ HDFS、KV ストレージ HBase、オブジェクト ストレージ Ceph など、さまざまなオープン ソースおよび自社開発のストレージ エンジン。このうち、Pegasus は Xiaomi が独自に開発し、現在は Apache でオープンソース化されています。

• データ コンピューティング レイヤー: Xiaomi は、Yarn を統合リソース管理プラットフォームとして使用し、一般的な MapReduce、Spark、Flink など、Yarn に基づくさまざまなバッチ処理およびストリーム処理コンピューティング エンジンを提供します。さらに、アドホック クエリと検索のニーズを満たす豊富な Olap エンジンも提供します。

• データプラットフォーム層: 社内ではデータファクトリーと呼んでおり、主にワンストップのデータ開発とデータ管理機能を提供します。

Xiaomi のビッグデータ事業は急速に発展しており、国内外の複数の地域をカバーしています。現在では、1,000 を超えるクラスターと数万のノードの規模に達し、総ストレージ容量はほぼ EB に達し、1 日あたり 300,000 件のコンピューティング タスクが実行されます。

ビッグデータの運用と保守の変革の課題

このような大規模なデータ規模は、サービスの運用と保守に多くの課題をもたらします。次に、それらについて詳しくお話ししましょう。

• 高い運用および保守コスト: 従来の運用および保守ソリューションとサービスの急速な発展との間の摩擦が増加し、運用および保守コストのエントロピーが増加し、品質、コスト、効率に反映されます。
• サービスライフサイクルのギャップ: ビッグデータサービスのシナリオは数多くあり、大きく異なるため、運用と保守の複雑さがさらに増しています。
• データサイロにより最適なデータ効率の実現が困難になる
• 運用保守レベルは経験に基づくシングルコア方式で開発されており、多くのプロセスを実装することが困難です。

問題を特定した後、私たちは徹底的な社内議論を行い、Xiaomi が長年ハイブリッド クラウドに取り組んできたことを考慮して、ビッグ データ運用保守プラットフォームである Qingzhou の全体計画を開始しました。 Qingzhou の主な方針は、共通のベースライン機能を構築し、究極の垂直機能を作成することで、サービスのライフサイクルを徹底的に接続することです。

青州の全体的な能力構造は、2つの能力+3つのセンターです。

• ベースライン機能レイヤーには、データ マートとパブリッシング センターが含まれており、運用および保守管理システム全体の基盤となります。

  
  

• 垂直機能レイヤーは、サービスの作成、運用から消滅まで、サービスのライフサイクル全体にわたって実行されます。運用は、サービスアップグレード、機械管理、検査管理など、私たちの日常業務の中で最も時間と労力がかかる部分です。

  
  

データアイランド問題を解決するために、私たちはデータ統合とアーキテクチャの分離というソリューションを採用しています。ビッグデータ向けの統合運用・保守データマートを構築することで、運用・保守に関わるすべてのデータが統合され、データソースとデータユーザー間の分離レイヤーが作成されます。データマート層では、運用・保守データをモデル化し階層的に処理するためのデータ仕様を開発しました。最後に、既存のデータ ソースに対して ETL スケジューリングが実行され、最終的に統合されたデータの保存と使用が実現されます。

新しいデータ アーキテクチャは、運用と保守のデータ システムを統合し、データ サイロの問題を解決するとともに、データ使用のハードルを下げます。現在、データシステム全体がすべてのビッグデータサービスに適用され、真の統一されたデータ管理を実現しています。さらに、データ シナリオ全体が閉ループになり、複雑さが O(n^2) から O(n) に変わり、コア データ分析ロジックが再利用可能になります。新しいデータ アーキテクチャ全体は、以前の人中心のアプローチに代わる、データ シナリオ中心になっています。

青州リリースセンター

Qingzhou の出版センターでは、スケジュール オーケストレーション + ローコード モードを使用して、ワークフローを柔軟に定義しています。同時に、テンプレートを活用してSOP を統合し、個人の経験を組織の能力に変換します。次の図は、パブリッシング センターのワークフロー テンプレートです。実行システムとカスタム スクリプトを操作プールに抽象化します。スケジューリング オーケストレーションでは、単一実行領域、ループ領域、非同期実行領域など、さまざまな論理領域が定義されます。

現在、セット全体が徐々にすべてのビッグデータ サービスに拡張されており、一部のシナリオでは無人変更が実現され、効率が 30% 向上しています。リリース センター全体は、既存の基盤に基づいて引き続き最適化および反復され、グローバルな相互接続が構築され、最終的には完全なプロセス自動化が実現されます。

オペレーション センターでは、データとハイブリッド オペレーションの概念を組み合わせて、コラボレーション、サービスの差別化、エクスペリエンスなど、複数の主要な問題点の解決に重点を置いています。現時点では、全体的な効果はまだ良好です。例えば、機械の故障処理の全プロセスが自動化され、ビッグデータサービスの 95%をカバーし、自動処理される機械の故障の年間平均件数は 10,000 回近くに達しています。容量管理では、データの傾向を分析することで、あらゆるシナリオを網羅した容量検出を実行し、大量の手動介入を削減できます。検査管理では、リスクの定量的なスコアリングを通じて、検査基準と処理手順がさらに強化されます。

さらに、環境管理と構成管理もあります。現在、オペレーションセンター全体はまだ建設と改善の途中です。

コアデータリンク

次は第2部、ビッグデータのアーキテクチャ実践です。

Xiaomi のコア データ リンクは、メッセージ キューと Talos+ アクセス ダンプの組み合わせであり、エンドツーエンドのデータ接続を実現するためのデータ バスとして機能します。あらゆる種類の生データは、エージェント収集方法を通じてメッセージ キューに入り、バイナリ ログ ベースのストックおよび増分収集もサポートされます。ダンプ レイヤーでは、データは通常、統合転送モジュールを介して他のビッグ データ ストレージ エンジンに転送され、さらに使用されます。

現在、Xiaomi のデータの半分以上がこのソリューションを通じてアクセスされています。プロセス全体が製品化のために設計されており、ユーザーはプラットフォームに基づいてデータリンクを自由に定義できます。

リアルタイム + オフライン レイク ウェアハウス アーキテクチャ

データ ウェアハウスの分野では、Xiaomi は Hadoop に基づくオフライン データ ウェアハウス、Kappa リアルタイム データ ウェアハウス、Lambda アーキテクチャ データ ウェアハウスのプロセスも経てきました。最新のデータ ウェアハウス システムは、データ レイク iceberg + flink + spark をベースに構築されたオフライン + リアルタイム データ ウェアハウスです。前述のように、データは MQ を通過して最終的にデータ レイクに入ります。 ETL は、Spark または Flink を介してデータ ウェアハウスの各レイヤー間に構築されます。

同時に、Xiaomi の OLAP エンジンは、レイク内のデータを直接クエリできるように変更されました。ソリューション全体のパフォーマンスは良好で、従来のアーキテクチャよりも複雑さが少なくなっています。データ ウェアハウス ストレージ層の統合と ztsd 圧縮アルゴリズムのアップグレードにより、ストレージも大幅に最適化されています。

HDFS 階層化: ホット データとコールド データの階層化

前述のデータ レイク氷山の基盤​​も HDFS に基づいています。ここでは、HDFS のデータ アーキテクチャの実践について説明します。

一般的な業界の実装では、データ階層化を実現するために、ソリッド ステート ドライブ、機械式ディスク、高密度ストレージが使用されます。 Xiaomi の社内実装では、コストをさらに削減するために、コールド データをクラウド上で直接管理する独自の HDFS Tering アーキテクチャを開発しました。

下の図は全体的なアーキテクチャ図です。バックグラウンドで HDFS コールド データを Alibaba Cloud OSS に自動的にダンプするムーバー プログラムが動作していることがわかります。次に、Namenode のメタデータが更新され、ファイル属性からブロック、オブジェクトへの変更が実装されます。同時に、ユーザーに対して透過的であり、proxydn モジュールがアーキテクチャに追加されます。

現在、ソリューション全体で 200PB を超えるコールド バックアップ データが蓄積されており、データ コストが 80% 以上削減されています。

リンドルムの紹介

リンドルム入門（I）

Xiaomi の IoT 戦略をサポートし、ビジネスの膨大なデータのインデックス作成とトランザクションのニーズを解決するためです。 Xiaomi の歴史は、社内で SDS と呼んでいる HBase コプロセッサをカプセル化して実装した自社開発のストレージに基づいています。

しかし、データ規模が拡大し続けるにつれて、範囲ベースのシャーディング、フェイルオーバー時間の遅延、複数の依存リンクなど、多くのアーキテクチャ上の問題が明らかになりました。同時に、ビジネスの時系列データ要件をサポートすることはできません。さらに、SDS の開発および保守コストも非常に高くなります。

選択の結果、Alibaba Cloud の Lindorm が当社のニーズにぴったり合うことがわかりました。図に示すように、 LindormはHBaseやHadoopなどのプロトコルと互換性があり、幅広いテーブルエンジンのほか、時系列などの複数のエンジンも提供しています。

同時に、マルチレベルハイブリッドストレージやサーバーレスなどの複数の機能を組み合わせることで、多くの従来の問題を解決できます。 Xiaomi の内部テストの結果、パフォーマンスは非常に良好で、全体的なニーズを満たしています。

この図は、全体的な移行アーキテクチャを示しています。 IDC からクラウドへの 100G ネットワーク リンクを開設しました。

サービスレベルでは、SDS と Lindorm の間でデータ同期リンクが事前に確立され、SDS と Lindorm の両方に最新のデータが確保されます。

ビジネス変更のコストを最小限に抑えるために、SDS プロキシ コンポーネントが提供され、データを lindorm にプロキシし、最終的にビジネスの移行を実現します。

ビッグデータイベントクラウドマップ

著者について:

Xiaomi のビッグデータ運用マネージャー/SRE エキスパートである Liu Zhijie 氏は、Baidu や通信会社で勤務し、ビッグデータ、運用エンジニアリング、データベースの実践において豊富な経験を持っています。