什麼是數據中台？打破資料孤島！
實現資料庫與資料庫的連結
您對「數據中台」的想像，是否就是一個超大型的資料倉儲（Data Warehouse）或資料湖（Data Lake）？在過往我們服務的客戶裡，時不時會有人提出這樣的疑問。
的確，對於傳統資料或數據的使用者或組織單位來說，如何將資料收集和存放在一起，然後又如何取出來使用，是最關心的議題。因此這也不難理解，為什麼當我們在討論數據中台時，許多人直覺地想像，就是能將資料從資料源收集到資料倉儲（如：Hadoop），然後可以從裡面去拿資料進行分析運算的平台。
想當然耳，長久以來這種「資料源 — 資料倉儲 — 資料應用」的關係，使得許多人很自然地認為資料倉儲的角色就是數據中台。
但數據中台真的只是這樣嗎？如果真的只是一個大型資料倉儲，那你相信當初提出「數據中台」的阿里巴巴，能光靠一個超大型的資料倉儲撐起來所有應用嗎？
如果你也不相信，這顯而易見並不是數據中台的應該要有的樣貌。那麼，所謂的數據中台到底是什麼？
數據分析只是眾多資料應用之一
想要了解數據中台的好處或是目標，必須要先認知一個事實：「企業組織內需要數據或資料的應用系統數量與日俱增。」
而以往講到大數據、資料分析，似乎這就已經是企業資料應用的全部，事實上在數位轉型的今天，這只是眾多資料應用的其中之一而已。其他業務系統、行政系統、線上服務整合，都將是企業資料的使用者之一。
此外，即使單看數據分析的工作，可能從過去一年、半年統計分析，也進展到一季、一個月甚至一天一次。對於一些講求效率的企業，甚至需要一小時、一分鐘或是近乎即時的分析，而且針對不同的需要，甚至需要同時處理多種分析和運算。
我們應該要認識到，企業對資料應用的需求，已經跟過去不一樣，數據也不是只有 BI、分析單位或是很潮的 ML/AI 團隊才有使用的需求，更多的 IT 系統都有使用資料的需求，而且場景還更為複雜和多元。
更大的資料孤島，資料供應的困境
過去幾年大數據議題的推波助瀾，所有的系統架構設計皆朝向「處理巨量資料」前進，因此在導入 Hadoop 這類資料倉儲、資料湖架構後，將企業的資料都集中存放在一起。而面對巨量的資料，這類資料倉儲或資料庫系統，因爲有能力快速地進行分析或查詢運算，滿足了許多數據分析等應用需求。
然而如前面所述，數據分析只是眾多應用的滄海之一粟，現今應用對資料的需求更多，衍伸出來的更多不是大量的資料處理需求，而是對資料的「高併發存取」及「整合商業邏輯」的需求。不只如此，不同的應用對資料格式、處理框架、落地場景也有不同的需要，也同樣需要得到滿足。
因此，面對更多應用需求，傳統的資料倉儲架構就彷彿形成了一個更大的資料孤島，難以滿足應用所需要的資料供應。
集中、單一的資料集散區，已經無法同時滿足「大量」與「高併發」的需求。 由於要使用單一的資料倉儲或是資料庫系統，保持足夠效能表現、打造統一的管理規範，還要滿足如此眾多的資料應用，相當困難，所以這樣的作法已經不知不覺形成了另一個更大的資料孤島。
應用各自為政、各自與資料源孤島建交
於是企業裡，因為單一大數據平台無法滿足眾多應用的需求，更多的業務應用開始打造各自的資料處理架構，自己從各資料源拉取資料。資料源是一個個資料孤島，為了讓資料可以被應用所使用，各應用會進行各種資料擷取、轉換、跨系統查詢等工作，甚至彙整成自己需要的格式，落地到自己需要的資料庫系統之中。
這種情況下，每一個應用程式的資料處理機制都各自獨立，也都實作多套從資料源索取資料的方法，面對異質資料庫的場景，更是一大麻煩。另外，多套不同的資料基礎架構（Data Infra）的管理和整合，更是企業最頭痛的問題。
應用越多，基層資料源越被嚴重壓榨
隨著應用越來越多，資料處理架構越來越多套，對資料源的索取無度，就會造成資料源系統巨大的壓力。尤以一些需要較為即時的資料查詢、跨資料庫系統的關聯查詢，更是會造成資料源毀滅性的打擊。
若是資料源是一些新的應用程式，可能還有開發人員能協助優化。不過，假若資料源是一些老舊的系統，就會有無人能維護、架構不易擴充或改造風險太高的問題，其不穩定性就會造成企業內莫大的隱憂，使數位轉型遭遇極大瓶頸。
這還只是前戲，當「新的應用程式本身也成為其他應用的資料源」時，整體資料風暴和系統災難才真正要開始。更多無數的客製化跨整合需求、效能優化設計，會讓開發人員疲於奔命，讓部門、組織間有無數的「溝通會議」要開。
數據中台如何解決這問題？
不同於應用各自為政的做法，數據中台以「統一規範和實現」方式，以各種代理管線和資料節點來統一化資料交換的方法，並基於這個架構下，提供更彈性的資料系統架構的手段，讓整個企業的資料系統樣貌得以重塑。
可以說，數據中台扮演著虛擬數據物流的角色，讓資料系統架構師可以自由設計資料的運送流程，並送入到大大小小不同的資料倉儲、資料庫系統，甚至讓資料可以「就近出貨」到終端應用。
這數據物流的管理技術，即是近年來被提及的數據網格（Data Mesh）。
因此，即便不改動既有的資料庫系統，數據中台也能協助應用從資料源快速取得資料，強化資料庫與資料庫之間的連結通道，打破各式資料孤島的問題，真正意義上實現分散式資料管理的架構。甚至是在未來跨雲的需求上，也能藉由不同資料節點的資料調度來滿足。
重點是，其快照和分散式資料節點架構，能完全避免對資料源造成衝擊。
數據中台帶來的更多好處
數據中台所帶來的是非侵入式資料系統框架，除了整合既有資料庫系統之外，更重要的是其統一規範和彈性，讓各種資料庫不再孤獨。因此理論上，導入數據中台後，所有資料庫系統都能得到更大的擴展性和彈性，使其不再受限於資料庫叢集、特定資料庫的工具之上，甚至能透過數據中台來利用異質資料庫的好處，以彌補原先資料庫系統的不足之處。
就利用異質系統強化整體應用這點，與微服務架構有異曲同工之妙。
實際應用場景下，尤其是當新的應用需要一條新的資料處理管線，數據中台可以快速的部署並滿足需求，甚至其彈性可以因應應用場景，實現資料庫的「多重副本」、「讀寫分離」和「資料快取」等機制，大幅滿足「高併發」的需求，無論原本的資料庫系統或應用程式架構是否有支援這些功能。
過去一些需要「高併發查詢」需求的應用，則會在資料落地後，額外實作「讀寫分離」、「快取」等機制。當然，實作的方式相當多元，有搭建資料庫叢集、主從架構的方式，也有自己程式實作的方式。各種強化和優化的需求，往往都需要專業的維運人員進行搭建，或是大量客製化開發工作。
導入數據中台困難嗎？
不可否認，整個企業範圍下大規模導入數據中台，無疑有一定難度。但若將數據中台的代理管線和資料節點技術，部分引入來改善既有資料庫系統、應用程式的效能，則是相當容易且沒有太大風險。
由於數據中台是由許多資料代理管線和節點所組成，當導入的數量達到一定程度，眾多資料源、資料出口被納管，就會自然形成數據中台的樣貌。
更多關於數據中台技術的實務場景
更多關於如何利用數據中台的部分技術，改善資料庫系統的問題，並強化資料庫效能，可以參考過往的其他文章：
想要導入數據中台嗎？欲知更多 Brobridge Gravity 的好處和功能，歡迎與我們寬橋（Brobridge）聯絡。
