作者丨Tina

采訪嘉賓丨滕昱

有人說世界上有三個偉大的發(fā)明：火，輪子，以及 Kafka。

發(fā)展到現(xiàn)在，Apache Kafka 無疑是很成功的，Confluent 公司曾表示世界五百強中有三分之一的企業(yè)在使用 Kafka。實時備份機制讓它在推薦、廣告等互聯(lián)網(wǎng)場景中游刃有余，但是實際生產(chǎn)中還有很多不允許丟數(shù)據(jù)的場景存在。針對這類場景是否有新的技術(shù)和框架出現(xiàn)？

Kafka：大數(shù)據(jù)平臺中的核心軟件。

據(jù)中國信通院企業(yè)采購大數(shù)據(jù)軟件調(diào)研報告來看，86.6% 的企業(yè)選擇基于開源軟件構(gòu)建自己的大數(shù)據(jù)處理業(yè)務(wù)，但大數(shù)據(jù)人都會感嘆大數(shù)據(jù)領(lǐng)域開源項目的“玲瑯滿目”。很多軟件只經(jīng)過一兩年就形成一次更替，經(jīng)過多年的廝殺和競爭，很多優(yōu)秀的產(chǎn)品已經(jīng)脫穎而出，也有很多產(chǎn)品慢慢走向消亡。比如 Spark 基本上已經(jīng)成為批處理領(lǐng)域的佼佼者， Flink 成為了低延遲流處理領(lǐng)域的不二選擇，而 Storm 開始慢慢退出歷史舞臺。Kafka 在消息中間件領(lǐng)域基本上占據(jù)了壟斷地位，最終沉淀出了以這幾個軟件為核心的大數(shù)據(jù)處理平臺。

那么現(xiàn)在的大數(shù)據(jù)架構(gòu)下的底層生態(tài)已經(jīng)足夠成熟來幫助企業(yè)用戶進行數(shù)字轉(zhuǎn)型嗎？哪些地方還存在優(yōu)化的空間？

同為開源數(shù)據(jù)管道，卻有不同命運。

回到 7 年前，Kafka 也肯定想不到自己會在大數(shù)據(jù)系統(tǒng)中起到這么重要的作用。2010 年， LinkedIn 開始研發(fā) Kafka，最初的設(shè)計理念非常簡單，就是一個以 append-only 日志作為核心的數(shù)據(jù)存儲結(jié)構(gòu)。2011 年的時候，Kafka 提出了一個叫做 ISR 實時備份列表的機制，來保證高可用性。

運行過 Kafka 大規(guī)模集群的人都知道，Kafka 里面有很多數(shù)據(jù)持久化的問題。在一些早期版本中或者沒有選擇正確配置時，如果一個服務(wù)器失敗（這在分布式系統(tǒng)里很常見），就會導(dǎo)致這個服務(wù)器端所存的數(shù)據(jù)在恢復(fù)之前無法再被取得，更有甚者，這些數(shù)據(jù)有可能就永遠丟失了。僅僅作為一個日志系統(tǒng)，這也許是可以勉強接受的。但是當越來越多企業(yè)開始使用 Kafka 來傳輸和保存重要商業(yè)數(shù)據(jù)，沒有高可用性是不行的。所以在引入了多備份機制之后，Kafka 脫穎而出，成為了當時整合流數(shù)據(jù)傳輸?shù)募惺酵ǖ赖氖走x，并慢慢進化出了強大的社區(qū)生態(tài)。

但企業(yè)采用 Kafka 之后，依然需要踩很多坑。為了應(yīng)對多租戶、支撐上百萬 Topics 等要求，雅虎研發(fā)了新一代消息平臺 Pulsar，并且在設(shè)計上采用了數(shù)據(jù)服務(wù)和數(shù)據(jù)存儲分層的架構(gòu)。2016 年雅虎將這套軟件進行了開源，當時有人感慨：“如果 Pulsar 早推出兩年，也許就沒 Kafka 什么事兒了。“

