国产精品chinese,色综合天天综合精品网国产在线,成午夜免费视频在线观看,清纯女学生被强行糟蹋小说

    <td id="ojr13"><tr id="ojr13"><label id="ojr13"></label></tr></td>

        1. 
<source id="ojr13"></source>
            <td id="ojr13"><ins id="ojr13"><label id="ojr13"></label></ins></td>
            

            
 
            
 
            
  
 
            

            
 
            
  
            
   
            Article / 文章中心
            
  
            
 
            
 
            
   
   
            
     
            
       
            阿里云EMR Remote Shuffle Service在小米的實踐
            
       
            發(fā)布時間：2022-01-17 點擊數(shù)：852
              
            
       
            
        
            
	Remote Shuffle Service(RSS) 

            

            
	阿里云EMR自2020年推出Remote Shuffle Service(RSS)以來，幫助了諸多客戶解決Spark作業(yè)的性能、穩(wěn)定性問題，并使得存算分離架構(gòu)得以實施，與此同時RSS也在跟合作方小米的共建下不斷演進。本文將介紹RSS的最新架構(gòu)，在小米的實踐，以及開源。 

            

            
             
             一  問題回顧 
	
            

             
            
             
		
            
Shuffle是大數(shù)據(jù)計算中最為重要的算子。首先，覆蓋率高，超過50%的作業(yè)都包含至少一個Shuffle[2]。其次，資源消耗大，阿里內(nèi)部平臺Shuffle的CPU占比超過20%，LinkedIn內(nèi)部Shuffle Read導(dǎo)致的資源浪費高達15%[1]，單Shuffle數(shù)據(jù)量超100T[2]。第三，不穩(wěn)定，硬件資源的穩(wěn)定性CPU>內(nèi)存>磁盤≈網(wǎng)絡(luò)，而Shuffle的資源消耗是倒序。OutOfMemory和Fetch Failure可能是Spark作業(yè)最常見的兩種錯誤，前者可以通過調(diào)參解決，而后者需要系統(tǒng)性重構(gòu)Shuffle。
            
             
		
            
			傳統(tǒng)Shuffle如下圖所示，Mapper把Shuffle數(shù)據(jù)按PartitionId排序?qū)懕P后交給External Shuffle Service(ESS)管理，Reducer從每個Mapper Output中讀取屬于自己的Block。 
		
            
		
            
			傳統(tǒng)Shuffle 
		
            
		
            
			
            
             
		
            
傳統(tǒng)Shuffle存在以下問題。
            
             
              
		
            • 
			本地盤依賴限制了存算分離。存算分離是近年來興起的新型架構(gòu)，它解耦了計算和存儲，可以更靈活地做機型設(shè)計：計算節(jié)點強CPU弱磁盤，存儲節(jié)點強磁盤強網(wǎng)絡(luò)弱CPU。計算節(jié)點無狀態(tài)，可根據(jù)負載彈性伸縮。存儲端，隨著對象存儲(OSS, S3)+數(shù)據(jù)湖格式(Delta, Iceberg, Hudi)+本地/近地緩存等方案的成熟，可當(dāng)作容量無限的存儲服務(wù)。用戶通過計算彈性+存儲按量付費獲得成本節(jié)約。然而，Shuffle對本地盤的依賴限制了存算分離。 
		
              • 
			
            

            

              
			
            • 
				寫放大。當(dāng)Mapper Output數(shù)據(jù)量超過內(nèi)存時觸發(fā)外排，從而引入額外磁盤IO。 
			
              • 
		
            

            

              
		
            • 
			大量隨機讀。Mapper Output屬于某個Reducer的數(shù)據(jù)量很小，如Output 128M，Reducer并發(fā)2000，則每個Reducer只讀64K，從而導(dǎo)致大量小粒度隨機讀。對于HDD，隨機讀性能極差；對于SSD，會快速消耗SSD壽命。 
		
              • 
			
            

            

              
			
            • 
				高網(wǎng)絡(luò)連接數(shù)，導(dǎo)致線程池消耗過多CPU，帶來性能和穩(wěn)定性問題。 
			
              • 
		
            

            

              
		
            • 
			Shuffle數(shù)據(jù)單副本，大規(guī)模集群場景壞盤/壞節(jié)點很普遍，Shuffle數(shù)據(jù)丟失引發(fā)的Stage重算帶來性能和穩(wěn)定性問題。 
		
              • 
			
            

             
            
				
            

             二  RSS發(fā)展歷程 
			
            

             
            
             
				
            
