背景

Apache Spark作為當(dāng)前最為流行的開源大數(shù)據(jù)計(jì)算框架膨俐，廣泛應(yīng)用于數(shù)據(jù)處理和分析應(yīng)用怕轿，它提供了兩種方式來處理數(shù)據(jù)：一是交互式處理问裕，比如用戶使用spark-shell或是pyspark腳本啟動(dòng)Spark應(yīng)用程序残腌，伴隨應(yīng)用程序啟動(dòng)的同時(shí)Spark會(huì)在當(dāng)前終端啟動(dòng)REPL(Read–Eval–Print Loop)來接收用戶的代碼輸入叠艳，并將其編譯成Spark作業(yè)提交到集群上去執(zhí)行;二是批處理烁登，批處理的程序邏輯由用戶實(shí)現(xiàn)并編譯打包成jar包怯屉，spark-submit腳本啟動(dòng)Spark應(yīng)用程序來執(zhí)行用戶所編寫的邏輯，與交互式處理不同的是批處理程序在執(zhí)行過程中用戶沒有與Spark進(jìn)行任何的交互饵沧。

兩種處理交互方式雖然看起來完全不一樣锨络，但是都需要用戶登錄到Gateway節(jié)點(diǎn)上通過腳本啟動(dòng)Spark進(jìn)程。這樣的方式會(huì)有什么問題嗎?

首先將資源的使用和故障發(fā)生的可能性集中到了這些Gateway節(jié)點(diǎn)狼牺。由于所有的Spark進(jìn)程都是在Gateway節(jié)點(diǎn)上啟動(dòng)的羡儿，這勢(shì)必會(huì)增加Gateway節(jié)點(diǎn)的資源使用負(fù)擔(dān)和故障發(fā)生的可能性，同時(shí)Gateway節(jié)點(diǎn)的故障會(huì)帶來單點(diǎn)問題是钥，造成Spark程序的失敗掠归。

其次難以管理缅叠、審計(jì)以及與已有的權(quán)限管理工具的集成。由于Spark采用腳本的方式啟動(dòng)應(yīng)用程序虏冻，因此相比于Web方式少了許多管理肤粱、審計(jì)的便利性，同時(shí)也難以與已有的工具結(jié)合厨相，如Apache Knox领曼。

同時(shí)也將Gateway節(jié)點(diǎn)上的部署細(xì)節(jié)以及配置不可避免地暴露給了登陸用戶。

為了避免上述這些問題蛮穿，同時(shí)提供原生Spark已有的處理交互方式悯森，并且為Spark帶來其所缺乏的企業(yè)級(jí)管理、部署和審計(jì)功能绪撵，本文將介紹一個(gè)新的基于Spark的REST服務(wù)：Livy瓢姻。

Livy

Livy是一個(gè)基于Spark的開源REST服務(wù)，它能夠通過REST的方式將代碼片段或是序列化的二進(jìn)制代碼提交到Spark集群中去執(zhí)行音诈。它提供了以下這些基本功能：

提交Scala幻碱、Python或是R代碼片段到遠(yuǎn)端的Spark集群上執(zhí)行;

提交Java、Scala细溅、Python所編寫的Spark作業(yè)到遠(yuǎn)端的Spark集群上執(zhí)行;

提交批處理應(yīng)用在集群中運(yùn)行褥傍。

從Livy所提供的基本功能可以看到Livy涵蓋了原生Spark所提供的兩種處理交互方式。與原生Spark不同的是喇聊，所有操作都是通過REST的方式提交到Livy服務(wù)端上恍风，再由Livy服務(wù)端發(fā)送到不同的Spark集群上去執(zhí)行。說到這里我們首先來了解一下Livy的架構(gòu)誓篱。

Livy的基本架構(gòu)

Livy是一個(gè)典型的REST服務(wù)架構(gòu)朋贬，它一方面接受并解析用戶的REST請(qǐng)求，轉(zhuǎn)換成相應(yīng)的操作;另一方面它管理著用戶所啟動(dòng)的所有Spark集群窜骄。具體架構(gòu)可見圖1锦募。

圖1 Livy的基本架構(gòu)

用戶可以以REST請(qǐng)求的方式通過Livy啟動(dòng)一個(gè)新的Spark集群，Livy將每一個(gè)啟動(dòng)的Spark集群稱之為一個(gè)會(huì)話(session)邻遏，一個(gè)會(huì)話是由一個(gè)完整的Spark集群所構(gòu)成的糠亩，并且通過RPC協(xié)議在Spark集群和Livy服務(wù)端之間進(jìn)行通信。根據(jù)處理交互方式的不同准验，Livy將會(huì)話分成了兩種類型：

