數據架構的將來——淺談流處理架構

時間 2019-11-18

原文原文鏈接

數據架構設計領域正在發生一場變革，其影響的不只是實時處理業務，這場變革可能將基於流的處理視爲整個架構設計的核心，而不是將流處理只是做爲某一個實時計算的項目使用。本文將對比傳統數據架構與流處理架構的區別，並將介紹如何將流處理架構應用於微服務及總體系統中。數據庫

傳統數據架構

傳統數據架構是一種中心化的數據系統，可能會分爲業務數據系統和大數據系統。apache

業務數據系統存儲事務性數據，好比SQL， NOSQL數據庫，這種數據擁有準確的數據，好比用戶業務，支付業務等體系均可以這樣實現，這類須要常常更新，是總體業務系統支撐的核心。緩存

大數據系統主要負責存儲不須要常常更新的數據，因爲數據量過大，可能須要Hadoop等大數據框架進行實現，系統會定時的計算結果，好比在天天零點統計用戶訪問量，可能將結果結果寫入SQL數據庫，完成統計工做。架構

而實時數據系統每每只做爲一個某一個項目使用，好比實時日誌報警系統，實時推薦系統。框架

這樣設計的緣由是由於數據處理性能和準確性的限制，在Streaming-大數據的將來一文中曾提到過，因爲對事件時間的不可控，咱們不能將實時數據做爲準確可靠的數據來源。而低延遲的要求將極大的佔用系統性能。分佈式

這種傳統架構成功地服務了幾十年，但隨着大型分佈式系統中的計算複雜度不斷上升，這種架構已經不堪重負。許多公司常常遇到如下問題。 • 在許多項目中，從數據到達到數據分析所需的工做流程太複雜、太緩慢。微服務

• 傳統的數據架構太單一：數據庫是惟一正確的數據源，每個應用程序都須要經過訪問數據庫來得到所需的數據。oop

• 採用這種架構的系統擁有很是複雜的異常問題處理方法。當出現異常問題時，很難保證系統還能很好地運行。性能

並且隨着系統規模擴大，維持實際數據與狀態數據間的一致性變得愈來愈困難，須要不斷更新維護全局狀態。大數據

流處理架構

做爲一種新的選擇，流處理架構解決了企業在大規模系統中遇到的諸多問題。以流爲基礎的架構設計讓數據記錄持續地從數據源流向應用程序，並在各個應用程序間持續流動。沒有一個數據庫來集中存儲全局狀態數據，取而代之的是共享且永不中止的流數據，它是惟一正確的數據源，記錄了業務數據的歷史。在流處理架構中，每一個應用程序都有本身的數據，這些數據採用本地數據庫或分佈式文件進行存儲。

這種思路在以前是不可能辦到的，它要求咱們對消息有重複消費的能力，還要保持消息系統的高性能，同時還必須對事件時間作出精確的處理，可是如今咱們有了Kafka與Flink，一切都變得簡單了。

流處理項目架構主要是兩部分：消息傳輸層，流處理層。數據來源是連續的消息流，好比日誌，點擊流事件，物聯網數據。輸出爲各類可能的數據流向。

消息傳輸層從各類數據源（生產者）採集連續事件產生的數據，並傳輸給訂閱了這些數據的應用程序和服務（消費者）。這種設計使得生產者與消費者解耦，topic的概念，多個源接收數據，給多個消費者使用，消費者不須要馬上處理消息也不須要一直處於啓動狀態。消息傳輸層須要同時具有高性能，持久性，至關於緩衝區，能夠將事件數據短時間保存起來。而Kafka可讓高性能和持久性兼得。Offset機制實現了消息持久性，消息能夠重播再計算；而基於磁盤緩存的讀寫能夠作到高吞吐。

流處理層有 3 個用途：①持續地將數據在應用程序和系統間移動；②聚合並處理事件；③在本地維持應用程序的狀態

Flink兼顧了這些優點，Apache Flink是一個框架和分佈式處理引擎，用於在無邊界和有邊界數據流上進行有狀態的計算。Flink 能在全部常見集羣環境中運行，並能之內存速度和任意規模進行計算。