Li Auto x JuiceFS: Hadoop からクラウドネイティブへの進化と考え方

Hadoop 時代の理想的な自動車の技術アーキテクチャ

まず、ビッグデータ技術の発展を簡単に振り返ると、私の個人的な理解に基づいて、ビッグデータの発展は次の 4 つの時期に分けられます。

第1期：2006年～2008年。Hadoop は 2008 年頃に Apache のトッププロジェクトとなり、正式にバージョン 1.0 をリリースしましたが、その基盤は主に Google の troika、GFS、MapReduce、BigTable に基づいて定義されています。

第二期：2009年から2013年。Yahoo、Alibaba、Facebook などの企業は、ますますビッグデータを使用しています。2013 年末、Hadoop は正式にバージョン 2.0 をリリースしました。2012年に幸運にもビッグデータに触れ、Hadoop 1.0とHiveでそれを体験した時、ビックデータはSQL ServerやMySQLでは解けなかった問題を数台のマシンで素早く解いてくれるという驚きを感じました。 .

第 3 段階: 2014 年から 2019 年までのこの期間の開発は非常に速く、その間に Spark と Flink がトップの Apache プロジェクトになりました。この急速な上昇期には、Storm も使用しようとしましたが、これは後に Flink に置き換えられました。

第 4 段階: 2020 年から現在まで、Hudi が Apache を卒業し、2020 年にトップレベルのプロジェクトになった後、データレイクは開発全体の成熟段階に入り、データレイク 2.0 段階に達したことを個人的に理解しています。ビッグデータの。データレイクには 3 つの主な特徴があります。1 つ目は統合されたオープンストレージ、2 つ目はオープンフォーマット、豊富なコンピューティングエンジンです。

全体的な開発プロセスにおいて、ビッグデータには主にいくつかの特徴があります。それは、誰もがよく口にする 4 つの「V」である、量、速度、多様性、および価値です。5 番目の「V」（真実性）は、データの正確さと信頼性です。データの品質は常に批判されてきました.データレイクの品質を改善するための一連の標準が業界に存在することを願っています.これは、データレイク2.0の出現の標準になる可能性があります.HudiやIceberg はすべて、データレイク全体の品質を向上させることを目的としており、データレイクの管理は適切に行われています。

個人的にはHadoopはビッグデータの代名詞だと思っていますが、ビッグデータはHadoopだけではありません。ビッグデータは、開発プロセス中に複数のコンポーネントを統合した後に形成される大量のデータを処理および使用するための一連のソリューションです。ここ数年、誰もが基本的に Hadoop は下り坂にあると考えています.まず、Hadoop の商業化企業である Cloudera と Hortonworks の合併と上場廃止、元のビジネスモデルが継続できなくなったこと、ユーザビリティの課題、Hadoop エコシステム自体の複雑性の増大などです。

理想的な自動車ビッグデータプラットフォームの現在のアーキテクチャ

この段階で、Li Auto のビッグデータプラットフォームは上の図に示されています。Ideal Car は、多くのオープンソースコンポーネントを使用しています。

トランスポート層: Kafka と Pulsar。Kafka はプラットフォーム構築の初期段階で全体として使用されました. Kafka のクラウドネイティブ機能は比較的貧弱です. Pulsar は設計の初期段階でクラウドネイティブアーキテクチャに従って設計されており、IoT に非常に適した機能をいくつか備えています.当社のビジネスシーンにもマッチするので、先日パルサーを導入しました。
ストレージ層は HDFS + JuiceFS です。
コンピューティングレイヤーの現在の主要なコンピューティングエンジンは Spark と Flink であり、これらのコンピューティングエンジンは現在の Yarn で実行されています。3 つのコンピューティングエンジンは、WeBank によってオープンソース化された Apache Linkis によって管理されており、現在は Linkis を多用しています。
右側に3つのデータベースがあります.最初のMatrixDBは時系列データベースの商用版です.TiDBは主にOLTPとOLAPの混合シナリオで使用されています.現在,主にTPシナリオで使用しています. StarRocks は OLAP シナリオを担当しています。
ShardingSphere は、Database Plus のコンセプトを使用して、ゲートウェイレベルの管理のために基盤となるデータベースを統合したいと考えています。まだ探索段階にあり、私たちが非常に興味を持っている新機能がたくさんあります。
右側の Thanos はクラウドネイティブの監視ソリューションで、コンポーネント、エンジン、マシンの監視を Thanos ソリューションに統合しました。
アプリケーション層は、データアプリケーション、データ開発、データ統合、データガバナンスを含む現在の 4 つの主要なミドルエンド製品です。

特徴

ビッグデータプラットフォームの現状から、いくつかの特徴を見つけることができます。

