作者：祝威廉

本文由 祝威廉 授權(quán)發(fā)布，版權(quán)所有歸作者，轉(zhuǎn)載請(qǐng)聯(lián)系作者！

之前我在微信朋友圈發(fā)了一段話，說明Spark Streaming 不僅僅是流式計(jì)算，也是一類通用的模式，可以讓你只關(guān)注業(yè)務(wù)邏輯而無需關(guān)注分布式相關(guān)的問題而迅速解決業(yè)務(wù)問題

前言

前兩天我剛在自己的一篇文章中鼓吹數(shù)據(jù)天生就是流式的,并且指出：

批量計(jì)算已經(jīng)在慢慢退化，未來必然是屬于流式計(jì)算的，數(shù)據(jù)的流動(dòng)必定是由數(shù)據(jù)自己驅(qū)動(dòng)流轉(zhuǎn)的。

而Spark Streaming 在上層概念上，完美融合了批量計(jì)算和流式計(jì)算，讓他們你中有我，我中有你，這種設(shè)計(jì)使得Spark Streaming 作為流式計(jì)算的一個(gè)載體，同時(shí)也能作為其他一些需要分布式架構(gòu)的問題提供解決方案。

Spark Streaming 作為一些分布式任務(wù)系統(tǒng)基礎(chǔ)的優(yōu)勢(shì)

1. 天然就是分布式的，不用再為實(shí)現(xiàn)分布式協(xié)調(diào)而蛋疼
2. 基于Task的任務(wù)執(zhí)行機(jī)制，可隨意控制Task數(shù)量
3. 無需關(guān)注機(jī)器，是面向資源的，使得部署變得異常簡(jiǎn)單，申明資源，提交，Over
4. 集成完善的輸入輸出，包括HDFS/Kafka/ElasticSearch/HBase/MySQL/Redis 等等，這些都無需自己去搞
5. 成熟簡(jiǎn)單的算子讓你對(duì)數(shù)據(jù)的處理變得異常簡(jiǎn)單

StreamingPro 項(xiàng)目讓申明式或者復(fù)雜的Spark Streaming程序更加簡(jiǎn)單，同時(shí)還可以通過StreamingPro提供的Rest 接口來增強(qiáng)Spark Streaming Driver的交互能力。

現(xiàn)在以標(biāo)題中的采集系統(tǒng)為例，整個(gè)事情你只要實(shí)現(xiàn)采集邏輯，至于具體元數(shù)據(jù)讀取，結(jié)果存儲(chǔ)到哪都可能只要個(gè)簡(jiǎn)單配置或者利用現(xiàn)成的組件，最后部署也只要簡(jiǎn)單申明下資源就可以在一個(gè)可以彈性擴(kuò)展的集群上。

開發(fā)采集系統(tǒng)的動(dòng)機(jī)

目前這個(gè)采集系統(tǒng)主要是為了監(jiān)控使用。但凡一個(gè)公司，或者部門內(nèi)部會(huì)有大量的開源系統(tǒng)，每個(gè)開源組件都會(huì)提供大致三類輸出：

1. 標(biāo)準(zhǔn)的metrics 輸出，方便你集成到gangila等監(jiān)控系統(tǒng)上
2. Web UI,比如Spark,Storm,HBase 都提供了自己的Web界面等
3. Rest 接口，主要是 JSon,XML,字符串

但是對(duì)于監(jiān)控來說，前面兩個(gè)直觀易用，但是也都有比較大的問題：

1. metrics 直接輸出到監(jiān)控系統(tǒng)，就意味著沒辦法定制，如果我希望把多個(gè)指標(biāo)放在一塊，這個(gè)可能就很難做到。
2. Web UI 則需要人去看了

相反，Rest 接口最為靈活，但是需要自己做寫邏輯，比如獲取數(shù)據(jù)，處理，然后做自己的呈現(xiàn) 。問題來了，如果我現(xiàn)在有幾千個(gè)Rest接口的數(shù)據(jù)要獲取，并且需要一個(gè)很方便的手段抽取里面要的值(或者指標(biāo))。這便涉及到了兩個(gè)問題：

1. 收集的接口可能非常多，如何讓收集程序是可很橫向擴(kuò)展的?
2. 接口返回的數(shù)據(jù)形態(tài)各異，如何提供一個(gè)方便一致的模型，讓用戶簡(jiǎn)單通過一個(gè)配置就可以抽取出里面的內(nèi)容?

