理想汽車 x JuiceFS：從 Hadoop 到雲原生的演進與思考

語言: CN / TW / HK

時間 2022-08-24 20:06:48 Juicedata

主題:

理想汽車在 Hadoop 時代的技術架構

首先簡單回顧下大資料技術的發展，基於我個人的理解，將大資料的發展分了4個時期：

第一個時期： 2006 年到 2008 年。2008 年左右，Hadoop 成為了 Apache 頂級專案，並正式釋出了 1.0 版本，它的基礎主要是基於谷歌的三駕馬車，GFS、MapReduce、BigTable 去定義的。

第二個時期： 2009 年到 2013 年階段。雅虎、阿里、Facebook 等企業對大資料的應用越來越多。2013 年底 Hadoop 正式釋出 2.0 版本。我有幸在 2012 年的時候開始接觸大資料，用 Hadoop 1.0 加 Hive 的模式體驗了下，當時感覺很神奇的，大資料用幾臺機器就可以快速解決原來用 SQL Server 或者 MySQL 解決不了的問題。

第三階段：2014 年到 2019 年，這段時間發展的非常快，期間 Spark、Flink 都成為了 Apache 頂級專案。在這個快速爬升期的過程中，我們還嘗試用過 Storm，後來 Storm 就被 Flink 所替代了。

第四階段：從 2020 年至今，2020 年 Hudi 從 Apache 畢業成為頂級專案之後，我個人理解資料湖進入到整個發展的成熟期，到了大資料的資料湖 2.0 階段。資料湖主要三個特點，首先是統一、開放式的儲存，其次是開放式的格式，以及豐富的計算引擎。

整體的發展過程中，大資料主要是有幾個特點，就是大家常說的四個“V”：規模性（Volume）、高速性（Velocity）、多樣性（Variety）、價值性（Value）。現在還有第五個“V”（Veracity），資料的準確性和可信賴度。資料的質量是一直被人詬病的，希望行業裡能有一套標準把資料湖的質量去做提升，這個可能是資料湖 2.0 出現的標準，因為出現了 Hudi、Iceberg 這些專案，都是想把整個資料湖的管理做好。

個人覺得 Hadoop 是大資料的一個代名詞，但是大資料並不只有 Hadoop。大資料是在發展過程中由多個元件整合之後形成的一套解決大量資料加工處理和使用的解決方案。這幾年，大家基本上認為 Hadoop 是在走下坡路的，首先是 Hadoop 商業化公司 Cloudera 和 Hortonworks 的合併和退市，原來的商業模式無法延續；也面臨著快速增長的雲供應商在成本和易用性上的挑戰，以及 Hadoop 本身生態系統的日益複雜。

理想汽車大資料平臺當前架構

在這個階段，理想汽車的大資料平臺如上圖所示。理想汽車用了很多開源的元件。

傳輸層： Kafka 和 Pulsar 。平臺構建初期整體都用的 Kafka，Kafka 的雲原生能力比較差，Pulsar 在設計之初就是按照雲原生架構設計的，並且有一些非常適合 IoT 場景的能力，和我們的業務場景也比較匹配，所以我們近期引進了 Pulsar。
儲存層是 HDFS + JuiceFS。
計算層目前的主要的計算引擎是 Spark 和 Flink，這些計算引都是跑在現在的 Yarn 上。三個計算引擎是通過 Apache Linkis 去管理的，Linkis 是微眾銀行開源的，目前我們對 Linkis 用的也是比較重的。
右邊是三個資料庫，第一個 MatrixDB ，它是一個商業版的時序資料庫，TiDB 主打做 OLTP 和 OLAP 的混合場景，目前我們主要用它來做 TP 的場景。StarRocks 負責 OLAP 的場景。
ShardingSphere，是想要用它的 Database Plus 的概念去把底下的資料庫統一的去做一個閘道器層的管理。目前還在探索階段，有很多新增特性我們都很感興趣。
再往右，Thanos 是一個雲原生的監控方案，我們已經將元件、引擎和機器的監控都整合到 Thanos 方案裡。
應用層是我們目前的四個主要的中臺產品，包括資料應用、資料開發、資料整合和資料治理。

特點

大家通過大資料平臺的現狀可以發現一些特點：