針對Shuffle的問題，工業(yè)界嘗試了各種方法，近兩年逐漸收斂到Push Shuffle的方案。 
             
            
					
            

             1  Sailfish 
				
            

             
            
             
			
            
Sailfish[3](2012)最早提出Push Shuffle + Partition數(shù)據(jù)聚合的方法，對大作業(yè)有20%-5倍的性能提升。Sailfish魔改了分布式文件系統(tǒng)KFS[4]，不支持多副本。
            
             
             2  Dataflow 
				
            

             
            
             
					
            
Goolge BigQuery和Cloud Dataflow[5](2018)實現(xiàn)了Shuffle跟計算的解耦，采用多層存儲(內(nèi)存+磁盤)，除此之外沒有披露更多技術(shù)細節(jié)。
            
             
             3  Riffle 
						
            

             
            
             
							
            
Facebook Riffle[2](2018)采用了在Mapper端Merge的方法，物理節(jié)點上部署的Riffle服務(wù)負責(zé)把此節(jié)點上的Shuffle數(shù)據(jù)按照PartitionId做Merge，從而一定程度把小粒度的隨機讀合并成較大粒度。
            
             
             4  Cosco 
								
            

             
            
             
									
            
Facebook Cosco[6][7](2019)采用了Sailfish的方法并做了重設(shè)計，保留了Push Shuffle + Parititon數(shù)據(jù)聚合的核心方法，但使用了獨立服務(wù)。服務(wù)端采用Master-Worker架構(gòu)，使用內(nèi)存兩副本，用DFS做持久化。Cosco基本上定義了RSS的標(biāo)準(zhǔn)架構(gòu)，但受到DFS的拖累，性能上并沒有顯著提升。
            
             
             5  Zeus 
										
            

             
            
             
											
            
Uber Zeus[8][9](2020)同樣采用了去中心化的服務(wù)架構(gòu)，但沒有類似etcd的角色維護Worker狀態(tài)，因此難以做狀態(tài)管理。Zeus通過Client雙推的方式做多副本，采用本地存儲。
            
             
             6  RPMP 
												
            

             
            
             
													
            
Intel RPMP[10](2020)依靠RDMA和PMEM的新硬件來加速Shuffle，并沒有做數(shù)據(jù)聚合。
            
             
             7  Magnet 
														
            

             
            
             
															
            
LinkedIn Magnet[1](2021)融合了本地Shuffle+Push Shuffle，其設(shè)計哲學(xué)是"盡力而為"，Mapper的Output寫完本地后，Push線程會把數(shù)據(jù)推給遠端的ESS做聚合，且不保證所有數(shù)據(jù)都會聚合。受益于本地Shuffle，Magnet在容錯和AE的支持上的表現(xiàn)更好(直接Fallback到傳統(tǒng)Shuffle)。Magnet的局限包括依賴本地盤，不支持存算分離；數(shù)據(jù)合并依賴ESS，對NodeManager造成額外壓力；Shuffle Write同時寫本地和遠端，性能達不到最優(yōu)。Magnet方案已經(jīng)被Apache Spark接納，成為默認的開源方案。
            
             
             8  FireStorm 
																
            

             
            
             
																	
            
FireStorm[11](2021)混合了Cosco和Zeus的設(shè)計，服務(wù)端采用Master-Worker架構(gòu)，通過Client多寫實現(xiàn)多副本。FireStorm使用了本地盤+對象存儲的多層存儲，采用較大的PushBlock(默認3M)。FireStorm在存儲端保留了PushBlock的元信息，并記錄在索引文件中。FireStorm的Client緩存數(shù)據(jù)的內(nèi)存由Spark MemoryManager進行管理，并通過細顆粒度的內(nèi)存分配(默認3K)來盡量避免內(nèi)存浪費。
            
