摘要：本文整理自阿里云開源大數(shù)據(jù)平臺(tái)數(shù)據(jù)湖存儲(chǔ)團(tuán)隊(duì)孫大鵬在7月17日阿里云數(shù)據(jù)湖技術(shù)專場(chǎng)交流會(huì)的分享。本篇內(nèi)容主要分為兩個(gè)部分：

1. 背景介紹
2. JindoData 數(shù)據(jù)湖存儲(chǔ)解決方案

點(diǎn)擊查看直播回放

背景介紹

大數(shù)據(jù)行業(yè)蓬勃發(fā)展，主要源自于通訊技術(shù)的發(fā)展，全球數(shù)據(jù)規(guī)模，預(yù)計(jì)2025年將增長(zhǎng)到163ZB，相當(dāng)于全球60億人，平均每人27TB數(shù)據(jù)。數(shù)據(jù)量爆發(fā)式增長(zhǎng)，使得企業(yè)擁有了更多數(shù)據(jù)資源。更多數(shù)據(jù)意味著需要更大的存儲(chǔ)。此外，數(shù)據(jù)本身極具價(jià)值，因此要挖掘數(shù)據(jù)價(jià)值并進(jìn)行充分利用，以此反向推動(dòng)業(yè)務(wù)的發(fā)展和改造。

大數(shù)據(jù)技術(shù)的發(fā)展趨勢(shì)是云化、輕量化、服務(wù)化。數(shù)據(jù)湖、與云融合、實(shí)時(shí)計(jì)算已經(jīng)成為大數(shù)據(jù)領(lǐng)域的關(guān)鍵詞。存算分離概念在云計(jì)算早期已被提出。存儲(chǔ)與計(jì)算耦合的自建平臺(tái)會(huì)造成額外成本，且受限于本地網(wǎng)絡(luò)帶寬。有了云計(jì)算以后，網(wǎng)絡(luò)帶寬得到了很大緩解?？梢园戳渴召M(fèi)，提供服務(wù)化、容器化的能力，更好地做運(yùn)維開發(fā)。

業(yè)界存儲(chǔ)架構(gòu)演進(jìn)

早期的大數(shù)據(jù)基于 HDFS 構(gòu)建數(shù)倉。 HDFS 是非常好的分布式存儲(chǔ)選型，單集群可穩(wěn)定支撐到 4-6 億文件規(guī)模，數(shù)據(jù)量可達(dá) 100 PB 。但是 HDFS 運(yùn)維成本比較高，存儲(chǔ)作為基礎(chǔ)組件，一旦存儲(chǔ)出現(xiàn)問題，則意味著整個(gè)業(yè)務(wù)被中斷。此外，達(dá)到4-6億文件規(guī)模，100PB數(shù)據(jù)量后，再進(jìn)行擴(kuò)展則會(huì)出現(xiàn)問題。

因此，社區(qū)提出了 HDFS Federation 方案。將 HDFS 集群進(jìn)行擴(kuò)展，并將業(yè)務(wù)進(jìn)行拆分，大業(yè)務(wù)可以獨(dú)立使用一組 NameNode，可突破單組 NameNode JVM 的限制，實(shí)現(xiàn)了HDFS 元數(shù)據(jù)和容量的橫向擴(kuò)展。此外，社區(qū)開發(fā)了 NS Router 組件，幫助更好地使用 HDFS 元數(shù)據(jù)。

隨著 HDFS 的擴(kuò)展，其運(yùn)維成本也成倍增加。業(yè)界開始選擇利用對(duì)象存儲(chǔ)的高可用、高吞吐，基于云上對(duì)象存儲(chǔ)構(gòu)建數(shù)據(jù)湖。每個(gè)云廠商都會(huì)從設(shè)計(jì)到運(yùn)維上投入大量人力、物力保證對(duì)象存儲(chǔ)可靠、穩(wěn)定、高效。

從存算一體到云原生數(shù)據(jù)湖

開源大數(shù)據(jù)平臺(tái)經(jīng)歷了幾次大的演進(jìn)。

第一代開源大數(shù)據(jù)平臺(tái)EMR，為更好地將 Hadoop 搬到云上提供了基礎(chǔ)運(yùn)維。在線下使用物理機(jī)，在云上使用 ECS 本地盤機(jī)型，即可實(shí)現(xiàn)與物理機(jī)近似的存儲(chǔ)能力和成本。其特點(diǎn)為將線下 IDC 集群搬上云，可以通過云簡(jiǎn)化集群部署和擴(kuò)容，但不解決 HDFS 的上線、運(yùn)維等問題。