第一，整個方案的元件是比較多的，使用者對這些元件的依賴性強，且元件之間互相的依賴性也比較強。建議大家在未來元件選型的時候儘量選擇雲原生化比較成熟的元件。
第二，我們的資料是有明確的波峰波谷。出行場景一般都是早高峰晚高峰，週六週日人數會比較多。
第三個特點，我們資料的熱度基本上都是最熱的，一般只訪問最近幾天或者最近一週的資料。但是產生了大量的資料，有的時候可能需要大量回溯，因而資料也需要長久的儲存，這樣對資料的利用率就差了很多。

最後，整個資料體系目前從檔案層面看缺少一些有效的管理手段。從建設至今，基本上還是以 HDFS 為主，有大量的無用資料存在，造成了資源的浪費，這是我們亟待解決的問題。

大資料平臺的痛點

第一，元件多，部署難度高、效率低。圍繞 Hadoop 的大資料元件有 30 多個，常用的也有 10 幾個之多。有些元件之間有強依賴和弱依賴，統一的配置和管理變得非常複雜。
第二，機器成本和維護成本比較高。為了業務的穩定執行，離線和實時叢集進行了分開部署。但上面提到的業務特點，我們業務波峰波谷現象明顯，整體利用率不高。叢集元件繁多需要專門人員管理和維護。
第三，跨平臺資料共享能力。目前跨叢集共享資料只能通過 DistCp 方式同步到其他 Hadoop 叢集。無法方便快捷的同步到其他平臺和伺服器上。
第四，資料的安全和隱私合規。基於不同的資料安全需求，普通使用者通過 Ranger 進行管理，特殊安全需求只能通過構建不同叢集並設定單獨 VPC 策略的方式來滿足，造成很多資料孤島和維護成本。

理想汽車雲原生的演進與思考

首先，先簡單分享一下我個人理解的雲原生：

第一，雲原生是在雲端計算的基礎上衍生出來的。現在大家用的如阿里雲、 AWS、騰訊雲、百度雲等雲廠商，最開始提供的都是 IaaS 層的技術服務，幫企業把儲存、計算、網路這些這些最基礎的東西封裝好統一管理，企業只需要在上面申請伺服器就可以了。申請了伺服器之後，這些伺服器還是由雲廠商來管理的，也就是大家傳統的上雲操作。

雲原生離不開雲端計算，籠統地說，雲原生屬於雲端計算的 PaaS 層服務，主要是面向開發者的一類應用。雲原生必須在雲上安裝，是一種基於雲端計算的軟體開發應用方式。雲+原生，雲即雲端計算，原生則是摒棄傳統的運維開發框架，通過容器化、DevOps，還有微服務架構實現應用彈性伸縮和自動化部署，充分利用雲端計算資源實現在最少的空間裡做最大的事。也能解決我們目前大資料系統的一些痛點，比如擴充套件性和維護性都比較差，需要大量人力與時間等。

上圖簡單列了一下雲原生的幾個時間點

第一個階段， AWS 提出了雲原生的概念，並且在 2006 年推出了 EC2，這個階段是伺服器階段，上文提到的雲端計算階段。
第二個階段，雲化階段，主是在開源 Docker 釋出和谷歌開源了 Kuberneters 之後。Kubernetes 是一個輕便的和可擴充套件的開源平臺，用於管理容器化應用和服務。通過 Kubernetes 能夠進行應用的自動化部署和擴縮容。
第三個階段，2015 年的時候成立了 CNCF 基金會，在主推雲原生概念，幫助雲原生整體發展的更好。最後是 Knative 的開源，Knative 一個很重要的目標就是制定雲原生、跨平臺的 Serverless 編排標準。衍生到現在，已經是雲原生 2.0 階段，即 Serverless 這個階段。我個人理解大資料的發展應該也是朝著 Serverless 的方向去發展。比如現在 AWS 整個線上的服務基本上都做到了 Serverless。

大資料雲原生架構

接下來介紹一下理想汽車大資料平臺在雲原生化之後元件發生的變化：

