Spark最佳實踐4使用Databricks作為分析平臺5領英如何應對ApacheSpark的Scalability挑戰11利用閃存優化在Cosco基礎上的SparkShuffle26基于Spark和TensorFlow的機器學習實踐33在kubernetes上運行apachespark：最佳實踐和陷阱42使用RayOnSpark在大數據平臺上運行新興的人工智能應用51使用Ray將可擴展的自動化機器學習（AutoML）用于時序預測58ApacheSpark3.0對Prometheus監控的原生支持68阿里云開源大數據平臺實踐80助力云上開源生態-阿里云開源大數據平臺的發展81EMRSpark-SQL性能極致優化揭秘概覽篇91EMRSpark-SQL性能極致優化揭秘RuntimeFilterPlus96EMRSpark-SQL性能極致優化揭秘NativeCodegenFramework102SparkCodegen淺析111Tablestore結合Spark的流批一體SQL實戰124Tablestore+DeltaLake(快速開始)132使用Databricks作為分析平臺簡介：簡介：SPARK+AISUMMIT2020中文精華版線上峰會將會帶領大家一起回顧2020年的SPARK又產生了怎樣的最佳實踐，技術上取得了哪些突破，以及周邊的生態發展。本文是阿里巴巴高級技術專家章劍鋒做的相關分享，介紹了YipitData公司基于Databricks平臺搭建的分析平臺。Spark等引擎都是作為工具被開發者使用的，而我們使用這些工具的最終目的是搭建合適的平臺提供給業務方。以下是YipitData‘sPlatform的相關介紹。一、為什么要用到平臺(Whyaplatform)？YipitData是一家咨詢公司，其客戶主要是投資基金以及財富五百強中的一些公司。該公司通過自己的數據產品進行分析，提供給客戶相應的數據分析報告。YipitData的主要產出方式和賺錢方式就是做數據分析，其公司內部有53個數據分析師，卻只有3個數據工程師。數據分析的基礎是數據，所以對于該公司來說大數據分析的平臺是非常重要的。二、平臺中有什么(Whatisinourplatform)？YipitData公司希望通過他們自己的數據分析平臺能夠讓數據分析師不需要付出太大的成本就完成數據分析的任務，也就是OwnTheProduct，而這個過程主要包括如下圖所示的DataCollection、DataExploration、ETLWorkflows和ReportGeneration四個階段。上面我們提到YipitData公司的人員主要包括數據分析師和數據工程師，其中數據分析師來分析數據并且提供基于數據的問題解答和分析報告，數據工程師來給數據分析師提供數據和分析數據的平臺。Databricks中的一個產品叫做Workspace，簡單來說它就是一個Notebook，你可以在其中寫python、Scala、SQL等語言的代碼，然后交由Databricks平臺去執行并返回結果。YipitData'Platform是基于Databricks平臺來搭建的，簡而言之就是他們對Databricks進行了更深一層的封裝，創建了一個PythonLibrary，更加方便分析師來進行使用。（一）獲取數據(Ingestingdata)YipitData公司的數據量是非常大的，有壓縮后大小超過1PB的Parquet，60K的Tables和1.7K的Databases。他們的數據收集使用的是Readypipe，簡單理解就是一個網絡爬蟲，在有了URL之后，將網頁內存download下來然后進行存儲，實現從URLs到Parquet。首先，使用Readypipe對網頁進行爬取，然后以流的方式源源不斷的寫入kinesisFirehose，kinesisFirehose會接著將數據寫入AWS的S3上。在這個階段所存儲的數據都是原始JSON數據，是沒有schema的，這類數據對于數據分析師來說是很難進行使用的。因此，第二步我們要對數據進行一些格式轉換和清理，比較典型的做法是將JSON文件轉換成Bucket，這一步也自帶了壓縮效果。轉換完成之后會有兩個輸出，如下圖所示，一個是元數據，會寫入GlueMetastore，另外一個是數據，會寫入ParquetBucket中。通過上面的過程，就完成了數據的收集和清理過程，整個過程是非常經典，非常有參考價值的。另外，因為數據流是實時數據，每隔一段時間就會產生一些JSON文件，屬于小文件，時間久了S3上面會存在非常多的小文件，帶來性能方面的許多問題，于是要對小文件做相應的Merge處理，將小文件匯聚成大文件，這對后續的處理非常有幫助。YipitData公司所使用的的數據都是第三方數據，他們本身不生產任何數據，而使用第三方數據會面臨一些問題，主要包括如下四類問題：lVariousFileFormatslPermissionsChallengeslDataLineagelDataRefreshes上面幾類問題是在實際業務中經常遇到的，如果不解決好自然也不能有很好的成果產出。YipitData公司解決上面幾類問題主要是靠Databricks平臺，比如上傳并利用額外的元數據將文件轉為parquet等，如下圖所示。（二）表實用程序(TableUtilities)YipitData'sPlatform提供了一些tableutilities來幫助分析師創建table和管理table。比如下圖所示的create_table函數，可以幫助數據分析師更快速地創建table。上圖所示的是一個非常典型的SparkJob的場景，通常包括read、processing和write三個模塊。但是對于YipitData公司來說，上面的過程仍然是一個比較繁瑣的過程，因為該公司最重要的任務是進行數據分析，且大多數人員也是數據分析師，如果讓數據分析師使用SparkAPI去完成上述過程，還是有一定門檻的。對于YipitData公司來說，最好是把一些功能進行封裝，不要暴露太多的底層功能，所以有了上面的create_table函數，大大降低了數據分析師的使用難度。（三）集群管理(ClusterManagement)對于數據分析師來說，最后還是要進行計算，就牽涉計算資源的管理，那么YipitData是怎么做的呢？我們知道，搭建一個Spark集群并不是很難，但是如何搭建一個能夠最優化地解決問題的Spark集群并不是那么容易，因為Spark集群有非常多的配置，而這項工作如果交給數據分析師來做的話就更不簡單了。為了解決易用性的問題，YipitData的工程師參照T-Shirt的Size劃分巧妙地將集群劃分成SMALL、MEDIUM、LARGE三類，如下圖所示，數據分析師在使用的時候雖然少了靈活性，但是節省了很多集群配置的時間，大大的提高了工作效率。背后的原理也是進行更深層次的封裝，將眾多參數設置隱藏起來，數據分析師只需要像選擇T-Shirt的尺寸一樣做選擇即可，而無需關心背后的復雜配置如何實現。在集群管理方面，Databricks還提供了許多其他的API來對集群的計算資源進行管理，比如可以通過RESTAPI控制集群，對集群做各種各樣的配置，還可以對集群的配置進行動態調整等等，如下圖所示。（四）ETLWorkflow的自動化(ETLWorkflowAutomation)YipitData使用Airflow來實現ETLWorkflow的自動化。越來越多的人使用Airflow來管理ETLWorkflow，已經逐漸成為ETL的一個標準工具。對于數據工程師來說，Airflow的使用不是很難：首先構建一個DAG，然后去定義其中的TASK，最后定義下這些TASKS的依賴關系即可。但是，終究是要寫一段代碼來實現這個過程，就需要有人來維護，對于大多數員工是數據分析師的YipitData來說就不是那么合適了。因此，YipitData使用Airflow+databricks的API來自動化構建DAGs。具體來說，每個文件夾就代表一個DAG，每個Notebook就代表一個Task，Notebook中指定一些屬性（內部是python腳本然后通過API來自動化構建DAG文件。通過上面的過程完成整個ETL的自動化，其中用戶只需要指定Notebook中的參數值即可。YipitData自動化創建Workflows的過程如下圖所示，整個流程都是在Databricks平臺上擴展得到的。三、Q&AQ1：Databricks和Dataworks都是一站式的數據分析平臺，兩者的區別是什么？A1：兩者的側重點不一樣。Dataworks綁定在阿里云，而Databricks可以在各個云上使用；Databricks綁定了Spark引擎，而Dataworks可以使用各種引擎；Dataworks在數據治理上更強一些，而Databricks的Spark應用更強一些。Q2：目前Zeppelin、Jupyter、Databricks產品的分析功能有些類似，他們有什么特別推薦的使用場景A2：這幾個產品最大的特點是提供了交互式的編程環境，和傳統的IDE開發不同，他們有著更好的開發效率，尤其是在數據分析和機器學習方面。另外，這類產品也不是只能做交互式開發，也可以用來做ETL。領英如何應對ApacheSpark的Scalability挑戰簡介：簡介：在集群計算引擎使用率快速增長的過程當中，會面對多維度的計算基礎架構規模擴展性的挑戰。同時由于Spark團隊直接與Spark用戶打交道，如何提升Spark用戶生產力，避免“用戶支持陷阱”，一直是較為頭疼的問題。本次直播將由領英Spark團隊軟件工程師沈旻和林致遠為您介紹，領英Spark生態系統，構建多元化Spark生態系統過程中遇到的挑戰，如何提升Spark用戶生成力以及如何優化Spark基礎計算架構。演講嘉賓簡介：沈旻，領英Spark團隊軟件工程師，技術負責人，伊利諾伊芝加哥分校計算機專業博士學位。林致遠，領英Spark團隊軟件工程師，卡耐基梅隆大學碩士學位，專攻分布式系統方向。本次分享主要圍繞以下四個方面：一、OverviewofSparkEcosystem@LinkedIn二、Scalingchallengeswehaveexperienced三、SolutionstoscaleourSparkusers’productivity四、SolutionstoscaleSparkcomputeinfrastructure一、OverviewofSparkEcosystem@LinkedIn本著協助成就職場人士，在職場上事半功倍的初衷與使命，領英平臺已演變成了數字化的全球經濟圖譜，圖譜中所蘊含的信息不僅為各種平臺產品提供了所需的數據，也提供了數字化洞悉全球經濟的途徑。在這樣一張龐大的圖譜中分析數據獲得insights才能幫助領英平臺中的職場人士。那么大規模的數據平臺必不可少，因此ApacheSpark成為了領英的主要計算引擎。領英Spark生態系統有兩個特別顯著的特性，一方面是一個大規模計算基礎架構，在Hadoop平臺中領英使用了上萬個節點，包括近100萬的vcores，以及2+PB的內存。每日大概有3萬個Spark應用在集群中運行，這些Spark應用程序占用了70%的計算資源，每日shuffle超過5PB的數據。計算基礎架構增長也非常迅速，僅僅2019年平均就增長了3倍以上。領英的Spark是一個多元化的生態系統，Spark用戶通過不同的方式在集群中使用Spark，要么通過Azkaban獲得預定的流程，或者通過Jupyternotebook運行交互式查詢。在領英，上千萬用戶通過Spark豐富的API開發各種大數據應用。大約60%的應用程序是SparkSQL應用，通過豐富的大數據應用，在領英涵蓋了多種應用場景，包括人工智能、數據分析、A/BTesting、DataWarehouse、指標報告等等。二、Scalingchallengeswehaveexperienced面臨挑戰快速增長的大規模基礎架構所支持的多元化生態系統給領英帶來了不小的難題。在擴展Spark基礎架構，賦能用戶，高效開發等方面遇到了不同維度的挑戰。首先在資源管理方面，在上千用戶的集群中管理用戶，并滿足不同團隊計算資源的需求會帶來不少集群運維的挑戰。在此之上，計算引擎本身也面臨這更高擴展性的問題，計算引擎快速增長意味著需要可擴展的基礎架構保證穩定性，否則將大大影響用戶使用的便捷性和滿意度，同時會帶來技術問題且會增加技術運維的開銷。在用戶生產力方面，當Spark使用量增加時，用戶支持問題也會接踵而至，為了確保內部Spark用戶的生產力，團隊中更多的人力也會自動的轉移到用戶支持的問題上。但這同時意味著有限的團隊資源無法投入到計算基礎架構的改進上，而這本身又會帶來更多用戶支持問題。這樣的惡性循環會形成阻礙團隊發展的“用戶支持陷阱”。解決方案領英展開了系列的動作來解決這些挑戰。在資源管理層面，工作中心是讓運維團隊從集群管理工作中解脫出來，創建了以業務為導向的集群資源隊列結構，使得各個部門自己管理自己的資源隊列。此外還優化了集成資源調度器，幫助用戶彈性管理資源，將集群中的空閑資源以彈性資源的方式分配給最需要的隊列。通過這些解決方案，資源管理很大程度上變成了自動化或用戶自我管理的方式。在計算引擎層面，領英花了很多精力優化SparkShuffle，SparkShuffle是最大的規模擴展瓶頸。領英還嘗試了多種SQL優化技術，SQL優化有助于減少同等Spark應用數量下的計算工作量，從而進一步緩解在快速增長的規模下計算引擎所面臨的壓力。在用戶生產力方面，領英的目標是拜托用戶支持的陷阱，盡量通過自動化的Spark系統回答最常見的用戶問題，分別是為什么我的Spark運行失敗了，為什么我的Spark運行很慢，以及如何讓它運行的更快。下面分別從用戶生產力及SparkShuffle方面展開詳細的介紹。三、SolutionstoscaleourSparkusers’productivity提升Spark用戶生產力提升用戶生產力，并幫助用戶理解Spark應用的各個方面對于團隊工作至關重要。鑒于Spark是非常復雜的計算引擎，對于Spark用戶而言，調試和調參往往都非常繁雜。由于Spark團隊資源相對有限，考慮到領英Spark規模非常龐大，如何更好的提供用戶支持也是一個極大的挑戰。在Spark中運行時，錯誤可能會出現在任何地方，用戶至少需要很多步驟才能獲取到相關日志，尋找出錯原因，有時即使找到出錯日志但想找到根本原因也不是很容易的事情。而且Spark用戶花費了很多功夫終于調試好了，但運行時還是有很多不盡人意的地方，調整應用性能瓶頸，再提升性能也是一項很頭疼的工作。針對用戶的痛點，領英開發了一套自動化的解決方案，幫助用戶查找用戶出錯的原因，分析并查找應用性能瓶頸，并提供各種調參建議。借助這些解決方案，可以大大提高用戶生產力，同時減輕Spark團隊在用戶支持上的負擔。第一類問題：為什么我的Spark應用失敗了？針對第一類問題，領英開發了一套自動出錯分析工具，作為領英的Spark用戶，大家可以在工作流失敗的情況下，到工作流管理器Azkaban上找出錯原因，免去了繁瑣的獲取相關日志，查詢出錯原因的步驟。用戶只需要點擊異常選項卡就能直觀的找到所有相關異常，同時也能看到應用運行失敗的根本原因。如下圖中，出錯原因是內存不足，用戶也可以點擊鏈接查看完整日志。此外，領英還做了一系列出錯原因分析可視化儀表，提供了各種原因的占比，可以為Spark用戶帶來更多幫助。如下圖，可以發現最主要的出錯類型是輸入數據的缺失，以及數據訪問權限問題。通過這些信息，團隊可以更方便的知道其故障原因所在，從而采取相應措施。自動故障分析可以時運維團隊收益。下圖是集群上各種錯誤知識趨勢，包括網絡問題和數據Shuffle問題等等。這種趨勢監控對集群健康至關重要，有助于提早發現異常行為，識別集群中的潛在問題。第二類問題：如何找到運行時的性能瓶頸？針對第二類問題，領英為此開發了性能分析工具GridBench，它可以通過各種報告幫助用戶理解性能指標，可以對同一個Spark應用多次運行后的結果自動分析，從而發現性能瓶頸點。GridBench也可以作為很好的衡量工具，幫助用戶了解存儲和計算模塊的性能指標。下圖中展示了GridBench針對某個應用做出的性能比較報告，通過對比兩組不同時間下運行間的之間執行記錄。GridBench可以確定應用性能是否有變化，可以發現ExecuterCPUTime有了明顯的提升，直觀的告訴用戶性能瓶頸所在，在優化性能時更加的有針對性。第三類問題：如何調參，使得應用運行的更快？針對第三類問題，領英為用戶提供了自動化參數調優建議。通過一系列預定義調參方案，自動化檢查應用配置，資源設置等等，給出對應的建議。如下圖，某個調優方案顯示的是紅色，表明有進一步優化的空間，如果顯示綠色表示參數設置已經比較合理。下圖中應用的內存設置太高，建議將其設置為較低的值，避免資源浪費。解決方案設計框架上述解決方案背后的設計框架中，各種Spark應用指標是框架核心元素，追蹤集群里運行的每個指標，將指標匯總成一個數據集，數據集會被前面提到的自動化錯誤分析，性能分析及調參建議工具使用到。在設計框架中，用SparkHistoryServer獲取所需要的數據，它是領英Spark生態系統中重要的一環，為所有Spark應用提供歷史日志記錄，通過網頁和RestAPI的方式提供Spark應用的詳細數據信息。再通過MetricAPI獲取指標數據。SparkHistoryServer當日均Spark應用數據達到上萬個時，通過SparkHistoryServer獲取每個指標數據，還是遇到了功能擴展問題。一方面在集群高峰時段，單位時間內結束的Spark應用數量比較大，SparkHistoryServer不能很好的處理大量的并發請求。其次，SparkHistoryServer在解析歷史日志，提取較大的日志文件時會非常耗時，影響應用指標的及時性。為了解決并發請求問題，設計了分布式的SparkHistoryServer，架構中包含一個proxyserver和多個workerserver，通過使用多臺服務器可以很好的橫向擴展。為了解決第二個問題，設計了增量SparkHistoryServer解析（IncrementalParsing）。一般情況下，在Spark應用運行結束后才解析歷史日志，IncrementalParsing可以在運行時開始解析，一點點的增量解析日志文件。當Spark應用結束后，SparkHistoryServerIncrementalParsing可以在很短的時間內提供所需要的指標數據。目前大約只需要20秒，SparkHistoryServerIncrementalParsing就可以完成對99%Spark應用的日志解析。通過對SparkHistoryServer擴展性和實時性的提升，得以以較低延遲提供所有Spark應用指標的數據。為了驅動各種用戶生產力數據，領英搭建了一套基于Kafka和samza的SparkTrackingService。基于Kafka和samza是領英開源的流處理系統，SparkTrackingService首先會讀取來自集群ResourceManager的數據流，獲取運行結束時的Spark應用ID，查詢SparkHistoryServer以獲取每個Spark應用的數據，在對原始數據處理后SparkTrackingService會進一步解析用戶所需要的指標數據。由此，前面提到的自動故障分析、性能分析及調參工具就有了數據來源。四、SolutionstoscaleSparkcomputeinfrastructureSparkShuffleService有了提升用戶生產力的各種工具之后，Spark團隊可以更多的投入的優化計算引擎之上。Spark本身是一個復雜的系統，應該首先改進哪個組件呢？隨著Spark在領英內部使用率的快速增長，SparkShuffleService成為了最先擴展瓶頸的的Spark組件之一。領英使用了ExternalSparkShuffleService管理Shuffle文件，啟用Spark動態資源分配功能，這種配置對多租戶集群中Spark應用間的公平資源共享至關重要。在這樣的部署中，集群中的每個計算節點都將部署一個SparkShuffleService，每個SparkExecuter在啟動時會和本地的SparkShuffleService對接，并提供注冊信息。之后SparkExecuter中ShuffleMapTasks會生成Shuffle文件，每個文件都包含對應不同Shuffle分區的ShuffleBlock，Shuffle文件被ExternalSparkShuffleService統一管理。當ShuffleReducerTasks開始運行時，都會從遠程的ShuffleService當中獲取相應的ShuffleBlock。在繁忙的生成集群當中，單個ShuffleService可以輕易的接收到數千個Shuffle并發連接，這些連接來自數十個應用中的ShuffleReducerTasks。由于SparkShuffleService共享性質，在大規模部署應用服務時遇到了很多問題。SparkShuffleService問題首先是Shuffle可靠性問題，在生成集群當中，在集群高峰時段ReducerTasks經常無法與Shuffle進行連接，連接失敗將導致ShuffleBlock的獲取失敗。這種問題導致工作流中的SLA無法滿足，甚至運行失敗。在此之外，還遇到了Shuffle效率問題，在集群當中，Shuffle文件存儲在硬盤之上，由于ReducerTasks請求陸續發出，ShuffleService也將訪問數據，如果ShuffleBlock大小很小，那么ShuffleService生成的少數據隨機獲取操作將嚴重硬盤的數據吞吐量，從而延長Shuffle等待時間。第三個問題是Shuffle規模擴展性問題，由于ShuffleService的共享屬性，一個需要Shuffle很多小Blocks的應用，在獲取ShuffleBlock時很容易對ShuffleService造成過大壓力，導致性能的下降。這不僅影響對Shuffle不友好的應用，還會影響共享同一個ShuffleService的相鄰應用。對于這些應用而言，調整ShuffleBlock并不容易，這種現象發生時也會導致其它正常應用運行時間的延長。下圖很直觀的展示了小ShuffleBlock帶來的問題，圖中采用了5000個ShuffleReduceStage，并在圖中展示了每個Stage平均ShuffleBlock的大小，以及每個任務的Shuffle等待時間。數據來源是領英2019年生產集群當中所運行的Spark應用。可以發現，經歷了較長Shuffle等待時間的Stage，大多數也是應用了小ShuffleBlockStage。Stage1：提升ShuffleService可靠性為了解決這些問題，領英分了三個階段來系統性的解決集群中的SparkShuffle組件。第一階段就是提升ShuffleService在集群高峰時段的可靠性。通過前面介紹的集群故障分析工具，發現在集群中Shuffle失敗的主要原因與網絡故障并沒有特別大的關系。而是由于ShuffleService在處理Shuffle驗證請求時超時。這個問題日均達到了1000次，某個日子甚至達到大約6000次。經過更進一步的研究，發現這是因為ShuffleService背后使用的Next-gen服務器的問題。在較輕量層的控制層RPC，如身份驗證請求并沒有很好的與更加耗時的數據處理RPC隔離開來，在集群高峰時段，大量的數據層的RPC占用了ShuffleService的處理時間，直接導致控制層RPC請求超時。領英修復了這個問題，在集群上部署了改進后的ShuffleService之后，看到了立桿見影的效果。大大減少了此類問題的出現，提升了集群中Shuffle組件的可靠性。Stage2：ShuffleService端限流機制在下一階段，著重于對ShuffleService端限流來幫助解決集群內abusive應用的影響。這類應用所帶來的最大的負面影響是ShuffleBlock索取的速度。這些abusive應用會生成大量的小ShuffleBlock，因此當ReducerTasks獲取ShuffleBlock時，ShuffleShuffle會開始大量的小數據隨機讀取操作，很容易導致硬盤帶寬過載。在領英生產環境中，abusive應用會延長Shuffle獲取等待時間。領英開發了ShuffleService限流機制，實時追蹤每個連接的應用ShuffleBlock獲取速率，當ShuffleBlock獲取速率超過閾值時，ShuffleService可以讓相應應用的ReducerTasks回退，通過減少并發ShuffleBlock獲取數據流的方式作出響應。領英最近在生產環境中使用了ShuffleService限流機制，觀察到集群中所有節點上的ShuffleServiceBlock獲取速率的波動幅度明顯降低，這意味著abusivejob對ShuffleService以及相鄰應用的影響開始受到了控制。同時，還觀察到集群上Shuffle數據傳輸速率并沒有特別明顯的變化。這意味著當限制那些少數abusive應用時并不會傷害整個集群Shuffle數據吞吐量。Stage3：Magnet盡管限流可以保護ShuffleService免受abusive應用的影響，但依然不能根本的解決小ShuffleBlock的問題。受到限流的作業可能是高優先級的作業，并且有嚴格的SLA要求，這些應用無法承受ShuffleService受導致的運行時間的影響。另一方面，挑戰這些應用的參數，以增加ShuffleBlock大小也不容易，這會導致任務處理數據量的增加，同時對該應用的其它方面產生影響。為了解決這個問題，領英對ShuffleService采取了根本的改進，設計并實現了Magnet，一種在Spark之上的全新的pushbaseShuffle實現方式。相關工作論文也被VLDB2020接收，目前領英也準備將這方面工作貢獻至開源社區。更詳細的Magnet可以關注后續工程博客文章。Magnet采用了推送和合并的Shuffle機制，生成Shuffle文件之后，MapTasks會將生成的ShuffleBlock劃分為多個組，每個組包含了連續的Shufflebyte組成的數據，分組之后另外單獨的線程會讀取一整個組，將其中的ShuffleBlock傳輸到遠程的ShuffleService中。ShuffleService中ShuffleBlock按照不同的Shuffle分區被合并。ShuffleDriver會在ShuffleMapStage一開始會選擇一系列的ShuffleService，每個MapTasks都將收到同樣的一系列Services，這樣可以確保屬于同一個分區的ShuffleBlock始終被分配到同一個遠程的ShuffleService上。在ShuffleService端將以Besteffort方式把收到ShuffleBlock按分區合并至對應的Shuffle文件當中。當推送和合并的過程完成時，除了原本并沒有被合并的ShuffleBlock大小和位置之外，SparkDriver也會收到這些分區合并的Shuffle文件大小和位置。當ReducerTasks開始運行時，通過SparkDriver查詢所需ShuffleBlock的位置和大小，這將大大減少ReducerTasks所需獲取的ShuffleBlock數量，從而避免小ShuffleBlock的問題。盡管ShuffleService端以Besteffort方式把收到ShuffleBlock按分區合并，會導致小部分ShuffleBlock沒有被合并，ReducerTasks仍然可以獲取那些沒有被合并的ShuffleBlock，從而保證數據的完整性。此外，由于目前ReducerTasks大部分輸入數據都被合并在集群的一個節點之上，SparkDriver在調用ReducerTasks時考慮到這點，有助于進一步提高Shuffle性能。基于Magnet的Shuffle過程中，MapTasks生成的ShuffleBlock會推送的遠程ShuffleService當中，并按照不同的Shuffle分區合并，這個過程有助于將Shuffle當中的小數據隨機讀取操作轉化為大數據的順序讀取操作。此外，ShuffleBlock合并的過程，相當于為Shuffle中間數據創造兩個副本，有助于進一步提高Shuffle的可靠性。同時ReducerTasks調取合并后的Shuffle分區的位置，有助于進一步提高Shuffle的性能。下圖所示，可以觀察到基于Magnet的生產性能有了顯著的提升。使用Gridbench性能分析工具，對同一個Spark應用，在使用Magnet后的性能進行了分析。下圖中使用了較為復雜的生成機器學習特征數據的生產流程，處理了集群中的真實數據。原本在應用執行過程中，占據較大比重的是Shuffle獲取等待時間被極大的縮短，帶來了接近30%的應用運行時間的縮短。目前，領英正在將這種全新的Shuffle機制推廣到生產集群中。利用閃存優化在Cosco基礎上的Spark簡介：簡介：SPARK+AISUMMIT2020中文精華版線上峰會將會帶領大家一起回顧2020年的SPARK又產生了怎樣的最佳實踐，技術上取得了哪些突破，以及周邊的生態發展。本文中，來自Databricks開源項目組的軟件工程師吳一介紹了利用Flash閃存優化在Cosco基礎上的SparkShuffle。原標題：FlashforSparkShufflewithCoscoCosco是Facebook開發的一種服務，主要用于優化SparkShuffle的性能，下文主要介紹用Flash閃存（以下簡稱：閃存）進一步優化Cosco。一、CoscoCosco作為一種服務主要優化SparkShuffle的性能，其優勢有：l相較于原生的SparkShuffle，能夠提升大約3倍的I/O性能，能夠有效降低磁盤的讀寫時間；l引入閃存以后Cosco能夠以更少的資源支撐更多的場景；l引入閃存之后有更大的可能降低Query的延遲；l利用閃存優化Cosco的過程中用到的技術也可以用于Cosco之外的領域。（一）Cosco產生背景在SparkShuffle中有MapTask和ReduceTask兩種Task，每個MapTask都會生成MapOutputFiles，然后根據Partition進行分組，決定將文件寫入本地磁盤還是分布式文件系統中；所有MapTask執行完畢之后，ReduceTask就會去讀取MapOutputFiles中某個分區的數據，將其合并成某個大的Partition，在必要的時候還會進行排序。在上面的過程中，主要會存在兩個與I/O性能相關的問題：（1）Writeamplificationproblem如下圖，這個問題也就說在最壞的情況下，同一個shuffle產生的字節會被寫入磁盤三次：l第一次是在MapTask產生shuffledata的過程中如果內存不足，會先把ShuffleDataSpill到磁盤；l第二次是寫入MapOutputFiles的過程；l第三次是在ReduceTask中，如果進行sort的時候內存不夠，也會先Spill到磁盤。（2）smallIOsproblem在SparkShuffle模型中，其I/O請求總數會有MxR個，而在生產中觀察到的I/O請求的size平均為200kb，相對于磁盤來說是非常小的，當整個作業的并行度提升之后會產生大量的小I/O請求，會急劇增加磁盤開銷，比如尋址時間等，從而導致Shuffle的性能變差。基于上述問題，Cosco應運而生，其工作原理如下圖所示。相較于原生的Spark每個Task生成一個自己的MapOutputFiles，Cosco允許不同的MapTask將同一個Partition寫入到同一個內存緩存中，緩存到達一個閾值后，會將這部分數據Flush到分布式文件系統的文件中。這種情況下，同一個Partition可能產生多個對應的Flush文件，等到ReduceTask執行的時候，只需要讀取HDFS系統中的文件即可，且文件的數據量在十幾M的級別，且文件數量遠小于之前的MxR數量級。因此，也就解決了小I/O的問題。（二）用Flash替換內存緩沖使用Flash來作為緩沖的話是通過追加寫的方式將Shuffle的數據寫入緩存中，之所以這么做是因為閃存的可擦寫次數是有限的，追加寫可以延長閃存的壽命。閃存相對于內存存在著一定的延遲，但是總體而言這個延遲相對于整個shuffle在Cosco中緩存的時間是可以忽略不計的。現在存在一個如何選擇的問題，比如在1GB的內存和每天能夠寫100GB的閃存之間讓我們用來部署集群，我們如何抉擇呢？這里有一條不精確的經驗：1GB的內存和每天能夠寫100GB的閃存這兩種選擇的效果是一樣的，也就是說能夠支撐同樣的場景，但是內存比閃存需要更多的能耗。大家在部署集群的時候可以根據這條經驗來實際操作，選擇最優的配置。（三）基于內存和閃存混合的緩存優化基于內存和閃存混合的緩存優化技術主要有兩種：l第一種是優先緩存內存，當內存達到一定閾值之后再Flush到閃存；l第二種是利用partition加載速度不一樣的特性，對于加載速度快的partition用內存緩存，對于加載速度慢的partition用閃存緩存。（1）第一種第一種優化技術利用了Shuffle數據隨時間變化的特性，如下圖所示，我們發現Shuffle數據隨時間變化的統計中，峰值情況是占據小部分的，于是我們用閃存來處理峰值情況，最終只用250GB的內存和每天能寫25TB的閃存就能達到和原來一樣的效果，這樣就實現了Cosco的優勢，用更少的硬件資源來支撐了同樣的場景。這種混合存儲的優化技術比之純用內存有著更強的伸縮性，不會在某些特殊情況下造成系統崩潰。比如單純用內存的時候，如果出現內存不足就會崩潰，但是混合使用的時候就可以用閃存來處理異常情況，避免造成嚴重后果。原來的Cosco集群有負載均衡的邏輯，更了獲得更好的效果，我們使用插件的方式將閃存的優化集成到負載均衡邏輯中，如下圖所示，引入一個閾值，當ShuffleService內存不夠的時候，就會利用閾值來進行判斷是否將數據Flush到閃存中，這樣有兩個好處：l實現簡單；l便于對集群的性能做評估。總的來說，第一種優化技術有如下特點：l利用了ShuffleData的分布隨時間變化而變化的特性；l采用了優先在內存內進行緩存的策略；l巧妙的適配了原來的負載均衡邏輯。（2）第二種第二種是利用partition加載速度不一樣的特性，對于加載速度快的partition用內存緩存，對于加載速度慢的partition用閃存緩存。其策略主要是周期性的檢測Partition的加載速率，當速率小于某個閾值的時候，就使用閃存來緩存，當速率大于某個閾值的時候就使用內存來緩存。從下圖中可以看出，在實際生產中大多數Partition的加載速度是比較慢的，少部分加載速度比較快，加載速度比較慢的Partition占用了少部分內存，造成內存的低使用率，因此我們用閃存來承載這些Partition，達到優化的目的。二、未來工作（一）低延遲查詢引入閃存之后，我們可以讓ReduceTask直接從閃存中讀取緩存的數據，而不是從HDFS中的文件讀取數據，這樣子提高了數據的讀取速率。另外，在引入閃存之后，Shuffle的數據塊會變得更大，在Reduce端合并數據塊的次數會變少，讓整個查詢變得更快。（二）性能提升當前，Cosco為了保證容錯性，每一份Shuffle數據在寫入持久化的文件之前，會在不同節點的ShuffleService保存兩份數據。如果我們引入閃存之后，因為閃存具有不易失性，這樣子在ShuffleService在恢復之后可以從閃存恢復數據，減少了拷貝的副本。另外，在引入閃存之后，數據塊變得更大，在整個DFS上的讀寫也會更加高效。三、性能評估技術在上述的優化過程中，主要有如下四種類型的評估技術：lDiscreteeventsimulationlSyntheticloadgenerationonatestclusterlShadowtestingonatestclusterlSpecialcanaryinaproductioncluster（1）DiscreteeventsimulationDiscreteeventsimulation，也就是離散時間模擬的方法，是一種比較通用的評估方法。我們把每個ShuffleData到達閃存的行為作為一個離散事件，記錄其到達的時間、此時閃存中寫入的數據總量以及最后閃存被Flush到DFS文件的數據總量。最終我們會得到如下圖所示統計表，包含了最終數據塊的大小和緩存的時間，由此我們就可以推算出數據塊的加載速率，也就是對應Partition的加載速率，并且把這個速率應用于上文中講到的第二種優化技術來進行決策。（2）Specialcanaryinaproductioncluster如果我們要在一個生產環境中來驗證我們所進行的優化是否有效是比較困難的，因為在Cosco中一個Task可以與多個ShuffleService進行通信，所以很難確定是因為加入了閃存提升了性能還是因為其他原因而提升。因此，我們將整個生產集群分成兩個互不干擾的子集群，然后進行對比試驗，比如對子集群A增加閃存優化，而子集群B保持原來的部署模式。之后，我們再對兩個子集群進行評估，就可以得知增加閃存優化是否起到了優化效果。基于Spark和TensorFlow的機器學習簡介：簡介：大數據以及計算能力的提升，使得AI技術有了突飛猛進的發展。在大數據和AI技術的熱潮下，在2019杭州云棲大會機器學習技術專場，阿里云高級技術專家吳威和阿里云技術專家江宇向大家分享了EMRE-Learning平臺和平臺上新開發的核心特性TensorFlowonSpark。EMRE-Learning平臺EMRE-Learning平臺基于的是大數據和AI技術，通過算法基于歷史數據來構建機器學習模型，從而進行訓練與預測。目前機器學習被廣泛應用到很多領域，如人臉識別、自然語言處理、推薦系統、計算機視覺等。近年來，大數據以及計算能力的提升，使得AI技術有了突飛猛進的發展。機器學習中重要的三要素是算法、數據和算力。而EMR本身是一個大數據平臺，平臺之上擁有多種數據，比如傳統的數據倉庫數據、圖像數據；EMR有很強的調度能力，可以很好地吊調度GPU和CPU資源；其結合機器學習算法，就可以成為一個比較好的AI平臺。典型的AI開發流程如下圖所示：首先是數據收集，手機、路由器或者日志數據進入大數據框架DataLake；然后是數據處理，收集到的數據需要通過傳統的大數據ETL或特征工程進行處理；其次是模型訓練，經過特征工程或ETL處理后的數據會進行模型的訓練；最后對訓練模型進行評估和部署；模型預測的結果會再輸入到大數據平臺進行處理分析，整個過程循環往復。下圖展示了AI開發的流程，左側是單機或者集群，主要進行AI訓練和評估，包含數據存儲；右側是大數據存儲，主要進行大數據處理，如特征工程等，同時可以利用左側傳輸的機器學習模型進行預測。AI開發的現狀主要有以下兩點：?兩套集群運維復雜：從圖中可以看出，AI開發涉及的兩套集群是分離的，需要單獨維護，運維成本復雜，容易出錯。?訓練效率較低：左右兩側集群需要大量數據傳輸和模型傳輸，帶來較高的端到端訓練的延遲。EMR作為統一的大數據平臺，包含了很多特性。最底層基礎設施層，其支持GPU和CPU機器；數據存儲層包括HDFS和阿里云OSS；數據接入層包括Kafka和Flume；資源調度層計算引擎包括YARN、K8S和Zookeeper；計算引擎最核心的是E-learning平臺，基于目前比較火的開源系統Spark，這里的Spark用的是jindoSpark，是EMR團隊基于Spark改造和優化而推出的適用于AI場景下的版本，除此之外，還有PAITensorFlowonSpark；最后是計算分析層，提供了數據分析、特征工程、AI訓練以及Notebook的功能，方便用戶來使用。EMR平臺的特性主要有以下幾點：?統一的資源管理與調度：支持CPU、Mem和GPU的細粒度的資源調度和分配，支持YARN和K8S的資源調度框架；?多種框架支持：包括TensorFlow、MXNet和Caffe等；?Spark通用的數據處理框架：提供DataSourceAPI來方便各類數據源的讀取，MLlibpipeline廣泛用于特征工程；?Spark+深度學習框架：Spark和深度學習框架的集成支持，包括高效的Spark和TensorFlow之間的數據傳輸，Spark資源調度模型支持分布式深度學習訓練；?資源監控與報警：EMRAPM系統提供完善的應用程序和集群監控多種報警方式；?易用性：Jupyternotebook以及Python多環境部署支持，端到端機器學習訓練流程等。EMRE-Learning集成了PAITensorFlow，其支持對深度學習的優化和對大規模稀疏場景的優化。TensorFlowonSpark經過市場調研發現，大多數的客戶在深度學習之前的數據ETL和特征工程階段使用的都是開源計算框架Spark，之后的階段廣泛使用的是TensorFlow,因此就有了將TensorFlow和Spark有機結合的目標。TensorFlowonSpark主要包含了下圖中的六個具體設計目標。TensorFlowonSpark從最底層來講實際上是PySpark應用框架級別的封裝。框架中實現的主要功能包括：首先調度用戶特征工程任務，然后再調度深度學習TensorFlow任務，除此之外還需要將特征工程的數據高效快速地傳輸給底層的PAITensorFlowRuntime進行深度學習和機器學習的訓練。由于Spark目前不支資源的異構調度，假如客戶運行的是分布式TensorFlow，就需要同時運行兩個任務（Ps任務和Worker任務），根據客戶需求的資源來產生不同的Sparkexecutor，Ps任務和Worker任務通過Zookeeper來進行服務注冊。框架啟動后會將用戶寫的特征工程任務調度到executor中執行，執行后框架會將數據傳輸給底層的PAITensorFlowRuntime進行訓練，訓練結束后會將數據保存到DataLake中，方便后期的模型發布。在機器學習和深度學習中，數據交互是可以提升效率的點，因此在數據交互部分，TensorFlowonSpark做了一系列優化。具體來講采用了ApacheArrow進行高速數據傳輸，將訓練數據直接喂給APITensorFlowRuntime,從而加速整個流程TensorFlowonSpark的容錯機制如下圖所示：最底層依賴TensorFlow的Checkpoints機制，用戶需要定時的將訓練模型Chenpoint到DataLake中。當重新啟動一個TensorFlow的時候，會讀取最近的Checkpoint進行訓練。容錯機制會根據模式不同有不同的處理方式，針對分布式任務，會啟動Ps和Worker任務，兩個任務直接存在daemon進程，監控對應任務運行情況；對于MPI任務，通過SparkBarrierExecution機制進行容錯，如果一個task失敗，會標記失敗并重啟所有task，重新配置所有環境變量；TF任務負責讀取最近的Checkpoint。TensorFlowonSpark的功能和易用性主要體現在以下幾點：?部署環境多樣：支持指定conda，打包python運行時virtualenv支持指定docker?TensorFlow架構支持：支持分布式TensorFlow原生PS架構和分布式HorovodMPI架構?TensorFlowAPI支持：支持分布式TensorFlowEstimator高階API和分布式TensorFlowSession低階API?快速支持各種框架接入：可以根據客戶需求加入新的AI框架，如MXNetEMR客戶有很多來自于互聯網公司，廣告和推送的業務場景比較常見，下圖是一個比較典型的廣告推送業務場景。整個流程是EMR客戶通過Kafka將日志數據實時推送到DataLake中，TensorFlowonSpark負責的是上半部分流程，其中可以通過Spark的工具如SparkSQL、MLlib等對實時數據和離線數據進行ETL和特征工程，數據訓練好之后可以通過TensorFlow框架高效地喂給PAITensorFlowRuntime進行大規模訓練和優化，然后將模型存儲到DataLake中。在API層面，TensorFlowonSpark提供了一個基類，該基類中包含了三個方法需要用戶去實現：pre_train、shutdown和train。pre_train是用戶需要做的數據讀取、ETL和特征工程等任務，返回的是Spark的DataFrame對象；shutdown方法實現用戶長連接資源的釋放；train方法是用戶之前在TensorFlow中實現的代碼，如模型、優化器、優化算子的選擇。最后通過pl_submit命令來提交TensorFlowonSpark的任務。下圖是推薦系統FM的樣例，FM是一個比較常見的推薦算法，具體場景是給電影評分，根據客戶對之前電影評分、電影類型和發布時間為用戶推薦潛在的電影。左側是一個特征工程，用戶可以使用SparkdatasourceAPI讀取電影和評分信息，原生支持Spark所有操作，如join、ETL處理等；右側是TensorFlow，進行模型、優化器的選擇。目前整個系統的代碼已經開源到Github。最后總結一下，EMRE-Learning平臺將大數據處理、深度學習、機器學習、數據湖、GPUs功能特性緊密的結合，提供一站式大數據與機器學習平臺；TensorFlowonSpark提供了高效的數據交互流程以及完備的機器學習訓練流程，將Spark與TensorFlow結合，借助PAITensorFlow，助力用戶加速訓練；目前E-Learning平臺在公有云服務不同的客戶，成功案例，CPU集群規模超過1000，GPU集群規模超過1000。在kubernetes上運行apachespark：最佳實踐和陷阱簡介：簡介：阿里云高級技術專家范振為大家帶來在kubernetes上運行apachespark的介紹。內容包括DataMechanic平臺介紹，Sparkonk8s，以及EMR團隊云原生的思考和實踐。以下由Spark+AISummit中文精華版峰會的精彩內容整理。一、DataMechanics平臺介紹這塊是datamechanics平臺的一個介紹。首先，它是一個serverless的平臺，即一個全托管的平臺，用戶不用去關心自己的機器。所有的應用的啟動和擴容都是在這種秒級的。然后，對于這種本地的開發轉到這種線上的部署，它是一種無縫的轉換。然后，它還能提供這種配置自動的spark的一些參數調優，整個這條pipeline都會做得非常的快，已經非常地穩定。然后他們相當于是把整個的平臺部署在用戶的賬號里邊的K8S集群。這樣的話，對整個的安全是一個非常大的保證。然后數據權限，包括運行權限，都在統一的賬號里面。二、Sparkonk8s（一）核心概念首先，k8s和spark的結合是出現在spark2.3版本以后的事情，在此之前有幾種方式。第一種就是Standalone，大家使用的并不是非常的多。第二種是Apachemesos，在國外用的比較多，但是市場規模也在逐漸縮小。第三種是Yarn，我們現在絕大多數的企業都是跑在Yarn的集群里面了。第四種是Kubernetes，現在大家也逐漸的把spark跑在k8s上面。Sparkonk8s的架構如下圖所示：提交應用的方式有兩種。一種是Sparksubmit，另一種是Spark-on-k8soperator。它們各自的特點如下圖所示：然后我們再對比一下Yarn和k8s的依賴的管理。這塊是區分點比較大的一個地方。Yarn提供一個全局的spark版本，包括python的版本，全局的包的依賴，缺少環境隔離。而k8s是完全的環境隔離，每一個應用可以跑在完全不同的環境、版本等。Yarn的包管理方案是上傳依賴包到HDFS。K8s的包管理方案是自己管理鏡像倉庫，將依賴包打入image中，支持包依賴管理，將包上傳到OSS/HDFS，區分不同級別任務，混合使用以上兩種模式。（三）配置和性能然后我們說一下配置sparkexecutors的小坑。舉個例子，假設k8snode為16G-RAM，4-core的ECS，下面的配置會一個executor都申請不到！如下圖所示。原因是什么，就是說Sparkpod只能按照node資源的一定比例來申請資源，而spark.executor.cores=4占用了nodecores全部資源。如下圖所示，假設我們計算得到的可用資源是85%，那么我們應該這樣配置資源，spark.kubernetes.executor.request.cores=3400m。然后這塊是一個比較重要的特點，就是動態資源。動態資源的完整支持目前做不到。比如說，Kill一個pod，shufflefile會丟失，會帶來重算。這一塊是Clusterautoscaling和dynamicallocation。上文中，我們看到PPT的某一頁，它有一個實線框，還有一個虛線框。實際上說的是，k8sclusterautoscaler：當pod處于pending狀態不能被分配資源時，擴展node節點。然后，Autoscaling和動態資源配合起來工作，就是說，當有資源時，executor會在10s內注冊到driver。而當沒有資源時，先通過autoscaling添加ECS資源，再申請executors。大約在1min~2min內完成executor申請過程。這個實際上也是更好的保證了我們運行時的彈性，還有一個我自己的理解，比較有意思的一個玩法，就是說更加省成本。Spotinstance會使得成本降低75%，它是可以被搶占的一種資源方式，跑一些SLA不高、價格敏感的應用。它在架構上整體設計，使得成本最低。如果executor被kill，會recover。如果driver被kill，就會很危險。配置nodeselector和affinities來控制Driver調度在非搶占的node，executor調度在spotinstance。會非常費時。如果沒有S3Acommitters，JindofsJobCommitter，應該設置spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version=2。還有Shuffle性能。I/O性能是shuffleboundworkload的關鍵點，spark2.x版本用dockerfilesystem。而Dockerfilesystem是非常慢的，需要用volume來代替。（四）未來工作未來的工作，我認為比較重要的就是shuffle的提升，中間數據的存儲與計算分離。這塊是一個比較大的工作。另外，還有Nodedecommission，支持上傳python依賴文件等等。我們選擇k8s的優缺點，如下圖所示：部署sparkonk8s的具體步驟，如下圖所示：三、EMR團隊云原生的思考和實踐（一）整體架構這塊是我們的一個整體架構，如下圖所示：（二）動態資源&shuffle提升Shuffleservice解決核心問題：?解決動態資源問題?解決掛載云盤貴，事前不確定大小的痛點?解決NAS作為中心存儲的擴展性以及性能問題?避免task由于fetch失敗重新計算的問題，提升中大作業的穩定性?通過Tiered存儲提升作業性能（四）EMRSpark云原生規劃EMR產品體系，創建EMR集群類型為ONACK：?JindoSpark鏡像?JindoFSService/JindoFSSDK提升訪問OSS數據湖能力?JindoJobCommitter增強提交OSS作業能力?JindoShuffleService&動態資源能力增強?ACK集群打通EMR原有集群，可以互訪老集群表和HDFS數據?Operator增強，Dependency管理，提供一站式管控命令?云原生日志、監控一站式平臺使用RayOnSpark在大數據平臺上運行新興的人工智能應用簡介：簡介：RayOnSpark能夠讓Ray的分布式應用直接無縫地集成到ApacheSpark的數據處理流水線中，省去集群間數據傳輸的overhead，支持用戶使用Spark處理的數據做新興人工智能應用的開發。本次直播將由Intel大數據團隊軟件工程師黃凱為您介紹Ray和Intel的開源項目AnalyticsZoo，開發RayOnSpark的動機和初衷，同時結合實際案例分享RayOnSpark的落地實踐。演講嘉賓簡介：黃凱，Intel大數據團隊軟件工程師，大數據和人工智能開源項目AnalyticsZoo和BigDL的核心貢獻者之一本次分享主要圍繞以下五個方面：一、OverviewofAnalyticsZoo二、IntroductiontoRay三、MotivationsforRayOnApacheSpark四、ImplementationdetailsandAPIdesign五、Real-worldusecases一、OverviewofAnalyticsZooAIonBigData英特爾大數據團隊近幾年在助力人工智能落地方面做了很多工作，先后開源了兩個項目。在2016年底開源了BigDL，是基于ApacheSpark開發的分布式高性能的深度學習框架，首次將深度學習引入到大數據平臺中，讓用戶在大數據平臺上更容易使用深度學習的算法。用BigDL寫的深度學習應用是一個標準的Spark程序，可以運行在標準的Spark或Hadoop集群上，對集群不需要做任何特殊的修改。BigDL在深度學習方面對標了現在流行的其他深度學習框架，和它們一樣提供了豐富的深度學習功能。在性能方面BigDL利用并行計算，以及依賴于英特爾底層的庫，如MKL等，使得BigDL基于CPU能有良好的性能。在可擴展性方面，BigDL能通過Spark擴展到成百上千個節點上做對深度學習模型做分布式的訓練和預測。開源了BigDL之后，英特爾又開源了統一的數據分析和AI平臺AnalyticsZoo，用戶可以根據不同的需求，在大數據的平臺上直接運行由使用TensorFlow、PyTorch、Keras、Ray、等框架構建的應用。AnalyticsZoo可以將用戶的大數據平臺作為數據存儲、數據處理挖掘、特征工程、深度學習等一體化的pipeline平臺。AnalyticsZooAnalyticsZoo底層依賴于一系列現有的常用框架，包括主流的深度學習框架、分布式計算框架、Python數據處理庫等，在這些框架之上搭建了一套非常完整的數據分析和人工智能的流水線，包括支持用戶在Spark上跑分布式的TensorFlow和PyTorch，只需要做很小的代碼改動就可以在大數據平臺運行主流的深度學習框架；對SparkDataFrame和MLPipeline提供了原生的深度學習支持；也提供了輕量級的API對訓練好的模型做線上推理。在流水線之上，AnalyticsZoo提供了MLworkflow，幫助用戶自動化地去構建大規模的人工智能應用，比如對時間序列做可擴展的預測，以及分布式ClusterServing。最上層對很多常見領域，如推薦、時間序列、計算機視覺、自然語言處理等等，提供了開箱即用的模型以及參考案例。實際工作中，開發部署一條數據分析和AI的流水線通常需要經歷三個步驟：開發者首先在筆記本上使用樣本數據完成開發的原型，然后使用歷史幾個月的數據在集群上做實驗，實驗結果沒有問題的話再到生產環境中進行大規模的部署。我們希望在執行三個步驟中，用戶幾乎不需要改動，就能將單機的代碼無縫地部署在生成環境中，并且簡化和自動化搭建整個pipeline的過程，這也是開發AnalyticsZoo和RayOnSpark的初衷和目的。二、IntroductiontoRayRay是由UCBerkeley開源的一個能夠非常快速和簡單地去構建分布式應用的框架，RayCore提供了非常友好的API，幫助用戶更容易地并行處理任務。Python用戶只需要增加幾行代碼就可以直接并行地執行Python函數和對象。簡單來說，用戶首先需要importray，調用ray.init()啟動Ray服務。正常情況下，在一個循環中調用多次Python函數是順序執行的，但是如果加上@ray.remote(num_cpus,...)的Python修飾器，就可以去并行執行這些Python函數，最后通過ray.get得到返回值。同樣對Pythonclass也能加上@ray.remote，變成Rayactor能夠被Ray去遠程地啟動。在@ray.remote中還可以指定運行所需資源，比如需要多少CPU等，在運行過程中Ray會預留這些資源。Ray可以支持單機和集群上的并行運行。除了直接使用RayCore實現簡單的并行之外，Ray還提供了一些high-level的library，加速人工智能workload的構建。其中RayTune能自動去調參，RLib提供統一的API去執行不同強化學習任務，RaySGD在PyTorch和TensorFlow原生的分布式模塊之上實現了一層wrapper來簡化部署分布式訓練的過程。三、MotivationsforRayOnApacheSparkRay可以讓用戶很容易的構建新興的人工智能的應用，在實際工作過程中也越來越需要將這些新興的人工智能技術應用在生產成數據上，來創造更多的價值。但其實用戶在這個過程中會往往面臨一些挑戰：首先，生成環境中的數據通常是大規模存儲在大數據集群上，而直接在大數據集群上部署Ray并不容易。其次，如何提前在集群的所有節點上準備好運行所需要的Python環境和依賴，同時不給整個集群帶來副作用。第三，如果用兩個不