從上述描述可知，當(dāng)前的方案基本收斂到Push Shuffle，但在一些關(guān)鍵設(shè)計上的選擇各家不盡相同，主要體現(xiàn)在:
            
             
              
																	
            1. 
																		集成到Spark內(nèi)部還是獨立服務(wù)。 
																		
              
																			
              
																		
              
																	
              2. 
																	
            2. 
																		RSS服務(wù)側(cè)架構(gòu)，選項包括：Master-Worker，含輕量級狀態(tài)管理的去中心化，完全去中心化。 
																		
              
																			
              
																		
              
																	
              3. 
																	
            3. 
																		Shuffle數(shù)據(jù)的存儲，選項包括：內(nèi)存，本地盤，DFS，對象存儲。 
																		
              
																			
              
																		
              
																	
              4. 
																	
            4. 
																		多副本的實現(xiàn)，選項包括：Client多推，服務(wù)端做Replication。 
																	
              5. 
																		
            

            
阿里云RSS[12][13]由2020年推出，核心設(shè)計參考了Sailfish和Cosco，并且在架構(gòu)和實現(xiàn)層面做了改良，下文將詳細介紹。
            
             
             三  阿里云RSS核心架構(gòu) 
																			
            

             
            
             
																				
            
針對上一節(jié)的關(guān)鍵設(shè)計，阿里云RSS的選擇如下：
            
             
              
																				
            1. 
																					獨立服務(wù)?？紤]到將RSS集成到Spark內(nèi)部無法滿足存算分離架構(gòu)，阿里云RSS將作為獨立服務(wù)提供Shuffle服務(wù)。 
																					
              
																						
              
																					
              
																				
              2. 
																				
            2. 
																					Master-Worker架構(gòu)。通過Master節(jié)點做服務(wù)狀態(tài)管理非常必要，基于etcd的狀態(tài)狀態(tài)管理能力受限。 
																					
              
																						
              
																					
              
																				
              3. 
																				
            3. 
																					多種存儲方式。目前支持本地盤/DFS等存儲方式，主打本地盤，將來會往分層存儲方向發(fā)展。 
																					
              
																						
              
																					
              
																				
              4. 
																				
            4. 
																					服務(wù)端做Replication。Client多推會額外消耗計算節(jié)點的網(wǎng)絡(luò)和計算資源，在獨立部署或者服務(wù)化的場景下對計算集群不友好。 
																				
              5. 
																					
            

            
下圖展示了阿里云RSS的關(guān)鍵架構(gòu)，包含Client(RSS Client, Meta Service)，Master(Resource Manager)和Worker三個角色。Shuffle的過程如下:
            
             
              
																					
            1. 
																						Mapper在首次PushData時請求Master分配Worker資源，Worker記錄自己所需要服務(wù)的Partition列表。 
																						
              
																							
              
																						
              
																					
              2. 
																					
            2. 
																						Mapper把Shuffle數(shù)據(jù)緩存到內(nèi)存，超過閾值時觸發(fā)Push。 
																						
              
																							
              
																						
              
																					
              3. 
																					
            3. 
																						隸屬同個Partition的數(shù)據(jù)被Push到同一個Worker做合并，主Worker內(nèi)存接收到數(shù)據(jù)后立即向從Worker發(fā)起Replication，數(shù)據(jù)達成內(nèi)存兩副本后即向Client發(fā)送ACK，F(xiàn)lusher后臺線程負責(zé)刷盤。 
																						
              
																							
              
																						
              
																					
              4. 
																					
            4. 
																						Mapper Stage運行結(jié)束，MetaService向Worker發(fā)起CommitFiles命令，把殘留在內(nèi)存的數(shù)據(jù)全部刷盤并返回文件列表。 
																						
              
																							
              
																						
              
																					
              5. 
																					
            5. 
																						Reducer從對應(yīng)的文件列表中讀取Shuffle數(shù)據(jù)。 
																					
              6. 
																				
            
             
																				
            
																					
            
																				
            
																				
            
																					Shuffle數(shù)據(jù) 
																				
            
阿里云RSS的核心架構(gòu)和容錯方面的介紹詳見[13]，本文接下來介紹阿里云RSS近一年的架構(gòu)演進以及不同于其他系統(tǒng)的特色。
            
             
             1  狀態(tài)下沉 
																					
            

             
            
             
																						
            