儲存層，雲原生化之後所有的儲存基本上都是物件儲存了。上面的架構圖引出了 Lustre，下文會詳細介紹。大家可以理解為「雲端儲存」這一層主要是以 JuiceFS 來管理物件儲存和 Lustre 並行分散式檔案系統（注：由於 Lustre 的單副本問題，我們目前也在考慮使用雲服務商提供的並行檔案系統產品）。
容器層，主要是在計算、儲存、網路之上，全部都用 Kubernetes 加 Docker 來替代，所有的元件都是在這上面生長出來的。
元件部分，首先是大資料計算框架，我們可能會廢棄掉 Hive，直接沿用 Spark 和 Flink，通過 Hudi 去做資料湖 2.0 的底層能力支撐並逐步替換HDFS。
中介軟體部分，除了 Pulsar 以外還有 Kafka，目前 Kafka 的雲原生化做的並不是特別好，我個人更傾向於用 Pulsar 去替換 Kafka。目前線上已經使用Linkis適配了所有Spark引擎，後面會進行Flink的適配和整合。ShardingSphere 在 5.1.2 版本剛剛支援雲原生，我們會按計劃進行場景驗證和能力探索。
資料庫層，還是 TiDB、StarRocks、MatrixDB，目前這三個資料庫已經有云原生的能力，它們都支援物件儲存。但這一塊還沒有單獨去測過，我們目前用的還都是物理機。因為對於資料庫來說，當前物件儲存提供的IO能力還無法滿足資料庫的效能要求，會使得資料庫的整體效能大打折扣。
運維方面，由 Thanos 方案多加了一個 Loki，主要是做雲原生的日誌收集。但是 Loki 和 Thanos 只是其中兩個，未來我理解應該會朝著阿里開源的SREWorks能力看齊，把整個的質量成本效率和安全全部都封在綜合運維能力裡邊，這樣就可以把整個的雲原生管理起來。
可觀測性，雲原生領域最近比較熱門的概念。現在大家做的元件，有一些是在有熱度之後，才開始發展雲原生的，它並不是一開始生在雲上，它只是後面希望長在雲上。這種情況下它會遇到一些問題，第一個問題，就是沒有全面的可見性的監控。我們考慮後續如何把這些元件整體的出一個方案，在所有元件上到雲原生後可以有效的監控。

總結一下，我個人覺得大資料未來的雲原生基本上就是：

統一使用雲原生的儲存作為所有元件（包括資料庫）的底層儲存
所有元件都執行在容器中
使用 Serverless 架構服務上層應用

但是這樣也給目前的資料平臺產品帶來挑戰，就是如何設計具備 Serverless能力的產品來給使用者使用。

大資料雲原生的優勢

第一點，存算分離，彈性伸縮。使用物理機部署 Hadoop 之後，如果需要擴容縮容還需要去聯絡運營商，並且可能會有很長的週期，存算分離很好地解決了這個問題。其次是按需付費，不用購買閒置資源，目前我們整個的業務場景的資料是有波峰波谷的，波峰的時候需要準備機器，波谷的時候需要撤機器，但現在是做不到的。現在我們基本上是把所有的機器都堆到波峰，波峰的時候能滿足需求，穩定不失敗，但它在波谷的時候最少 12 個小時左右是閒置的，這種情況下資源也是要付費的。雲原生之後我們就可以不用再為此買單了。

第二點，自動化部署和可運維性。Kubernetes 是支援 DevOps 整合化的部署方案的。這樣我們的元件整體可以實現快速的部署（比如通過 Helm chart），把元件運維的能力下沉到雲原生平臺上，這樣大資料就不需要考慮元件運維場景了。

第三點，物件儲存。物件儲存是雲端計算推出的最核心最主要的產品。物件儲存的好處不言而喻了，易擴充套件，儲存空間無上下限，單價比較低，而且物件儲存還分為低頻儲存、歸檔儲存等多種儲存型別，進一步降低儲存成本，資料就可以存更長時間。同時成本可控，高可靠，操作複雜性低也都是物件儲存的優勢。

第四點，安全和合規性。雲原生之後可以實現專用名稱空間，多租戶隔離，遠端認證。目前我們做到的基本上都是網路層面上的隔離，HDFS的檔案管理大家公認的方案是Ranger。通過 Ranger 去管理 HDFS 的目錄許可權，也能管理如 Hive server、HBase、Kafka 的一些許可權，但是相對而言這些許可權都會偏弱一些。

還有一個方案是 Kerberos，整個大資料元件的安全性會提高很多，但是它有很多的成本，它任何一個請求都要去驗證。這個方案目前我們沒有使用過，和我們的叢集環境和場景有關係，我們基本上都是內網的，並不對外提供服務。如果大家做的大資料專案需要對外網提供一些服務，還是需要有強認證，不然資料很容易洩露。

大資料雲原生的難點

大資料雲原生的難點同樣也是存在的。