對比 Pulsar，Kafka 的先發(fā)優(yōu)勢非常明顯，在強大的社區(qū)支撐下，Kafka 背后的公司 Confluent 不斷獲得融資，估值高達 25 億美元。但是 Pulsar 背后的公司 Streamlio，發(fā)展卻不那么順利，沒幾年就被 Splunk 以人才收購的方式合并到一起了。關(guān)于開源軟件的商業(yè)模式很難用一兩句話討論清楚，但 Pulsar 一開始的目的是想做“更好的 Kafka”，它在技術(shù)上可以認為是成功的，并且是值得被借鑒和被采用的。

也就是在 Pulsar 開發(fā)的同時，戴爾科技集團的研發(fā)團隊發(fā)現(xiàn)做一個更好的消息隊列 /Kafka 并不能解決新一代大數(shù)據(jù)平臺在數(shù)據(jù)存儲層上的挑戰(zhàn)，因此他們重新思考了數(shù)據(jù)處理和存儲的規(guī)則，設(shè)計并開源了全新流存儲”Pravega”項目（https://github.com/pravega）。通過一個全新的“stream”存儲抽象層，Pravega 讓上層計算引擎能更好和無縫去跟底層存儲解耦：“所有計算機領(lǐng)域的問題，都可以通過增加一個額外的中間層抽象解決”。

一套新的開源大數(shù)據(jù)平臺

“Steam is the new file system for continous data."

有了 Pravega 提供的存儲層以后，大數(shù)據(jù)架構(gòu)將會變成如上圖右側(cè)所示，并帶來以下改變：

在整個流水線中，無論有多少計算處理單元，原始的數(shù)據(jù)只會被保存一份。

不再需要根據(jù)數(shù)據(jù)的“時間”屬性去選擇不同的處理流水線 (streaming or batch)，可以同時對實時和歷史數(shù)據(jù)的聚合做低延時的實時處理。

計算處理邏輯統(tǒng)一，降低應(yīng)用開發(fā)難度。

為了詳細解釋這三點，我們可以先用下表來簡單對比一下 Pravega 和 Kafka 設(shè)計哲學的不同之處，這也代表了流存儲和消息隊列的本質(zhì)差異：

接下來我們可以就第一點再展開，以理解新系統(tǒng)的優(yōu)勢：

“數(shù)據(jù)無價，而計算可以重試”， 在左邊使用 Kafka+Spark/ES 的大數(shù)據(jù)技術(shù)棧中，很多企業(yè)為了保證數(shù)據(jù)不丟失，必然對重要（甚至所有的）的數(shù)據(jù)進行 3 拷貝落盤的設(shè)定。一份 topic，在 Lamda 架構(gòu)下，從 Kafka 到離線、實時計算上要形成至少 6 個拷貝。再加上多數(shù)據(jù)中心，比如說 2-3 個站點，那么一個 topic 就至少形成 12-18 個拷貝。而現(xiàn)在每天產(chǎn)生 PB 級別數(shù)據(jù)的企業(yè)不在少數(shù)，那就意味著這些副本也需要 PB 級別的資源去存儲，成本相當昂貴。

而在 Pravega+Flink 這套技術(shù)棧下，Pravega 是一個抽象的存儲接口，在這個流水線上所有的原始數(shù)據(jù)只被存儲一份，然后將數(shù)據(jù)寫到持久存儲層如對象存儲或 HDFS。并且如果選用支持高效 EC 糾錯碼的商業(yè)分布式存儲作為 Pravega 的 long term storage，在保證數(shù)據(jù)的高可用高可靠性的情況下，對比 Kafka，就節(jié)省掉了相當多的數(shù)據(jù)存儲開銷。當企業(yè)的數(shù)據(jù)量達到 10+PB 級別后，Pravega/Flink + 商業(yè)存儲模式遠比完全使用開源軟件自建要省錢的多。