RSS采用Master-Worker架構(gòu)，最初的設(shè)計中Master統(tǒng)一負責(zé)集群狀態(tài)管理和Shuffle生命周期管理。集群狀態(tài)包括Worker的健康度和負載；生命周期包括每個Shuffle由哪些Worker服務(wù)，每個Worker所服務(wù)的Partition列表，Shuffle所處的狀態(tài)(Shuffle Write，CommitFile，Shuffle Read)，是否有數(shù)據(jù)丟失等。維護Shuffle生命周期需要較大數(shù)據(jù)量和復(fù)雜數(shù)據(jù)結(jié)構(gòu)，給Master HA的實現(xiàn)造成阻力。同時大量生命周期管理的服務(wù)調(diào)用使Master易成為性能瓶頸，限制RSS的擴展性。
            
             
																						
            
																							為了緩解Master壓力，我們把生命周期狀態(tài)管理下沉到Driver，由Application管理自己的Shuffle，Master只需維護RSS集群本身的狀態(tài)。這個優(yōu)化大大降低Master的負載，并使得Master HA得以順利實現(xiàn)。 
																						
            
																						
            
																							Master HA 
																						
            
 
             2  Adaptive Pusher 
																							
            

             
            
             
																								
            
在最初的設(shè)計中，阿里云RSS跟其他系統(tǒng)一樣采用Hash-Based Pusher，即Client會為每個Partition維護一個(或多個[11])內(nèi)存Buffer，當(dāng)Buffer超過閾值時觸發(fā)推送。這種設(shè)計在并發(fā)度適中的情況下沒有問題，而在超大并發(fā)度的情況下會導(dǎo)致OOM。例如Reducer的并發(fā)5W，在小Buffer[13]的系統(tǒng)中(64K)極端內(nèi)存消耗為64K*5W=3G，在大Buffer[11]的系統(tǒng)中(3M)極端內(nèi)存消耗為3M*5W=146G，這是不可接受的。針對這個問題，我們開發(fā)了Sort-Based Pusher，緩存數(shù)據(jù)時不區(qū)分Partition，當(dāng)總的數(shù)據(jù)超過閾值(i.e. 64M)時對當(dāng)前數(shù)據(jù)按照PartitionId排序，然后把數(shù)據(jù)Batch后推送，從而解決內(nèi)存消耗過大的問題。
            
            Sort-Based Pusher會額外引入一次排序，性能上比Hash-Based Pusher略差。我們在ShuffleWriter初始化階段根據(jù)Reducer的并發(fā)度自動選擇合適的Pusher。
            
             
             3  磁盤容錯 
																									
            

             
            
             
																										
            
出于性能的考慮，阿里云RSS推薦本地盤存儲，因此處理壞/慢盤是保證服務(wù)可靠性的前提。Worker節(jié)點的DeviceMonitor線程定時對磁盤進行檢查，檢查項包括IOHang，使用量，讀寫異常等。此外Worker在所有磁盤操作處(創(chuàng)建文件，刷盤)都會捕捉異常并上報。IOHang、讀寫異常被認為是Critical Error，磁盤將被隔離并終止該磁盤上的存儲服務(wù)。慢盤、使用量超警戒線等異常僅將磁盤隔離，不再接受新的Partition存儲請求，但已有的Partition服務(wù)保持正常。在磁盤被隔離后，Worker的容量和負載將發(fā)生變化，這些信息將通過心跳發(fā)送給Master。
            
             
             4  滾動升級 
																											
            

             
            
             
																												
            