交互式會(huì)話(interactive session)赎线，這與Spark中的交互式處理相同，交互式會(huì)話在其啟動(dòng)后可以接收用戶所提交的代碼片段糊饱，在遠(yuǎn)端的Spark集群上編譯并執(zhí)行;

批處理會(huì)話(batch session)垂寥，用戶可以通過Livy以批處理的方式啟動(dòng)Spark應(yīng)用，這樣的一個(gè)方式在Livy中稱之為批處理會(huì)話，這與Spark中的批處理是相同的矫废。

可以看到盏缤，Livy所提供的核心功能與原生Spark是相同的，它提供了兩種不同的會(huì)話類型來代替Spark中兩類不同的處理交互方式蓖扑。接下來我們具體了解一下這兩種類型的會(huì)話唉铜。

交互式會(huì)話(Interactive Session)

使用交互式會(huì)話與使用Spark所自帶的spark-shell、pyspark或sparkR相類似律杠，它們都是由用戶提交代碼片段給REPL潭流，由REPL來編譯成Spark作業(yè)并執(zhí)行。它們的主要不同點(diǎn)是spark-shell會(huì)在當(dāng)前節(jié)點(diǎn)上啟動(dòng)REPL來接收用戶的輸入柜去，而Livy交互式會(huì)話則是在遠(yuǎn)端的Spark集群中啟動(dòng)REPL灰嫉，所有的代碼、數(shù)據(jù)都需要通過網(wǎng)絡(luò)來傳輸嗓奢。

我們接下來看看如何使用交互式會(huì)話讼撒。

創(chuàng)建交互式會(huì)話

POST /sessions

?使用交互式會(huì)話的前提是需要先創(chuàng)建會(huì)話。當(dāng)我們提交請(qǐng)求創(chuàng)建交互式會(huì)話時(shí)股耽，我們需要指定會(huì)話的類型(“kind”)根盒，比如“spark”，Livy會(huì)根據(jù)我們所指定的類型來啟動(dòng)相應(yīng)的REPL物蝙，當(dāng)前Livy可支持spark炎滞、pyspark或是sparkr三種不同的交互式會(huì)話類型以滿足不同語言的需求。

當(dāng)創(chuàng)建完會(huì)話后诬乞，Livy會(huì)返回給我們一個(gè)JSON格式的數(shù)據(jù)結(jié)構(gòu)表示當(dāng)前會(huì)話的所有信息：

其中需要我們關(guān)注的是會(huì)話id册赛，id代表了此會(huì)話，所有基于該會(huì)話的操作都需要指明其id震嫉。

提交代碼

POST /sessions/{sessionId}/statements

創(chuàng)建完交互式會(huì)話后我們就可以提交代碼到該會(huì)話上去執(zhí)行森瘪。與創(chuàng)建會(huì)話相同的是，提交代碼同樣會(huì)返回給我們一個(gè)id用來標(biāo)識(shí)該次請(qǐng)求责掏，我們可以用id來查詢?cè)摱未a執(zhí)行的結(jié)果柜砾。

查詢執(zhí)行結(jié)果

GET /sessions/{sessionId}/statements/{statementId}

Livy的REST API設(shè)計(jì)為非阻塞的方式，當(dāng)提交代碼請(qǐng)求后Livy會(huì)立即返回該請(qǐng)求id而并非阻塞在該次請(qǐng)求上直到執(zhí)行完成换衬，因此用戶可以使用該id來反復(fù)輪詢結(jié)果，當(dāng)然只有當(dāng)該段代碼執(zhí)行完畢后用戶的查詢請(qǐng)求才能得到正確結(jié)果证芭。

當(dāng)然Livy交互式會(huì)話還提供許多不同的REST API來操作會(huì)話和代碼瞳浦，在這就不一一贅述了。

使用編程API

在交互式會(huì)話模式中废士，Livy不僅可以接收用戶提交的代碼叫潦，而且還可以接收序列化的Spark作業(yè)。為此Livy提供了一套編程式的API供用戶使用官硝，用戶可以像使用原生Spark API那樣使用Livy提供的API編寫Spark作業(yè)矗蕊，Livy會(huì)將用戶編寫的Spark作業(yè)序列化并發(fā)送到遠(yuǎn)端Spark集群中執(zhí)行短蜕。表1就是使用Spark API所編寫PI程序與使用Livy API所編寫的程序的比較。

表1 使用Spark API所編寫PI程序與使用Livy API所編寫程序的比較

可以看到除了入口函數(shù)不同傻咖，其核心邏輯完全一致朋魔，因此用戶可以很方便地將已有的Spark作業(yè)遷移到Livy上。