第一，大資料相關的元件是比較多的，同時 Kubernetes 的更新比較快，元件和元件之間交叉之後，相容性、複雜性和擴充套件性，都會存在問題。

第二，資源的分配和再分配。Kubernetes 是通用的容器資源排程工具，很難滿足不同大資料元件的資源使用場景。大資料場景下資源使用會比較大，請求頻率高，每次啟動的 pod 的數又會比較多，這種情況下，目前沒有什麼好的方案。目前我們正在看 Fluid 這個方案，Fluid 也實現了 JuiceFS 的 runtime，這個也是我們後邊要去深入調研的，Fluid 目前宣稱是可以支援大資料和 AI 的，並不是只有 AI 的場景，因為大資料和 AI 的場景是比較像的，都是資料密集型的操作，Fluid 在計算效率和資料抽象管理方面是有了一些突破性的進展。

第三點，物件儲存也是有一些劣勢的。物件儲存的劣勢是元資料操作效能低、和大資料元件相容性差、最終一致性等問題。

最後一點，就是資料密集型應用。存算分離模式無法滿足大資料、AI 等資料密集型應用在計算執行效率、資料抽象管理方面的需求。

JuiceFS 在大資料雲原生方案的探索和落地

在 JuiceFS 開源之前我們就已經關注並做了一些落地的測試，開源版上線之後，我們就馬上上線使用了。上線的時候也遇到了一些許可權的問題和幾個小的 bug，社群非常給力，快速地幫我們都解決了。

要下線 HDFS 是因為它的擴充套件性差，同時我們的資料量比較大，HDFS 的儲存成本比較高。在儲存了幾批資料後，物理機的空間就不夠了，而且需要的計算非常多。當時我們的業務發展還在初期，為了儘可能從資料中獲得價值，我們要保留儘可能多的資料。而且 HDFS 需要三副本，我們後來改成兩副本，但是兩副本還是有風險的。

在這個基礎上，我們深度測試了 JuiceFS，測試完成之後，我們很快就把 JuiceFS 引到我們的線上環境。把一些比較大的表從 HDFS 遷移到 JuiceFS 裡，緩解了我們的燃眉之急。

我們對 JuiceFS 比較看重的三點：

第一， JuiceFS 是多協議相容。完全相容 POSIX、HDFS 和 S3 協議，目前用下來都是百分百相容的，沒有遇到任何問題。
第二，跨雲的能力。當企業有一定規模之後，為了避免系統性風險，都不會只使用一個雲服務商。不會綁在一個雲上，都會是多雲操作的。這種情況下，JuiceFS 的跨雲資料同步的能力就起到了作用。
第三，雲原生的場景。JuiceFS 支援 CSI，目前 CSI 這個場景我們還沒有用，我們基本上都是用 POSIX 去掛載的，但是使用 CSI 的方式會更簡單更相容，我們現在也正在往雲原生上去發展，但整個的元件還沒有真正上到 Kubernetes。

JuiceFS 在理想汽車的應用

從 HDFS 將資料持久化到物件儲存

JuiceFS 開源之後，我們就開始嘗試把 HDFS 上的資料同步到 JuiceFS。開始同步的時候是使用 DistCp，結合 JuiceFS 的 Hadoop SDK 同步非常方便，整體遷移比較順利。之所以要把資料從 HDFS 遷移到 JuiceFS 上，是因為遇到了一些問題。

第一就是 HDFS 的存算耦合設計擴充套件性差，這個是沒有辦法解決的。我個人從一開始接觸大資料的認知就是大資料是必須要部署在物理機上的，而不是在雲主機。包括後來雲廠商推出的各類 EMR 系統，其實是在對 Hadoop 進行封裝，最近一兩年這些 EMR 系統都在逐漸去 Hadoop 化。

第二是 HDFS 難以適配雲原生化。現在的 HDFS 很難適配雲原生，因為它比較重，雖然社群一直在著重發力去做雲原生，但是我個人認為 Hadoop 的發展趨勢在走下坡路，未來應該以物件儲存為主。

第三，物件儲存也有一些弊病，它不能很好的適配 HDFS API，由於網路等原因效能跟本地盤比也相差很多，另外 list 目錄等元資料操作也很慢。我們通過 JuiceFS 做一些加速，測下來效能非常可觀，在有快取的情況下基本上可以媲美本地盤，基於此我們快速地將當前的場景直接切換到 JuiceFS 上。

平臺級別的檔案共享

