一、Data Mechanic平臺介紹
這塊是data mechanic平臺的一個介紹。首先，它是一個serverless的平臺，即一個全託管的平臺，用戶不用去關心自己的機器。所有的應用的啟動和擴容都是在這種秒級的。然後，對於這種本地的開發轉到這種線上的部署，它是一種無縫的轉換。然後，它還能提供這種配置自動的spark的一些參數調優，整個這條pipeline都會做得非常的快，已經非常地穩定。
然後他們相當於是把整個的平臺部署在用戶的賬號裡邊的K8S集群。這樣的話，對整個的安全是一個非常大的保證。然後數據權限，包括運行權限，都在統一的賬號裡面。
二、Spark on k8s
（一）核心概念
首先，k8s和spark的結合是出現在spark 2.3版本以後的事情，在此之前有幾種方式。第一種就是Standalone，大家使用的並不是非常的多。第二種是Apache mesos，在國外用的比較多，但是市場規模也在逐漸縮小。第三種是Yarn，我們現在絕大多數的企業都是跑在Yarn的集群裡面了。第四種是Kubernetes，現在大家也逐漸的把spark跑在k8s上面。
Spark on k8s的架構如下圖所示：
提交應用的方式有兩種。一種是Spark submit，另一種是Spark-on-k8s operator。它們各自的特點如下圖所示：
然後我們再對比一下Yarn和k8s的依賴的管理。這塊是區分點比較大的一個地方。Yarn提供一個全局的spark版本，包括python的版本，全局的包的依賴，缺少環境隔離。而k8s是完全的環境隔離，每一個應用可以跑在完全不同的環境、版本等。Yarn的包管理方案是上傳依賴包到HDFS。K8s的包管理方案是自己管理鏡像倉庫，將依賴包打入image中，支持包依賴管理，將包上傳到 OSS/HDFS，區分不同級別任務，混合使用以上兩種模式。
（二）配置和性能
然後我們說一下配置spark executors的小坑。舉個例子，假設k8s node為16G-RAM，4-core的ECS，下面的配置會一個executor都申請不到！如下圖所示。
原因是什麼，就是說Spark pod只能按照node資源的一定比例來申請資源，而spark.executor.cores=4佔用了node cores全部資源。如下圖所示，假設我們計算得到的可用資源是85%，那麼我們應該這樣配置資源，spark.kubernetes.executor.request.cores=3400m。
然後這塊是一個比較重要的特點，就是動態資源。動態資源的完整支持目前做不到。比如說，Kill一個pod，shuffle file會丟失， 會帶來重算。
這一塊是Cluster autoscaling和dynamic allocation。上文中，我們看到PPT的某一頁，它有一個實線框，還有一個虛線框。實際上說的是，k8s cluster autoscaler：當pod處於pending狀態不能被分配資源時，擴展node節點。然後， Autoscaling和動態資源配合起來工作，就是說，當有資源時，executor會在10s內註冊到driver。而當沒有資源時，先通過autoscaling添加ECS資源，再申請executors。 大約在1min~2min內完成executor申請過程。
這個實際上也是更好的保證了我們運行時的彈性，還有一個我自己的理解，比較有意思的一個玩法，就是說更加省成本。Spot instance會使得成本降低75%，它是可以被搶佔的一種資源方式，跑一些SLA不高、價格敏感的應用。它在架構上整體設計，使得成本最低。如果executor被kill，會recover。如果driver被kill，就會很危險。配置node selector和affinities來控制Driver調度在非搶佔的node，executor調度在spot instance。
然後，下一個就是對象存儲的IO問題。Sparkonk8s通常都是針對對象存儲，rename，list，commit task/job會非常費時。如果沒有S3A committers，Jindofs JobCommitter，應該設置 spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version=2。
還有Shuffle性能。 I/O性能是shuffle bound workload的關鍵點，spark2.x版本用docker file system。而Docker file system是非常慢的，需要用volume來代替。
（三）未來工作
未來的工作，我認為比較重要的就是shuffle的提升，中間數據的存儲與計算分離。這塊是一個比較大的工作。另外，還有Node decommission，支持上傳python依賴文件等等。
我們選擇k8s的優缺點，如下圖所示：
部署spark on k8s的具體步驟，如下圖所示：
三、EMR團隊雲原生的思考和實踐
（一）整體架構
這塊是我們的一個整體架構，如下圖所示：
（二）動態資源&shuffle提升
Shuffle service解決核心問題：
▪ 解決動態資源問題
▪ 解決掛載雲盤貴，事前不確定大小的痛點
▪ 解決NAS作為中心存儲的擴展性以及性能問題
▪ 避免task由於fetch失敗重新計算的問題，提升中大作業的穩定性
▪ 通過Tiered存儲提升作業性能
（三）EMR Spark雲原生規劃
EMR產品體系，創建EMR集群類型為ON ACK：
▪ JindoSpark鏡像
▪ JindoFSService/JindoFSSDK提升訪問OSS數據湖能力
▪ JindoJobCommitter增強提交OSS作業能力
▪ JindoShuffleService&動態資源能力增強
▪ ACK集群打通EMR原有集群，可以互訪老集群表和HDFS數據
▪ Operator增強，Dependency管理，提供一站式管控命令
▪ 雲原生日誌、監控一站式平臺
關鍵詞：kubernetes，apache spark，雲原生，data mechanics，spark on k8s