第二代開源大數(shù)據(jù)平臺(tái)EMR 將 OSS 和 S3 對(duì)象存儲(chǔ)作為 storage connector 引入集群。當(dāng)存儲(chǔ)集群達(dá)到一定規(guī)模后，溫?cái)?shù)據(jù)、冷數(shù)據(jù)可以轉(zhuǎn)存到 OSS 或 S3 對(duì)象存儲(chǔ)，進(jìn)一步降低存儲(chǔ)成本。

第三代開源大數(shù)據(jù)平臺(tái)的特點(diǎn)為本地集群基本不保留任何元數(shù)據(jù)，而是保留在云上。DLF使用 Table 替代了 Hive Metastore 元數(shù)據(jù)方案，表的元數(shù)據(jù)通過云服務(wù)托管，利用 OSS 做存儲(chǔ)，使集群基本實(shí)現(xiàn)無狀態(tài)。因此，用戶只需創(chuàng)建好集群即可使用資源，體驗(yàn)極佳。且可以對(duì)接更多存儲(chǔ)引擎，互相之間能夠?qū)崿F(xiàn)隔離，比如離線、在線可以利用云上元數(shù)據(jù)和存儲(chǔ)實(shí)現(xiàn)集群分離。

數(shù)據(jù)湖存儲(chǔ)演進(jìn)之路

數(shù)據(jù)湖存儲(chǔ)的演進(jìn)主要也分為三個(gè)階段：

• 數(shù)據(jù)湖1.0：存算分離架構(gòu)，冷熱分層，以Hadoop生態(tài)為主。
• 數(shù)據(jù)湖2.0：以對(duì)象存儲(chǔ)為中心，統(tǒng)一存儲(chǔ)承載生產(chǎn)業(yè)務(wù)、大規(guī)模、高性能。
• 數(shù)據(jù)湖3.0：以對(duì)象存儲(chǔ)為中心，構(gòu)建企業(yè)數(shù)據(jù)湖全兼容、多協(xié)議、統(tǒng)一元數(shù)據(jù)。

JindoData 數(shù)據(jù)湖存儲(chǔ)解決方案

經(jīng)過不斷演化，最終實(shí)現(xiàn)了 JindoData 數(shù)據(jù)湖存儲(chǔ)解決方案。JindoData 是存儲(chǔ)加速項(xiàng)目。JindoFS 存儲(chǔ)系統(tǒng)構(gòu)建在 OSS 之上，提供了文件元數(shù)據(jù)功能和目錄功能，可以和 NameNode 進(jìn)行比對(duì)，解決了對(duì)象存儲(chǔ)在模擬文件系統(tǒng)時(shí)的操作比如 rename 等問題。Jindo FSx 是存儲(chǔ)加速系統(tǒng)，負(fù)責(zé)解決帶寬問題。客戶端或計(jì)算集群側(cè)有存儲(chǔ)資源，如果都通過網(wǎng)絡(luò)，則延時(shí)、效率與 HDFS 存在差距，經(jīng)過不斷地放大后，用戶會(huì)逐漸感受到性能差距。因此需要 Jindo FSx 存儲(chǔ)加速系統(tǒng)來解決帶寬和延時(shí)問題。

基于以上兩大核心系統(tǒng)，我們對(duì)上層提供了 HDFS API 和 POSIX API ，兩個(gè) API 基本可以滿足大數(shù)據(jù)平臺(tái)上對(duì)存儲(chǔ)的使用需求，F(xiàn)link 、Hadoop 、Spark 等大數(shù)據(jù)相關(guān)組件可以直接通過相關(guān) API 方便地接入。比如當(dāng)前新興的 AI 訓(xùn)練可以將中間結(jié)果、TFRecord等通過 POSIX API 存到對(duì)象存儲(chǔ)系統(tǒng)里。

JindoSDK 生態(tài)工具解決了和生態(tài)對(duì)接問題，比如與計(jì)算對(duì)接、本地 POSIX 掛載。JindoDistCP 解決從 OSS 和 HDFS 之間的數(shù)據(jù)遷移，JindoTable 能夠以表粒度做遷移，JindoShell 能夠幫助我們更好地使用對(duì)象存儲(chǔ)。

