亚洲一区精品自拍_2021年国内精品久久_男同十八禁gv在线观看_免费观看a级性爱黄片

Article / 文章中心

阿里云EMR Remote Shuffle Service在小米的實(shí)踐

發(fā)布時(shí)間：2022-01-17 點(diǎn)擊數(shù)：947

Remote Shuffle Service(RSS)

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


一  問題回顧


Shuffle是大數(shù)據(jù)計(jì)算中最為重要的算子。首先，覆蓋率高，超過50%的作業(yè)都包含至少一個(gè)Shuffle[2]。其次，資源消耗大，阿里內(nèi)部平臺Shuffle的CPU占比超過20%，LinkedIn內(nèi)部Shuffle Read導(dǎo)致的資源浪費(fèi)高達(dá)15%[1]，單Shuffle數(shù)據(jù)量超100T[2]。第三，不穩(wěn)定，硬件資源的穩(wěn)定性CPU>內(nèi)存>磁盤≈網(wǎng)絡(luò)，而Shuffle的資源消耗是倒序。OutOfMemory和Fetch Failure可能是Spark作業(yè)最常見的兩種錯(cuò)誤，前者可以通過調(diào)參解決，而后者需要系統(tǒng)性重構(gòu)Shuffle。

傳統(tǒng)Shuffle如下圖所示，Mapper把Shuffle數(shù)據(jù)按PartitionId排序?qū)懕P后交給External Shuffle Service(ESS)管理，Reducer從每個(gè)Mapper Output中讀取屬于自己的Block。

傳統(tǒng)Shuffle


傳統(tǒng)Shuffle存在以下問題。
  • 本地盤依賴限制了存算分離。存算分離是近年來興起的新型架構(gòu)，它解耦了計(jì)算和存儲，可以更靈活地做機(jī)型設(shè)計(jì)：計(jì)算節(jié)點(diǎn)強(qiáng)CPU弱磁盤，存儲節(jié)點(diǎn)強(qiáng)磁盤強(qiáng)網(wǎng)絡(luò)弱CPU。計(jì)算節(jié)點(diǎn)無狀態(tài)，可根據(jù)負(fù)載彈性伸縮。存儲端，隨著對象存儲(OSS, S3)+數(shù)據(jù)湖格式(Delta, Iceberg, Hudi)+本地/近地緩存等方案的成熟，可當(dāng)作容量無限的存儲服務(wù)。用戶通過計(jì)算彈性+存儲按量付費(fèi)獲得成本節(jié)約。然而，Shuffle對本地盤的依賴限制了存算分離。

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

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

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

  • Shuffle數(shù)據(jù)單副本，大規(guī)模集群場景壞盤/壞節(jié)點(diǎn)很普遍，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)實(shí)現(xiàn)了Shuffle跟計(jì)算的解耦，采用多層存儲(內(nèi)存+磁盤)，除此之外沒有披露更多技術(shù)細(xì)節(jié)。

3  Riffle


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

4  Cosco


Facebook Cosco[6][7](2019)采用了Sailfish的方法并做了重設(shè)計(jì)，保留了Push Shuffle + Parititon數(shù)據(jù)聚合的核心方法，但使用了獨(dú)立服務(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的角色維護(hù)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è)計(jì)哲學(xué)是"盡力而為"，Mapper的Output寫完本地后，Push線程會把數(shù)據(jù)推給遠(yuǎn)端的ESS做聚合，且不保證所有數(shù)據(jù)都會聚合。受益于本地Shuffle，Magnet在容錯(cuò)和AE的支持上的表現(xiàn)更好(直接Fallback到傳統(tǒng)Shuffle)。Magnet的局限包括依賴本地盤，不支持存算分離；數(shù)據(jù)合并依賴ESS，對NodeManager造成額外壓力；Shuffle Write同時(shí)寫本地和遠(yuǎn)端，性能達(dá)不到最優(yōu)。Magnet方案已經(jīng)被Apache Spark接納，成為默認(rèn)的開源方案。

