資料架構的未來——淺談流處理架構
資料架構設計領域正在發生一場變革，其影響的不僅是實時處理業務，這場變革可能將基於流的處理視為整個架構設計的核心，而不是將流處理只是作為某一個實時計算的專案使用。本文將對比傳統資料架構與流處理架構的區別，並將介紹如何將流處理架構應用於微服務及整體系統中。
傳統資料架構
傳統資料架構是一種中心化的資料系統，可能會分為業務資料系統和大資料系統。
業務資料系統儲存事務性資料，比如SQL， NOSQL資料庫，這種資料擁有準確的資料，比如使用者業務，支付業務等體系都可以這樣實現，這類需要經常更新，是整體業務系統支撐的核心。
大資料系統主要負責儲存不需要經常更新的資料，由於資料量過大，可能需要Hadoop等大資料框架進行實現，系統會定時的計算結果，比如在每天零點統計使用者訪問量，可能將結果結果寫入SQL資料庫，完成統計工作。
而實時資料系統往往只作為一個某一個專案使用，比如實時日誌報警系統，實時推薦系統。
這樣設計的原因是因為資料處理效能和準確性的限制，在Streaming-大資料的未來一文中曾提到過，由於對事件時間的不可控，我們不能將實時資料作為準確可靠的資料來源。而低延遲的要求將極大的佔用系統性能。
這種傳統架構成功地服務了幾十年，但隨著大型分散式系統中的計算複雜 度不斷上升，這種架構已經不堪重負。許多公司經常遇到以下問題。
• 在許多專案中，從資料到達到資料分析所需的工作流程太複雜、太緩慢。
• 傳統的資料架構太單一：資料庫是唯一正確的資料來源，每一個應用程式 都需要通過訪問資料庫來獲得所需的資料。
• 採用這種架構的系統擁有非常複雜的異常問題處理方法。當出現異常問題時，很難保證系統還能很好地執行。
而且隨著系統規模擴大，維持實際資料與狀態資料間的一 致性變得越來越困難，需要不斷更新維護全域性狀態。
流處理架構
作為一種新的選擇，流處理架構解決了企業在大規模系統中遇到的諸多問題。以流為基礎的架構設計讓資料記錄持續地從資料來源流向應用程式，並在各個應用程式間持續流動。沒有一個數據庫來集中儲存全域性狀態資料， 取而代之的是共享且永不停止的流資料，它是唯一正確的資料來源，記錄了業務資料的歷史。在流處理架構中，每個應用程式都有自己的資料，這些 資料採用本地資料庫或分散式檔案進行儲存。
這種思路在之前是不可能辦到的，它要求我們對訊息有重複消費的能力，還要保持訊息系統的高效能，同時還必須對事件時間做出精確的處理，但是現在我們有了Kafka與Flink，一切都變得簡單了。
流處理專案架構主要是兩部分：訊息傳輸層，流處理層。 資料來源是連續的訊息流，比如日誌，點選流事件，物聯網資料。輸出為各種可能的資料流向。
訊息傳輸層從各種資料來源（生產者）採集連續事件產生的資料，並傳輸 給訂閱了這些資料的應用程式和服務（消費者）。 這種設計使得生產者與消費者解耦，topic的概念，多個源接收資料，給多個消費者使用，消費者不需要立刻處理訊息也不需要一直處於啟動狀態。訊息傳輸層需要同時具備高效能，永續性，相當於緩衝區，可以將事件資料短期儲存起來。而Kafka可以讓高效能和永續性兼得。Offset機制實現了訊息永續性，訊息可以重播再計算；而基於磁碟快取的讀寫可以做到高吞吐。
流處理層有 3 個用途：①持續地將資料在應用程式和系統間移動；②聚合並處理事件；③在本地維持應用程式的狀態
Flink兼顧了這些優勢，Apache Flink是一個框架和分散式處理引擎，用於在無邊界和有邊界資料流上進行有狀態的計算。Flink 能在所有常見叢集環境中執行，並能以記憶體速度和任意規模進行計算。
將流處理架構應用於微服務與整體系統
應用於微服務
從上文可以知道，流處理架構的訊息是從Kafka中流出的流資料。 Flink從訊息佇列中訂閱資料並加以處理。處理後的資料可以流向另一個訊息佇列。這樣所有的應用都可以共享流資料。
基於流處理的微服務架構也為欺詐檢測系統的開發人員帶來了靈活性。新增加一個數據消費者的開銷幾乎可以忽略不計，同時只要合適，資料的歷史資訊可以儲存成任何一種格式，並且使用任意的資料庫服務。訊息就在反覆使用，處理，持久化中發揮了其最大最高效的作用。
應用於整體系統
事實上，流處理架構的作用遠不止於此，流資料消費者並不僅限於實時應用程式，儘管它們是很重要的一種。
圖中展示了從流處理架構中獲益的幾類消費者。A 組消費者可能做各種實時分析，包括實時更新儀表盤。B 組消費者記錄資料的當前狀態，這些資料可能同時也被儲存在資料庫或搜尋檔案中。
比如在電力監控系統中，我們需要實時的對電力故障報警，也需要實時監控電流電壓資料，也需要持久化資料做歷史分析預測等等。
本文簡單對比了傳統資料架構與流處理架構的區別，以及流處理架構的優勢所在，但這種體系也面臨著其複雜性和很多挑戰，深入瞭解Kafka和Flink將使得這一切變得更加簡單。
參考資料：Flink基礎教程
Flink官方文件
相關文章：
Flink快速入門
Streaming-大資料的未來
什麼是Kafka？
更多實時計算,Flink,Kafka等相關技術博文，歡迎關注實時流式計算
相關推薦
資料架構的未來——淺談流處理架構
資料架構設計領域正在發生一場變革，其影響的不僅是實時處理業務，這場變革可能將基於流的處理視為整個架構設計的核心，而不是將流處理只是作為某一個實時計算的專案使用。本文將對比傳統資料架構與流處理架構的區別，並將介紹如何將流處理架構應用於微服務及整體系統中。 傳統資料架構 傳統資料架構是一種中心化的資料
淺談流處理
什麼是流處理 流處理是一種大資料處理技術。它使使用者能夠查詢連續資料流，並在從接收資料開始很短的時間內快速檢測條件。檢測時間從幾毫秒到幾分鐘不等。例如，通過流處理，你可以通過查詢來自溫度感測器的資料流並檢測溫度何時達到凍結點來接收警報。 它還有許多名稱：實時分析、流分析、複雜事件處理、實時流分析和事件處理
淺談web網站架構演變過程
zookeeper 現在 故障 容災 nosql數據庫 管理系統 出現 mycat 協議 前言 我們以javaweb為例，來搭建一個簡單的電商系統，看看這個系統可以如何一步步演變。 該系統具備的功能： 用戶模塊：用戶註冊和管理 商品模塊：商品展示和
淺談微服務架構、容器技術與K8S
關注嘉為科技，獲取運維新知 企業應用系統：從單體應用走向微服務架構；從裸金屬走向容器。 如果在諸多熱門雲端計算技術諸如容器、微服務、DevOps、OpenStack等之中，找出一個最火的方向，那麼可能非微服務莫屬。儘管話題炙手可熱，但對傳統行業來說，微服
Mongodb架構設計淺談
概覽 Mongodb是文件型資料庫，由於其不屬於關係型資料庫，不必遵守三大正規化，而且也沒有Join關鍵字來支援表連線，所以Mongodb的表結構設計跟Oracle、MySQL很不一樣。下面針對幾種不同的表設計結構分別舉例： 1對1關係模型 在關係型資料庫中，1對1關係模型通常是通過外來
阿里P8資深架構師淺談Java程式設計師由初級-中級-高階進階詳細介紹
Java從業者職業生涯規劃 Java進階之路-從初級到架構 java技術的學習階段有三 第1個是java基礎，比如對集合類，併發，IO，JVM，記憶體模型，泛型，異常，反射，等有深入瞭解。 第2個是全面的網際網路技術相關知識，比如redis，mogodb，ng
淺談三層架構中的實體類(C#)
最近因為三層架構中的實體類，引發了不少小問題，下面列舉一下，談談自己的感想。 本文所指的實體類僅限於三層中的實體類，即資料庫表的對映。 一、為什麼要用實體類？ | 使程式簡潔易懂，便於維護。
阿里P8架構師淺談——Java程式設計師的路該怎麼走？（九點概括）
第一：提醒自己還有多少沒有學習 學習新東西的第一步是自己認識到哪些不足。這聽起來很簡單，但是有一些經驗的程式設計師要克服這個假設需要很長時間。有很多計算機專業的學生畢業時昂著頭傲慢地說：“這不算什麼，我全都知道”類似這般的虛張聲勢， 剛到工作崗位上，似乎在向每個同事證明自
阿里P7架構師淺談Java 的年薪 40W 是什麼水平？
做Java架構師（P7）崗位有三年時間了，期間也從事了很多招聘定級工作，來說說我見解吧。 既然樓主提到年薪40w，那我們看看什麼公司，什麼級別可以給到，再看看要求。 阿里是Java大廠，所以可以參考阿里的標準，阿里一般是16薪水，所以就是稅前2.5w，在阿里應該是P6就可以達到，而對P6的要
Red5 流處理架構設計解析
前言 流處理是 Red5 容器的一個核心。本文是一個 Red5 流處理的設計文件，來自於 Red5 團隊的郵件列表，作者是 Steven Gong，起稿於 2006 年 4 月。本文的原文標題是《關於流處理架構設計的介紹》，原文可以點選這裡進行檢視
淺談SpringMVC之架構與工作流程
MVC模式是在Java的Web應用開發中非常常用的模式。MVC全名是Model View Controller，是模型(model)－檢視(view)－控制器(controller)的縮寫，一種軟體設計典範，用一種業務邏輯、資料、介面顯示分離的方法組織程式碼，將
iOS開發之淺談MVVM的架構設計與團隊協作
1 // 2 // NetRequestClass.m 3 // MVVMTest 4 // 5 // Created by 李澤魯 on 15/1/6. 6 // Copyright (c) 2015年 李澤魯. All rights reserved. 7
淺談微服務架構中的鑑權體系
文章概要 在微服務架構中，有一個核心的問題是處理好“集權”（中心化）和“放權”（去中心化）的關係。雖然微服務的主旋律是把資料和業務拆成小而獨立的模組，但我們仍然需要一個強力的中央安保體系來確保“資料分散，許可權集中”。這一篇就談談微服務架構中的鑑權體系。 身份認證 身份認證（Auth
淺談HTTP RESTful架構
RESTful 是一種非常流行的軟體架構，或者說設計風格而非新的技術標準。提供了一組設計原則和約束條件，主要用於客戶端與伺服器的互動。RESTful架構更簡潔，更有層次，更易於實現快取等機制。 1.理解RESTful RESTful, 全稱Representatio
淺談facebook伺服器架構
大體層次劃分 Facebook的架構可以從不同角度來換分層次。 一種是：一邊是PHP整的經典的LAMP stack；另外一個是非PHP整的各種service。 Facebook的頁面從剛創立的時候扎克伯格寫的，到現在，都用PHP開發。後端有用各種語言開發的service。它們之間用跨語言的thrift
系統分析與設計 -- 淺談B/S 架構與C/S架構
關於B/S架構與C/S架構之間異同的文章，相信有很多是寫得十分全面的，如這裡。 這篇文章將從純小白的角度，以最快的時間講解其本質與差異。 歸根結底，便是下面這幅圖: C/S架構的特點是在S端有C端的app映象，兩者是意義繫結的。其就是我們移動app的模式
淺談Android App架構
一、什麼是架構 什麼是架構，我最初的理解，架構就是通過降低偶合性，提高安全性和擴充套件性，達到方便對軟體進行維護的一套行之有效的分層思想。在我看來架構最主要的就是降低偶合性和提高擴充套件性，我們平常對於客戶端的修改和重構也基本上是圍繞這兩個點而進行的。當
淺談 IIS7.0 架構
IIS是Internet Information Server的縮寫，它是微軟公司主推的WEB伺服器，現在使用者一般常用的版本是Windows2003裡面包含的IIS 6或者是更早的IIS 5，IIS與Window NT Server完全整合在一起，因而使用者能夠利用Wind
【架構篇】Android移動app架構設計淺談
前言 架構，又名軟體架構，是有關軟體整體結構與元件的抽象描述，用於指導大型軟體系統各個方面的設計。 軟體架構設計目標： 1.可靠性（Reliable）。軟體架構的可靠是產品設計的前提。 2.安全性（Secure）。軟體架構的安全性是
兩層架構CS和三層架構BS淺談
• C/S 和B/S 作為兩種不同的系統登入方式，各有優缺點，要做出正確的判斷就要對兩種架構有著明確的認識。下面就分別介紹這兩種結構的特點。C/S 結構（Client/Server 的簡稱，客戶機/伺服器模式）。在上個世紀八十年代及九十年代初便已經得到了大量應用，最直接的原因