在接受 InfoQ 的采訪時，戴爾科技中國研發(fā)集團滕昱解釋完這套產(chǎn)品后表示：“我認為，下一個十年企業(yè)用戶真正需要的大數(shù)據(jù)平臺就應(yīng)該是這個樣子的。“

大數(shù)據(jù)平臺的幾個發(fā)展方向

開發(fā)人員也需要有一個“整體”的商業(yè)思維。

豐富的開源項目能讓一個大數(shù)據(jù)系統(tǒng)的初始搭建變得簡單，Kafka+Spark/Flink 的 Lambda 架構(gòu)已經(jīng)很普遍，一定程度上降低了技術(shù)的入門門檻。但一個企業(yè)里的端到端方案，并不是簡單的堆積一些大數(shù)據(jù)產(chǎn)品組件，用戶需要的也不是 Hadoop、Spark、Flink、Kafka 等這些技術(shù)，而是要以這些技術(shù)為基礎(chǔ)的能解決業(yè)務(wù)問題的一套完整的產(chǎn)品方案。

現(xiàn)在很多國內(nèi)的企業(yè)，將建設(shè)一套解決方案的事情上升到了組織架構(gòu)層面，形成各種部門，有叫大數(shù)據(jù)的，有叫基礎(chǔ)架構(gòu)的，有的專門管存儲，有的專門管計算...... 每個部門各司其職，各自負責尋找各自的“局部最優(yōu)解”，比如用 Kafka 的大數(shù)據(jù)部門就覺得把 Kafka 做好就行了。但是比單個技術(shù)應(yīng)用更重要的，是企業(yè)還需要整體去考慮規(guī)模化應(yīng)用、運維管控和成本優(yōu)化方面的事情。只有把整套架構(gòu)放到一起，做好優(yōu)化，同時考慮整體成本，才更具有優(yōu)勢。比如管存儲的部門的 KPI 可能是基于有多少數(shù)據(jù)量來考慮的，那么做一個統(tǒng)一存儲層的動力自然不足，但是這從整個公司角度來看其實是有問題的。

“做分布式存儲遠比做分布式計算更難。”

在一套大數(shù)據(jù)技術(shù)棧下，從數(shù)據(jù)采集到計算，到存儲，再到底層的基礎(chǔ)設(shè)施，最難的往往是存儲相關(guān)的這一塊。

所謂的數(shù)字化資產(chǎn)，就是企業(yè)保存下來的原始數(shù)據(jù)。對于有價值的資產(chǎn)，在數(shù)據(jù)安全性上是不允許有閃失的。大家可以很清楚的發(fā)現(xiàn)，相對于計算框架的百花齊放，開源分布式存儲項目上其實一直處于“不堪大用”的地步。因為任何軟件都有 bug，當存儲產(chǎn)品出現(xiàn) bug 的時候，開源模式就決定了無法找到一個 24*7 的響應(yīng)模式來幫助客戶 fix DU/DL 的支持團隊，這其實是沒有任何企業(yè)用戶可以接受的。所以你會發(fā)現(xiàn)，到最后就變成了自建團隊維護自己專屬分支的結(jié)局，想想 Ceph 的歷史上有多少 bug 已經(jīng)無人問津的現(xiàn)實吧，Ceph 官方的做法是設(shè)計一個新的存儲引擎去挖新坑。

未來企業(yè)數(shù)據(jù)量只會越來越大，當超過 EB 級別以后，現(xiàn)有開源的存儲產(chǎn)品都會有一些基本設(shè)計上的問題，即使它們的架構(gòu)圖是那么“完美”。而商業(yè)存儲產(chǎn)品在 2013-2014 年就已經(jīng)達到 2-3EB 單個系統(tǒng)的體量，這種積累其實是開源存儲產(chǎn)品很難在短時間跟上的。所以當數(shù)據(jù)量達到一定程度后，所有企業(yè)都需要去平衡技術(shù)和商業(yè)。

