1.數(shù)據(jù)分析平臺(tái)搭建的若干主題
????????筆者從事大數(shù)據(jù)功能平臺(tái)建設(shè)若干年，在筆者就職的公司，業(yè)務(wù)分析人員常使用到如SparkSql， PySpark，hive，python等方式分析數(shù)據(jù)。搭建一個(gè)安全、穩(wěn)定同時(shí)滿足所有業(yè)務(wù)分析人員使用習(xí)慣的大數(shù)據(jù)功能分析功能平臺(tái)并不是一個(gè)簡(jiǎn)單的任務(wù)，因?yàn)橐紤]的東西比較多，筆者認(rèn)為通常有以下幾點(diǎn)。
1.資源的細(xì)粒度以及多維度管控。
2.多租戶隔離。
3.多樣的執(zhí)行方式支持。
4.用戶使用界面友好。
5.功能平臺(tái)的穩(wěn)定與高可用。
2.公司平臺(tái)的現(xiàn)狀以及問題
????????公司現(xiàn)在運(yùn)行的平臺(tái)主要是基于Zeppelin進(jìn)行開發(fā)。我們同時(shí)在一套新的環(huán)境部署了Cloudera的一款開源產(chǎn)品——Livy。Livy在一定程度上結(jié)合了Spark JobServer和Zeppelin的優(yōu)點(diǎn)，同時(shí)也解決了兩者的一些痛點(diǎn)。相較于兩位前輩，Livy的一大優(yōu)勢(shì)是能夠支持Spark的Yarn-Cluster模式，因此有著比前兩者有更強(qiáng)的擴(kuò)展性。我們?cè)诩夹g(shù)選型的時(shí)候，也是看到了這個(gè)新興開源項(xiàng)目的一些優(yōu)勢(shì)，準(zhǔn)備在我們的平臺(tái)進(jìn)行部署以提升集群的能力。
Livy開放的用戶提交作業(yè)的接口還是比較豐富的，用戶可以通過三種方式進(jìn)行提交:
1).使用LivyClient進(jìn)行提交，這個(gè)方式需要實(shí)現(xiàn)編程接口，對(duì)于后臺(tái)開發(fā)者友好，但是對(duì)于公司的數(shù)據(jù)分析人員就顯得門檻較高了。
2).使用REST API的session接口提交代碼片段，這個(gè)接口是數(shù)據(jù)分析人員最常使用的接口，他們將自己的腳本代碼通過REST方式提交到Spark集群，然后從集群中獲取作業(yè)執(zhí)行的結(jié)果。
3).使用REST API的batch接口提交jar包執(zhí)行，這個(gè)方式一般用來進(jìn)行跑批任務(wù)。
????????我們?cè)谠囉肔ivy的時(shí)候，發(fā)現(xiàn)他的優(yōu)點(diǎn)在我們生產(chǎn)表現(xiàn)并不明顯，反而缺點(diǎn)讓我們有點(diǎn)頭疼。例如它不支持sparksql的提交，同時(shí)他對(duì)其他類型的大數(shù)據(jù)作業(yè)如hive、單機(jī)python等不支持?jǐn)U展。另外，livy沒有提供對(duì)用戶友好的界面，平臺(tái)還需要針對(duì)接口進(jìn)行前端的開發(fā)，這項(xiàng)工作從開發(fā)到調(diào)試到維護(hù)也是一項(xiàng)頗費(fèi)人力的事情。另外LivyServer在當(dāng)前還有單點(diǎn)的風(fēng)險(xiǎn)，這些使用上的缺點(diǎn)讓我們組的人員對(duì)Livy這個(gè)新產(chǎn)品逐漸失去了興趣。慢慢對(duì)Livy的支持也變少了。
3.意外的邂逅-Linkis
????????淘沙邂逅得黃金，莫便沙中著意尋。如詩所言，我在github上面搜索關(guān)于大數(shù)據(jù)IDE前端的相關(guān)開源項(xiàng)目時(shí)，看到微眾銀行最新開源的Scriptis項(xiàng)目(https://github.com/WeBankFinTech/Scriptis) 的演示(https://www.oschina.net/p/scriptis)。覺得他們做的這款前端IDE產(chǎn)品幾乎完美符合我們的業(yè)務(wù)分析人員的需求，操作友好，頁面簡(jiǎn)潔，還有日志、進(jìn)度這些用戶關(guān)心內(nèi)容的返回，瞬間被圈粉。深入了解之后，發(fā)現(xiàn)他與微眾銀行另一個(gè)開源的產(chǎn)品——Linkis(https://github.com/WeBankFinTech/Linkis )是配合使用的，當(dāng)時(shí)就一個(gè)感覺，這么爽，直接可以打包使用啊。
????????Linkis官方文檔介紹自己說是用了微服務(wù)的架構(gòu)方式，向用戶暴露了REST和websocket兩種接口。內(nèi)部將執(zhí)行的微服務(wù)抽象成了 Entrance、EngineManager和Engine 三個(gè)微服務(wù)，我理解Entrance應(yīng)該是用戶作業(yè)的管理者，Engine是用戶作業(yè)真正的執(zhí)行者，EngineManager是Engine的啟動(dòng)者和管理者。Linkis還直接開源了Spark(sql、pyspark、scala)、hive、python、pipeline等四個(gè)Engine，支持的執(zhí)行作業(yè)內(nèi)容涵蓋了我們公司平臺(tái)的使用范圍。
????????除了上面三個(gè)抽象，我覺得最吸引我的還是要屬他們更細(xì)粒度和多維度的資源管理器，從事大數(shù)據(jù)平臺(tái)建設(shè)這些年里，我覺得很頭疼的一件事就是集群資源的管控，有時(shí)候也會(huì)出現(xiàn)隊(duì)列資源被某些用戶占光的問題。Linkis自身實(shí)現(xiàn)了一套資源管控的方案，他能將用戶啟動(dòng)的Engine進(jìn)行控制，這個(gè)功能非常矚目。
????????另外，我要考察了他們多租戶隔離的方案，他們的方案是用戶啟動(dòng)Engine的時(shí)候，是要以服務(wù)器上的實(shí)名用戶進(jìn)行啟動(dòng)，這樣啟動(dòng)的進(jìn)程就是在該用戶的權(quán)限下，該進(jìn)程能夠接觸的數(shù)據(jù)也只能局限在該用戶能操作的數(shù)據(jù)。
4.Linkis的測(cè)試試用
????????既然Linkis自己吹的這么好，還是有必要試一下的 ，趁著一個(gè)周末，我將他們最新的后臺(tái)release包下載了下來，好家伙，將近500M，果然是一個(gè)很大的工程。
????????他們的安裝還是比較簡(jiǎn)單的，需要配置好微服務(wù)的IP和端口，同時(shí)設(shè)定好一些必要的path，另外還有數(shù)據(jù)庫的一些配置，執(zhí)行他們的install.sh,執(zhí)行完之后，start-all一下，然后去自己的Eureka地址那里看一下是否啟動(dòng)成功。當(dāng)然啟動(dòng)并不是那么順利，如果失敗了，還是需要自己去查看一下日志，畢竟這個(gè)是第一個(gè)release版本，肯定有兼容問題。根據(jù)筆者的經(jīng)驗(yàn)，需要啟動(dòng)的微服務(wù)有Gateway，datasource, publicService，PythonEntrance，PythonEngineManager(如果要執(zhí)行python),要執(zhí)行spark的話，需要spark的entrance和EM。
然后需要裝上Scriptis，Scriptis的安裝比較簡(jiǎn)單，只需要將gateway的ip和端口指定到nginx的配置文件中就可以了，然后直接啟動(dòng)成功。
用瀏覽器打開Scriptis的部署的ip和port之后，首先會(huì)需要登錄，Linkis文檔告訴我們他們使用的是LDAP的登陸方式，同時(shí)也開放了一個(gè)超級(jí)用戶登錄，就是這個(gè)linkis項(xiàng)目的部署用戶，我用的是hadoop用戶部署的，同時(shí)密碼也是hadoop，然后直接登陸。登陸之后報(bào)了一個(gè)錯(cuò)，說是根目錄不存在，查看日志后發(fā)現(xiàn)是需要為用戶創(chuàng)建一個(gè)根目錄，這個(gè)問題我覺得是微眾銀行應(yīng)該是在用戶管理的時(shí)候，首先會(huì)為用戶新建根目錄，然后用戶才能有資格訪問這個(gè)系統(tǒng)。不過沒有問題，我們直接在服務(wù)器本地創(chuàng)建了一個(gè)目錄就行。建好之后，刷新頁面，如下面所示。
然后我迫不及待地新建了一個(gè)python腳本進(jìn)行執(zhí)行，因?yàn)楫吘惯@個(gè)最簡(jiǎn)單，不需要多余的環(huán)境變量配置。寫完一個(gè)簡(jiǎn)單的腳本測(cè)試，經(jīng)過一系列的過程之后，成功跑出了結(jié)果(*￣︶￣)。日志、進(jìn)度、狀態(tài)等信息也是返回的很精確。
當(dāng)然，單機(jī)的python能運(yùn)行并不能說明問題，畢竟集群運(yùn)行的spark和hive才是關(guān)鍵，新建了一個(gè)spark sql的腳本，然后點(diǎn)擊運(yùn)行，不出意外的，果然報(bào)錯(cuò)了(怎么可能會(huì)這么順利的嘛)，查看日志，我發(fā)現(xiàn)是spark在啟動(dòng)Engine去請(qǐng)求隊(duì)列的資源的時(shí)候，報(bào)了一個(gè)隊(duì)列不存在的問題，但是這個(gè)隊(duì)列明明是存在的。
自己排查很久之后，沒有能夠解決。后來，我加入了他們的微信群，把這個(gè)問題提了出來，群里的工作人員讓我排查了我的fair-scheduler.xml是不是正確的，最后才發(fā)現(xiàn)我們的hadoop版本是不一樣的，我的hadoop版本是2.8+的，返回的json是他們的RM不能解析的，他們公司內(nèi)部使用的是2.7.2，這個(gè)小小的兼容性問題讓我和微眾銀行的同行也搞了好久。
后來解決之后，點(diǎn)擊運(yùn)行開始執(zhí)行任務(wù)，他們引擎啟動(dòng)方式也是默認(rèn)yarn-client方式，這次算是成功執(zhí)行了(幸好我的spark版本是2.1.0)，可以直接運(yùn)行，結(jié)果也是正確的。
5.簡(jiǎn)單的總結(jié)
????????當(dāng)然對(duì)一個(gè)剛剛開源的產(chǎn)品來說，Linkis是不可能直接拿來就用的，因?yàn)椴恢肋@種重型后臺(tái)項(xiàng)目能不能抗住生產(chǎn)性能的問題，還有各種安全的問題，需要在測(cè)試環(huán)境上做很多的驗(yàn)證才行。
????????另外Linkis本身對(duì)非微眾銀行的環(huán)境兼容性問題也是比較大的一個(gè)挑戰(zhàn)，畢竟這個(gè)產(chǎn)品在他們銀行能夠跑得很好，其他的公司就不一定了。
????????當(dāng)然，他的優(yōu)勢(shì)還是很明顯的，前后臺(tái)同時(shí)開源，獨(dú)特的資源管理功能，使用了當(dāng)下最新的微服務(wù)架構(gòu)，這個(gè)架構(gòu)模式對(duì)于技術(shù)人員來說，不論是學(xué)習(xí)還是使用，都有很大的借鑒意義，我覺得這個(gè)系統(tǒng)會(huì)在我們公司的測(cè)試環(huán)境先運(yùn)行一兩個(gè)月，查看一下Linkis的性能和兼容、安全問題，畢竟這是一款值得嘗試和學(xué)習(xí)的好產(chǎn)品。
