現(xiàn)在依然很多人使用Azkaban/Oozie等工具銜接各個(gè)系統(tǒng)括荡，通過外力讓數(shù)據(jù)進(jìn)行流轉(zhuǎn)见咒。而隨著流式計(jì)算慢慢成熟與穩(wěn)定洽议，數(shù)據(jù)必然如河水一般宗收，天生就是流式的。
題外話
好久沒寫文章亚兄，發(fā)現(xiàn)寫長(zhǎng)文太辛苦了混稽，所以慢慢往短文開始靠。這次算是第一個(gè)實(shí)踐审胚。
完全由流式計(jì)算構(gòu)建的體系
部門目前核心其實(shí)就是流式計(jì)算匈勋，從根部開始(一個(gè)超大的Kafka集群)開始，延伸出一個(gè)超級(jí)龐大的樹形結(jié)構(gòu)膳叨。整個(gè)過程都是數(shù)據(jù)自我驅(qū)動(dòng)進(jìn)行流轉(zhuǎn)洽洁，沒有使用類似Azkaban/Oozie 等外部工具去讓數(shù)據(jù)從一個(gè)系統(tǒng)流轉(zhuǎn)到另外一個(gè)系統(tǒng)。 而我之前提出 Transformer架構(gòu) 本質(zhì)就是一個(gè)流式數(shù)據(jù)架構(gòu)菲嘴。
這個(gè)架構(gòu)的核心概念是：
你開發(fā)的任何一個(gè)應(yīng)用饿自，本質(zhì)上都是將兩個(gè)或者多個(gè)節(jié)點(diǎn)連接起來(lái)汰翠，從而使得數(shù)據(jù)可以在不同節(jié)點(diǎn)之間流轉(zhuǎn)
數(shù)據(jù)的流轉(zhuǎn)必然由批量到流式
如果說在大數(shù)據(jù)領(lǐng)域，批量處理是第一次數(shù)據(jù)革命昭雌，那么流式處理則必然是第二次數(shù)據(jù)革命复唤。
從某種角度而言，批量是流式處理的一個(gè)特例烛卧，譬如隔天處理數(shù)據(jù)佛纫，本質(zhì)就是時(shí)間窗口為一天的流式計(jì)算。當(dāng)然我們也可以實(shí)現(xiàn)以數(shù)量為窗口的計(jì)算总放。
當(dāng)你需要借助外力的時(shí)候呈宇，事情往往就變得并不美好了。你需要額外的維護(hù)譬如Oozie等系統(tǒng)里的工作流局雄，并且你需要考慮各個(gè)系統(tǒng)能夠完成的時(shí)間甥啄，從而協(xié)調(diào)好組件。
數(shù)據(jù)流轉(zhuǎn)的理想狀態(tài)應(yīng)該就如同河水一樣哎榴，當(dāng)源頭水量變大后型豁，水壓會(huì)自動(dòng)迫使數(shù)據(jù)流轉(zhuǎn)速度加快。當(dāng)我們需要灌溉新的農(nóng)田時(shí)尚蝌，我們只要接上一個(gè)蓄水池(比如Kafka,)在蓄水池延伸出新的河道(由流式引擎比如Spark Streaming完成)，就可以很方便的將水引入充尉。整個(gè)過程是水壓驅(qū)動(dòng)水的流轉(zhuǎn)飘言。
假設(shè)我們有河道A, 蓄水池C,河道B。水流方向是 A -> C ->B驼侠。 A 內(nèi)部是典型的依賴于重力的將水壓力蓄水池C姿鸿。 而B 則因?yàn)榈貏?shì)可能更高些，需要靠消費(fèi)額外的資源(CPU資源)將水抽取到B自己的河道里(pull 模式)倒源。 當(dāng)然苛预，B也可能是地勢(shì)低，這樣C可以利用重力將水引入C （典型的push模式）笋熬。
批量與流式的微妙關(guān)系
批處理和流式本來(lái)就存在某種微妙的關(guān)系热某，我中有你，你中有我胳螟。Spark Streaming則充分利用了這種微妙關(guān)系昔馋，將其發(fā)揮到極致。批量處理是Spark Streaming流式處理的一個(gè)窗口特別大的特例糖耸，但是如果細(xì)加觀察,Spark Streaming 的每個(gè)batch 又都是一個(gè)批處理秘遏，只是因?yàn)檫@個(gè)批處理可以足夠小，看起來(lái)就像數(shù)據(jù)在真實(shí)流動(dòng)一樣嘉竟，所以我們也稱之為流式處理邦危。
這里有個(gè)值得提出的東西是洋侨，當(dāng)處理時(shí)間等于調(diào)度周期，那么spark streaming就是一個(gè)永不干涸的河道倦蚪。而如果處理時(shí)間大于調(diào)度周期希坚，則有兩種情況需要闡述：
- 限制抽水泵的功率(也就是背壓，backpressure)
- 限制抽水泵的工作時(shí)間审丘。因?yàn)檠訒r(shí)吏够，抽水泵需要一個(gè)或者多個(gè)調(diào)度周期才會(huì)開始真的工作。（Direct Approach模式）
如果抽水泵不限制功率也不推延工作時(shí)間(Receiver模式容易出現(xiàn))滩报，那么就讓河道溢出了(OOM)了锅知。
從某種角度而言，Spark Streaming 這種將批處理和流處理巧妙融合的方式可以保證自己可以充分利用流式和批處理的優(yōu)勢(shì)脓钾。
Storm這種流式引擎則能實(shí)現(xiàn)最細(xì)粒度的流轉(zhuǎn)售睹，但是這種細(xì)粒度的流轉(zhuǎn)在很多場(chǎng)景并不足夠高效，因?yàn)樵诹鬓D(zhuǎn)的過程中可训，往往下游無(wú)法接受來(lái)一條就處理一條的情況昌妹，需要通過小窗口的batch來(lái)完成更加高效的入庫(kù)操作。而獲取數(shù)據(jù)握截，Storm從某種角度而言也是批處理飞崖。因?yàn)橄M(fèi)者每次從kafka 抽取數(shù)據(jù)的時(shí)候，也是一次抽取到足夠的量谨胞，然后交給后端一條一條處理固歪。
所以Storm 和Spark Streaming的本質(zhì)區(qū)別在于抽水泵的工作機(jī)制。
幾句話
- 從另外一個(gè)角度而言胯努，流式不過是一個(gè)具有無(wú)限數(shù)據(jù)的批處理過程牢裳。
- 流式處理則是我們通向?qū)崟r(shí)的一條必經(jīng)之路
- 實(shí)時(shí)是我們永不言棄的目標(biāo)
總結(jié)
從宏觀角度而言，批處理pipeline 一般而言借住一個(gè)協(xié)調(diào)組件叶沛，又該協(xié)調(diào)組件產(chǎn)生動(dòng)力蒲讯，調(diào)用各個(gè)系統(tǒng)完成某種功能。通常而言灰署，批處理pipeline的數(shù)據(jù)處理周期都較長(zhǎng)判帮，符合離線的定義，譬如隔天氓侧，并且各個(gè)系統(tǒng)作為管道脊另，只有在需要的時(shí)候才會(huì)被創(chuàng)建。
流式處理pipeline 則不需要借助外部協(xié)調(diào)組件约巷，每個(gè)系統(tǒng)通過主動(dòng)拉取或者推送的方式偎痛，完成數(shù)據(jù)在不同系統(tǒng)中的流轉(zhuǎn)。通常而言独郎，流式pipeline的數(shù)據(jù)處理周期都很短踩麦，符合準(zhǔn)實(shí)時(shí)的定義枚赡，并且各個(gè)系統(tǒng)作為管道，都是一直存在的谓谦。