這也是 Pravega 被推出的一個重要原因，用開源技術(shù)連接底層存儲和開源計算，解決“成本”問題。在項目啟動早期，仍然可以使用 HDFS/Ceph/ 公有云去“試水”， 正式進入商業(yè)以后，可以使用商業(yè)分布式存儲和公有云存儲混布的架構(gòu)，在滿足上層計算完全通過 Pravega 的抽象訪問數(shù)據(jù)無需更改的前提下，用戶可以根據(jù)自己數(shù)字資產(chǎn)特性去自由地在公有云和商業(yè)云原生存儲平臺之間動態(tài)遷移，畢竟公有云存儲對于絕大部分企業(yè)用戶來說實在太昂貴了。

“技術(shù)當然很重要，但更重要的是順應(yīng)技術(shù)趨勢去思考未來發(fā)展。”

從 2012 年開始，Mesos 的流行、Docker 的興起，然后 Kubernetes 出現(xiàn)并一舉打敗 Yarn 和 Mesos，到現(xiàn)在整個基礎(chǔ)架構(gòu)正在全面往云原生方向發(fā)展。

另一方面，雖然公有云廠商總是宣傳讓大家“全面上云”，但是除了對公有云存儲成本的擔憂之外，企業(yè)用戶更加擔心的是數(shù)據(jù)鎖定（Lockdown）隱患。尤其是沒有人能保證公有云廠商不會進入自己的商業(yè)領(lǐng)域，企業(yè)必須選擇將自己最看重的數(shù)據(jù)資產(chǎn)放到自己能掌控的硬件環(huán)境下或者是更靠近數(shù)據(jù)產(chǎn)生的邊緣端。所以未來的大趨勢必然以混合云多云的方式為主。這也是為什么云原生存儲對企業(yè)用戶有吸引力，因為它和上面的趨勢是契合的。

云原生最重要的一個隱含意義就是做到端到端的存儲計算動態(tài)可伸縮性。當負載增大時，負責這條流水線的底層架構(gòu)可以自動感知變化并進行合理調(diào)度，并且是在沒有 DevOps 人為干預(yù)的前提下。而當負載變小后，又可以動態(tài)釋放多余資源給系統(tǒng)中其他流水線使用，如下圖所示。這樣可以在最大程度上榨干硬件資源每一份能力。

面向傳統(tǒng)企業(yè)，開源需做出改變

“一切人類活動都是經(jīng)濟活動，軟件開發(fā)也不例外”。

AWS 曾表示：公有云至今只轉(zhuǎn)移了世界上 3% 的 Workload，另外 97% 仍然還是傳統(tǒng)的企業(yè)開發(fā)。

這 97% 的存量 ToB 市場跟互聯(lián)網(wǎng)企業(yè)有著很不一樣的商業(yè)模式，主要表現(xiàn)在以下幾點：

第一，這不是一個“從 0 到 1”的市場。這些傳統(tǒng)企業(yè)往往在本領(lǐng)域已經(jīng)是頭部，它們的營收一般在百億美元以上，每年的增長可能只有 10%-20%。在它們選擇新技術(shù)時候，一個 3-4 年的 TCO（Total Cost of Ownership 總擁有成本）往往是其 COO 首先考慮的指標。那么他 / 她必然要在公有云的“彈性”和“昂貴”中作出取舍，更不說上面提到的 Lockdown 的商業(yè)風險。

一般互聯(lián)網(wǎng)企業(yè)喜歡的是全新的顛覆性的市場，用全新打法來追求爆炸性的增長率。對比互聯(lián)網(wǎng)企業(yè)，傳統(tǒng)企業(yè)自然在技術(shù)上取舍上會不一致。“先有再演化”的開源軟件自然是不二選擇。只是隨著整體的經(jīng)濟形式變化，每個今天的新興企業(yè)都有可能成為明天的成熟行業(yè)。他們同樣會面臨技術(shù)使用上對成本的整體考慮，比如最近兩年就出現(xiàn)了從 AWS 等公有云存儲回歸私有商業(yè)存儲的“歸隊”趨勢。