まず、ソリューション全体には多くのコンポーネントがあり、ユーザーはこれらのコンポーネントに強く依存しており、コンポーネント間の相互依存も比較的強いです。今後コンポーネントを選択する際は、より成熟したクラウドネイティブコンポーネントを選択することをお勧めします。
第二に、データには明確な山と谷があります。旅行シーンは概ね朝のピークと夕方のピークで、土日は人が多くなります。
3 つ目の特徴は、基本的にデータの人気が最も高く、通常は過去数日または先週のデータのみにアクセスすることです。ただし、大量のデータが生成され、場合によっては大量のバックトラックが必要になることもあり、データも長期間保存する必要があるため、データの使用率ははるかに悪くなります。

最後に、現在、データシステム全体には、ファイルレベルでの効果的な管理方法がいくつかありません。構築から現在に至るまで、基本的には HDFS をベースとしており、大量の無駄なデータが存在し、リソースの浪費につながっており、早急に解決しなければならない問題です。

ビッグデータプラットフォームの問題点

第 1 に、多くのコンポーネントがあり、導入が困難で非効率的です。Hadoop には 30 以上のビッグデータコンポーネントがあり、一般的に使用されるものは 10 以上あります。一部のコンポーネント間には強い依存関係と弱い依存関係があり、統合された構成と管理は非常に複雑になります。
第二に、機械のコストとメンテナンスのコストが比較的高いです。ビジネスの安定運用のために、オフラインクラスターとリアルタイムクラスターを別々にデプロイします。しかし、上記のような事業特性から、当社の事業は山あり谷ありであり、全体の稼働率は高くありません。多数のクラスタコンポーネントを管理および保守するには、専門の担当者が必要です。
3 つ目は、クロスプラットフォームのデータ共有機能です。現在、クラスター間で共有されるデータは、DistCp を介して他の Hadoop クラスターにのみ同期できます。他のプラットフォームやサーバーと簡単かつ迅速に同期することはできません。
4 つ目は、データセキュリティとプライバシーのコンプライアンスです。さまざまなデータセキュリティ要件に基づいて、通常のユーザーは Ranger を介して管理されます。特別なセキュリティ要件は、異なるクラスターを構築し、個別の VPC ポリシーを設定することによってのみ満たすことができます。その結果、多くのデータアイランドとメンテナンスコストが発生します。

理想のカークラウドネイティブの進化と考え方

まず、クラウドネイティブに関する私の個人的な理解を簡単に共有させてください。

まず、クラウドネイティブはクラウドコンピューティングから派生したものです。現在、誰もが Alibaba Cloud、AWS、Tencent Cloud、Baidu Cloud などのクラウドベンダーを使用しており、最初は IaaS レイヤーで技術サービスを提供し、企業がストレージ、コンピューティング、ネットワークなどの最も基本的なものをパッケージ化して統合管理できるようにしています。その上でサーバーを申請するだけです。サーバーを申請した後も、これらのサーバーは引き続きクラウドベンダーによって管理されます。これは、当社の従来のクラウド運用です。

クラウドネイティブはクラウドコンピューティングと切り離すことはできません. 一般的に言えば、クラウドネイティブはクラウドコンピューティングの PaaS 層サービスに属し、主に開発者向けのアプリケーションの一種です. クラウドネイティブはクラウド上にインストールする必要があり、クラウドベースのソフトウェア開発およびアプリケーション方法です。クラウド + ネイティブ、クラウドはクラウドコンピューティング、ネイティブは従来の運用と保守の開発フレームワークを放棄し、コンテナ化、DevOps、およびマイクロサービスアーキテクチャを通じて、アプリケーションの柔軟なスケーリングと自動展開を実現し、クラウドコンピューティングリソースを最大限に活用して達成します最小のスペースで最大のことを行います。また、スケーラビリティや保守性が低く、多くの人手と時間が必要であるなど、現在のビッグデータシステムのいくつかの問題点を解決することもできます。

上の図は、クラウドネイティブのいくつかの時点を簡単に示しています。

最初の段階で AWS はクラウドネイティブの概念を提案し、2006 年に EC2 を開始しました。この段階がサーバー段階、前述のクラウドコンピューティング段階です。
2 番目の段階であるクラウド化段階は、主にオープンソースの Docker と Google のオープンソースの Kubernetes のリリース後です。Kubernetes は、コンテナ化されたアプリケーションとサービスを管理するための軽量で拡張可能なオープンソースプラットフォームです。アプリケーションの自動展開とスケーリングは、Kubernetes を通じて実行できます。
第 3 段階では、CNCF Foundation が 2015 年に設立され、クラウドネイティブの概念を促進し、クラウドネイティブの開発全体を支援しています。最後は Knative のオープンソースです. Knative の非常に重要な目標は、クラウドネイティブでクロスプラットフォームのサーバーレスオーケストレーション標準を開発することです。現在に至ると、すでにクラウドネイティブ2.0の段階、つまりサーバーレスの段階です。個人的には、ビッグデータの開発もサーバーレスの方向に進むべきだと理解しています。たとえば、AWS のオンラインサービス全体は基本的にサーバーレスです。