RSS作為常駐服務(wù)，有永不停服的要求，而系統(tǒng)本身總在向前演進，因此滾動升級是必選的功能。盡管通過Sub-Cluster部署方式可以繞過，即部署多個子集群，對子集群做灰度，灰度的集群暫停服務(wù)，但這種方式依賴調(diào)度系統(tǒng)感知正在灰度的集群并動態(tài)修改作業(yè)配置。我們認為RSS應(yīng)該把滾動升級閉環(huán)掉，核心設(shè)計如下圖所示。Client向Master節(jié)點的Leader角色(Master實現(xiàn)了HA，見上文)發(fā)起滾動升級請求并把更新包上傳給Leader，Leader通過Raft協(xié)議修改狀態(tài)為滾動升級，并啟動第一階段的升級：升級Master節(jié)點。Leader首先升級所有的Follower，然后替換本地包并重啟。在Leader節(jié)點改變的情況下，升級過程不會中斷或異常。Master節(jié)點升級結(jié)束后進入第二階段：Worker節(jié)點升級。RSS采用滑動窗口做升級，窗口內(nèi)的Worker盡量優(yōu)雅下線，即拒絕新的Partition請求，并等待本地Shuffle結(jié)束。為了避免等待時間過長，會設(shè)置超時時間。此外，窗口內(nèi)的Worker選擇會盡量避免同時包含主從兩副本以降低數(shù)據(jù)丟失的概率。             
																												
            
																													
            
																												
            
																												
            
																													Worker 
																												
            

             5  混亂測試框架 
																													
            

             
            
             
																														
            
對于服務(wù)來說，僅依靠UT、集成測試、e2e測試等無法保證服務(wù)可靠性，因為這些測試無法覆蓋線上復(fù)雜環(huán)境，如壞盤、CPU過載、網(wǎng)絡(luò)過載、機器掛掉等。RSS要求在出現(xiàn)這些復(fù)雜情況時保持服務(wù)穩(wěn)定，為了模擬線上環(huán)境，我們開發(fā)了仿真(混亂)測試框架，在測試環(huán)境中模擬線上可能出現(xiàn)的異常，同時保證滿足RSS運行的最小運行環(huán)境，即至少3個Master節(jié)點和2個Worker節(jié)點可用，并且每個Worker節(jié)點至少有一塊盤。我們持續(xù)對RSS做此類壓力測試。
            
            仿真測試框架架構(gòu)如下圖所示，首先定義測試Plan來描述事件類型、事件觸發(fā)的順序及持續(xù)時間，事件類型包括節(jié)點異常，磁盤異常，IO異常，CPU過載等?？蛻舳藢lan提交給Scheduler，Scheduler根據(jù)Plan的描述給每個節(jié)點的Runner發(fā)送具體的Operation，Runner負責(zé)具體執(zhí)行并匯報當(dāng)前節(jié)點的狀態(tài)。在觸發(fā)Operation之前，Scheduler會推演該事件發(fā)生產(chǎn)生的后果，若導(dǎo)致無法滿足RSS的最小可運行環(huán)境，將拒絕此事件。
            
             
																														
            
																															我們認為仿真測試框架的思路是通用設(shè)計，可以推廣到更多的服務(wù)測試中。 
																														
            
																														
            
																															
            
																														
            
																														
            
																															仿真測試框架的思路
																														
            

																														
            
																															6  多引擎支持
																														
            
																														
            
																															
            
            
																														
            
Shuffle是通用操作，不跟引擎綁定，因此我們嘗試了多引擎支持。當(dāng)前我們支持了Hive+RSS，同時也在探索跟流計算引擎(Flink)，MPP引擎(Presto)結(jié)合的可能性。盡管Hive和Spark都是批計算引擎，但Shuffle的行為并不一致，最大的差異是Hive在Mapper端做排序，Reducer只做Merge，而Spark在Reducer端做排序。由于RSS暫未支持計算，因此需要改造Tez支持Reducer排序。此外，Spark有干凈的Shuffle插件接口，RSS只需在外圍擴展，而Tez沒有類似抽象，在這方面也有一定侵入性。
            
            當(dāng)前大多數(shù)引擎都沒有Shuffle插件化的抽象，需要一定程度的引擎修改。此外，流計算和MPP都是上游即時Push給下游的模式，而RSS是上游Push，下游Pull的模式，這兩者如何結(jié)合也是需要探索的。
            
            
																														
            
																															7  測試
																														
            
																														
            
																															
            
            
																														
            