系統(tǒng)處理結(jié)構(gòu)

• 采集元數(shù)據(jù)源，目前存儲(chǔ)在ES里
• 采集系統(tǒng)會(huì)定時(shí)到ES里獲取元數(shù)據(jù)，并且執(zhí)行特定的收集邏輯
• 通過采集系統(tǒng)的一定的算子，將數(shù)據(jù)格式化，接入Kafka
• 通過標(biāo)準(zhǔn)(已經(jīng)存在的)ETL系統(tǒng)完成數(shù)據(jù)的處理，供后續(xù)流程進(jìn)一步處理

通用信息抽取方案

回到上面的一個(gè)問題， 接口返回的數(shù)據(jù)形態(tài)各異，如何提供一個(gè)方便一致的模型，讓用戶簡(jiǎn)單通過一個(gè)配置就可以抽取出里面的內(nèi)容。

Rest 接口返回的數(shù)據(jù)，無非四種：

1. HTML
2. JSON
3. XML
4. TEXT

對(duì)于1,我們先不探討。對(duì)于JSON,XML 我們可以采用 XPATH，對(duì)于TEXT我們可以采用標(biāo)準(zhǔn)的正則或者ETL來進(jìn)行抽取。

我們?cè)诙x一個(gè)需要采集的URL時(shí)，需要同時(shí)配置需要采集的指標(biāo)以及對(duì)應(yīng)的指標(biāo)的XPATH路徑或者正則。當(dāng)然也可以交給后端的ETL完成該邏輯。不過我們既然已經(jīng)基于Spark Streaming做采集系統(tǒng)，自然也可以利用其強(qiáng)大的數(shù)據(jù)處理功能完成必要的格式化動(dòng)作。所以我們建議在采集系統(tǒng)直接完成。

采集系統(tǒng)

數(shù)據(jù)源的一個(gè)可能的數(shù)據(jù)結(jié)構(gòu)：

采集系統(tǒng)通過我們封裝的一個(gè) DInputStream,然后根據(jù)batch(調(diào)度周期)，獲取這些數(shù)據(jù)，之后交給特定的執(zhí)行邏輯去執(zhí)行。采用StreamingPro,會(huì)是這樣：

通過上面的配置文件，可以很好看到處理流程。

1. 輸入采集源
2. 采集結(jié)果
3. 根據(jù)XPATH 抽取指標(biāo)
4. 輸出結(jié)果

制作元數(shù)據(jù)管理系統(tǒng)

元數(shù)據(jù)管理系統(tǒng)是必要的，他可以方便你添加新的URL監(jiān)控項(xiàng)。通過StreamingPro,你可以在Spark Streaming 的Driver中添加元數(shù)據(jù)管理頁面，實(shí)現(xiàn)對(duì)元數(shù)據(jù)的操作邏輯。我們未來會(huì)為 如何通過StreamingPro 給Spark Streaming 添加自定義Rest 接口/Web頁面提供更好的教程。

完結(jié)了么?

上面其實(shí)已經(jīng)是試下了一個(gè)采集系統(tǒng)的雛形，得益于Spark Streaming天然的分布式，以及靈活的算子，我們的系統(tǒng)是足夠靈活，并且可橫向擴(kuò)展。

然而你會(huì)發(fā)現(xiàn)，

• 如果我需要每個(gè)接口有不同的采集周期該如何?
• 如果我要實(shí)現(xiàn)更好的容錯(cuò)性如何?
• 如何實(shí)現(xiàn)更好的動(dòng)態(tài)擴(kuò)容?

第一個(gè)問題很好解決，我們?cè)谠獢?shù)據(jù)里定義采集周期，而Spark Streaming的調(diào)度周期則設(shè)置為最小粒度。

第二個(gè)問題容錯(cuò)性屬于業(yè)務(wù)層面的東西，但是如果有Task失敗，Spark Streaming也會(huì)把你嘗試重新調(diào)度和重試。我們建議由自己來完成。

第三個(gè)，只要開啟了 Dynamic Resource Allocation,則能夠根據(jù)情況，實(shí)現(xiàn)資源的伸縮利用。

原文>>>

End.