ビッグデータクラウドネイティブアーキテクチャ

次に、クラウドネイティブ化後の理想的な自動車ビッグデータプラットフォームのコンポーネントの変化を紹介します。

ストレージ層では、クラウドネイティブ化後のストレージは基本的にすべてオブジェクトストレージです。上記のアーキテクチャ図は Lustre につながります。Lustre については以下で詳しく説明します。「クラウドストレージ」レイヤーは、主にJuiceFSを使用してオブジェクトストレージとLustre並列分散ファイルシステムを管理することが理解できます（注：Lustreのシングルコピーの問題により、現在、クラウドサービスプロバイダー製品が提供する並列ファイルシステムの使用を検討しています）。
主にコンピューティング、ストレージ、およびネットワークの上にあるコンテナー層はすべて、Kubernetes と Docker に置き換えられ、すべてのコンポーネントがその上で成長します。
コンポーネント部分については、最初はビッグデータコンピューティングフレームワークです.Hive を放棄し、Spark と Flink を直接使用し、Hudi を Data Lake 2.0 の基盤となる機能サポートとして使用し、HDFS を徐々に置き換えます。
ミドルウェアの部分では、Pulsar 以外に Kafka がありますが、現時点では Kafka のクラウドネイティブ化があまり進んでいないので、個人的には Kafka を Pulsar に置き換えることを好みます。現在、すべての Spark エンジンを適応させるために Linkis がオンラインで使用されており、Flink は後で適応および統合される予定です。ShardingSphere は、バージョン 5.1.2 でクラウドネイティブをサポートしたばかりであり、シナリオの検証と機能の探索を計画どおりに実行します。
データベースレイヤーは引き続き TiDB、StarRocks、および MatrixDB です. 現在、これら 3 つのデータベースは既にクラウドネイティブ機能を備えており、すべてオブジェクトストレージをサポートしています. しかし、この部分は個別にテストされておらず、まだ物理マシンを使用しています. データベースの場合、現在のオブジェクトストレージによって提供される IO 機能は、データベースのパフォーマンス要件を満たすことができず、データベースの全体的なパフォーマンスが大幅に低下するためです。
運用と保守に関しては、主にクラウドネイティブのログ収集のために、追加の Loki が Thanos ソリューションに追加されます。しかし、Loki と Thanos はそのうちの 2 つに過ぎません. 将来的には、Ali のオープンソース SREWorks 機能と連携し、包括的な運用と保守機能で全体の品質、コスト効率、およびセキュリティを封印することを理解しています.クラウドネイティブ管理スタンドアップで管理できます。
オブザーバビリティは、クラウドネイティブの分野で最近人気のある概念です。誰もが今作っているコンポーネントの中には、人気が出てからクラウドネイティブに開発され始めているものもあります. それらは最初はクラウド上で生まれていませんが、後でクラウド上で成長することを望んでいます. この場合、いくつかの問題が発生します. 最初の問題は、包括的な可視性監視がないことです. 今後、これらのコンポーネント全体の計画をどのように策定するかを検討し、クラウドネイティブになった後にすべてのコンポーネントを効果的に監視できるようにします。

要約すると、私は個人的に、ビッグデータの将来のクラウドネイティブは基本的に次のようになると考えています。

すべてのコンポーネント (データベースを含む) の基盤となるストレージとしてクラウドネイティブストレージを統合して使用
すべてのコンポーネントはコンテナーで実行されます
サーバーレスアーキテクチャを使用して上位層のアプリケーションにサービスを提供する

しかし、これは現在のデータプラットフォーム製品、つまり、ユーザーが使用できるサーバーレス機能を備えた製品をどのように設計するかという課題ももたらします。

ビッグデータクラウドネイティブの利点

1つ目のポイントは、記憶と計算の分離と、弾性的な伸縮です。物理マシンを利用してHadoopを導入した後、容量の拡張や縮小が必要な場合はオペレーターに連絡する必要があり、サイクルが長くなる可能性がありますが、ストレージと計算を分離することで、この問題をうまく解決できます。2 つ目は、遊休リソースを購入しない従量制です. 現在、ビジネスシナリオ全体のデータには山と谷があります. ピークの場合はマシンを準備する必要があり、谷の場合はマシンを撤去する必要がありますが、これは現在不可能です。今は基本的にすべてのマシンをピークに積み上げます. ピーク時には需要を満たすことができ, 故障することなく安定しています. しかし, 谷間では少なくとも 12 時間アイドル状態になります. この場合, リソースも課金されます. クラウドネイティブの後は、もう料金を支払う必要はありません。