8  FireStorm


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


  2. RSS服務(wù)側(cè)架構(gòu)，選項(xiàng)包括：Master-Worker，含輕量級狀態(tài)管理的去中心化，完全去中心化。


  3. Shuffle數(shù)據(jù)的存儲，選項(xiàng)包括：內(nèi)存，本地盤，DFS，對象存儲。


  4. 多副本的實(shí)現(xiàn)，選項(xiàng)包括：Client多推，服務(wù)端做Replication。

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

三  阿里云RSS核心架構(gòu)


針對上一節(jié)的關(guān)鍵設(shè)計(jì)，阿里云RSS的選擇如下：
  1. 獨(dú)立服務(wù)?？紤]到將RSS集成到Spark內(nèi)部無法滿足存算分離架構(gòu)，阿里云RSS將作為獨(dú)立服務(wù)提供Shuffle服務(wù)。


  2. Master-Worker架構(gòu)。通過Master節(jié)點(diǎn)做服務(wù)狀態(tài)管理非常必要，基于etcd的狀態(tài)狀態(tài)管理能力受限。


  3. 多種存儲方式。目前支持本地盤/DFS等存儲方式，主打本地盤，將來會往分層存儲方向發(fā)展。


  4. 服務(wù)端做Replication。Client多推會額外消耗計(jì)算節(jié)點(diǎn)的網(wǎng)絡(luò)和計(jì)算資源，在獨(dú)立部署或者服務(wù)化的場景下對計(jì)算集群不友好。

下圖展示了阿里云RSS的關(guān)鍵架構(gòu)，包含Client(RSS Client, Meta Service)，Master(Resource Manager)和Worker三個(gè)角色。Shuffle的過程如下:
  1. Mapper在首次PushData時(shí)請求Master分配Worker資源，Worker記錄自己所需要服務(wù)的Partition列表。


  2. Mapper把Shuffle數(shù)據(jù)緩存到內(nèi)存，超過閾值時(shí)觸發(fā)Push。


  3. 隸屬同個(gè)Partition的數(shù)據(jù)被Push到同一個(gè)Worker做合并，主Worker內(nèi)存接收到數(shù)據(jù)后立即向從Worker發(fā)起Replication，數(shù)據(jù)達(dá)成內(nèi)存兩副本后即向Client發(fā)送ACK，F(xiàn)lusher后臺線程負(fù)責(zé)刷盤。


  4. Mapper Stage運(yùn)行結(jié)束，MetaService向Worker發(fā)起CommitFiles命令，把殘留在內(nèi)存的數(shù)據(jù)全部刷盤并返回文件列表。


  5. Reducer從對應(yīng)的文件列表中讀取Shuffle數(shù)據(jù)。


Shuffle數(shù)據(jù)

阿里云RSS的核心架構(gòu)和容錯(cuò)方面的介紹詳見[13]，本文接下來介紹阿里云RSS近一年的架構(gòu)演進(jìn)以及不同于其他系統(tǒng)的特色。

1  狀態(tài)下沉


RSS采用Master-Worker架構(gòu)，最初的設(shè)計(jì)中Master統(tǒng)一負(fù)責(zé)集群狀態(tài)管理和Shuffle生命周期管理。集群狀態(tài)包括Worker的健康度和負(fù)載；生命周期包括每個(gè)Shuffle由哪些Worker服務(wù)，每個(gè)Worker所服務(wù)的Partition列表，Shuffle所處的狀態(tài)(Shuffle Write，CommitFile，Shuffle Read)，是否有數(shù)據(jù)丟失等。維護(hù)Shuffle生命周期需要較大數(shù)據(jù)量和復(fù)雜數(shù)據(jù)結(jié)構(gòu)，給Master HA的實(shí)現(xiàn)造成阻力。同時(shí)大量生命周期管理的服務(wù)調(diào)用使Master易成為性能瓶頸，限制RSS的擴(kuò)展性。