第二個場景平臺級別的檔案共享。我們目前的整個排程系統、實時系統、開發平臺的共享檔案的資料全部都是存在 HDFS 上的，後續如果要是停止使用HDFS ，需要把這些資料遷移走。目前的方案是用 JuiceFS 對接物件儲存，通過應用層的服務，全部以 POSIX 的方式掛載上去，大家就可以無感地去請求 JuiceFS 裡的檔案。

JuiceFS 在這個場景滿足了我們大部分的應用需求，但還有些小場景存在問題。最初的設想是會把 Python 環境之類的都放進去，後來發現實操難度太大，因為 Python 環境裡邊有大量的小檔案，載入的時候還是會有問題。類似 Python 環境這種包含大量碎檔案的場景還是需要儲存在本地盤來操作。後續我們準備掛一塊塊儲存，專門來做這件事。

分享幾個我們之前使用 HDFS 遇到的問題：

第一個，當 NameNode 壓力大或 Full GC 時會有下載失敗的情況，目前暫時沒有一個完美的方案解決。我們的方案是儘量加記憶體，或者在下載包的時候加一些重試，避一避它的高峰期，但是這種情況下很難完全解決 HDFS 的問題，因為它終究是 Java 寫的，GC 的場景是沒有辦法避免的。

第二個，在跨系統裡面去使用 HDFS 的時候，比如我們有兩個叢集，現在要用一個叢集去共享檔案，基本上是不現實的，因為需要開通網路，來把兩個叢集之間打通或者應用上打通，這樣安全性是沒有辦法保證的。目前我們基本上就是兩個叢集是獨立各自維護自己的共享檔案。現在實時平臺（如 Flink 平臺）已經切換到 JuiceFS 上了，目前還是非常順利，沒有遇到什麼問題。

第三個，目前我們有大量的物理機部署，物理機部署都是單叢集的，沒有容災的策略，如果哪天機房出了一些災難性的問題，我們整個服務就不可用了。但是物件儲存它本身是跨機房，是同一個 region 裡面，應該都是有最少三個副本，雲廠商幫我們做到了備份。後續，我們可能會發展多雲，希望通過 JuiceFS 去共享一些高級別的檔案、核心的資料庫，包括一些核心的備份檔案，在多雲裡面去做備份。這樣就實現了多雲、多 region、多地域，就可以解決現在單點容災的問題。

海量資料跨平臺使用

另外一個場景，平臺和平臺之間全部都是通過 JuiceFS 去共享海量資料。我們這邊的共享的資料中第一類是路試車的資料，路試車會有大量的影片語音影象資料上傳，這些資料上傳了之後會直接進到 JuiceFS 裡，方便下游去做一些同步和共享，包括一些資料的篩查，再拿到 PFS 就是並行檔案系統，其下面掛載的是 SSD。這樣可以讓 GPU 利用率更高一些，因為物件儲存的能力是相對比較弱的，不然 GPU 的能力就會有大量浪費。

剩下的資料型別包括車輛上報的一些用於分析的日誌，埋點資料，還有一些國家平臺需要的車輛相關的訊號資料，這些資料都會進到數倉裡面去做一些分析。也會對這些資料做一些特徵資料提取，給演算法團隊去做模型訓練，或者做一些 NLP 的檢索和其他的更多場景。

雲原生儲存加速 - Lustre 作為讀快取（測試中）

現在我們正在測的是另外一個場景是在物件儲存層掛一個 Lustre 去給 JuiceFS 去做讀快取，通過 Lustre 的快取來幫助 JuiceFS 來提高讀取速度和快取命中率。

這樣可以有一個好處是我們現在用的都是物理機，它是有物理盤的，物理盤可以用來快取資料。但是因為計算任務在多個節點執行，快取的命中率不太高。這是因為社群版 JuiceFS 目前還不支援 P2P 的分散式快取，只支援單節點的本地快取，每一個節點可能會讀很多資料。這種情況下也給計算節點造成了一些磁碟的壓力，因為快取會佔用一定的磁碟空間。

目前我們的方案是通過 Lustre 來作為 JuiceFS 的讀快取。具體來說是根據需要快取的資料大小，將一個容量大概是 20~30TB 的 Lustre 檔案系統掛載到計算節點本地，然後將這個 Lustre 掛載點作為 JuiceFS 的快取目錄。這種情況下 JuiceFS 讀完資料之後，可以非同步快取到 Lustre 裡。這個方案可以有效解決快取命中率不高的問題，大幅度提高讀取效能。

