訂閱你的資料頻道
當企業資料規模與日俱增的同時，資料價值發掘的渴望也隨之而生。只是，線上交易資料庫的設計訴求與結構，與多維度資料分析的期待總是有些距離感。然而，一個有效的分析系統從來都不只是資訊系統的問題，和商業文化有著密切的關連。
資料治理是一個很有趣的研究方向呢！
當你打算在資料庫上分析資料時，你只有一個資料庫主宰著所有資料，而你並不希望分析行為會減損你的線上交易效能；你也可能早就預想過這一天的到來，早就以多個資料庫分散處理不同的應用業務，但你卻想要進行跨資料庫的分析行為。
綜合而言，你可能打算取得資料庫中部份資料，你也可能希望集合多個資料庫的資料。並且，你不會只有一個分析資料庫。
Logical Replication
PostgreSQL 在版本 10 開始，提供了 Logical Replication 的功能，簡而言之，它可以進行 Table 層次的資料複寫行為，複寫單位是 Transaction。它並不要求資料結構上的完全一致，訂閱端仍然是一個獨立可讀寫的資料庫。由於是 Table 層次的複寫，所以發佈端可以僅發佈一部份的資料表，而非整個資料庫，或者訂閱多個發佈端，讓資料集合在一個資料庫之中。
Logical Replication 並不是一個以即時備援為訴求的機制，它追求的是最終一致性。相對於 Streaming Replication，Logical Replication 發佈端與訂閱端的容錯空間較大，兩方沒有主從關係，資料庫結構可以稍有差異，也可以在各自方便的時間停機維護，在服務回復時會逐步追上未完成的交易。
它可能會產生一些資料的時間差，甚至是故意暫停訂閱來製造時間差。是否會對分析有所影響？你需要進一步地理解你的 Domain。
Domain Driven Design
Domain Driven Design 時常會簡稱為 DDD，當你感到你的資訊系統有點複雜而不知道如何評估時，DDD 提供了其中一個有效率的方向，從商業或治理需求來判斷其設計是否適當。
簡單來說，第一步應該是寫下你的商業需求及決策流程，一一檢視系統設計是否能夠有所對應。沒有完美的技術，只有適合的技術。所以請確立好經營的策略，作為與技術溝通的橋樑，才能達到相輔相成的期待。
許多團隊會在決策過程中被複雜的系統元件所混淆，DDD 可以幫助你聚焦在「為何而戰」的議題上。當治理目標及方法被明確化，再來以系統化的方式產製資料，對於「資料治理」而言，顯然會是更有效率的執行方向。
分析資料流
分析資料流可能是比較抽象的概念，我建議可以用實體的道路交通來想像。每一個分析目的地，就如同每一個人的家一樣，每個人都希望高速公路到我家。實際上必須瞭解的是，資料傳輸是資料處理最花時間與成本的一環，和道路建設很貴一樣。所以資料複寫和交通運輸一樣需要好好做好道路設計的。需要連接哪兩個地點（決策點）、設置岔路口（分析點）、停車場（儲存空間）……等等。
Logical Replication 剛好提供了一個彈性的方式，以交通來比喻就是提供各種大小的運輸車輛，如同宅配的集貨配送會運用不同大小的車輛送到你的家門口一樣，絕非是無腦的點對點運送。Logical Replication 雖然只負責轉送資料，但若搭配資料庫的運算能力，就可以整合 ETL 的運算，減少無謂的傳輸成本。
以決策端來看，越精準的資料配送才能越快速觀察到需要決策的資料；以資訊技術來看，資料流規劃地越清晰，越能節省系統資源，以回饋到必要的資料運算與傳輸。整體概念就是把決策樹落實在資料流之中，讓資料準備好就送到你的決策門口。
如果你無法寫清楚你的門牌地址，自然會增加資料派送的成本；如果你不知道資料要派送到哪裡去，就應該問清楚再出發。
突顯資料價值
前面談到資料流，潛藏在背後的意義就是，資料是流動的。如果你總是在收集資料堆在倉庫，沒有流動的行為，那就只是徒增倉儲的成本罷了。我認為，資料價值建立在資料流向決策，而決策也因此而產生了「決策流」，不斷相互回饋。
透過 Logical Replicaion 的機制，你得選擇好你需要的資料，也就是你需要確認好你的決策範圍。在每一次交易之後，資料會自然擴散到每一個決策點，讓決策人員可以更快地調整決策。接下來的問題就轉換為，我們是否準備好進行下一個決策了？
資料流的建立，真正的目地在於推動更有效的決策流，如果資料流無法對應到決策流就沒有意義。所以透過 Domain Driven Design，讓決策流在企業內部更為透明，也就更容易對應具體的資料流，進而找到最適當的技術運作模式。
在 PostgreSQL 之中，除了瞭解哪些部門訂閱了哪些資料之外，也提供了資料庫層級和資料表層級的使用統計，還有執行各種語法的時間統計也方便。可以突顯資料團隊是否善用了其所訂閱的資料。不論對於成本中心或是利潤中心的管理策略都會是有意義的數據。
