内容簡要：
（一）項目背景簡介
（二）Fluid核心理念
（三）Fluid架構功能
Fluid是在Cool Natives的環境下自由流動，支撐彈性的機器學習和大資料應用，能夠更好的通路資料進行資料管理。
1）技術發展背景
過去10年IT的發展如火如荼，有非常多的技術，概念層出不窮，在這些概念、技術中，有三樣東西應該是最主要的趨勢：第一:雲計算，第二:大資料，第三:人工智能。
在這些領域中,有非常多開源軟體出現，互相競争，不斷疊代，部分軟體随着時間的推移，成為了這個領域裡面的主流。
在雲計算領域的Docker和Kubernetes大約産生于2013年和2014年，到了2020年，根據雲上的資料，通過調查5000家公司，發現其中有45%的公司已經開始使用Docker和Kubernetes，成為雲計算平台上的一個主流技術方案。
大資料領域Hadoop、Spark、Flink已經成了真正的業界标準。
人工智能領域Tensorflow，已經是工業界使用最主要的一種工具，PyTorch得到了學術界的廣泛應用，分别來自谷歌和Facebook。
三者的關系，發現大資料和AI更多的還是在應用層。大資料和AI的應用差別在于，大資料以結構化資料為主，人工智能 AI主要是以非結構化資料為主，他們的資料讀取方式，大資料是由冷熱資料之分，而AI場景之内都是以全量資料的運算為主。有差別也有相似，相似性是通過巨大的算力通路這些海量的資料。
現在使用多核的CPU，甚至使用GPU進行這種資料處理，是非常敏感型的應用。
雲計算平台可以看到，随着Docker和Kubernetes技術，能夠提供标準化的應用疊代，提升應用疊代的速度，同時通過計算成本降低規模化部署，提高整個平台的 OAI投入，也成為了大家關注的重要因素。
大資料和AI是在應用層，而像雲計算、Docker和Kubernetes，是屬于在基礎架構層，當良性發展時，三者的融合會成為很重要的趨勢。
當大資料和AI都已經發展到一定程度的時候，這三種融合實際上就是如何把大資料和AI等應用運作在雲計算的平台上。Gartner預測到2023年70%的 AI的工作負載将以容器化的方式運作和service的方式去建構，而spark3.0一個很重要的趨勢，原生的支援communities排程和communities文法。
2）面臨的問題
實踐中,在雲原生環境下運作大資料和AI應用，實際上效果并不好，具體分成兩個方面，第一運作效率比較低下，以圖為例，在英偉達的GPU環境為100GPU環境下，通過本地記憶體去進行模型訓練，發現訓練速度是1萬張圖檔每秒。 當用雲存儲的時候，在計算分存儲分離場景下，速度變成原來的1/3，效率急劇下降。
另外一方面，由于在Docker和Kubernetes場景下，對于資料集的管理和考慮比較欠缺，像一些資料多版本多變的問題，資料接口的問題如何去對接。
對于資料類型是幾TB的大檔案，還是幾百兆的小中等檔案，甚至是幾百k的小檔案如何去接受缺乏思考。
底層的存儲hdfs safe，各種各樣存儲如何對接，也是欠缺的，究其原因，實際上是在于雲原生環境和資料密集型處理架構之間，它的設計理念是有天然分歧的，本質上是因為出現要解決的問題不一樣，是以思考的角度也不同。
3）問題的原因分析
在雲原生環境下，在計算存儲分離是最主要的思考，要考慮降低成本，計算和存儲需要單獨擴縮容，才能達到成本的最優效果。
在大資料場景下，更多的是資料通路的效率。
第一個沖突是關于資料是本地化的通路，計算要圍繞資料來進行排程，計算存儲分離和資料本地化。
第二個沖突，雲原生應用考慮到彈性的擴縮融和自動化的故障恢複，希望應用盡量是一個無狀态的應用，這樣恢複的速度會非常快。
資料密集型的架構是以資料抽象為中心來進行工作，以Spark為例，核心理念rdd彈性資料集，彈性資料集中有算子，這些算子都是有狀态的，通過Dag圖進行關聯，這裡面一旦某個算子出現問題，就有非常大的恢複成本。 它是以資料為核心，有狀态的計算這兩者也是很明顯的差異，同時也發現在cncf雲原生全景圖中，是缺少針對于資料高效支撐的元件。
4）雲原生環境下的資料支撐挑戰
綜上看到有三個最核心的問題;
第一，如何在雲原生上面去支撐資料應用，進行計算存儲分離，因為計算存儲分離會導緻資料通路的延時影響計算的效率。
第二，現有的雲原生的排程器，是Kubernetes的預設排程器中，對于應用的排程時沒有考慮到資料的相關的資訊，隻把它作為了一個資源排程，而不是應用排程，是以它的排程有效性值得商榷。
第三，混合雲場景下的跨存儲的聯合分析，在雲原生環境下很難支撐，但是在大資料場景下，以Alluxio為例，它最擅長的是跨雲的以Pattylan為理念的資料運算。
5）Kubernetes生态中缺失的一塊抽象
Kubernetes架構，它的成功之處在于，對于應用和底層的計算資源做了非常好的抽象,把計算抽象成了一個Pod;把存儲抽象了成了PVC;把網絡又抽象成了Service，應用有相應的對應的抽象，但其實缺乏于這種對于資料的抽象。雲原生整個大圖中，對于存儲抽象中其實也有一定幫助，像Rook如何解決的是對于Ceph有狀态的應用和服務，生命周期如何在Kubernetes的環境下面進行管理，如何去做它的更新。
ChubaoFS是京東和中科大一起開源的軟體，解決的是另外一種分布式存儲，這個分布式存儲如何部署在Kubernetes這個環境下，缺乏的是以應用為中心的資料抽象，及對其的生命周期管理。
6）商店購物模式演變的聯想
在雲原生環境下應用是有彈性的，當應用開始做彈性的時候，如何有相應的資料和它相對應滿足lps，這些都需要考慮。 一個主要的初衷，把它和應用彈性相關聯,資料的通路和商品的類比有很多的相似之處，把商品超市客戶類比成資料存儲和應用，商品和資料非常類似，一個核心特點就是消費被使用，而超市和存儲是有非常大的類似性，提供兩個核心功能:
第一，資料的貯藏，如何把資料存到超市裡面。
第二，顧客如何在超市裡面購買（即獲得這些資料），和應用很類似，通常是在超市裡面進行資料消費（即進行商品購買）。
直到2006年出現了電商模式,電商模式最核心的價值，就是它帶來了更大的交易量，更加以客戶為中心，客戶可以選擇所需要的任何一種商品。當電商模式出現之後，整個網上的購物方式就發生根本性變化，倉庫負責貯藏商品，客戶在虛拟的服務商店購買商品，由現代化的物流服務，把商品投遞到客戶手中。
在現在的雲架構環境下，兩者非常相識。
資料貯存在雲存儲系統中，應用部署在計算的叢集裡面，二者是分離的，但是由于高效的物流系統缺失，導緻密集型應用通路這些資料的時候，效率非常低下。
高效的物流體系，對于整個應用的通路非常重要，通過類比可以看到為什麼會有電商模式，有兩點優勢：
第一，支付模式。
第二，高效的物流體系。
對此思考，當我們有更高的IO需求時，也需要雲平台上有資料的傳遞平台，Fluid可以扮演雲原生平台下面的資料物流系統這個角色。
（二）Fluid的核心理念
Fluid扮演雲原生的資料物流系統角色
回顧整個應用，如何在存儲中通路資料場景的變化。最早的時候，當儲存在Hadoop場景的時候，是計算和存儲相綁定的場景，一個節點，它既提供計算又提供存儲，實際是data fetch取資料，應用要被放到存儲上，才能夠運作。這種方式提供了很好的性能，與此同時，又帶來一個巨大的問題，就是成本非常高昂，機器需要非常大的存儲，非常多的計算資源和記憶體。這種方案沒有辦法持續，第一，成本高；第二，計算和存儲雖然是兩個不在一起，當計算和存儲發生了分離，計算是固定的，他們是一個靜态部署，永遠都在某個節點上啟動。
這個時候就出現了Alluxio，第一，提供應用通路資料的路由機制，相當于可以把不同的協定進行互相轉化，提供遠端通路的能力。 第二，提供資料緩存的能力，可以把資料緩存到某個節點上，這種在計算存儲分離的場景下，如果計算是靜态部署，就會有優勢，因為熱資料持續被通路。
今天，雲環境變得更加靈活，第一，資源池化，應用的部署非常的靈活，并不能夠固定到某些節點上。第二，彈性伸縮，有時候它屬于由波峰波谷，屬于削峰、天谷的情況大量存在，這個時候的應用特性，變成了動态的彈性部署。資料傳遞，開始負責應用的部署和排程，會有應用部署排程的資訊，部署到哪些節點上，結合要使用的資料，就可以把資料去傳遞到更近的節點上。甚至某些場景下，可以先把資料放到節點上，再把應用排程上去，實作資料傳遞效果。
Fluid核心的想法，希望Fluid扮演雲原生下的資料物流的角色，又有了很多變化。
第一，視角的轉變：從雲原生資源排程結合資料密集處理兩方面，綜合審視雲原生場景的資料抽象與支撐通路；
第二，思路的轉變：針對容器編排缺乏資料感覺，資料編排缺乏 架構感覺，提出協同編排、多元管理、智能感覺創新方法；
第三，理念的轉變：讓資料像流體一樣在資源編排層和計 算處理層靈活高效地通路、轉換和管理。
在這種操作之下，通過和資料引擎互動，做資料的遷移，讓更資料集靈活的在整個Spark環境下進行變化。
最後如何消費資料的應用，因為他也在叫叢集排程，需要知道資料相關的資訊。獲得這之前，我們對資料集進行了編排和部署，知道哪些資料在哪些節點上，當排程應用的時候，就會根據資訊來排程應用。
1）Fluid的系統架構
如上圖所示：Fluid系統架構。從上到下來看，作為客戶，使用者左邊其實要定義兩個東西，一個是資料集的通用定義 Runtime，是資料的編排和緩存引擎，這裡面主要會支援兩個引擎，一個是Alluxio，一個是JindoFLS,這兩個引擎能做到的是資料的緩存加速和自動的資料驅逐的工作。
還有兩個核心元件在輔助的裡面兩個核心元件
第一，資料集的編排。
第二，使用資料集的應用的編排，左邊是資料集的編排，三個Controller了。第一個是Dataset Controller資料集，負責整個資料集的生命周期，從建立到綁定；第二個是Runtime Controller負責資料集如何在雲原生平台下排程，部署需要放到節點上；第三個是Volume controller要和Spark平台對接，需要一個對接的協定，這裡會提供一個PVC協定，資料持有券，是spark本地的協定站。
右邊這一側，結合前面進行資料編排的一些相關的資訊，可以對于現有的k8s排程器進行擴充，這裡有兩個Plugin：
第一個Cache co-locality Plugin結合前面的資料排程資訊，把應用排程到最合适的節點能夠讀到緩存；
第二個Prefec Plugin，當你的整個叢集裡面沒有任何緩存存在的情況下，會把應用先排程下去，排程應用的時候，會結合應用需要的資料資訊，做智能預取。
第一層是服務的最主要工作。第二層就是k8s标準元件，隻要一個标準的k8s就可以把整個的元件和子產品運作起來。 最後一層就可以對接各種各樣的存儲,由于做了Fluid這層抽象，Alluxio支援存儲類型和新的知識存儲類型，還有他們不支援的存儲類型，也可以支援。
2）Fluid的功能概念
需要強調的是服務的功能概念是輔助的，Fluid不是全存儲加速和管理，而是應用使用的資料集加速和管理
這裡面有三個概念：
第一，Dataset: 資料集是邏輯上相關的一組資料的集合，一緻的檔案特性，會被同一運算引擎使用；
第二，Runtime: 實作資料集安全性，版本管理和資料加速等能力的執行引擎的接口，定義了一系列生命周期的方法；
第三個AlluxioRuntime: 來自Alluixo社群，是支撐Dataset資料管理和緩存的執行引擎高效實作。
核心的功能，第一：加速；第二：k8s存儲對接；第三：資料集隔離。
加速的意思，并不是部署了緩存就能得到加速，涉及到三點：
·
第一，能夠提供多大的緩存，如緩存量是很小，而且同時你的據通路又不是很規則化，緩存未必是有好的效果的。對于緩存的能力可觀測性，首先知道資料特點，然後再知道緩存特點，才能判斷緩存是否帶來效益；
·第二， Prtable和scalable，通過觀測了解到緩存能力是什麼樣子，涉及到是否要對它進行遷移，是否要換到一些更合适的節點，是否要對它整體換存檔來進行擴容，在k8s面，都是一鍵式的配置；
·第三， Colocality信用在k8s度器裡面，讓計算和應用更近，對接不同的存儲，然後以PVC以k8s能夠接受的一種接口，接入到k8s的體系中，在k8s中的name、space作為隔離，來讓不同的資料集對于不同的資料科學家有可見性。
舉例說明，如下圖所示：
使用者在一個場景下，使用來自兩個不同地方的資料源，一個資料源是在阿裡雲上的對象存儲OSS，另外一個資料源是資料中心裡面搭建的self。場景比較常見，有些資料是脫敏資訊，可以在阿裡雲上用，有些是敏感資訊，它可能隻能部署線上下的資料中心。
通過編排在API描述對應的就是兩個mountPoint，而這兩個mountPoint隻要定義好之後，通過Fluid就會把它轉化成PV/PVC。這樣計算可以把k8s裡面定義的Pod隻要把 PVC挂載下來，可以同時去通路線上的資料。阿裡雲上面OSS資料和線下資料中心的資料，整個的操作是一個透明的，增加了使用資料的友善性。
如何對數集進行檢查，當把dataset部署下去cache capability，能夠提供多少的緩存能力也能看到底層存儲、資料集底層存儲需要多大的量，在這個例子中底層存儲隻需要84g，上層緩存能力能提供200g，就不需要再做擴容操作。
當打算做擴容的操作的時候，可以去設定它的 work的數量，可以把4變成3，這樣它的緩存的能力就可以在降低。
而整個工具也把它做成了一個直接可以在k8s裡面直接去查詢，有時候性能不好，是因為緩存的量還不夠多，這個時候就可以做對于緩存能力有一個可觀測性，根據這種觀測性來決定我是否要skill out，還是skill in。
三個節點中有兩個節點是有緩存引擎的，有一個節點是沒有緩存引擎，首先kps排程分成兩個，一個叫做過濾，一個叫做優選，在過濾的時候，第三個節點就可以把它過濾，因為它沒有緩存能力，而前兩個節點在優選的時候，會判斷誰的緩存能力更大，就先把應用優先部署到哪個節點上。
選擇第一個節點，和排程相結合，通過一個demo，如何通過Fluid去加速一個已有k8s的持久化的資料卷，加速一個已有的納斯的nfs的這種已有的PVC隻通過服務的用非常簡單的方式使它速度得到極大的提升。