2点目は導入の自動化と運用性です。Kubernetes は、DevOps 統合デプロイソリューションをサポートしています。このように、コンポーネント全体を迅速に展開でき (たとえば、Helm チャートを介して)、コンポーネントの運用および保守機能はクラウドネイティブプラットフォームに下げられるため、ビッグデータはコンポーネントの運用および保守を考慮する必要がありません。シナリオ。

3点目はオブジェクトストレージです。オブジェクトストレージは、クラウドコンピューティングによって開始されたコアで最も重要な製品です。オブジェクトストレージの利点は、自明であり、拡張が容易で、ストレージスペースが無制限であり、単価が比較的低いことです。また、オブジェクトストレージは、低頻度ストレージ、アーカイブストレージ、およびその他のストレージタイプに分割され、ストレージコストをさらに削減し、データをより長期間保存されます。同時に、制御可能なコスト、高い信頼性、低い操作の複雑さもオブジェクトストレージの利点です。

4点目は、セキュリティとコンプライアンスです。クラウドネイティブの後、専用の名前空間、マルチテナント分離、およびリモート認証を実現できます。現在、私たちが達成したのは基本的にネットワークレベルでの分離です. HDFS ファイル管理のソリューションとして広く認知されているのは Ranger です. Ranger を使用して HDFS ディレクトリのアクセス許可を管理すると、Hive サーバー、HBase、Kafka などの一部のアクセス許可も管理できますが、これらのアクセス許可は比較的弱いものです。

もう 1 つのソリューションは Kerberos です. ビッグデータコンポーネント全体のセキュリティは大幅に向上しますが、多くのコストがかかり、すべての要求を検証する必要があります. これまでこのソリューションを使用したことがなく、これはクラスター環境とシナリオに関係しており、基本的にイントラネット上にあり、外部サービスは提供していません。ビッグデータプロジェクトで外部ネットワークにサービスを提供する必要がある場合でも、強力な認証が必要です。そうしないと、データが簡単に漏洩してしまいます。

クラウドネイティブなビッグデータの難しさ

ビッグデータクラウドネイティブの難しさも存在します。

まず、ビッグデータに関連する多くのコンポーネントがあります.同時に、Kubernetesの更新は比較的高速です.コンポーネントが交差した後、互換性、複雑さ、およびスケーラビリティに問題が発生します.

第二に、リソースの割り当てと再割り当てです。Kubernetes は汎用コンテナーリソーススケジューリングツールであり、さまざまなビッグデータコンポーネントのリソース使用シナリオを満たすことは困難です。ビッグデータのシナリオでは、リソースの使用量が比較的多く、リクエストの頻度が高く、毎回のポッドの数が比較的多くなります.この場合、現在、適切な解決策はありません. 現在、Fluid のソリューションを検討しています. Fluid は JuiceFS のランタイムも実装しています. これについては後で調査します. Fluid は現在、AI シナリオだけでなく、ビッグデータと AI をサポートできると主張しています。 Fluid は、コンピューティング効率とデータ抽象化管理においていくつかのブレークスルーを実現しました。

第 3 に、オブジェクトストレージにはいくつかの欠点もあります。オブジェクトストレージの欠点は、メタデータ操作のパフォーマンスが低いこと、ビッグデータコンポーネントとの互換性が低いこと、および結果整合性です。

最後のポイントは、データ集約型アプリケーションです。ストレージコンピューティング分離モードは、コンピューティング操作の効率とデータ抽象化管理の観点から、ビッグデータや AI などのデータ集約型アプリケーションの要件を満たすことができません。

ビッグデータクラウドネイティブソリューションにおける JuiceFS の探索と実装

JuiceFSのオープンソース化前に注目し、着地テストを行ってきましたが、オープンソース版がローンチされた後、すぐに使用する予定です。オンラインになったとき、いくつかの権限の問題といくつかの小さなバグに遭遇しました. コミュニティは非常に協力的で、迅速に解決するのに役立ちました.

HDFS はスケーラビリティが低いためにオフラインになりつつありますが、同時に、データ量が比較的大きく、HDFS のストレージコストが比較的高くなります。いくつかのバッチのデータを保存した後、物理マシンのスペースが不足し、多くの計算が必要になります。当時、私たちのビジネス開発はまだ初期段階にあり、データからできるだけ多くの価値を引き出すために、できるだけ多くのデータを保持したいと考えていました。また、HDFS には 3 つのコピーが必要でした。後で 2 つのコピーに変更しましたが、2 つのコピーは依然として危険です。