為了緩解Master壓力，我們把生命周期狀態(tài)管理下沉到Driver，由Application管理自己的Shuffle，Master只需維護(hù)RSS集群本身的狀態(tài)。這個(gè)優(yōu)化大大降低Master的負(fù)載，并使得Master HA得以順利實(shí)現(xiàn)。

Master HA

2  Adaptive Pusher


在最初的設(shè)計(jì)中，阿里云RSS跟其他系統(tǒng)一樣采用Hash-Based Pusher，即Client會為每個(gè)Partition維護(hù)一個(gè)(或多個(gè)[11])內(nèi)存Buffer，當(dāng)Buffer超過閾值時(shí)觸發(fā)推送。這種設(shè)計(jì)在并發(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，這是不可接受的。針對這個(gè)問題，我們開發(fā)了Sort-Based Pusher，緩存數(shù)據(jù)時(shí)不區(qū)分Partition，當(dāng)總的數(shù)據(jù)超過閾值(i.e. 64M)時(shí)對當(dāng)前數(shù)據(jù)按照PartitionId排序，然后把數(shù)據(jù)Batch后推送，從而解決內(nèi)存消耗過大的問題。
Sort-Based Pusher會額外引入一次排序，性能上比Hash-Based Pusher略差。我們在ShuffleWriter初始化階段根據(jù)Reducer的并發(fā)度自動選擇合適的Pusher。

3  磁盤容錯(cuò)


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

4  滾動升級


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


Worker

5  混亂測試框架


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

我們認(rèn)為仿真測試框架的思路是通用設(shè)計(jì)，可以推廣到更多的服務(wù)測試中。


仿真測試框架的思路

6  多引擎支持


Shuffle是通用操作，不跟引擎綁定，因此我們嘗試了多引擎支持。當(dāng)前我們支持了Hive+RSS，同時(shí)也在探索跟流計(jì)算引擎(Flink)，MPP引擎(Presto)結(jié)合的可能性。盡管Hive和Spark都是批計(jì)算引擎，但Shuffle的行為并不一致，最大的差異是Hive在Mapper端做排序，Reducer只做Merge，而Spark在Reducer端做排序。由于RSS暫未支持計(jì)算，因此需要改造Tez支持Reducer排序。此外，Spark有干凈的Shuffle插件接口，RSS只需在外圍擴(kuò)展，而Tez沒有類似抽象，在這方面也有一定侵入性。
當(dāng)前大多數(shù)引擎都沒有Shuffle插件化的抽象，需要一定程度的引擎修改。此外，流計(jì)算和MPP都是上游即時(shí)Push給下游的模式，而RSS是上游Push，下游Pull的模式，這兩者如何結(jié)合也是需要探索的。

7  測試


我們對比了阿里云RSS、Magent及開源系統(tǒng)X。由于大家的系統(tǒng)還在向前演進(jìn)，因此測試結(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。在這個(gè)Benchmark下，RSS明顯優(yōu)于另外兩個(gè)，Magent的e2e時(shí)間略好于傳統(tǒng)Shuffle。



 阿里云RSS vs. Magnet

阿里云RSS vs. 開源系統(tǒng)X
RSS跟開源系統(tǒng)X在TPCDS-3T的性能對比如下，總時(shí)間RSS快了20%。

TPCDS-3T

穩(wěn)定性
在穩(wěn)定性方面，我們測試了Reducer大規(guī)模并發(fā)的場景，Magnet可以跑通但時(shí)間比RSS慢了數(shù)倍，System X在Shuffle Write階段報(bào)錯(cuò)。

四  阿里云RSS在小米的實(shí)踐


1  現(xiàn)狀及痛點(diǎn)


小米的離線集群以Yarn+HDFS為主，NodeManager和DataNode混合部署。Spark是主要的離線引擎，支撐著核心計(jì)算任務(wù)。Spark作業(yè)當(dāng)前最大的痛點(diǎn)集中在Shuffle導(dǎo)致的穩(wěn)定性差，性能差和對存算分離架構(gòu)的限制。在進(jìn)行資源保證和作業(yè)調(diào)優(yōu)后，作業(yè)失敗原因主要?dú)w結(jié)為Fetch Failure，如下圖所示。由于大部分集群使用的是HDD，傳統(tǒng)Shuffle的高隨機(jī)讀和高網(wǎng)絡(luò)連接導(dǎo)致性能很差，低穩(wěn)定性帶來的Stage重算會進(jìn)一步加劇性能回退。此外，小米一直在嘗試?yán)么嫠惴蛛x架構(gòu)的計(jì)算彈性降低成本，但Shuffle對本地盤的依賴造成了阻礙。