如果我們在 Spark 場景往物件儲存裡直接寫資料的時候，會有頻寬和 QPS 的限制，如果寫入得太慢，上游的任務可能會發生抖動，在這種情況下可以通過 JuiceFS 的寫快取功能把資料先寫到 Lustre 裡，再非同步寫到物件儲存，這個方案在某些場景下是適用的。但是有一個問題是 Lustre 並不是一個雲原生的方案，它對於使用者來說是有感知的，使用者在啟動 pod 的時候需要顯式寫一個命令把它掛載上去。因此後面我們也希望對 JuiceFS 做一些改造，自動去識別物件儲存和 Lustre，然後自動實現一些快取的機制，這樣就不需要使用者來感知 Lustre 的存在。

目前這個方案的 PoC 已經完成，通過了基礎測試，接下來我們會在生產環境做大量的壓測，預計今年 Q3 應該可以正式上線覆蓋一些邊緣業務。

JuiceFS 在大資料雲原生的整體方案

從整體方案的架構圖可以看到，目前 JuiceFS 客戶端提供的三種方式我們都有用到。

如上圖左半部分所示，我們會有獨立的 Spark、Flink 叢集，我們通過 CSI Driver 的方式將 JuiceFS 直接掛載到整個叢集上，這樣使用者啟動 Spark 和 Flink 的時候，就完全感知不到 JuiceFS 到存在了，計算任務的讀寫都是通過物件儲存來完成。

這部分目前有一個有關 shuffle 的問題。因為 Spark 任務在計算過程中的 shuffle 階段需要大量的資料落盤，這其間產生的大量檔案讀寫請求對於底層儲存的效能要求較高。Flink 相對來說好一些，因為它是流式的，不需要大量的落盤。未來我們希望 JuiceFS 可以直接寫到 Lustre 裡，但是這樣就需要在 JuiceFS 裡做一些改造，通過客戶端整合的方式，讓 JuiceFS 直接讀寫 Lustre，這對於使用者來說就無感知了，也能提升 shuffle 階段的讀寫效能。

上圖右半部分的應用有兩個場景。一個是簡單查詢一下 JuiceFS 的資料，例如通過HiveJDBC來進行資料預覽，這個場景可以通過 S3 閘道器訪問 JuiceFS。

第二個是大資料平臺和 AI 平臺聯動的場景。比方說 AI 平臺的同事在日常工作中需要經常讀取樣本資料、特徵資料等，而這些資料通常是由大資料平臺上的 Spark 或者 Flink 任務產生的，並且已經儲存到了 JuiceFS 裡。為了不同的平臺之間能夠共享資料，在 AI 平臺的 pod 啟動時，會通過 FUSE 的方式將 JuiceFS 直接掛載到 pod 裡，這樣 AI 平臺的同事就可以通過 Jupyter 直接訪問 JuiceFS 裡的資料做一些模型的訓練，而不用像傳統的架構那樣在不同平臺之間重複拷貝資料，提高了跨團隊的協作效率。

因為 JuiceFS 使用 POSIX 標準的使用者、使用者組進行許可權控制，同時容器啟動預設是 root 使用者，導致許可權不好管控。因此我們對 JuiceFS 做了一個改造，通過一個認證 token 來掛載檔案系統，這個 token 裡面包含元資料引擎的連線資訊和其他一些許可權控制資訊。在某些需要同時訪問多個 JuiceFS 檔案系統的場景，我們使用 JuiceFS S3 閘道器並結合 IAM 策略做統一的許可權管理。

目前使用 JuiceFS 遇到的一些難題

第一點，基於使用者和使用者組的許可權管理功能比較簡單，在某些場景容器啟動預設為 root 使用者，許可權不好管控。

第二點，關於 JuiceFS Hadoop SDK 的配置優化。目前我們對 JuiceFS Hadoop SDK 進行優化的手段主要有三個配置：juicefs.prefetch、juicefs.max-uploads 和 juicefs.memory-size。其中在調優 juicefs.memory-size 配置的過程中遇到了一些問題，這個配置的預設值是 300MB，官方的建議是設定預設值 4 倍大小的堆外記憶體，也就是 1.2GB。目前我們大部分任務都是配置到 2GB 的堆外記憶體，但是有些任務即使配置了超過 2GB 的記憶體也偶爾會寫入失敗（HDFS 可以穩定寫入）。不過這個並不一定是 JuiceFS 的問題，也有可能是 Spark 或者物件儲存的原因導致。因此目前我們也在計劃把 Spark 和 JuiceFS 深度適配以後，再一步一步來找原因，爭取把這些坑都趟過去，在保證任務穩定的情況下把記憶體降下來。