Livy交互式會(huì)話是Spark交互式處理基于HTTP的實(shí)現(xiàn)卿操。有了Livy的交互式會(huì)話警检，用戶無需登錄到Gateway節(jié)點(diǎn)上去啟動(dòng)Spark進(jìn)程并執(zhí)行代碼。以REST的方式進(jìn)行交互式處理提供給用戶豐富的選擇害淤，也方便了用戶的使用扇雕，更為重要的是它方便了運(yùn)維的管理。

批處理會(huì)話(Batch Session)

在Spark應(yīng)用中有一大類應(yīng)用是批處理應(yīng)用窥摄，這些應(yīng)用在運(yùn)行期間無須與用戶進(jìn)行交互镶奉，最典型的就是Spark Streaming流式應(yīng)用。用戶會(huì)將業(yè)務(wù)邏輯編譯打包成jar包崭放，并通過spark-submit啟動(dòng)Spark集群來執(zhí)行業(yè)務(wù)邏輯：

Livy也為用戶帶來相同的功能腮鞍，用戶可以通過REST的方式來創(chuàng)建批處理應(yīng)用：

通過用戶所指定的“className”和“file”，Livy會(huì)啟動(dòng)Spark集群來運(yùn)行該應(yīng)用莹菱，這樣的一種方式就稱為批處理會(huì)話移国。

至此我們簡(jiǎn)單介紹了Livy的兩種會(huì)話類型，與它相對(duì)應(yīng)的就是Spark的兩種處理交互方式道伟，因此可以說Livy以REST的方式提供了Spark所擁有的兩種交互處理方式迹缀。

企業(yè)級(jí)特性

前面我們介紹了Livy的核心功能，相比于核心功能的完整性蜜徽，Livy的企業(yè)級(jí)特性則更體現(xiàn)了其相比于原生Spark處理交互方式的優(yōu)勢(shì)祝懂。本章節(jié)將介紹Livy幾個(gè)關(guān)鍵的企業(yè)特性。

多用戶支持

假定用戶tom向Livy服務(wù)端發(fā)起REST請(qǐng)求啟動(dòng)一個(gè)新的會(huì)話拘鞋，而Livy服務(wù)端則是由用戶livy啟動(dòng)的砚蓬，這個(gè)時(shí)候所創(chuàng)建出來Spark集群用戶是誰呢，會(huì)是用戶tom還是livy?在默認(rèn)情況下這個(gè)Spark集群的用戶是livy盆色。這會(huì)帶來訪問權(quán)限的問題：用戶tom無法訪問其擁有權(quán)限的資源灰蛙，而相對(duì)的是他卻可以訪問用戶livy所擁有的資源。

為了解決這個(gè)問題Livy引入了Hadoop中的代理用戶(proxy user)模式隔躲，代理用戶模式廣泛使用于多用戶的環(huán)境摩梧，如HiveServer2。在此模式中超級(jí)用戶可以代理成普通用戶去訪問資源宣旱，并擁有普通用戶相應(yīng)的權(quán)限仅父。開啟了代理用戶模式后，以用戶tom所創(chuàng)建的會(huì)話所啟動(dòng)的Spark集群用戶就會(huì)是tom。

圖2 Livy多用戶支持

為了使用此功能用戶需要配置“l(fā)ivy.impersonation.enabled”笙纤，同時(shí)需要在Hadoop中將Livy服務(wù)端進(jìn)程的用戶配置為Hadoop proxyuser 耗溜。當(dāng)然還會(huì)有一些Livy的額外配置就不在這展開了。

有了代理用戶模式的支持省容，Livy就能真正做到對(duì)多用戶的支持抖拴，不同用戶啟動(dòng)的會(huì)話會(huì)以相應(yīng)的用戶去訪問資源。

端到端安全

在企業(yè)應(yīng)用中另一個(gè)非常關(guān)鍵的特性是安全性蓉冈。一個(gè)完整的Livy服務(wù)中有哪些點(diǎn)是要有安全考慮的呢?

客戶端認(rèn)證

當(dāng)用戶tom發(fā)起REST請(qǐng)求訪問Livy服務(wù)端的時(shí)候城舞，我們?nèi)绾沃涝撚脩羰呛戏ㄓ脩裟?Livy采用了基于Kerberos的Spnego認(rèn)證。在Livy服務(wù)端配置Spnego認(rèn)證后寞酿，用戶發(fā)起Http請(qǐng)求之前必須先獲得Kerberos認(rèn)證家夺，只有通過認(rèn)證后才能正確訪問Livy服務(wù)端，不然的話Livy服務(wù)端會(huì)返回401錯(cuò)誤伐弹。