第二，垂直細分領(lǐng)域在企業(yè)開發(fā)中相當常見。不同領(lǐng)域有不同的需求，比如在遠洋運輸和石油鉆井平臺行業(yè)中，網(wǎng)絡(luò)連接甚至都不是一個“必選項”，那么其實也就不存在一個能滿足所有行業(yè)的開源項目。更多是需要在理解這些領(lǐng)域挑戰(zhàn)得前提下，有商業(yè)化支持的云原生存儲計算的混合云方案。

另外一個例子是在很多金融公司和銀行里面，對安全的標準往往是物理隔離或者是多年行業(yè)形成的一系列規(guī)范。絕大部分的開源軟件其實完全沒有考慮或者也沒法考慮這類要求，必須借助商業(yè)軟件才能完成。比如戴爾科技集團在基于 Pravega+Flink 的 Streaming data platform 上就加入了基于 K8S 的全棧安全特性支持，并且作為默認設(shè)置。

第三，在實踐中，“ToB”和“ToC”另一個巨大的不同點在于技術(shù)方案不再由單個人來評估好壞，更多是一個企業(yè)決策者群體共同的決定結(jié)果。而這個群體里面每個決策者，又會因為各自代表利益的不一樣，需要從很多非技術(shù)的角度去考慮。這甚至造成了企業(yè)開發(fā)中“慢速敏捷”的現(xiàn)狀，穩(wěn)定和兼容性的要求遠大于新功能和快速試錯的要求。

很多企業(yè)甚至表示，“我們不需要一周一個新版本”。因為光是協(xié)調(diào)升級線上系統(tǒng)的批復(fù)流程都需要 1-2 周，一個月一次的 bug fix 升級已經(jīng)足夠敏捷，6-8 個月的大版本升級也“足夠好”，但是向后兼容是必須要保證的，而這在開源軟件中往往很難做到。業(yè)界最好的例子莫過于 Intel 的 CPU 指令集，為了最大程度的保證向后兼容，x86 不得不一直維護著一些很古老的指令來保證所有的用戶都不會因為新 CPU 造成上層程序的兼容出錯。

滕昱說：“這就是企業(yè)開發(fā)的特點，和市場每年以 300% 甚至 500% 的速度快速膨脹的互聯(lián)網(wǎng)企業(yè)本質(zhì)上并不一樣。只不過經(jīng)過 10 年高速發(fā)展之后，大家終于開始把目光投向了這些巨大的存量企業(yè)市場。而這個時候，我們所有的技術(shù)，包括開源項目和云技術(shù)，都要做出一些相應(yīng)的商業(yè)上的調(diào)整，才能抓住這些用戶的心和市場（real money） 。”

嘉賓介紹

滕昱，現(xiàn)就職于 戴爾科技集團并擔任軟件開發(fā)總監(jiān)。負責分布式對象存儲 ECS(Elastic Cloud Storage) 以及基于開源 Pravega 項目的新一代大數(shù)據(jù)分析平臺的研發(fā)工作。滕昱于 2007 年加入 戴爾易安信 以后一直專注于分布式存儲領(lǐng)域，先后參與領(lǐng)導(dǎo)了戴爾易安信中國研發(fā)團隊在前后兩代對象存儲產(chǎn)品中的核心研發(fā)工作并取得商業(yè)成功。他正在積極擁抱新的邊緣 / 混合云 / 多云和實時流處理時代的到來，為企業(yè)用戶提供下一代大數(shù)據(jù)平臺而努力完善整個生態(tài)系統(tǒng)的構(gòu)建。

有道無術(shù)，術(shù)可成；有術(shù)無道，止于術(shù)

歡迎大家關(guān)注Java之道公眾號

好文章，我在看??

總結(jié)

以上是生活随笔為你收集整理的Apache Kafka 迎来了“后浪”的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。