第三點，由於整體架構（JuiceFS + 物件儲存 + Lustre）變得複雜，可能的故障點變多，任務的穩定性可能會有一些下降，需要其它容錯機制保障。例如 Spark 任務在 shuffle write 階段可能會有類似「lost task」這樣的報錯，目前還沒有定位到具體的錯誤原因。

前面提到的 JuiceFS + 物件儲存 + Lustre 的架構組合一定程度上提升了讀寫效能，但同時也使得架構更加複雜，相應地增加了一些可能的故障點。比如說 Lustre 沒有很強的容災副本能力，如果 Lustre 突然掛了一個節點，正在執行的任務到底能不能穩定地繼續讀寫 Lustre 裡面的資料，或者 Lustre 裡的資料意外丟失了，是否還能穩定的去 JuiceFS 裡通過物件儲存重新拉出來，這個目前是不確定的，目前我們在也在做這種災難性的測試。

未來和展望

基於 Flink + Hudi + JuiceFS 的實時資料湖方案

近期我們要做的一個是 Flink+ Hudi + JuiceFS 的實時資料湖方案。上圖中左邊是資料來源，通過 Flink 、Kafka/Pulsar，把資料實時地寫到 Hudi 裡，同時 Hudi 的資料會落到 JuiceFS 裡替換我們目前的實時數倉。

大資料雲原生的遠期規劃

最後，介紹一下理想汽車大資料雲原生的遠期規劃，也是一個展望。

第一點是統一的資料管理和治理系統。我們認為資料湖 2.0 時代，最大的需要解決的問題就是把資料湖 1.0 場景中的資料沼澤的問題解決掉。但現在好像並沒有一個比較好的統一元資料管理、資料目錄管理、資料安全管控的開源產品，類似 AWS Glue、AWS Lake Formation。目前我們在做一個「起源系統」的專案，這個系統第一步就是把上面的資料庫、物件儲存裡邊所有的元資料做統一的目錄管理，統一的安全管控，以及統一的資料管理，這塊兒我們正摸索著往前走。

第二點是更快、更穩定、更低成本的底層儲存能力。目前所有的場景最大的難點是在物件儲存上，物件儲存的優勢是穩定、低成本，同時物件儲存也在持續迭代。就目前而言我覺得如果大資料雲原生要發展，物件儲存必須是要在確保穩定的前提下提供更好的效能。

同時 S3 可能宣稱支援強一致性了，但是目前我理解基於物件儲存的架構設計，可能很難能實現強一致性，或者說它為了實現強一致性，勢必要犧牲一些東西，這可能是一個需要權衡的問題。JuiceFS 原生支援強一致性，這個功能對於大資料平臺來說非常友好。

第三點，更智慧、更高效、更易用的查詢引擎。引申一下前面提到的對湖倉一體的思考，目前湖倉一體還是在發展初期，可能還需要經歷 5~10 年的發展過程。Databricks、微軟都在嘗試做資料湖上的向量化 MPP 引擎，希望能把湖倉一體架構推起來。這可能是一個未來的發展方向，但是短時間內好像並沒有辦法用一個引擎來滿足所有場景的需求。

我們目前的架構基本上是配備了所有的查詢引擎，比如 Spark、Flink、關係型資料庫（面向 OLTP 的場景）、時序資料庫、OLAP 資料庫。原則上還是誰優用誰，我們上層再通過統一的中介軟體去做管理。再比如 Snowflake，它現在雖然已經支援了同時查詢結構化和半結構化的資料，但是未來像人工智慧涉及的的非結構化資料（如圖片、語音、影片）到底應該怎麼支援，目前還是不太清楚。不過我認為這肯定是以後的一個發展方向，理想汽車也有類似的人工智慧場景，所以我們會與各個業務方一起去探索和共建。

最後，整個大資料發展的最終目標還是要以最低的成本、最高的效能完成資料分析，從而實現真正的商業價值。

如有幫助的話歡迎關注我們專案 Juicedata/JuiceFS 喲！ (0ᴗ0✿)

「其他文章」