これに基づいて、JuiceFS を詳細にテストし、テストが完了した後、すぐに JuiceFS をオンライン環境に導入しました。いくつかの比較的大きなテーブルを HDFS から JuiceFS に移行することで、緊急の必要性が解消されました。

私たちは JuiceFS の 3 つのポイントを重視しています。

まず、JuiceFS はマルチプロトコルに対応しています。POSIX、HDFS、および S3 プロトコルと完全に互換性があり、現在の使用では問題なく 100% 互換性があります。
第二に、雲を越える能力。企業がある程度の規模を持っている場合、システミックリスクを回避するために、1 つのクラウドサービスプロバイダーだけを使用することはありません。1 つのクラウドに縛られるのではなく、すべてマルチクラウドで運用されます。この場合、クラウド間でデータを同期する JuiceFS の機能が役割を果たします。
3 つ目は、クラウドネイティブシナリオです。JuiceFS は CSI をサポートしています. 現在、このシナリオでは CSI を使用していません. 基本的には POSIX を使用してマウントしていますが、CSI を使用すると、より簡単で互換性が高くなります. また、現在クラウドネイティブに向けて開発していますが、コンポーネント全体は実際には使用していません.まだ Kubernetes に到達していません。

理想の車への JuiceFS の適用

HDFS からオブジェクトストレージへのデータの永続化

JuiceFS がオープンソース化された後、HDFS 上のデータを JuiceFS に同期する試みを開始しました。同期の最初は DistCp を使用しましたが、JuiceFS の Hadoop SDK と同期するのは非常に便利で、全体的な移行は比較的スムーズです。HDFS から JuiceFS にデータを移行する理由は、いくつかの問題のためです。

1 つ目は、HDFS のストレージとコンピューティングの結合設計はスケーラビリティが低く、この問題を解決する方法がないことです。ビッグデータを最初から個人的に理解していたのは、ビッグデータはクラウドホストではなく、物理マシンにデプロイする必要があるということです。その後クラウドベンダーが立ち上げたさまざまなEMRシステムも含めて、実際にはHadoopをカプセル化しており、ここ1、2年でこれらのEMRシステムは徐々にde-Hadoop化されています。

2 つ目は、HDFS がクラウドネイティブ化に適応しにくいことです。現在の HDFS は比較的重いため、クラウドネイティブに適応するのが難しく、コミュニティはクラウドネイティブに焦点を当てていますが、個人的には Hadoop の開発トレンドは下り坂にあり、将来はオブジェクトストレージをベースにする必要があると思います。

第三に, オブジェクトストレージにもいくつかの欠点があります. HDFS API にうまく適応できません. ネットワークやその他の理由により, パフォーマンスもローカルディスクのパフォーマンスとは大きく異なります. さらに, リストディレクトリなどのメタデータ操作も非常に困難です.遅い。JuiceFS を使用して一部の高速化を行い、測定されたパフォーマンスは非常に印象的です.キャッシュの場合、基本的にローカルディスクに匹敵します.これに基づいて、現在のシーンを直接 JuiceFS にすばやく切り替えます.

プラットフォームレベルのファイル共有

2 番目のシナリオは、プラットフォームレベルでのファイル共有です。現在のスケジューリングシステム、リアルタイムシステム、および開発プラットフォームの共有ファイルデータはすべて HDFS に保存されていますが、後で HDFS を使用しなくなった場合、これらのデータを移行する必要があります。現在の解決策は、JuiceFS を使用してオブジェクトストレージに接続することです.アプリケーション層のサービスを通じて、それらはすべて POSIX モードでマウントされ、誰もが感じずに JuiceFS 内のファイルを要求できます。

JuiceFS は、このシナリオでのアプリケーション要件のほとんどを満たしていますが、まだ問題のある小さなシナリオがいくつかあります。当初はPython環境などを全部入れようと思っていたのですが、後で調べてみると、Python環境は小さいファイルがたくさんあり、読み込みにまだ問題があり、実際の操作は難しすぎることがわかりました。多数の断片化されたファイルを含む Python 環境のようなシナリオでは、操作のためにローカルディスクに保存する必要があります。将来的には、これを行うために特別にブロックストレージを使用する予定です。

以前に HDFS で遭遇したいくつかの問題を共有します。

まず、NameNode に大きな負荷がかかっている場合やフル GC の場合、ダウンロードに失敗しますが、現時点では完全な解決策はありません。私たちの解決策は、可能な限りメモリを増やすか、パッケージをダウンロードするときにリトライを追加してピーク時間を回避することですが、この場合、HDFS の問題を完全に解決することは困難です。と GC シーンを回避する方法はありません。