我們對比了阿里云RSS、Magent及開源系統(tǒng)X。由于大家的系統(tǒng)還在向前演進，因此測試結(jié)果僅代表當(dāng)前。
            
            測試環(huán)境
            
            Header * 1: ecs.g6e.4xlarge, 16 * 2.5GHz/3.2GHz, 64GiB, 10GbpsWorker * 3: ecs.g6e.8xlarge, 32 * 2.5GHz/3.2GHz, 128GiB, 10Gbps
            
            阿里云RSS vs. Magnet
            
            5T Terasort的性能測試如下圖所示，如上文描述，Magent的Shuffle Write有額外開銷，差于RSS和傳統(tǒng)做法。Magent的Shuffle Read有提升，但差于RSS。在這個Benchmark下，RSS明顯優(yōu)于另外兩個，Magent的e2e時間略好于傳統(tǒng)Shuffle。
																														
            
																															
            

            
 阿里云RSS vs. Magnet
																														
            
阿里云RSS vs. 開源系統(tǒng)X
            
            RSS跟開源系統(tǒng)X在TPCDS-3T的性能對比如下，總時間RSS快了20%。
																														
            
																															TPCDS-3T
																														
            
穩(wěn)定性
            
            在穩(wěn)定性方面，我們測試了Reducer大規(guī)模并發(fā)的場景，Magnet可以跑通但時間比RSS慢了數(shù)倍，System X在Shuffle Write階段報錯。
            
            
																														
            
																															四  阿里云RSS在小米的實踐
																														
            
																														
            
																															
            
            
																														
            
																														
            
																															1  現(xiàn)狀及痛點
																														
            
																														
            
																															
            
            
																														
            
小米的離線集群以Yarn+HDFS為主，NodeManager和DataNode混合部署。Spark是主要的離線引擎，支撐著核心計算任務(wù)。Spark作業(yè)當(dāng)前最大的痛點集中在Shuffle導(dǎo)致的穩(wěn)定性差，性能差和對存算分離架構(gòu)的限制。在進行資源保證和作業(yè)調(diào)優(yōu)后，作業(yè)失敗原因主要歸結(jié)為Fetch Failure，如下圖所示。由于大部分集群使用的是HDD，傳統(tǒng)Shuffle的高隨機讀和高網(wǎng)絡(luò)連接導(dǎo)致性能很差，低穩(wěn)定性帶來的Stage重算會進一步加劇性能回退。此外，小米一直在嘗試?yán)么嫠惴蛛x架構(gòu)的計算彈性降低成本，但Shuffle對本地盤的依賴造成了阻礙。
																														
            
																															小米的離線集群
																														
            
																														
            
																															2  RSS在小米的落地
																														
            
																														
            
																															
            
            
																														
            
小米一直在關(guān)注Shuffle優(yōu)化相關(guān)技術(shù)，21年1月份跟阿里云EMR團隊就RSS項目建立了共創(chuàng)關(guān)系，3月份第一個生產(chǎn)集群上線，開始接入作業(yè)，6月份第一個HA集群上線，規(guī)模達100+節(jié)點，9月份第一個300+節(jié)點上線，集群默認開啟RSS，后續(xù)規(guī)劃會進一步擴展RSS的灰度規(guī)模。
            
            在落地的過程，小米主導(dǎo)了磁盤容錯的開發(fā)，大大提高了RSS的服務(wù)穩(wěn)定性，技術(shù)細節(jié)如上文所述。此外，在前期RSS還未完全穩(wěn)定階段，小米在多個環(huán)節(jié)對RSS的作業(yè)進行了容錯。在調(diào)度端，若開啟RSS的Spark作業(yè)因Shuffle報錯，則Yarn的下次重試會回退到ESS。在ShuffleWriter初始化階段，小米主導(dǎo)了自適應(yīng)Fallback機制，根據(jù)當(dāng)前RSS集群的負載和作業(yè)的特征(如Reducer并發(fā)是否過大)自動選擇RSS或ESS，從而提升穩(wěn)定性。
            
            
																														
            
																															3  效果
																														
            
																														
            
																															
            
            
																														
            
接入RSS后，Spark作業(yè)的穩(wěn)定性、性能都取得了顯著提升。之前因Fetch Failure失敗的作業(yè)幾乎不再失敗，性能平均有20%的提升。下圖展示了接入RSS前后作業(yè)穩(wěn)定性的對比。
            
            ESS：
																														
            
																															接入RSS前后作業(yè)穩(wěn)定性
																														
            
																														
            
																															RSS:
																														
            
																														
            
																															接入RSS前后作業(yè)穩(wěn)定性的對比
																														
            
																														
            
																															
            
																																
            
            
																															
            
																														
            
