有人說世界上有三個偉大的發明：火，輪子，以及Kafka。
發展到現在，Apache Kafka無疑是很成功的，Confluent公司曾表示世界五百強中有三分之一的企業在使用Kafka。實時備份機制讓它在推薦、廣告等互聯網場景中遊刃有餘，但是實際生產中還有很多不允許丟數據的場景存在。針對這類場景是否有新的技術和框架出現？
Kafka：大數據平臺中的核心軟件
據中國信通院企業採購大數據軟件調研報告來看，86.6% 的企業選擇基於開源軟件構建自己的大數據處理業務，但大數據人都會感嘆大數據領域開源項目的“玲琅滿目”。很多軟件只經過一兩年就形成一次更替，經過多年的廝殺和競爭，很多優秀的產品已經脫穎而出，也有很多產品慢慢走向消亡。比如Spark基本上已經成爲批處理領域的佼佼者， Flink成爲了低延遲流處理領域的不二選擇，而Storm開始慢慢退出歷史舞臺。 Kafka在消息中間件領域基本上佔據了壟斷地位，最終沉澱出了以這幾個軟件爲核心的大數據處理平臺。
那麼現在的大數據架構下的底層生態已經足夠成熟來幫助企業用戶進行數字轉型嗎？哪些地方還存在優化的空間？
同爲開源數據管道，卻有不同命運。
回到7年前，Kafka也肯定想不到自己會在大數據系統中起到這麼重要的作用。2010 年， LinkedIn開始研發Kafka，最初的設計理念非常簡單，就是一個以append-only日誌作爲核心的數據存儲結構。2011年的時候，Kafka提出了一個叫做ISR實時備份列表的機制，來保證高可用性。
運行過Kafka大規模集羣的人都知道，Kafka裏面有很多數據持久化的問題。在一些早期版本中或者沒有選擇正確配置時，如果一個服務器失敗（這在分佈式系統裏很常見），就會導致這個服務器端所存的數據在恢復之前無法再被取得，更有甚者，這些數據有可能就永遠丟失了。僅僅作爲一個日誌系統，這也許是可以勉強接受的。但是當越來越多企業開始使用Kafka來傳輸和保存重要商業數據，沒有高可用性是不行的。所以在引入了多備份機制之後，Kafka脫穎而出，成爲了當時整合流數據傳輸的集中式通道的首選，並慢慢進化出了強大的社區生態。
但企業採用Kafka之後，依然需要踩很多坑。爲了應對多租戶、支撐上百萬Topics等要求，雅虎研發了新一代消息平臺Pulsar，並且在設計上採用了數據服務和數據存儲分層的架構。2016年雅虎將這套軟件進行了開源，當時有人感慨：“如果Pulsar早推出兩年，也許就沒Kafka什麼事兒了。“
對比Pulsar，Kafka的先發優勢非常明顯，在強大的社區支撐下，Kafka背後的公司Confluent不斷獲得融資，估值高達25億美元。但是Pulsar背後的公司Streamlio，發展卻不那麼順利，沒幾年就被Splunk以人才收購的方式合併到一起了。關於開源軟件的商業模式很難用一兩句話討論清楚，但Pulsar一開始的目的是想做“更好的Kafka”，它在技術上可以認爲是成功的，並且是值得被借鑑和被採用的。
也就是在Pulsar開發的同時，戴爾科技集團的研發團隊發現做一個更好的消息隊列/Kafka並不能解決新一代大數據平臺在數據存儲層上的挑戰，因此他們重新思考了數據處理和存儲的規則，設計並開源了全新流存儲”Pravega”項目（https://github.com/pravega）。通過一個全新的“stream”存儲抽象層，Pravega讓上層計算引擎能更好和無縫去跟底層存儲解耦：“所有計算機領域的問題，都可以通過增加一個額外的中間層抽象解決”。
一套新的開源大數據平臺
“Steam is the new file system for continous data."
有了Pravega提供的存儲層以後，大數據架構將會變成如上圖右側所示，並帶來以下改變：
- 在整個流水線中，無論有多少計算處理單元，原始的數據只會被保存一份。
- 不再需要根據數據的“時間”屬性去選擇不同的處理流水線(streaming or batch)，可以同時對實時和歷史數據的聚合做低延時的實時處理。
- 計算處理邏輯統一，降低應用開發難度。
爲了詳細解釋這三點，我們可以先用下表來簡單對比一下Pravega和Kafka設計哲學的不同之處，這也代表了流存儲和消息隊列的本質差異：
接下來我們可以就第一點再展開，以理解新系統的優勢：
“數據無價，而計算可以重試”， 在左邊使用Kafka+Spark/ES的大數據技術棧中，很多企業爲了保證數據不丟失，必然對重要（甚至所有的）的數據進行3拷貝落盤的設定。一份topic，在Lamda架構下，從Kafka到離線、實時計算上要形成至少6個拷貝。再加上多數據中心，比如說2-3個站點，那麼一個topic就至少形成12-18個拷貝。而現在每天產生PB級別數據的企業不在少數，那就意味着這些副本也需要PB級別的資源去存儲，成本相當昂貴。
而在Pravega+Flink這套技術棧下，Pravega是一個抽象的存儲接口，在這個流水線上所有的原始數據只被存儲一份，然後將數據寫到持久存儲層如對象存儲或HDFS。並且如果選用支持高效EC糾錯碼的商業分佈式存儲作爲Pravega的long term storage，在保證數據的高可用高可靠性的情況下，對比Kafka，就節省掉了相當多的數據存儲開銷。當企業的數據量達到10+PB級別後，Pravega/Flink +商業存儲模式遠比完全使用開源軟件自建要省錢的多。
在接受InfoQ的採訪時，戴爾科技中國研發集團滕昱解釋完這套產品後表示：“我認爲，下一個十年企業用戶真正需要的大數據平臺就應該是這個樣子的。“
大數據平臺的幾個發展方向
開發人員也需要有一個“整體”的商業思維。
豐富的開源項目能讓一個大數據系統的初始搭建變得簡單，Kafka+Spark/Flink的Lambda架構已經很普遍，一定程度上降低了技術的入門門檻。但一個企業裏的端到端方案，並不是簡單的堆積一些大數據產品組件，用戶需要的也不是 Hadoop、Spark、Flink、Kafka等這些技術，而是要以這些技術爲基礎的能解決業務問題的一套完整的產品方案。
現在很多國內的企業，將建設一套解決方案的事情上升到了組織架構層面，形成各種部門，有叫大數據的，有叫基礎架構的，有的專門管存儲，有的專門管計算…每個部門各司其職，各自負責尋找各自的“局部最優解”，比如用Kafka的大數據部門就覺得把Kafka做好就行了。但是比單個技術應用更重要的，是企業還需要整體去考慮規模化應用、運維管控和成本優化方面的事情。只有把整套架構放到一起，做好優化，同時考慮整體成本，才更具有優勢。比如管存儲的部門的KPI可能是基於有多少數據量來考慮的，那麼做一個統一存儲層的動力自然不足，但是這從整個公司角度來看其實是有問題的。
“做分佈式存儲遠比做分佈式計算更難。”
在一套大數據技術棧下，從數據採集到計算，到存儲，再到底層的基礎設施，最難的往往是存儲相關的這一塊。
所謂的數字化資產，就是企業保存下來的原始數據。對於有價值的資產，在數據安全性上是不允許有閃失的。大家可以很清楚的發現，相對於計算框架的百花齊放，開源分佈式存儲項目上其實一直處於“不堪大用”的地步。因爲任何軟件都有bug，當存儲產品出現bug的時候，開源模式就決定了無法找到一個24*7的響應模式來幫助客戶fix DU/DL的支持團隊，這其實是沒有任何企業用戶可以接受的。所以你會發現，到最後就變成了自建團隊維護自己專屬分支的結局，想想Ceph的歷史上有多少bug已經無人問津的現實吧，Ceph官方的做法是設計一個新的存儲引擎去挖新坑。
未來企業數據量只會越來越大，當超過EB級別以後，現有開源的存儲產品都會有一些基本設計上的問題，即使它們的架構圖是那麼“完美”。而商業存儲產品在2013-2014年就已經達到2-3EB單個系統的體量，這種積累其實是開源存儲產品很難在短時間跟上的。所以當數據量達到一定程度後，所有企業都需要去平衡技術和商業。
這也是Pravega被推出的一個重要原因，用開源技術連接底層存儲和開源計算，解決“成本”問題。在項目啓動早期，仍然可以使用HDFS/Ceph/公有云去“試水”， 正式進入商業以後，可以使用商業分佈式存儲和公有云存儲混布的架構，在滿足上層計算完全通過Pravega的抽象訪問數據無需更改的前提下，用戶可以根據自己數字資產特性去自由地在公有云和商業雲原生存儲平臺之間動態遷移，畢竟公有云存儲對於絕大部分企業用戶來說實在太昂貴了。
“技術當然很重要，但更重要的是順應技術趨勢去思考未來發展。”
從 2012 年開始，Mesos的流行、Docker的興起，然後Kubernetes出現並一舉打敗Yarn和Mesos，到現在整個基礎架構正在全面往雲原生方向發展。
另一方面，雖然公有云廠商總是宣傳讓大家“全面上雲”，但是除了對公有云存儲成本的擔憂之外，企業用戶更加擔心的是數據鎖定（Lockdown）隱患。尤其是沒有人能保證公有云廠商不會進入自己的商業領域，企業必須選擇將自己最看重的數據資產放到自己能掌控的硬件環境下或者是更靠近數據產生的邊緣端。所以未來的大趨勢必然以混合雲多雲的方式爲主。這也是爲什麼雲原生存儲對企業用戶有吸引力，因爲它和上面的趨勢是契合的。
雲原生最重要的一個隱含意義就是做到端到端的存儲計算動態可伸縮性。當負載增大時，負責這條流水線的底層架構可以自動感知變化並進行合理調度，並且是在沒有DevOps人爲干預的前提下。而當負載變小後，又可以動態釋放多餘資源給系統中其他流水線使用，如下圖所示。這樣可以在最大程度上榨乾硬件資源每一份能力。
面向傳統企業，開源需做出改變
“一切人類活動都是經濟活動，軟件開發也不例外”。
AWS曾表示：公有云至今只轉移了世界上3%的Workload，另外97%仍然還是傳統的企業開發。
這97%的存量ToB市場跟互聯網企業有着很不一樣的商業模式，主要表現在以下幾點：
第一，這不是一個“從0到1”的市場。這些傳統企業往往在本領域已經是頭部，它們的營收一般在百億美元以上，每年的增長可能只有10%-20%。在它們選擇新技術時候，一個3-4年的TCO（Total Cost of Ownership 總擁有成本）往往是其COO首先考慮的指標。那麼他/她必然要在公有云的“彈性”和“昂貴”中作出取捨，更不說上面提到的Lockdown的商業風險。
一般互聯網企業喜歡的是全新的顛覆性的市場，用全新打法來追求爆炸性的增長率。對比互聯網企業，傳統企業自然在技術上取捨上會不一致。“先有再演化”的開源軟件自然是不二選擇。只是隨着整體的經濟形式變化，每個今天的新興企業都有可能成爲明天的成熟行業。 他們同樣會面臨技術使用上對成本的整體考慮，比如最近兩年就出現了從AWS等公有云存儲迴歸私有商業存儲的“歸隊”趨勢。
第二，垂直細分領域在企業開發中相當常見。不同領域有不同的需求，比如在遠洋運輸和石油鑽井平臺行業中，網絡連接甚至都不是一個“必選項”，那麼其實也就不存在一個能滿足所有行業的開源項目。更多是需要在理解這些領域挑戰得前提下，有商業化支持的雲原生存儲計算的混合雲方案。
另外一個例子是在很多金融公司和銀行裏面，對安全的標準往往是物理隔離或者是多年行業形成的一系列規範。絕大部分的開源軟件其實完全沒有考慮或者也沒法考慮這類要求，必須藉助商業軟件才能完成。比如戴爾科技集團在基於Pravega+Flink的Streaming data platform上就加入了基於K8S的全棧安全特性支持，並且作爲默認設置。
第三，在實踐中，“ToB”和“ToC”另一個巨大的不同點在於技術方案不再由單個人來評估好壞，更多是一個企業決策者羣體共同的決定結果。而這個羣體裏面每個決策者，又會因爲各自代表利益的不一樣，需要從很多非技術的角度去考慮。這甚至造成了企業開發中“慢速敏捷”的現狀，穩定和兼容性的要求遠大於新功能和快速試錯的要求。
很多企業甚至表示，“我們不需要一週一個新版本”。因爲光是協調升級線上系統的批覆流程都需要1-2周，一個月一次的bug fix升級已經足夠敏捷，6-8個月的大版本升級也“足夠好”，但是向後兼容是必須要保證的，而這在開源軟件中往往很難做到。業界最好的例子莫過於Intel的CPU指令集，爲了最大程度的保證向後兼容，x86不得不一直維護着一些很古老的指令來保證所有的用戶都不會因爲新CPU造成上層程序的兼容出錯。
滕昱說：“這就是企業開發的特點，和市場每年以300%甚至500%的速度快速膨脹的互聯網企業本質上並不一樣。只不過經過10年高速發展之後，大家終於開始把目光投向了這些巨大的存量企業市場。而這個時候，我們所有的技術，包括開源項目和雲技術，都要做出一些相應的商業上的調整，才能抓住這些用戶的心和市場（real money） 。”
嘉賓介紹：
滕昱，現就職於 戴爾科技集團並擔任軟件開發總監。負責分佈式對象存儲ECS(Elastic Cloud Storage)以及基於開源Pravega項目的新一代大數據分析平臺的研發工作。滕昱於2007 年加入 戴爾易安信 以後一直專注於分佈式存儲領域，先後參與領導了戴爾易安信中國研發團隊在前後兩代對象存儲產品中的核心研發工作並取得商業成功。他正在積極擁抱新的邊緣/混合雲/多雲和實時流處理時代的到來，爲企業用戶提供下一代大數據平臺而努力完善整個生態系統的構建。