次に、システム間で HDFS を使用する場合、たとえば 2 つのクラスターがある場合、1 つのクラスターを使用してファイルを共有するのは基本的に非現実的です。セキュリティを保証する方法はありません。現在、基本的には、独自の共有ファイルを個別に維持する 2 つのクラスターがあります。現在、リアルタイムプラットフォーム (Flink プラットフォームなど) は JuiceFS に切り替えられていますが、依然として非常にスムーズで、問題は発生していません。

第 3 に、現在、多数の物理マシンを展開していますが、そのすべてが単一クラスターであり、災害復旧戦略がありません.コンピュータールームで壊滅的な問題が発生した場合、サービス全体が利用できなくなります. しかし、オブジェクトストレージ自体は複数のコンピュータールームにまたがっており、同じリージョン内に少なくとも 3 つのコピーが存在する必要があります。クラウドベンダーがバックアップを支援してくれます。将来的には、JuiceFS を使用していくつかの高レベルのファイル、いくつかのコアバックアップファイルを含むコアデータベースを共有し、複数のクラウドでバックアップを作成することを期待して、複数のクラウドを開発する可能性があります。このようにして、マルチクラウド、マルチリージョン、マルチリージョンが実現され、シングルポイントディザスタリカバリの問題を解決できます。

大量のデータをクロスプラットフォームで使用

別のシナリオでは、すべてのプラットフォームが JuiceFS を通じて大量のデータを共有します。私たちの側の最初のタイプの共有データはロードテストデータです.ロードテスト用にアップロードされた大量のビデオ、オーディオ、画像データがあります.アップロード後、これらのデータは直接 JuiceFS に入力されます.これは、ダウンストリームがいくつかのことを行うのに便利です同期と共有. いくつかのデータスクリーニングを含めて、PFS は、SSD がマウントされている並列ファイルシステムです。オブジェクトのストレージ容量が比較的弱いため、GPU の使用率が高くなる可能性があります。そうしないと、GPU の容量が大幅に浪費されます。

残りのデータタイプには、分析のために車両によって報告されたいくつかのログ、埋没点データ、および一部の国のプラットフォームで必要とされる車両関連の信号データが含まれます.これらのデータは、いくつかの分析のためにデータウェアハウスに入力されます. また、これらのデータの特徴データ抽出、アルゴリズムチーム向けのモデルトレーニング、NLP 検索などのシナリオも行います。

クラウドネイティブストレージアクセラレーション - 読み取りキャッシュとしての光沢 (テスト中)

現在、オブジェクトストレージレイヤーに Lustre を掛けて JuiceFS の読み取りキャッシュとして機能させ、Lustre のキャッシュを使用して JuiceFS が読み取り速度とキャッシュヒット率を向上させるという別のシナリオをテストしています。

これの利点の 1 つは、現在、データのキャッシュに使用できる物理ディスクを備えた物理マシンを使用していることです。ただし、計算タスクは複数のノードで実行されるため、キャッシュヒット率はあまり高くありません。これは、JuiceFS のコミュニティバージョンがまだ P2P 分散キャッシングをサポートしておらず、単一ノードのローカルキャッシングのみをサポートしており、各ノードが大量のデータを読み取る可能性があるためです。この場合、キャッシュが一定量のディスク領域を占有するため、コンピューティングノードでもディスクプレッシャが発生します。

現在の解決策は、Lustre を JuiceFS の読み取りキャッシュとして使用することです。具体的には、キャッシュするデータのサイズに合わせて、容量20～30TB程度のLustreファイルシステムをローカル計算ノードにマウントし、このLustreマウントポイントをJuiceFSのキャッシュディレクトリとして利用します。この場合、JuiceFS はデータを読み取った後、非同期で Lustre にキャッシュできます。このソリューションは、キャッシュヒット率が低いという問題を効果的に解決し、読み取りパフォーマンスを大幅に向上させることができます。

Spark シナリオでオブジェクトストレージに直接データを書き込むと、帯域幅と QPS の制限があります. 書き込みが遅すぎると、上流のタスクがジッタする可能性があります. この場合、JuiceFS の書き込みキャッシュ機能を使用できます. データの書き込み最初に Lustre に書き込み、次に非同期でオブジェクトストレージに書き込む場合、このソリューションはいくつかのシナリオに適用できます。しかし、Lustre はクラウドネイティブソリューションではなく、ユーザーに認識されており、ユーザーは Pod の起動時にマウントするコマンドを明示的に記述する必要があるという問題があります。したがって、ユーザーが Lustre の存在を認識する必要がないように、将来的に JuiceFS にいくつかの変更を加え、オブジェクトストレージと Lustre を自動的に識別し、いくつかのキャッシュメカニズムを自動的に実装したいと考えています。

現在、このソリューションのPoCは完了し、基本的なテストに合格しています.次に、本番環境で多くの圧力テストを行います.一部のエッジサービスをカバーするために、今年の第3四半期に正式に開始される予定です. .

