資料串流處理架構的關鍵設計考量
Key Points for Data Streaming Architecture Design
近年來，資料串流（Data Streaming）的處理架構逐漸扮演重要地位，要讓原始數據、各類加工的資料可以被高度、更廣泛重用，使其價值被最大化發揮，傳統孤島式、集中囤積形式的資料系統設計，必須得改造成相容於資料串流的架構才能滿足。不僅如此，若想要提高資料價值回饋的即時性，或是為爭取時間而實現資料平行化處理的可能性，資料串流架構的設計，是唯一的選擇。
但是當我們在設計和實現資料串流處理架構時，總是發現很多事情似乎沒有想像中的這麼簡單，各種與過往截然不同的資料系統設計問題一一浮現。而到底有哪些問題是需要我們特別注意及解決的呢？
本文將會就過往在客戶身上的經驗，點出常見的設計關鍵議題。
引入訊息佇列只是開端
許多人對資料串流架構的認知，僅僅只是將訊息佇列系統（Message Queuing System）搭建起來，並提供資料串流的訂閱機制而已。而搭建起來後多半只能做一些簡單的即時應用、監控需求等，也無法改善原本的資料系統效能，或是增加原本資料系統的處理能力規模化。
雖然表面上來看，訊息佇列建構了一個高速資料傳遞網路，可以因此供應可多個系統，但其大量零散且片段的資料供應能力，對於一些重型資料應用來說仍然是難以實作。試想，當馬桶需要囤積一定量的水才能沖走穢物，而你用不停出水的小水管去沖，得到的結果肯定是怎麼也沖不乾淨。（抱歉，這舉例有些觀感不佳）
訊息佇列如同物流中的高速公路和馬路，雖然是資料串流處理架構中必要的一環，但僅僅是開端，真正關於貨物處理、供應效率的關鍵，在於各種集貨倉、轉運站的機制和路線設計。
常需要保證資料完整性，但是費時又傷效能
除非我們可以容許應用只處理部分資料，或是對結果射後不理，否則多數的資料都必須累積起來才有其價值。這意味著，當我們需要資料時，往往需要去取得完整的資料集，而不是部分、短期內的資料。
這代表，單單只是在訊息佇列上短期內、有限量的資料，根本滿足不了我們的需求，常常總是需要從源頭將資料完整拉取。而這樣的做法，常傷及資料的源頭系統效能，甚至影響其他業務系統的運作。
將批次處理邏輯轉化成串流處理邏輯
效能、時效的殺手，往往出現在大規模的批次處理上，雖然身為工程控的我們，都知道計算 1、2、3… 累加到 10,000 的最快速算法，就是利用梯形公式來算。但在資料系統中的現實是，你必須等 10,000 個數字都完全接收到並確認無誤時，才能進行計算，才能得到結果。而一次查詢並載入這 10,000 個數字，時常會造成系統龐大的負擔。
在實務上，如果你需要考慮即時性，又或是我們希望讓這工作能分散在其他時間順手做掉，而不集中在特定時間點消耗大量系統運算能力。適當的做法應該是在資料產生的那一刻，就以串流形式（Streaming）拋出，然後讓統計程式一筆筆從 1、2、3…累加得到「當下」的累積結果。
ETL 工作排程轉換成即時串流處理工作
離峰時段滿滿的排程工作，讓系統總是有很長一段時間無法好好處理核心業務，各種資料又不能即時被同步到所有相關系統中呈現，要等各種繁重的 ETL 工作做完後才能得到結果。一天 24 小時不夠用，甚至只能分不同日子去處理。如此沒有效率的資料處理、發佈和更新機制，勢必要用即時串流的設計和架構來解決，才能滿足數位轉型的需要。
資料串流處理邏輯需要標準的開發、部署管理
傳統批次資料處理，大不了單工排程執行，互相不干擾，也沒有即時調整的需求。但導入了資料串流處理架構後，開發出來的資料處理程式，需要無時無刻待命如同一般業務服務，又或是需要動態部署和管理，因此甚至需要個統一個管理模式。
如何同時滿足批次處理和串流處理的需求？
有些東西需要批次處理，我們需要得到完整的資料集；某些時候我們又需要即時的資料串流來進行分析；但又有一些情況，我們需要得到整個完整的資料集，又需要這資料集不斷追上最新的資料狀態。
不滿足批次處理，無法完成一些報表、整體性的分析工作；不滿足串流，我們無法實現即時需求和提高系統處理效率；如果不滿足即時的完整資料集供應，則無法滿足新應用的擴展和規模化需求。各種需求在數位轉型的今天，缺一不可。
誰都有可能是資料消費者，也可能是資料源
當資料處理的工作不被集中在特定系統上，每一支經手資料的服務程式，除了是資料消費者之外，也可能是其他服務的資料源。因此會最大限度地讓資料可以有機會重複利用，讓許多應用無需總是從原始資料（Raw Data）來重複進行同樣的工作，浪費系統寶貴的運算資源以及傷害資料的時效價值。
害怕開 API 讓人打趴自己的系統
在做資料串流時，因為資料是一筆筆依序處理，針對一些關聯資料，時常需要藉由查詢其他系統來取得。但最可怕的是，當身為資料擁有者（Data Owner）的我們，開了 API 來分享資料給這些外部程式進行查詢，其大量的一筆筆查詢，會把我們自己的系統打趴。
我們總是在想，到底是該開放 API 呢？還是不該開放？還是到底應該依據什麼條件開放，又或是應該要有更好的做法？
如何有效率且規模化的實現快取層？
資料快取（Caching）往往僅僅被視為是一種應用程式取得資料的加速手段，過去有各式的做法和工具，存在很零散、沒有規則，使其基本不被視為主要資料系統架構的主要部分。但是當我們想要資料的重用性得到提高，快取機制就是一個不可或缺的功能。若是想為不同資料、應用程式都花大量時間去實現高度客製化的快取，顯然不是正確的做法。如何在架構中，尋找一個有效率生成並建構快取機制的模式，打造資料系統中的通用快取層，是一個關鍵要素。
需要兼顧跨組織、系統、Domain 的資料治理
引入資料串流架構後，需要管控的不再只是「資料庫系統」中資料是否可以被存取的問題而已，而是如何跨組織、系統、應用來快速且安全取得，並且任何的資料取用和供應不能造成其他系統過大的壓力和負擔，同時治理的範圍也包括批次、即時、串流等各類型資料處理的需求。
本文整理自寬橋（Brobridge）過往協助客戶導入資料串流架構、資料系統架構改造以及實現一些資料即時性需求的經驗，若您有相關的疑慮和困擾，歡迎 與我們直接聯繫。