小米的離線集群

2  RSS在小米的落地


小米一直在關(guān)注Shuffle優(yōu)化相關(guān)技術(shù)，21年1月份跟阿里云EMR團(tuán)隊(duì)就RSS項(xiàng)目建立了共創(chuàng)關(guān)系，3月份第一個(gè)生產(chǎn)集群上線，開始接入作業(yè)，6月份第一個(gè)HA集群上線，規(guī)模達(dá)100+節(jié)點(diǎn)，9月份第一個(gè)300+節(jié)點(diǎn)上線，集群默認(rèn)開啟RSS，后續(xù)規(guī)劃會進(jìn)一步擴(kuò)展RSS的灰度規(guī)模。
在落地的過程，小米主導(dǎo)了磁盤容錯(cuò)的開發(fā)，大大提高了RSS的服務(wù)穩(wěn)定性，技術(shù)細(xì)節(jié)如上文所述。此外，在前期RSS還未完全穩(wěn)定階段，小米在多個(gè)環(huán)節(jié)對RSS的作業(yè)進(jìn)行了容錯(cuò)。在調(diào)度端，若開啟RSS的Spark作業(yè)因Shuffle報(bào)錯(cuò)，則Yarn的下次重試會回退到ESS。在ShuffleWriter初始化階段，小米主導(dǎo)了自適應(yīng)Fallback機(jī)制，根據(jù)當(dāng)前RSS集群的負(fù)載和作業(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è)運(yùn)行時(shí)間的對比。
ESS:

小米海外集群接入RSS

在存算分離方面，小米海外某集群接入RSS后，成功上線了1600+ Core的彈性集群，且作業(yè)運(yùn)行穩(wěn)定。
在阿里云EMR團(tuán)隊(duì)及小米Spark團(tuán)隊(duì)的共同努力下，RSS帶來的穩(wěn)定性和性能提升得到了充分的驗(yàn)證。后續(xù)小米將會持續(xù)擴(kuò)大RSS集群規(guī)模以及作業(yè)規(guī)模，并且在彈性資源伸縮場景下發(fā)揮更大的作用。

五  開源


重要的事說三遍：“阿里云RSS開源啦!” X 3
git地址: https://github.com/alibaba/RemoteShuffleService
開源代碼包含核心功能及容錯(cuò)，滿足生產(chǎn)要求。
計(jì)劃中的重要Feature:
  1. AE
  2. Spark多版本支持
  1. Better 流控
  2. Better 監(jiān)控
  1. Better HA
  2. 多引擎支持

歡迎各路開發(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在趣頭條的實(shí)踐. https://developer.aliyun.com/article/779686[13]Aliyun RSS架構(gòu). https://developer.aliyun.com/article/772329

Redis數(shù)據(jù)庫入門


Redis是一個(gè)開源的使用ANSI C語言編寫、支持網(wǎng)絡(luò)、可基于內(nèi)存亦可持久化的日志型、Key-Value數(shù)據(jù)庫，并提供多種語言的API。Redis 是一個(gè)高性能的key-value數(shù)據(jù)庫。Redis的出現(xiàn)，很大程度補(bǔ)償了memcached這類key/value存儲的不足，在部 分場合可以對關(guān)系數(shù)據(jù)庫起到很好的補(bǔ)充作用。它提供了Java，C/C++，C#，PHP，JavaScript，Perl，Object-C，Python，Ruby，Erlang等客戶端，使用很方便。點(diǎn)擊閱讀原文查看詳情。