下圖展示了接入RSS前后作業(yè)運行時間的對比。
            
            ESS:
																														
            
																															小米海外集群接入RSS
																														
            
在存算分離方面，小米海外某集群接入RSS后，成功上線了1600+ Core的彈性集群，且作業(yè)運行穩(wěn)定。
            
            在阿里云EMR團隊及小米Spark團隊的共同努力下，RSS帶來的穩(wěn)定性和性能提升得到了充分的驗證。后續(xù)小米將會持續(xù)擴大RSS集群規(guī)模以及作業(yè)規(guī)模，并且在彈性資源伸縮場景下發(fā)揮更大的作用。
            
            
																														
            
																															五  開源
																														
            
																														
            
																															
            
            
																														
            
重要的事說三遍：“阿里云RSS開源啦!” X 3
            
            git地址: https://github.com/alibaba/RemoteShuffleService
            
開源代碼包含核心功能及容錯，滿足生產(chǎn)要求。
            
            計劃中的重要Feature:
            
            
																														
              
																															
            1. 
																																AE
																															
              2. 
																															
            2. 
																																Spark多版本支持
																															
              3. 
																														
            
																														
              
																															
            1. 
																																Better 流控
																															
              2. 
																															
            2. 
																																Better 監(jiān)控
																															
              3. 
																														
            
																														
              
																															
            1. 
																																Better HA
																															
              2. 
																															
            2. 
																																多引擎支持
																															
              3. 
																														
            

            
歡迎各路開發(fā)者共建！
																														
            
																															
            
																														
            
																														
            
																															六  Reference
																														
            
																														
            
																															
            
            
																														
            
[1]Min Shen, Ye Zhou, Chandni Singh. Magnet: Push-based Shuffle Service for Large-scale Data Processing. VLDB 2020.[2]Haoyu Zhang, Brian Cho, Ergin Seyfe, Avery Ching, Michael J. Freedman. Riffle: Optimized Shuffle Service for Large-Scale Data Analytics. EuroSys 2018.[3]Sriram Rao, Raghu Ramakrishnan, Adam Silberstein. Sailfish: A Framework For Large Scale Data Processing. SoCC 2012.[4]KFS. http://code.google.com/p/kosmosfs/[5]Google Dataflow Shuffle. https://cloud.google.com/blog/products/data-analytics/how-distributed-shuffle-improves-scalability-and-performance-cloud-dataflow-pipelines[6]Cosco: An Efficient Facebook-Scale Shuffle Service. https://databricks.com/session/cosco-an-efficient-facebook-scale-shuffle-service[7]Flash for Apache Spark Shuffle with Cosco. https://databricks.com/session_na20/flash-for-apache-spark-shuffle-with-cosco[8]Uber Zeus. https://databricks.com/session_na20/zeus-ubers-highly-scalable-and-distributed-shuffle-as-a-service[9]Uber Zeus. https://github.com/uber/RemoteShuffleService[10]Intel RPMP. https://databricks.com/session_na20/accelerating-apache-spark-shuffle-for-data-analytics-on-the-cloud-with-remote-persistent-memory-pools[11]Tencent FireStorm. https://github.com/Tencent/Firestorm[12]Aliyun RSS在趣頭條的實踐. https://developer.aliyun.com/article/779686[13]Aliyun RSS架構(gòu). https://developer.aliyun.com/article/772329
            
																														
            
																														
            
																														
            
																															Redis數(shù)據(jù)庫入門
																														
            
																														
            
																															
            
            
																														
            
Redis是一個開源的使用ANSI C語言編寫、支持網(wǎng)絡(luò)、可基于內(nèi)存亦可持久化的日志型、Key-Value數(shù)據(jù)庫，并提供多種語言的API。Redis 是一個高性能的key-value數(shù)據(jù)庫。Redis的出現(xiàn)，很大程度補償了memcached這類key/value存儲的不足，在部 分場合可以對關(guān)系數(shù)據(jù)庫起到很好的補充作用。它提供了Java，C/C++，C#，PHP，JavaScript，Perl，Object-C，Python，Ruby，Erlang等客戶端，使用很方便。點擊閱讀原文查看詳情。