ビッグデータクラウドネイティブにおける JuiceFS の全体的なソリューション

ソリューション全体のアーキテクチャ図からわかるように、現在、JuiceFS クライアントによって提供される 3 つの方法すべてを使用しています。

上の図の左半分に示すように、独立した Spark クラスターと Flink クラスターを用意し、CSI ドライバーを介して JuiceFS をクラスター全体に直接マウントします。これにより、ユーザーが Spark と Flink を起動したときに、 JuiceFS は存在し、コンピューティングタスクの読み取りと書き込みはすべてオブジェクトストレージを介して行われます。

このセクションには現在、シャッフルに関する質問があります。Spark タスクでは、計算プロセスのシャッフルフェーズ中に大量のデータをディスクに書き込む必要があるため、この期間中に大量のファイルの読み取りおよび書き込み要求が生成されると、基盤となるストレージのパフォーマンス要件が高くなります。Flink はストリーミングであり、多数のディスクを必要としないため、比較的優れています。将来的には、JuiceFS が Lustre に直接書き込めるようになることを期待していますが、これには JuiceFS にいくつかの変更が必要です. クライアント統合により、JuiceFS は Lustre を直接読み書きできるようになります. これはユーザーには認識されず、シャッフルステージの読み取りも改善できますそして書き込み性能。

上図の右半分のアプリケーションには 2 つのシナリオがあります。1 つは、HiveJDBC を介してデータプレビューなどの JuiceFS データを単純にクエリする方法で、このシナリオでは、S3 ゲートウェイを介して JuiceFS にアクセスできます。

2 つ目は、ビッグデータプラットフォームと AI プラットフォームが連携するシナリオです。たとえば、AI プラットフォームの同僚は、日常業務でサンプルデータ、特徴データなどを読み取る必要があることがよくあります。これらのデータは通常、ビッグデータプラットフォーム上の Spark または Flink タスクによって生成され、JuiceFS に格納されています。 . 異なるプラットフォーム間でデータを共有するために、AI プラットフォームのポッドが開始されると、JuiceFS は FUSE を介してポッドに直接マウントされるため、AI プラットフォーム上の同僚は Jupyter を介して JuiceFS のデータに直接アクセスできます。従来のアーキテクチャのように異なるプラットフォーム間でデータを繰り返しコピーするのではなく、いくつかのモデルをトレーニングすることで、チーム間のコラボレーションの効率が向上します。

JuiceFS はパーミッション制御に POSIX 標準ユーザーとユーザーグループを使用し、コンテナーはデフォルトで root ユーザーとして起動するため、パーミッション制御が困難になります。そのため、メタデータエンジンの接続情報やその他の権限制御情報を含む認証トークンを介してファイルシステムをマウントするように、JuiceFS に変更を加えました。複数の JuiceFS ファイルシステムに同時にアクセスする必要がある一部のシナリオでは、JuiceFS S3 ゲートウェイを IAM ポリシーと組み合わせて使用して、統合された権限管理を行います。

現在、JuiceFS を使用する際に遭遇するいくつかの問題

最初のポイントは、ユーザーとユーザーグループに基づく権限管理機能が比較的単純であることです.一部のシナリオでは、コンテナはデフォルトでルートユーザーとして起動し、権限を制御するのは容易ではありません.

2点目は、JuiceFS Hadoop SDKの構成最適化についてです。現在、JuiceFS Hadoop SDK を最適化するために、主に 3 つの構成がありjuicefs.prefetchます。構成の調整中にいくつかの問題が発生しました。この構成のデフォルト値は 300MB です。公式の提案では、オフヒープメモリをデフォルト値の 4 倍のサイズ (1.2GB) に設定することをお勧めします。現在、ほとんどのタスクは 2GB のオフヒープメモリに構成されていますが、一部のタスクでは 2GB を超えるメモリが構成されていても書き込みに失敗することがあります (HDFS は安定して書き込みできます)。ただし、これは必ずしも JuiceFS の問題ではなく、Spark またはオブジェクトストレージが原因である可能性もあります。したがって、現在、Spark と JuiceFS を深く適応させ、その理由を段階的に見つけて、これらすべての落とし穴を克服し、タスクの安定性を確保しながらメモリを削減することも計画しています。juicefs.max-uploadsjuicefs.memory-sizejuicefs.memory-size

3 つ目のポイントは、全体的なアーキテクチャ (JuiceFS + オブジェクトストレージ + Lustre) が複雑になるにつれて、より多くの障害ポイントが発生する可能性があり、タスクの安定性が低下する可能性があるため、他のフォールトトレラントメカニズムを保証する必要があることです。たとえば、Spark タスクのシャッフル書き込みフェーズ中に、「失われたタスク」のようなエラーが報告される場合がありますが、エラーの具体的な原因はまだ特定されていません。