底層數(shù)據(jù)源可以對(duì)接 HDFS、對(duì)象存儲(chǔ)、NAS以及阿里云OSS。

JindoSDK：超級(jí)數(shù)據(jù)湖SDK

JindoSDK 是對(duì)接生態(tài)的重要 SDK，上層可以對(duì)接各種引擎，下層對(duì)接各種存儲(chǔ)。通常，很多組件和存儲(chǔ)都是基于煙囪式開發(fā)，導(dǎo)致 SDK 能力規(guī)格存在很大偏差。因此我們重點(diǎn)打造了 Native Core 層，使用 C++ 語言開發(fā)，對(duì)上層抽象出了 ObjectStore API 、DataStream API 和 FileSystem API。 通過 Cython 對(duì)接 Python SDK， 通過 JNI 對(duì)接 Hadoop SDK，通過 C SDK 對(duì)接 Jindo Fuse，使上層所有計(jì)算引擎都可以使用相同的一套原生 SDK。因此，SDK 層面改進(jìn)后，上層全鏈路都可以享受 SDK 改進(jìn)帶來的收益，比如文件系統(tǒng)元數(shù)據(jù)操作優(yōu)化、IO 路徑的讀寫優(yōu)化、安全、靈活的 STS 配置策略等。

ObjectStore是對(duì)象存儲(chǔ)的接口，OSS、S3 都可以歸結(jié)到 ObjectStore 內(nèi)部API。上圖左下角為 Jindo Native SDK 和 OSS Java SDK 的性能對(duì)比，可以看到 Jindo SDK 性能平均提升 2.2 倍。

Hadoop SDK 訪問 OSS ，性能也可以得到全面提升。幾個(gè) SDK 廣泛應(yīng)用在 EMR 生產(chǎn)集群，其穩(wěn)定性等性能都已經(jīng)過阿里云上的產(chǎn)品驗(yàn)證。

JindoFS：構(gòu)建在OSS上的高性能存儲(chǔ)系統(tǒng)

JindoFS 重點(diǎn)解決了超大規(guī)模 HDFS 存儲(chǔ)集群的挑戰(zhàn)，比如單組 NameNode 架構(gòu)存在容量限制，如果想突破容量限制，必須投入極高的運(yùn)維成本，需要運(yùn)維十多個(gè)服務(wù)包括NameNode、ZKFC 、ZK、JN；同時(shí)，元數(shù)據(jù)運(yùn)維重啟時(shí)間可高達(dá)幾個(gè)小時(shí)，參數(shù)調(diào)優(yōu)、JVM GC、全局鎖等問題也存在挑戰(zhàn)。除此之外，DataNode 做節(jié)點(diǎn)上下線、集群節(jié)點(diǎn)替換、HDFS 內(nèi)部 balancer 等都需要解決。

早期，受限于當(dāng)時(shí)的技術(shù)，使用 QJM 架構(gòu)來解決上述痛點(diǎn)。而隨著 Raft 在業(yè)界廣泛推廣和使用，JindoFS 選擇基于 Raft 架構(gòu)建元數(shù)據(jù)，內(nèi)部只需三個(gè) NamespaceService 節(jié)點(diǎn)，避免了 HDFS 大量服務(wù)部署。

運(yùn)維成本上，實(shí)現(xiàn)了分鐘級(jí)重啟。通過C++語言開發(fā)，性能非常好。基于 OSS 存儲(chǔ)，可以大大簡(jiǎn)化頂層設(shè)計(jì)，服務(wù)也更高效，且本地 block 可以用作緩存。

半托管的 JindoFS 通過這套元數(shù)據(jù)可以解決 HDFS 的運(yùn)維復(fù)雜度以及 OSS 接口的損耗，滿足用戶“對(duì)系統(tǒng)穩(wěn)定可靠、運(yùn)維簡(jiǎn)單、節(jié)省成本；對(duì)象存儲(chǔ)數(shù)據(jù)湖和 HDFS 相比性能只好不差”的需求。