HTTPS/SSL

那么如何保證客戶端與Livy服務(wù)端之間HTTP傳輸?shù)陌踩阅?Livy使用了標(biāo)準(zhǔn)的SSL來加密HTTP協(xié)議拉馋，以確保傳輸?shù)腍ttp報(bào)文的安全。為此用戶需要配置Livy服務(wù)端SSL相關(guān)的配置已開啟此功能惨好。

SASL RPC

除了客戶端和Livy服務(wù)端之間的通信煌茴，Livy服務(wù)端和Spark集群之間也存在著網(wǎng)絡(luò)通信，如何確保這兩者之間的通信安全性也是需要考慮的日川。Livy采用了基于SASL認(rèn)證的RPC通信機(jī)制：當(dāng)Livy服務(wù)端啟動(dòng)Spark集群時(shí)會(huì)產(chǎn)生一個(gè)隨機(jī)字符串用作兩者之間認(rèn)證的秘鑰蔓腐，只有Livy服務(wù)端和該Spark集群之間才有相同的秘鑰，這樣就保證了只有Livy服務(wù)端才能和該Spark集群進(jìn)行通信龄句，防止匿名的連接試圖與Spark集群通信回论。

將上述三種安全機(jī)制歸結(jié)起來就如圖3所示。

圖3 Livy端到端安全機(jī)制

這樣構(gòu)成了Livy完整的端到端的安全機(jī)制分歇，確保沒有經(jīng)過認(rèn)證的用戶傀蓉，匿名的連接無法與Livy服務(wù)中的任何一個(gè)環(huán)節(jié)進(jìn)行通信。

失敗恢復(fù)

由于Livy服務(wù)端是單點(diǎn)职抡，所有的操作都需要通過Livy轉(zhuǎn)發(fā)到Spark集群中葬燎，如何確保Livy服務(wù)端失效的時(shí)候已創(chuàng)建的所有會(huì)話不受影響，同時(shí)Livy服務(wù)端恢復(fù)過來后能夠與已有的會(huì)話重新連接以繼續(xù)使用?

Livy提供了失敗恢復(fù)的機(jī)制缚甩，當(dāng)用戶啟動(dòng)會(huì)話的同時(shí)Livy會(huì)在可靠的存儲(chǔ)上記錄會(huì)話相關(guān)的元信息谱净，一旦Livy從失敗中恢復(fù)過來它會(huì)試圖讀取相關(guān)的元信息并與Spark集群重新連接。為了使用該特性我們需要配置Livy使其開啟此功能：

失敗恢復(fù)能夠有效地避免因Livy服務(wù)端單點(diǎn)故障造成的所有會(huì)話的不可用蹄胰，同時(shí)也避免了因Livy服務(wù)端重啟而造成的會(huì)話不必要失效岳遥。

結(jié)語

本文從Spark處理交互方式的局限引出了Livy這樣一個(gè)基于Spark的REST服務(wù)。同時(shí)全面介紹了其基本架構(gòu)裕寨、核心功能以及企業(yè)級(jí)特性，Livy不僅涵蓋了Spark所提供了所有處理交互方式，同時(shí)又結(jié)合了多種的企業(yè)級(jí)特性宾袜，雖然Livy項(xiàng)目現(xiàn)在還處于早期捻艳，許多的功能有待增加和改進(jìn)，我相信假以時(shí)日Livy必定能成為一個(gè)優(yōu)秀的基于Spark的REST服務(wù)庆猫。

為了幫助大家讓學(xué)習(xí)變得輕松认轨、高效，給大家免費(fèi)分享一大批資料月培，幫助大家在成為大數(shù)據(jù)工程師嘁字，乃至架構(gòu)師的路上披荊斬棘。在這里給大家推薦一個(gè)大數(shù)據(jù)學(xué)習(xí)交流圈：658558542 歡迎大家進(jìn)群交流討論杉畜，學(xué)習(xí)交流纪蜒，共同進(jìn)步。

當(dāng)真正開始學(xué)習(xí)的時(shí)候難免不知道從哪入手此叠，導(dǎo)致效率低下影響繼續(xù)學(xué)習(xí)的信心纯续。

但最重要的是不知道哪些技術(shù)需要重點(diǎn)掌握，學(xué)習(xí)時(shí)頻繁踩坑灭袁，最終浪費(fèi)大量時(shí)間猬错，所以有有效資源還是很有必要的。

最后祝福所有遇到瓶疾且不知道怎么辦的大數(shù)據(jù)程序員們茸歧，祝福大家在往后的工作與面試中一切順利倦炒。