2020-03-15 22:56:16 Alluxio

摘要：首先是要聞——Alluxio現在支持K8s Helm charts啦！K8s是Alluxio的一種經過認證的運行環境了。現在，重點是——Alluxio為K8s中的解耦式的數據分析技術棧帶回了數據本地性。怎麼做到的？繼續讀下去吧：）

在過去幾年中，容器在實際部署中的興起是毫無爭議的。容器使得在任意環境中運行應用變得簡單，而Kubernetes進一步改變了軟件和應用程序的部署及擴展方式，而不用關心具體的環境。實際上，Kubernetes越來越被視為一項關鍵技術，它不僅讓數據中心中的資源編排變得簡單，並且在混合環境和多雲環境中也是如此。儘管容器和Kubernetes在無狀態應用程序（例如Web服務器）甚至完全獨立的數據庫（例如mongoDB，Couchbase等）上都表現出色，但在高級數據分析和AI的世界中，技術體系看起來有些不同。

現代的數據分析技術棧採用的是高度解耦的架構。與傳統的數據庫或數據倉庫不同的是，新式的技術棧是分開的。

選擇一個數據湖（或者兩個、三個）用來存儲數據（S3, GCS, HDFS等）
選擇一個計算框架用來分析數據（Apache Spark,Presto, Hive, TensorFlow等）
確保其他所有的依賴項（如目錄服務）均可用（Hive Metastore，AWS Glue，KMS等）

在K8s中運行解耦數據分析棧的挑戰

Kubernetes極大地降低了將多個分佈式系統一起部署的複雜性。並且，在K8s集群上運行高級數據分析將成為常態。但是，要使這種現代的分析技術棧有效，仍然存在一些關鍵的差距需要彌補。

挑戰#1——K8s集群中沒有共享的數據訪問/緩存層

K8s是一種出色的容器編排技術，藉助Helm圖表、算子等工具，可以大大簡化部署。但是，對於諸如高級分析之類的數據密集型工作負載，我們通常需要有效地共享作業之間的數據，這樣一個job中的數據才能被下一個job輕鬆地訪問到。如果沒有數據訪問/緩存層，那我們就需要將數據寫回到數據湖，然後又需要讀回到K8s集群，這大大降低了數據流水線的效率。

挑戰#2——缺少數據本地性

由於數據被存儲在S3中，或其他雲對象存儲中，或Hadoop的本地存儲中，為了在K8s集群中執行分析任務，用戶只有兩種選擇。數據要麼被遠程訪問（意味著性能不佳），要麼被手動複製到K8s集群中（意味著每個工作負載的承擔者會面臨大量額外的DevOps和管理開銷）。通常，管理這些副本之間的差異將帶來沉重的負擔。理想的解決方案是，在這種解構式的技術棧之中重新創造出數據局部性。

挑戰#3——沒有可用於彈性計算的數據彈性

K8s的優點在於，即使在最複雜的計算工作負載上，它也可以根據需要和需求靈活地擴展：縮小、升級、重新啟動等。但是，對於數據密集型的工作負載而言，對於可獲取的數據的依賴性依然存在。在對計算進行橫向、縱向或者擴大、縮小的擴展時，K8s中的數據也必須能夠完成同樣的操作，這樣才能利用K8s所帶來的靈活性。

數據編排可以通過將數據同步到K8s集群中，並允許無縫的內存數據訪問和靈活的跨作業數據共享，以及根據需要進行縮小或擴展，來解決這些挑戰。