隨著 JindoFS 半托管的深入使用，我們發(fā)現(xiàn)即使運(yùn)維簡(jiǎn)單，但因?yàn)樾枰獮橛脩粼诎胪泄苌喜渴鹨惶追?wù)，也會(huì)給用戶帶來一定的運(yùn)維成本。因此我們實(shí)現(xiàn)了基于云原生容器化和存儲(chǔ)服務(wù)化的JindoFS數(shù)據(jù)湖3.0架構(gòu)，

數(shù)據(jù)層面， OSS 服務(wù)可以提供兩層 API ，分別是對(duì)象 API 和目錄 API，通過兩套 API 組合使用，可以基本滿足所有高性能元數(shù)據(jù)和存儲(chǔ)需求。客戶實(shí)際部署時(shí)，可以將 SDK 以及 JindoFSx加速等組件部署在線下、容器或 ECS 里，使容器上的組件也可以更好地使用云上服務(wù)。

JindoFS 使用了對(duì)象存儲(chǔ)作為底層存儲(chǔ)，因此可以實(shí)現(xiàn)冷熱分層，可以根據(jù)對(duì)象文件生命周期的不同，選擇標(biāo)準(zhǔn)型、低頻型、歸檔型和冷歸檔型四種模式，最大程度地節(jié)省成本。歸檔類型適合長(zhǎng)期存儲(chǔ)但可能很長(zhǎng)時(shí)間不讀的數(shù)據(jù)，低頻適合讀得比較少的數(shù)據(jù)。

JindoFSx：高性能/性價(jià)比的存儲(chǔ)加速系統(tǒng)

JindoFSx 緩存加速系統(tǒng)部署在 worker 上。很多對(duì)象存儲(chǔ)遠(yuǎn)端有一定的網(wǎng)絡(luò)開銷，而如果全走網(wǎng)絡(luò)請(qǐng)求，會(huì)導(dǎo)致延時(shí)增加。IO 越短，GPU 機(jī)器成本也可以發(fā)揮到最大。JindoFSx 可以在內(nèi)部進(jìn)行分層，能夠?qū)Ρ镜卮鎯?chǔ)資源進(jìn)行管理。通過 JindoSDK 對(duì)上層對(duì)接了各種 ETL、交互式分析、實(shí)時(shí)計(jì)算、機(jī)器學(xué)習(xí)等組件，底層可以對(duì)接不同數(shù)據(jù)源。比如阿里云上可能要訪問其他云的對(duì)象存儲(chǔ)，帶寬性能上可能無法滿足高性能查詢的需求。但部署 JindoFSx 以后，對(duì)數(shù)據(jù)進(jìn)行緩存、預(yù)熱即可基本滿足存儲(chǔ)需求。

JindoFSx 實(shí)現(xiàn)了分布式緩存架構(gòu)，包括 Namespace、Storage，上層有一套 NameSpaceService 服務(wù)做文件元數(shù)據(jù)層面的加速，通過文件系統(tǒng)接口暴露給 JindoSDK，供上層應(yīng)用使用，以此解決 IO 密集、帶寬受限、遠(yuǎn)端數(shù)據(jù)訪問的問題。

生態(tài)工具和場(chǎng)景

上圖為數(shù)據(jù)湖存儲(chǔ)對(duì)接計(jì)算引擎的大圖，通過 OSS 可以方便地對(duì)接各種服務(wù)和存儲(chǔ)。

我們?cè)跀?shù)據(jù)流層面做了異步數(shù)據(jù)預(yù)讀、復(fù)用，使得讀取 Parquet/ORC 格式時(shí)可以實(shí)現(xiàn)高效尋址，利用緩存使數(shù)據(jù)讀取更高效。

對(duì)象存儲(chǔ)上的 rename 操作比較重，因此我們?cè)O(shè)計(jì)了JindoCommitter，基于對(duì)象存儲(chǔ)系統(tǒng)的 Multiple Upload，結(jié)合 OSS 文件系統(tǒng)層面的定制支持，可以實(shí)現(xiàn)在保證數(shù)據(jù)一致性前提下無需 rename 操作的 Job Committer。在 OSS 上運(yùn)行作業(yè)時(shí)，只要加上Jindocommitter ，即可同時(shí)保證 Hadoop V1 版本的事務(wù)性和 Hadoop V2 版本的高性能。