上記の JuiceFS + オブジェクトストレージ + Lustre のアーキテクチャの組み合わせにより、読み取りと書き込みのパフォーマンスがある程度向上しますが、アーキテクチャがより複雑になり、それに応じていくつかの障害ポイントが増加する可能性があります。たとえば、Lustre には強力なディザスタリカバリコピー機能がありません.Lustre が突然ノードをハングアップさせた場合、実行中のタスクは引き続き Lustre でデータを安定して読み書きできますか?それとも、Lustre のデータが誤って失われるのでしょうか?それでも安定できますか? ? JuiceFS に移動して、オブジェクトストレージを介して再プルするかどうかは現在不明であり、現在、この種の壊滅的なテストを行っています。

将来と見通し

Flink + Hudi + JuiceFS に基づくリアルタイムデータレイクソリューション

近い将来に行う予定の 1 つは、Flink + Hudi + JuiceFS のリアルタイムデータレイクソリューションです。上の図の左側がデータソースです. Flink, Kafka/Pulsar を介して、データはリアルタイムで Hudi に書き込まれます. 同時に、Hudi のデータは JuiceFS に落ちて、現在のリアルタイムデータを置き換えます.倉庫。

ビッグデータクラウドネイティブの長期計画

最後に、展望でもある理想のカービッグデータクラウドネイティブの長期計画を紹介したいと思います。

1 つ目のポイントは、統一されたデータ管理とガバナンスシステムです。データレイク 2.0 の時代に解決しなければならない最大の問題は、データレイク 1.0 のシナリオにおけるデータの沼地の問題を解決することだと考えています。しかし現在、AWS Glue や AWS Lake Formation に似た、統合されたメタデータ管理、データディレクトリ管理、およびデータセキュリティ制御のためのオープンソース製品はないようです。私たちは現在、「オリジンシステム」プロジェクトに取り組んでいます. このシステムの最初のステップは、上記のデータベースとオブジェクトストレージ内のすべてのメタデータを、統一されたディレクトリ管理、統一されたセキュリティ制御、および統一されたデータ管理で管理することです.先へ。

2 番目のポイントは、より高速で安定性が高く、低コストの基盤となるストレージ機能です。現在、すべてのシナリオで最大の難点はオブジェクトストレージであり、オブジェクトストレージの利点は安定性と低コストであると同時に、オブジェクトストレージは絶えず反復されます。今のところ、ビッグデータのクラウドネイティブ化が進むのであれば、オブジェクトストレージは安定性を確保する前提でより良いパフォーマンスを提供する必要があると思います。

同時に、S3 は強整合性をサポートしていると主張するかもしれませんが、現時点では、オブジェクトストレージに基づくアーキテクチャ設計は強整合性を実現するのが難しいか、強整合性を実現するためにいくつかのことを犠牲にしなければならないことを理解しています。これはバランスの問題かもしれません。JuiceFS は強力な整合性をネイティブでサポートしており、ビッグデータプラットフォームに非常に適しています。

3 つ目のポイントは、よりスマートで効率的で使いやすいクエリエンジンです。上記の湖と倉庫の統合に関する考え方を拡張するには、湖と倉庫の統合はまだ開発の初期段階にあり、開発には 5 年から 10 年かかる可能性があります。Databricks と Microsoft は、データレイク上にベクトル化された MPP エンジンを構築しようとしており、レイクとウェアハウスの統合アーキテクチャを促進することを望んでいます。これは今後の開発の方向性かもしれませんが、1 つのエンジンを使用してすべてのシナリオのニーズを短時間で満たす方法はないようです。

現在のアーキテクチャには、基本的に、Spark、Flink、リレーショナルデータベース (OLTP シナリオ用)、時系列データベース、OLAP データベースなど、すべてのクエリエンジンが搭載されています。原則として、どちらが優れているかを使用する方が適切であり、上位層は統合されたミドルウェアによって管理されます。もう 1 つの例は Snowflake で、構造化データと半構造化データのクエリを同時にサポートしていますが、将来、人工知能に関連する非構造化データ (画像、音声、ビデオなど) をサポートする方法はまだ不明です。クリア。ただ、これは間違いなく今後の発展の方向性だと思います.李汽車にも同様の人工知能のシナリオがあるので、さまざまなビジネス関係者と一緒に探索し、構築していきます.

最後に、ビッグデータ開発全体の最終的な目標は、最小のコストと最大のパフォーマンスでデータ分析を完了し、真のビジネス価値を実現することです。

お役に立てれば、私たちのプロジェクト Juicedata/JuiceFSに注目してください ! (0ᴗ0✿)