大數(shù)據(jù)開發(fā)的存儲技術(shù)探索與實踐

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