?目錄 rename 的優(yōu)化提供了針對(duì) EMR 優(yōu)化前綴重命名接口，目錄 rename 降低到毫秒級(jí)并保證原子性。另外，我們支持了 fast copy，對(duì)比大部分對(duì)象存儲(chǔ)對(duì)于 object 的copy 操作需要將數(shù)據(jù)進(jìn)行真實(shí)拷貝， fast copy只需在內(nèi)部做一次索引轉(zhuǎn)換，避免了數(shù)據(jù)真實(shí)拷貝。

很多數(shù)據(jù)湖引擎是基于文件系統(tǒng)原子 rename 特性設(shè)計(jì)的，即對(duì)象如果已經(jīng)存在，則不能被二次覆蓋。對(duì)于這個(gè)重要特性，我們?cè)?OSS 上做了重點(diǎn)支持。首先，OSS 是一個(gè)強(qiáng)一致性存儲(chǔ)，比如向 bucket 里寫入 object，如果沒有強(qiáng)一致的保證，在 list 時(shí)可能無法獲取到最新的對(duì)象。其次，對(duì)象存儲(chǔ)的 rename是 Key 覆蓋， Key 級(jí)別對(duì)象不會(huì)檢查文件是否存在。而數(shù)據(jù)湖場(chǎng)景下，原子 rename 特性，我們實(shí)現(xiàn)了兩種方案：在 SDK 層面基于 OTS 構(gòu)建原子 Rename 的能力。同時(shí)進(jìn)行深度優(yōu)化后，已經(jīng)可以實(shí)現(xiàn) OSS 原生原子性 rename 支持，不依賴任何外部服務(wù)，可以在文件做 copy 時(shí)進(jìn)行強(qiáng)一致的檢測(cè)。

對(duì)象存儲(chǔ)是不支持 Flush 的，而像 Flink、Flume 這類引擎對(duì) Flush 的依賴是比較重的，我們?cè)趯?duì)象存儲(chǔ)上也做了深度優(yōu)化，雖然不能保證完整的 Flush 語義，即數(shù)據(jù) Flush 以后立刻可見，但是可以保證 Flush 以后數(shù)據(jù)不丟，對(duì)于 Flume 層面來說已經(jīng)完全滿足實(shí)際使用需求。 Flink 里使用了 MPU 接口，實(shí)現(xiàn)了 recoverable writer 的可恢復(fù)寫入。

數(shù)據(jù)湖生態(tài)的 JindoTable 是專門為結(jié)構(gòu)化數(shù)據(jù)設(shè)計(jì)一套工具集，可以幫助降低存儲(chǔ)成本和維護(hù)成本。

JindoTable 可以以表維度做數(shù)據(jù)冷熱轉(zhuǎn)換。比如表存在 OSS 或 HDFS 上，可以通過JindoTable 操作 Hive ?MetaStore 等的數(shù)據(jù)，可以按照 DB 級(jí)別、表級(jí)別、前綴級(jí)別做生命周期轉(zhuǎn)換，可以很方便地進(jìn)行冷熱數(shù)據(jù)統(tǒng)計(jì)，并按特點(diǎn)進(jìn)行數(shù)據(jù)分層操作。

Hadoop 原生 DistCP 在對(duì)象存儲(chǔ)和 HDFS 同步數(shù)據(jù)會(huì)存在一些問題，比如拷貝策略、存儲(chǔ)類型、數(shù)據(jù)校驗(yàn)等支持。JindoDistCP 重點(diǎn)解決這類問題：JindoDistCP 上實(shí)現(xiàn)了異構(gòu) checksum 比對(duì)，HDFS 和對(duì)象存儲(chǔ)的 checksum 算法是不同的，傳統(tǒng)的做法無法將HDFS 和對(duì)象直接做 checksum 比對(duì)，在 JindoDistCP 里進(jìn)行了透明的 checksum 轉(zhuǎn)換，保證了寫入和傳輸過程中的數(shù)據(jù)準(zhǔn)確性。

此外，我們對(duì) JindoDistCP 的內(nèi)核也進(jìn)行了重新優(yōu)化，實(shí)現(xiàn)了動(dòng)態(tài)拷貝，類似搶占式拷貝的方式，大文件和小文件可以快速同時(shí)并行，帶寬利用率大幅提高。

問答

Q：JindoFS 和 HDFS 性能數(shù)據(jù)對(duì)比如何？

