DataLake和Lakehouse從何而來？1.什么是DataLakeWikipedia上關(guān)于DataLake的介紹是：Adatalakeisasystemorrepositoryofdatastoredinitsnatural/rawformat,usuallyobjectblobsorfiles.這段話的核心是nature/rawformat。DataLake和傳統(tǒng)數(shù)據(jù)倉庫的不同點(diǎn)是DataLake能夠存儲(chǔ)更原始格式的數(shù)據(jù)，可以存儲(chǔ)結(jié)構(gòu)化、半結(jié)構(gòu)化、非結(jié)構(gòu)數(shù)據(jù)。而傳統(tǒng)數(shù)倉需要將數(shù)據(jù)匯聚起來，并且在不同業(yè)務(wù)線上構(gòu)建不同的數(shù)倉。今天我們希望把更多的原始數(shù)據(jù)匯聚到一起，解決數(shù)據(jù)孤島、多業(yè)務(wù)多格式數(shù)據(jù)統(tǒng)一等問題。為了實(shí)現(xiàn)高效存儲(chǔ)，存儲(chǔ)計(jì)算分離成為必然；為了更快地看到數(shù)據(jù)，需要將數(shù)據(jù)先入湖，將ETL環(huán)節(jié)后置。2.什么是Lakehouse2020年，Databricks公司提出了Lakehouse概念，意思是DataLake不是想替代掉數(shù)倉，而是想成為一家人，所以數(shù)倉仍然存在，只是后置了。傳統(tǒng)的數(shù)據(jù)倉庫需要做T+1的batchETL工作，導(dǎo)致數(shù)據(jù)倉庫生產(chǎn)的數(shù)據(jù)具有滯后性。隨著技術(shù)升級(jí)和業(yè)務(wù)發(fā)展，我們需要更實(shí)時(shí)地處理數(shù)據(jù)、更高效地分析數(shù)據(jù)。由于機(jī)器學(xué)習(xí)和深度學(xué)習(xí)所需的數(shù)據(jù)可以存放于數(shù)據(jù)倉庫或者數(shù)據(jù)湖中，因此數(shù)據(jù)平臺(tái)不僅要服務(wù)于BI和報(bào)表，還要實(shí)現(xiàn)大數(shù)據(jù)場(chǎng)景和AI場(chǎng)景的數(shù)據(jù)融合。Databricks公司針對(duì)Lakehouse引入了ACID事務(wù)、多版本數(shù)據(jù)、索引、零拷貝等特性，這些常出現(xiàn)在數(shù)據(jù)庫領(lǐng)域里的特性在DataLake階段是沒有提及的。所以Lakehouse對(duì)存儲(chǔ)的要求更高HDFS與對(duì)象存儲(chǔ)適合么1.存儲(chǔ)系統(tǒng)比較無論業(yè)務(wù)架構(gòu)怎么構(gòu)建，最底層的存儲(chǔ)系統(tǒng)常見選項(xiàng)是HDFS和對(duì)象存儲(chǔ)。針對(duì)這兩種存儲(chǔ)進(jìn)行比較，左側(cè)是比較的維度。單個(gè)namespace的存儲(chǔ)規(guī)模，HDFS通常做到億級(jí)，行業(yè)實(shí)踐中單個(gè)HDFS集群3億以內(nèi)的文件運(yùn)維是比較輕松的，5億以上需要考慮到Federation（聯(lián)邦）機(jī)制。但是對(duì)象存儲(chǔ)在私有化部署中可以達(dá)到千億級(jí)，公有云可以達(dá)到萬億級(jí)的對(duì)象規(guī)模。在一致性方面，HDFS是強(qiáng)一致性的文件系統(tǒng)，對(duì)象存儲(chǔ)大部分則是最終一致性。最終一致性在ETL過程中會(huì)引入一些問題，這也是應(yīng)用開發(fā)者會(huì)忽略的部分，后面會(huì)再具體解釋。容量管理方面，HDFS是手工運(yùn)維的，需要手工的容量規(guī)劃、擴(kuò)容；對(duì)象存儲(chǔ)是彈性的，沒有了容量規(guī)劃的過程。原子重命名能力，在文件系統(tǒng)中這是個(gè)基本功能，但對(duì)象存儲(chǔ)里沒有。后面會(huì)再講到在對(duì)象存儲(chǔ)里如何實(shí)現(xiàn)最簡(jiǎn)單的對(duì)象或者目錄改名的功能，很多應(yīng)用開發(fā)者并沒有關(guān)注過這個(gè)差異。List的性能，在文件系統(tǒng)里執(zhí)行l(wèi)s命令是日常操作，在對(duì)象存儲(chǔ)中執(zhí)行該操作性能會(huì)差100倍。在隨機(jī)寫上，HDFS和對(duì)象存儲(chǔ)都不支持隨機(jī)寫。緩存加速，在這兩個(gè)系統(tǒng)里也都默認(rèn)沒有帶。在運(yùn)維復(fù)雜度上，對(duì)象存儲(chǔ)在公有云上不需要運(yùn)維后，雖然已經(jīng)積累了很多經(jīng)驗(yàn)和最佳實(shí)踐，但是仍然需要專業(yè)的、經(jīng)驗(yàn)豐富的運(yùn)維人員來維護(hù)。在HDFS兼容性上，HDFS本身兼容性很好；對(duì)象存儲(chǔ)其實(shí)在適配整個(gè)Hadoop生態(tài)時(shí)是有一些痛點(diǎn)的。今天我們看所有公有云上的半托管的大數(shù)據(jù)服務(wù)，比如各家提供的EMR或類似產(chǎn)品里能提供的計(jì)算組件是非常有限的。盡管Hadoop上層組件很豐富，有幾十個(gè)，但是大部分公有云上提供的只有Spark、Hive、Presto等，Impala、Trino等計(jì)算組件公有云大部分都沒有提供適配，提供的Spark、Hive和Presto的版本也是有限的，這是因?yàn)檫@些云廠商在上層計(jì)算引擎和自己的對(duì)象存儲(chǔ)之間的Connector及引擎之間做了深度的修改工作，導(dǎo)致云廠商在對(duì)接每一種引擎和對(duì)象存儲(chǔ)時(shí)工作量較大，沒法去對(duì)接所有引擎，無法跟進(jìn)所有社區(qū)版本，這就會(huì)給上層組件的選擇帶來限制。使用社區(qū)的Hadoop的生態(tài)還是云廠商提供的生態(tài)，不同公司有不同的選擇。PyTorch、TensorFlow等對(duì)HDFS的API兼容并不好，對(duì)S3能夠兼容，但性能上不能滿足模型訓(xùn)練的需求，因此在訓(xùn)練時(shí)，通常需要將數(shù)據(jù)先拷貝到另外一個(gè)POSIX的文件系統(tǒng)里，再去跑訓(xùn)練，這增加了系統(tǒng)使用復(fù)雜度。2.存儲(chǔ)系統(tǒng)的阿克琉斯之踵比較了兩個(gè)存儲(chǔ)系統(tǒng)之后，再講一下它們的共性問題--阿克琉斯之踵。這來源于一個(gè)希臘神話，阿克琉斯是一位非常厲害的戰(zhàn)士，他唯一的“死穴”是腳后跟。和阿克琉斯一樣，強(qiáng)大的HDFS和對(duì)象存儲(chǔ)都存在各自的致命弱點(diǎn)。3.HDFS阿克琉斯之踵--NameNodeHDFS最大的弱點(diǎn)是NameNode。HDFS最開始設(shè)計(jì)時(shí)并沒有考慮到今天的數(shù)據(jù)規(guī)模，NameNode一直以來都是垂直擴(kuò)展方案。在ScaleUp的擴(kuò)展模式下，隨著單個(gè)HDFS集群、單個(gè)NameSpace文件數(shù)量增加，NameNode內(nèi)存開銷也在增大。由于單個(gè)節(jié)點(diǎn)內(nèi)存是有上限的，NameNode運(yùn)維是很恐怖的，F(xiàn)ailover需要耗時(shí)兩到三個(gè)小時(shí)。因此，在高可靠性、高可用性場(chǎng)景下，NameNode是不會(huì)做到這么大實(shí)例的。業(yè)界常用的解決辦法是：聯(lián)邦架構(gòu)1.0，ViewFs+多集群；聯(lián)邦架構(gòu)2.0，Router-basedFederation(RBF)聯(lián)邦方案。這兩種方案表面上解決了橫向擴(kuò)展難題，對(duì)用戶而言并不是完全透明的。針對(duì)路徑感知、擴(kuò)縮容感知等情況，仍然需要知道Router的細(xì)節(jié)。因此，并沒有透明的、簡(jiǎn)單的橫向擴(kuò)展方案實(shí)現(xiàn)HDFS單個(gè)NameSpace對(duì)10億、100億文件的管理。4.對(duì)象存儲(chǔ)阿克琉斯之踵--元數(shù)據(jù)對(duì)象存儲(chǔ)的弱點(diǎn)是元數(shù)據(jù)管理。比如，如何實(shí)現(xiàn)文件目錄改名？如果在硬盤上或者文件系統(tǒng)中執(zhí)行mv命令則可以把目錄改名，在文件系統(tǒng)執(zhí)行這個(gè)命令的過程中是原子操作，只需要找到這個(gè)目錄名字對(duì)應(yīng)的inode改名即可。在對(duì)象存儲(chǔ)中沒有原生目錄，只是把目錄路徑看作一個(gè)字符串作為對(duì)象的key，所有對(duì)象都是平鋪的，彼此之間沒有任何關(guān)聯(lián)的數(shù)據(jù)結(jié)構(gòu)。在對(duì)象存儲(chǔ)中保存對(duì)象要先創(chuàng)建一個(gè)bucket，這個(gè)bucket的名字其實(shí)非常形象，意味著裝進(jìn)去的那些對(duì)象沒有任何層次結(jié)構(gòu)。假設(shè)以/foo前綴的key有100萬個(gè)對(duì)象，如果要想把/foo改個(gè)名，會(huì)對(duì)元數(shù)據(jù)做全量索引搜索，找到所有以/foo為前綴的對(duì)象，可能是10個(gè)、10萬個(gè)、100萬...取決于key的命名，找到全部符合key前綴的對(duì)象后做一次完整的IO拷貝，數(shù)據(jù)可能是1G、100G、100T...取決于這些對(duì)象的數(shù)據(jù)量，使用新名字拷貝為一批新的對(duì)象完成后，再去刪掉舊的對(duì)象。這就是在對(duì)象存儲(chǔ)里面完成一個(gè)rename的過程。Mv這個(gè)命令在文件系統(tǒng)里面是個(gè)原子操作，在對(duì)象存儲(chǔ)中顯然不是原子操作，它有多個(gè)步驟，并且這些步驟的執(zhí)行是沒有事務(wù)保障的，實(shí)際上這個(gè)過程是分階段完成的。因此可能會(huì)引起兩個(gè)問題：第一，假如運(yùn)行到一半出現(xiàn)宕機(jī)，重啟后只能去重新執(zhí)行rename操作，重新拷貝、重新刪除，時(shí)間代價(jià)是很高的；第二，機(jī)器沒掛，但是過程中消耗IO量比較大，需要幾秒、幾分鐘、幾小時(shí)、甚至更長(zhǎng)的時(shí)間，在這個(gè)過程中若別的進(jìn)程同時(shí)在訪問數(shù)據(jù)，則會(huì)引起數(shù)據(jù)不一致的問題，這也是對(duì)象存儲(chǔ)大多是最終一致性的原因。對(duì)象存儲(chǔ)僅僅對(duì)最終一致性負(fù)責(zé)，過程中的耗時(shí)情況、開始時(shí)間、結(jié)束時(shí)間等對(duì)開發(fā)者也是不可見的。運(yùn)行在這個(gè)過程中的問題是無法復(fù)現(xiàn)的，因?yàn)楫?dāng)我們想復(fù)現(xiàn)的時(shí)候，過程已經(jīng)執(zhí)行結(jié)束了。什么時(shí)候要改名呢？舉個(gè)ETL的例子。比如在執(zhí)行Spark任務(wù)時(shí)，在進(jìn)行mapreduce計(jì)算時(shí)，有一些分支結(jié)束后會(huì)先提交到臨時(shí)目錄中，當(dāng)所有的worker都結(jié)束時(shí)，最后要將臨時(shí)目錄改名。在HDFS里最后提交的過程是可以忽略不計(jì)的；在云上用對(duì)象存儲(chǔ)運(yùn)行同樣的任務(wù)，commit時(shí)可能會(huì)持續(xù)很長(zhǎng)一段時(shí)間，就是rename過程的開銷有很大不同。執(zhí)行l(wèi)s命令的效率在不同存儲(chǔ)系統(tǒng)上也有質(zhì)的差別。大家會(huì)有意識(shí)的不在單一目錄下放太多文件，比如某個(gè)目錄下有100萬文件運(yùn)行l(wèi)s時(shí)會(huì)卡、1000萬文件運(yùn)行l(wèi)s會(huì)卡更久。在對(duì)象存儲(chǔ)里是什么樣的？在文件系統(tǒng)中，整個(gè)目錄樹對(duì)應(yīng)了一個(gè)樹形的數(shù)據(jù)結(jié)構(gòu)，在對(duì)象存儲(chǔ)中所有對(duì)象是平鋪的，沒有樹型數(shù)據(jù)結(jié)構(gòu)，會(huì)把所有的key的字符串前綴做個(gè)全文索引，上圖展示了針對(duì)不同文件數(shù)量在對(duì)象存儲(chǔ)S3中執(zhí)行l(wèi)isting帶來時(shí)延的差別。在Hudi文檔測(cè)試中，100個(gè)文件50ms、100K個(gè)文件9s，在對(duì)象存儲(chǔ)里面對(duì)大量對(duì)象做listing遍歷時(shí)，性能代價(jià)是不能忽視的。為了解決這個(gè)問題，Hudi提出了MetadataTable改進(jìn)方案用于獨(dú)立記錄所有元數(shù)據(jù)，因此不需要在對(duì)象存儲(chǔ)里直接調(diào)ls了，使用MetadataTable會(huì)更快。在公有云對(duì)象存儲(chǔ)上，所有訪問都是通過HTTPAPI調(diào)用的，并有QPS限制，以S3舉例，它在每個(gè)前綴上默認(rèn)的get請(qǐng)求QPS是5000，put請(qǐng)求QPS是3500，如果達(dá)到QPS上限則返回400錯(cuò)誤碼，但是它會(huì)在一段時(shí)間后使用前綴進(jìn)行再分配，慢慢地增加這個(gè)QPS，這可能是在系統(tǒng)沒有達(dá)到一定負(fù)載程度下開發(fā)者難以注意的問題，等碰上了想解決這個(gè)問題時(shí)，就會(huì)發(fā)現(xiàn)已經(jīng)很困難了，因?yàn)檎麄€(gè)prefix前綴可能已經(jīng)按照業(yè)務(wù)最理想的表達(dá)方式寫過了。為了解決這個(gè)問題，在Iceberg里做了優(yōu)化，設(shè)定一個(gè)參數(shù)聲明一下，如果是對(duì)象存儲(chǔ)，可以enable這個(gè)開關(guān)，后面也會(huì)進(jìn)一步講到。5.Lakehouse對(duì)文件系統(tǒng)的需要Lakehouse文檔中，對(duì)文件系統(tǒng)提出三個(gè)具體的需求：一、原子語義，比如上文提到的對(duì)象存儲(chǔ)上rename是沒有原子語義的，但希望Lakehouse下面的存儲(chǔ)系統(tǒng)是有原子語義的；二、并發(fā)寫的能力；三、強(qiáng)一致性的能力，比如上文提到的在對(duì)大量對(duì)象改名的過程中做listing出現(xiàn)不一致的情況是不符合一致性要求的。 JuiceFS的設(shè)計(jì)2016年，我們有了做JuiceFS的想法。當(dāng)時(shí)在Databricks內(nèi)部的S3存儲(chǔ)平臺(tái)上跑批大量的大數(shù)據(jù)任務(wù)時(shí)碰到了很多痛點(diǎn)，當(dāng)時(shí)還沒有提出DataLake、Lakehouse等概念，因此我們開始思考能否把文件系統(tǒng)的能力和云上S3的優(yōu)勢(shì)結(jié)合起來。比如文件系統(tǒng)里面有原生的目錄樹、有一套使用方便的API、有強(qiáng)一致性保障等；S3有彈性伸縮、免運(yùn)維等好處。于是我們提出將這兩種存儲(chǔ)系統(tǒng)的優(yōu)勢(shì)在云上融合，為開發(fā)者提供更適合大數(shù)據(jù)使用的存儲(chǔ)方案。1.什么是JuiceFS實(shí)際使用中，S3雖然解決了一些規(guī)模上的瓶頸，但還有元數(shù)據(jù)性能差、沒有原子rename、沒有強(qiáng)一致性保證、并發(fā)寫入限制、APIQPS限制、API調(diào)用成本高等痛點(diǎn)。比如，將一個(gè)HDFS的集群搭起來后，無論如何使用它，都不會(huì)為每一個(gè)request付錢，但是S3上的每一個(gè)request是要交錢的，并且費(fèi)用是不同的，分兩類計(jì)費(fèi)。其中ListingAPI是GetAPI價(jià)格的十倍。在ETL的過程中需要大量使用ListingAPI做數(shù)據(jù)發(fā)現(xiàn)，成本極高。如何解決客戶使用對(duì)象存儲(chǔ)的痛點(diǎn)、難點(diǎn)是當(dāng)時(shí)和今天仍然迫切的需求。無論是DataLake，還是Lakehouse，還是其他的概念，底層都需要有一個(gè)更好用、更適合的文件系統(tǒng)，才能解決今天這個(gè)數(shù)據(jù)規(guī)模上的各種痛點(diǎn)。從2017年起，JuiceFS項(xiàng)目啟動(dòng)，當(dāng)時(shí)還不是開源的，以服務(wù)云上客戶為核心，通過云服務(wù)方式做了6年。在這個(gè)過程中，我們發(fā)現(xiàn)不僅大數(shù)據(jù)上有文件存儲(chǔ)需求，其他很多場(chǎng)景也有同樣的需求，因此我們?cè)?021年發(fā)布了開源社區(qū)版，為開發(fā)者提供了更開放的選擇，在不同的場(chǎng)景中可以做一些自定義組合。不論是商業(yè)版還是社區(qū)版使用的用戶都有很多，主要圍繞著AI和大數(shù)據(jù)這兩個(gè)場(chǎng)景。2.JuiceFS架構(gòu)社區(qū)版架構(gòu)圖如上圖左所示。圖中三個(gè)虛線框分別代表了文件系統(tǒng)中最主要的三個(gè)核心元素，左下角是元數(shù)據(jù)引擎、右下角是數(shù)據(jù)持久化引擎、上面是用來訪問數(shù)據(jù)的客戶端。這三個(gè)組件和2005年Google發(fā)表的第一篇GoogleFileSystem論文里的頂層架構(gòu)是一樣的。那篇論文的第一個(gè)開JuiceFS。JuiceFS與HDFS、Ceph等其他分布式文件系統(tǒng)的區(qū)別是什么？數(shù)據(jù)持久化這一層以前都是面向很多節(jié)點(diǎn)、很多磁盤的，需要先將這些節(jié)點(diǎn)和磁盤做一個(gè)管理服務(wù)，包括數(shù)據(jù)寫入方式、副本配置方式、IO讀寫路徑等，類似HDFSDataNode的角色。JuiceFS的實(shí)現(xiàn)并不是這樣，它借助公有云已經(jīng)提供的對(duì)象存儲(chǔ)作為基礎(chǔ)設(shè)施。對(duì)象存儲(chǔ)管理海量硬盤的能力已經(jīng)很強(qiáng)大了。我們將S3或者其他對(duì)象存儲(chǔ)看成一個(gè)無限容量、彈性伸縮的大硬盤，其中MetadataEngine相當(dāng)于這塊硬盤的分區(qū)表，比如當(dāng)我們的電腦需要增加硬盤時(shí)，首先要在電腦插上一塊硬盤，然后格式化一個(gè)分區(qū)格式。MetadataEngine就相當(dāng)于格式化出來的一個(gè)分區(qū)表，用于管理文件系統(tǒng)里面目錄樹、文件名、時(shí)間戳等信息。JuiceFS的MetadataEngine引擎與以往的分布式文件系統(tǒng)最大的不同是，JuiceFS是一個(gè)插件MetadataEngine這樣設(shè)計(jì)可以借助已成熟的存儲(chǔ)引擎為社區(qū)的開發(fā)者降低使用門檻，因?yàn)樵谏鐓^(qū)中推廣自研的分布式引擎并讓用戶理解、掌握、積累運(yùn)維經(jīng)驗(yàn)的過程是很漫長(zhǎng)的，而如何運(yùn)維好Redis、MySQL已經(jīng)有非常豐富的經(jīng)驗(yàn)，而且在云上有托管服務(wù)，不需要用戶自己運(yùn)維。盡管這些引擎經(jīng)過了十幾年的驗(yàn)證、成熟穩(wěn)定，但是它們作為文件系統(tǒng)使用不一定是最優(yōu)的，要結(jié)合使用場(chǎng)景來看。JuiceFS在開源之前已經(jīng)做了三年多的商業(yè)化，在此期間我們發(fā)現(xiàn)市場(chǎng)上對(duì)于文件存儲(chǔ)的應(yīng)用有著非常廣泛的需求，不只是大數(shù)據(jù)和AI場(chǎng)景。在不同的場(chǎng)景上，大家對(duì)于文件規(guī)模、容量、性能、可靠性、可用性、成本這些維度的優(yōu)先級(jí)排序是不同的。我們認(rèn)為架構(gòu)的選擇上沒有銀彈，沒有哪一款引擎能夠完美解決所有場(chǎng)景需求，因此我們做一款更開放式的插件引擎，用戶可以結(jié)合自己場(chǎng)景、經(jīng)驗(yàn)，選擇一個(gè)合適的存儲(chǔ)引擎做JuiceFS的MetadataEngine。DataStorage持久化也是插件式架構(gòu)，兼容了現(xiàn)在市場(chǎng)上所有的對(duì)象存儲(chǔ)服務(wù)。Client客戶端與以前的文件系統(tǒng)的差別在于JuiceFS兼容了三種最主流的標(biāo)準(zhǔn)：首先，提供了POSIX的完整兼容，POSIX從上個(gè)世紀(jì)80年代開始迭代到現(xiàn)在，是文件系統(tǒng)標(biāo)準(zhǔn)的最大集，因此完整地支持POSIX標(biāo)準(zhǔn)就意味著已經(jīng)能夠和過去40年的各種應(yīng)用系統(tǒng)直接兼容；其次，提供了JavaSDK完整兼容HDFSAPI。在大數(shù)據(jù)生態(tài)里面中只有POSIX是不夠的，JuiceFS同時(shí)兼容HDFS的2和3版本；最后，提供了S3API兼容，S3從2006年發(fā)布到現(xiàn)在也已經(jīng)積累了大量用S3API寫的代碼。這樣，JuiceFS完美解決了更換存儲(chǔ)系統(tǒng)需要改一遍代碼的難題。關(guān)于數(shù)據(jù)存儲(chǔ)在S3上面的性能優(yōu)化問題，JuiceFS在客戶端里面做了緩存層。意味著在大數(shù)據(jù)、AI讀場(chǎng)景下，所有讀到的數(shù)據(jù)都可以在客戶端建立緩存，下次再讀同樣數(shù)據(jù)的時(shí)候就可以在緩存中找到了，在緩存層可以用SSD做性能提升。因此，對(duì)于數(shù)倉查詢、AI模型訓(xùn)練等場(chǎng)景，讀緩存發(fā)揮著非常重要的作用。JuiceFS內(nèi)部的功能實(shí)現(xiàn)如上圖右側(cè)所示。很多用戶會(huì)問JuiceFS和Alluxio對(duì)比有什么區(qū)別？Alluxio的定位是在現(xiàn)有的存儲(chǔ)系統(tǒng)之上提供緩存加速層，在實(shí)際項(xiàng)目中存儲(chǔ)系統(tǒng)大多是對(duì)象存儲(chǔ)系統(tǒng)；JuiceFS的定位是為云環(huán)境設(shè)計(jì)的分布式文件系統(tǒng)，可以通過緩存機(jī)制加速數(shù)據(jù)訪問。在使用JuiceFS時(shí)，寫入文件與HDFS類似，會(huì)做大文件拆分，將文件拆分后的數(shù)據(jù)塊存儲(chǔ)在對(duì)象存儲(chǔ)中，一般按4M的block塊存儲(chǔ)在對(duì)象存儲(chǔ)里。這樣的架構(gòu)設(shè)計(jì)提供了完整POSIX兼容、數(shù)據(jù)存儲(chǔ)強(qiáng)一致性、覆蓋寫和追加寫、緩存一致性保障等核心能力。JuiceFS是一個(gè)文件存儲(chǔ)的服務(wù)，而不是透明的緩存加速層。3.存儲(chǔ)系統(tǒng)比較對(duì)HDFS、對(duì)象存儲(chǔ)、JuiceFS進(jìn)行對(duì)比，如上圖所示。宏觀上JuiceFS在單個(gè)namespace下可以存百億級(jí)的文件。不過JuiceFS支持了十幾種不同的元數(shù)據(jù)引擎，并不是每個(gè)引擎都能存百億。比如，TiKV的社區(qū)用戶實(shí)踐有很多過百億的，我們自研的商業(yè)引擎也可以，但是Redis和MySQL不能。一致性上實(shí)現(xiàn)了Read-After-Close強(qiáng)一致性保障。容量管理上，基于S3的底層存儲(chǔ)是彈性的。在完整的POSIX兼容情況下，原子重命名、List的性能等都得到了保障。在兼容性方面也做了很強(qiáng)的優(yōu)化。通常兼容性是選擇新系統(tǒng)時(shí)需要考慮的重要事情，即不用修改代碼即可引入新系統(tǒng)。4.JuiceFS與HDFS、對(duì)象存儲(chǔ)元數(shù)據(jù)性能比較JuiceFS與HDFS、對(duì)象存儲(chǔ)元數(shù)據(jù)性能比較，如上圖所示，比較點(diǎn)有兩個(gè)：吞吐和時(shí)延。在吞吐量上，JuiceFS比對(duì)象存儲(chǔ)和HDFS更有優(yōu)勢(shì)，在單機(jī)情況下或者同配置情況下JuiceFS可以獲得更高QPS。在時(shí)延上，JuiceFS執(zhí)行rename操作時(shí)，時(shí)延優(yōu)勢(shì)是最明顯的，對(duì)象存儲(chǔ)和文件系統(tǒng)之間相差近100倍。5.JuiceFS緩存加速與HDFS性能比較基于TPC-DS數(shù)據(jù)集，測(cè)試HDFS和JuiceFS查詢性能之間的比較，如上圖所示。HDFS具備存算耦合、數(shù)據(jù)本地性的特征，實(shí)現(xiàn)查詢性能加速。存算分離以后會(huì)下降多少呢？TPC-DS前10個(gè)query重復(fù)執(zhí)行，即數(shù)據(jù)預(yù)熱到緩存中時(shí)，JuiceFS與HDFS的表現(xiàn)是一樣的。6.Lakehouse對(duì)文件系統(tǒng)的需要在QPS限制上，S3有自己的限制，其他公有云也有類似的限制。Iceberg場(chǎng)景中，在key前面去加一個(gè)隨機(jī)哈希值。JuiceFS自動(dòng)將文件切分成很多prefix，這個(gè)多級(jí)的前綴也能夠提升API的QPS。的做法是，在對(duì)象存儲(chǔ)block后，形成多級(jí)的除此之外，因?yàn)橛芯彺娴拇嬖冢跀?shù)據(jù)讀取時(shí)，可以優(yōu)先命中緩存，進(jìn)而降低了后端對(duì)象存儲(chǔ)在存儲(chǔ)和QPS的壓力。其次，listing、rename等操作只發(fā)生在JuiceFS元數(shù)據(jù)引擎中，不用再請(qǐng)求到對(duì)象存儲(chǔ)，因此，JuiceFS對(duì)下面對(duì)象存儲(chǔ)的API依賴就只有g(shù)et、put、delete這三個(gè)最基礎(chǔ)API了。用戶案例分享1.用戶案例-某上市集團(tuán)K12教育業(yè)務(wù)某上市集團(tuán)K12教育業(yè)務(wù)數(shù)據(jù)平臺(tái)。在數(shù)據(jù)湖場(chǎng)景上，通過Hudi+JuiceFS方式收集上游不同數(shù)據(jù)源CDC的數(shù)據(jù)。以前在沒有數(shù)據(jù)湖情況下，ETL是幾小時(shí)的時(shí)延；引入數(shù)據(jù)湖后，將原始數(shù)據(jù)CDC入湖，數(shù)據(jù)馬上就可以被查詢引擎使用，數(shù)據(jù)時(shí)延從幾小時(shí)縮短到10分鐘。2.用戶案例-豆瓣豆瓣在2019年完成了將所有作業(yè)從機(jī)房遷移上云的過程。在機(jī)房中使用的是MooseFS，它也是一款支持POSIX的文件系統(tǒng)。上云之后沒有選擇重建MooseFS，而是用了云上托管的JuiceFS服務(wù)。由于兩個(gè)POSIX文件系統(tǒng)之間很容易平移，所以它把日志、CSV、數(shù)倉的列存文件、算法等這些各種各樣的數(shù)據(jù)都遷移了上來,并在數(shù)倉上增加了Iceberg，與上一個(gè)案例類似，也是引入了數(shù)據(jù)庫CDC采集，為豆瓣的一些算法提供更實(shí)時(shí)的數(shù)據(jù)訪問。今天用戶所有收藏、打分、點(diǎn)擊等數(shù)據(jù)，都可以更快地進(jìn)入數(shù)據(jù)湖里供給算法使用。從BI到AI前文中分析了不同存儲(chǔ)系統(tǒng)之間的差異。從業(yè)務(wù)角度來看，在過去6年中我們發(fā)現(xiàn)越來越多的數(shù)據(jù)平臺(tái)將數(shù)據(jù)提供給算法團(tuán)隊(duì)使用，包括機(jī)器學(xué)習(xí)和深度學(xué)習(xí)。從最開