ビッグデータとクラウドコンピューティングの深い統合の傾向はどのような側面に反映されていますか?

[[386480]]

この記事はWeChatの公開アカウント「Mingge's IT Essays」から転載したもので、著者はIT Minggeです。この記事を転載する場合は、Mingge の IT Essays 公開アカウントにご連絡ください。

ITエコシステム全体のさらなる発展に伴い、2021年には、IT実務家の間ではビッグデータの開発動向について一般的なコンセンサスが形成され、ビッグデータとクラウドコンピューティングのさらなる深い統合、つまりビッグデータがクラウドコンピューティングを取り入れてクラウドネイティブへと移行するという動向が高まっています。

ミン兄弟がここにいます。私たちは、ディープ インテグレーションのトレンドの中で、ビッグ データとクラウド コンピューティングのディープ インテグレーションが具体的にどこに現れるのかを一緒に見ていきます。

ビッグデータとクラウド コンピューティングの緊密な統合は、次の側面に反映されています。

まず、アプリケーション側のビッグデータ プラットフォームがクラウド上に置かれます。ビッグデータ テクノロジを使用するビジネス アプリケーション ビルダーは、独自のデータ センターを構築するのではなく、ビッグデータ プラットフォームをクラウドに移行します。クラウドベンダーのIaaSレイヤー上に自社のビッグデータプラットフォームを構築する企業もあれば（現在ではこのようにクラウド上でビッグデータを活用する事例は比較的少ない）、クラウドベンダーが提供するPaaSレイヤーのビッグデータ関連製品（AWS EMR、Alibaba Cloudのe-MapReduceなど）を直接利用する企業もあれば、クラウドベンダーが発売するSaaSレイヤーのビッグデータ関連製品（AWS RedShift、Alibaba CloudのMaxComputeなど）を直接利用する企業もある。 「クラウド移行」において強調する必要がある傾向が 1 つあります。それは、ベンダー ロックインが発生しないことを誰もが非常に重視しているということです。基盤となるクラウドは、複数のパブリック クラウドとプライベート クラウドを統合したハイブリッド クラウドである場合があります。

第二に、クラウド コンピューティング ベンダーは、ビッグ データに基づく独自の付加価値サービスを継続的にリリースしています。主要なクラウド ベンダーは、市場競争力を高め、市場での地位をさらに強化/拡大するために、最も基本的な S3/OSS、EMR/E-MapReduce、前述の AWS RedShift、Alibaba Cloud の MaxCompute など、独自の統合ビッグ データ関連製品を積極的にリリースしています。さらに、さまざまなクラウド データベース、クラウド上のサーバーレス形式のさまざまなビッグ データ サービスなどがあります。次のスクリーンショットに示すように、このリストはまだ増え続けています。

第三に、従来のビッグデータベンダーは、自社の製品やサービスを提供するためにクラウドに依存するようになりました。たとえば、Elasticは長い間、クラウドを基盤とした独自のELKテクノロジースタックを提供しており、Databricksのビッグデータプラットフォームと製品は常にクラウドを基盤として顧客にサービスを提供しています（AWS、GCP、Azureなどのクラウドプラットフォームに接続できます）。また、Clouderaはビジネスモデルを絶えず模索し、変更してきました（ビッグデータトロイカの栄光の時代から、業績低下によるHortorWorksとの合併、ビジネスモデルの積極的な変更、クラウドを基盤とした自社の製品やサービスの提供、さらにはビッグデータプラットフォームのデータセンターバージョンがCDP Private Cloud Baseに改名されるまで）。

4 番目に、それぞれの特定のビッグ データ コンポーネントは、独自のアーキテクチャを積極的に変更し、クラウド ネイティブから「クラウド化」へと積極的に移行しています。概念レベルでは、ビッグ データは、初期の「データの局所性」と「モバイル データはモバイル コンピューティングほど優れていない」という重視から、現在の「ストレージとコンピューティングの分離」の重視へと進化しています。新しくリリースされた各コンポーネントとフレームワークは、クラウド ネイティブを積極的に採用しています。たとえば、Pulsa と TiDB は、ストレージとコンピューティングが分離されたクラウド ネイティブ アーキテクチャに基づいています。伝統的なコンポーネントには歴史的な負担が伴いますが、常に革新と変化を求めています。たとえば、Flink/Spark は深く統合されており、Kubernetes クラスター モードをサポートしています。 Kafka は、Zookeeper 依存関係の完全な削除や Rebalance Protocol の静的メンバーシップなど、クラウドベースのコンポーネントも継続的に調査しています。古いことわざに「意志に従えば繁栄し、従わなければ滅びる」というのがあります。クラウド ネイティブ アーキテクチャに適さない一部の技術コンポーネントの市場は縮小しています。たとえば、多くのシナリオでは、Kubernetes が Yarn に取って代わり、オブジェクト ストレージ OSS/S3 も HDFS に取って代わります (Apache コミュニティによって開始された Ozone にも注目しています。このコンポーネントは、オブジェクト ストレージに基づいて、ファイル システム API も統合して開始します。元の HDFS コミュニティから多くのコミッターがこのコンポーネントにコードを貢献しており、このコンポーネントは Cloudera CDP プラットフォームにも組み込まれています)。次の図は、Flink/Spark と Kubernetes の深い統合を示しています。(k8s オペレーターを使用して k8s クラスターで Spark/Flink ジョブを実行するだけでなく、ネイティブの深い統合であることに注意してください)

参考リンク

http://spark.apache.org/docs/latest/running-on-kubernetes.html

https://ci.apache.org/projects/flink/flink-docs-release-1.12/deployment/resource-providers/native_kubernetes.html

詳しくはこちら

https://www.confluent.io/blog/kafka-rebalance-protocol-static-membership/