A：后續(xù)會(huì)逐步發(fā)布測(cè)試數(shù)據(jù)，JindoFS 本身設(shè)計(jì)上有一定優(yōu)勢(shì)。在 HDFS 里做 rename、delete 等操作，特別是對(duì)大目錄進(jìn)行操作時(shí)，會(huì)存在大量的加鎖和檢查操作。隨著文件數(shù)量變大，時(shí)間也會(huì)遞增；這些操作在 JindoFS 上的時(shí)間是穩(wěn)定的。

Q：JindoFS 只有三個(gè)節(jié)點(diǎn)，最大能夠支持多大文件數(shù)量？

A：早期版本是一般是三節(jié)點(diǎn)組 raft，這種模式可以穩(wěn)定支持十億級(jí)別，相比于 HDFS 有兩倍的提升?，F(xiàn)在的 3.0 云原生架構(gòu)下，用戶通過 endpoint 訪問，元數(shù)據(jù)服務(wù)可以在內(nèi)部進(jìn)行橫向擴(kuò)展。

Q：JindoFS 和 Alluxio 的對(duì)比？

A：JindoFS 是元數(shù)據(jù)的管理和優(yōu)化，Alluxio 是一套開源分布式緩存加速服務(wù)，其功能定位與 JindoFSx 比較接近。Alluxio 主打開源，Jindo 在對(duì)象存儲(chǔ)上做了較多優(yōu)化，加上 Native 底層，理論上性能會(huì)有一定優(yōu)勢(shì)。

Q：HDFS 上 k8s 場(chǎng)景是否有具體的實(shí)踐？

A：HDFS 是一個(gè)存儲(chǔ)引擎，每個(gè)存儲(chǔ)節(jié)點(diǎn)是有狀態(tài)的。HDFS 部署在 k8s 節(jié)點(diǎn)也需要重度的運(yùn)維，比如釋放需要首先進(jìn)行 HDFS Decommission 操作，要日常對(duì)節(jié)點(diǎn)進(jìn)行 balance 等，k8s 部署 HDFS 無明顯優(yōu)勢(shì)。

更多信息：

產(chǎn)品官網(wǎng)

[1] 數(shù)據(jù)湖構(gòu)建Data Lake Formation：數(shù)據(jù)湖構(gòu)建 Data Lake Formation_數(shù)據(jù)倉庫_數(shù)據(jù)實(shí)時(shí)分析-阿里云

[2] 開源大數(shù)據(jù)平臺(tái)EMR： E-MapReduce_EMR_大數(shù)據(jù)框架_大數(shù)據(jù)-阿里云

[3] 大數(shù)據(jù)知識(shí)圖譜： 大數(shù)據(jù)知識(shí)圖譜

數(shù)據(jù)湖系列

[1] 數(shù)據(jù)湖揭秘—Delta Lake： 數(shù)據(jù)湖揭秘—Delta Lake-阿里云開發(fā)者社區(qū)

[2] 數(shù)據(jù)湖構(gòu)建—如何構(gòu)建湖上統(tǒng)一的數(shù)據(jù)權(quán)限： ?數(shù)據(jù)湖構(gòu)建—如何構(gòu)建湖上統(tǒng)一的數(shù)據(jù)權(quán)限-阿里云開發(fā)者社區(qū)

[3] 關(guān)于 Data Lake 的概念、架構(gòu)與應(yīng)用場(chǎng)景介紹：關(guān)于 Data Lake 的概念、架構(gòu)與應(yīng)用場(chǎng)景介紹-阿里云開發(fā)者社區(qū)

[4] 數(shù)據(jù)湖架構(gòu)及概念簡(jiǎn)介：

數(shù)據(jù)湖架構(gòu)及概念簡(jiǎn)介-阿里云開發(fā)者社區(qū)

[5] 數(shù)據(jù)湖統(tǒng)一元數(shù)據(jù)和權(quán)限

數(shù)據(jù)湖統(tǒng)一元數(shù)據(jù)與權(quán)限-阿里云開發(fā)者社區(qū)

[6] 數(shù)據(jù)湖管理及優(yōu)化

數(shù)據(jù)湖管理及優(yōu)化-阿里云開發(fā)者社區(qū)文章來源地址http://www.zghlxwxcb.cn/news/detail-784203.html

到了這里，關(guān)于基于EMR的新一代數(shù)據(jù)湖存儲(chǔ)加速技術(shù)詳解的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！