資料治理：企業如何走出資料孤島？

資料已成為數字經濟的重要生產要素，這意味著，整合更多資料、擁有更強的資料分析和處理能力，以資料資產化、資料服務化、資料知識化驅動業務，將是組織獲得核心競爭力的關鍵。

然而，在構建資料驅動型組織的道路上，資料孤島已成為釋放資料價值的關鍵障礙，主要表現在資料整合與治理、組織運營、數字創新等各個層面。

一、“資料孤島”是什麼?

企業發展到一定階段，必然會跟隨時代發展進行資訊化建設。而資訊化建設的不平衡，催生了“資料孤島”現象的產生。

企業內部通常存在多個事業部，每個事業部都有各自的資料，事業部之間的資料往往都各自儲存，各自定義，形成不同的子系統。而子系統之間並未建立有效的資料交換服務，各業務系統資料描述標準不一，造成嚴重的資料不一致。各個子系統內所儲存佔有的資料，就像一個個孤島，難以和企業內部的其他資料進行連線互動。

這樣的情況就被稱為“資料孤島”現象。簡單來說，就是企業內部的資料間缺乏關聯性，彼此無法相容。

組織中一切活動都會產生資料，但這些海量的資料由於組織戰略、架構設定、數字化建設等原因，分散儲存在組織的各個部門、業務系統、應用之中，彼此無法互聯互通、共享，也無法被利用，形成了一個又一個孤立的資料島嶼。

資料孤島作為數字化轉型的負面產物，已成為一種普遍現象，Forrester調研發現，82%的企業都受到資料孤島的阻礙。

二、“資料孤島”的危害

企業內不同部門資料的“各自為政”，大大制約著企業管理和業務的順暢開展：

1、資料重複：由於資料流通不暢，企業各部門在收集資料時會產生重複行為，造成了資料的重複、冗餘、無效等情況，降低了資料的質量和準確度。

2、錯誤決策：資料的不準確、不及時，往往導致企業決策錯誤或決策遲緩，從而影響企業的口碑和在市場中的競爭地位。

3、協作不良：企業內部資料孤島現象的顯著，會在很大程度上使得企業各個部門、團隊之間，因難以獲取工作需要的資料，而關係緊張、協作不良。

4、效率低下：由於不同部門對資料的理解和定義不同，企業內部的溝通成本上升。同時，各部門對資料的重複管理，造成了時間和金錢的浪費、工作效率的低下。

5、客戶體驗差：企業內各部門擁有的資料不一，容易造成客戶端到端的體驗混雜，總體評價低。

三、為何會產生“資料孤島”現象?

1、以功能為標準的部門劃分導致資料孤島。企業各部門之間相對獨立，資料各自保管儲存，對資料的認知角度也截然不同，最終導致資料之間難以互通，形成孤島。也因此集團化的企業更容易產生資料孤島的現象。

2、缺少企業內資訊化建設的戰略和標準，如果不能做到資訊系統建設的統一，由不同部門，不同公司來建設的話，必須有一個標準能夠使得日後的互通比較容易實現。

3、不同型別、不同版本的資訊化管理系統導致資料孤島。人事部門用OA系統，生產部門用ERP系統，銷售部門用CRM系統，甚至一個人事部門使用一家考勤軟體的同時，卻在同時使用另一家的報銷軟體，後果就是一家企業的資料互通越來越難。

四、企業如何走出資料孤島?

關於事物各個部分之間的關係對整體發展的影響，哲學上也曾給出過確定的解答：“當事物的各部分以有序、合理、最佳化的結構形成整體時，整體的功能將大於各部分功能之和;當各部分以無序、欠佳的結構形成整體時，各部分原有的效能得不到發揮，力量削弱、甚至相互抵消，使整體功能小於各部分之和。”

因此，從長久發展來看，企業應該徹底解決資料孤島現象，讓各部門的資訊資料以合理有序的方式相互連通影響，從而推動企業的發展進步。

為了解決資料孤島的問題，企業進行了很多嘗試。很多企業開始有意識地透過調整資料交換架構來改善資料質量，以打破“資料孤島”、實現業務系統間資料的順暢流動。

然而，實踐表明，企業網狀的資料交換架構和以主資料治理(管理)平臺為中心的資料交換架構都無法徹底地解決資料孤島問題。企業需要既能解決資料的互動流動，又能控制資料質量，並且是控制全部靜態資料(主資料+業務場景資料等)的質量的解決方案。

經過多年的實踐研究發現，基於靜態資料中心的資料交換架構，可以實現這一訴求。

構建基於靜態資料中心的資料治理平臺，並以其為中心構建雪花狀資料交換架構，如圖1所示。

該架構的核心是企業基於資料治理平臺的靜態資料中心，企業所有業務系統的資料流動都要經過該中心的中轉，資料從各業務系統採集過來然後分發出去，同時該靜態資料中心對經其中轉的資料會進行規範化和標準化，確保資料質量，實現資料從源頭到目標消費系統的真正流動，從根本上徹底打通企業內的資料孤島。

該架構中的靜態資料中心對靜態資料的全方位管理可以很好地規避主資料動態性的問題，並且可以透過靜態資料中心實現由企業頂層通覽全域性靜態資料。

該架構對資料質量的控制非常全面，靜態資料中心對靜態資料的全方位管理可以解決包含主資料及業務場景資料的質量問題。

該架構能夠提供多種技術形式的資料交換介面，透過即插即用的方式可以隨時掛接新的業務系統，實現新的資料互動和流動。

另外，資料的源頭(指資料最初的產生地點，一般指某業務系統)是資料流動的起點，也是資料交換架構的核心點，針對資料的源頭的選擇更是打通資料孤島的關鍵點，也決定了整個資料交換架構的佈局。

為了更好地詮釋該資料交換架構針對企業資料管理的適用性，下面具體說明一下不同型別資料來源頭的位置：物資資料的源頭一定是靜態資料中心(資料治理平臺);客戶資料的源頭可以是CRM(如有)也可以是靜態資料中心(資料治理平臺)，供應商資料的源頭可以是SRM(如有)也可以是靜態資料中心(資料治理平臺)等，具體原因如表1所示。

五、基於資料中臺的資料孤島解決方案

部門A為了解決一些大資料問題，採購了廠商X的大資料解決方案，安裝了一個大資料平臺，匯入自己的資料並開發了一些大資料應用，執行得挺不錯。這個時候，部門B也需要解決一些大資料問題，於是試圖採購廠商Y提供的大資料解決方案，但Y的大資料平臺和X的有一些版本、元件上的差異，所以需要對X的大資料平臺進行改造。

問題是，這個任務由誰來完成，由誰負責改造後的大資料平臺的運維?有可能廠商Y的大資料應用也需要做些改造，這可行嗎?部門A的應用已經執行得很好了，部門B的應用會不會對部門A的應用造成影響(包括效能和資料安全的影響)?如果影響了，誰來負責?比較簡單且快速見效的方法是直接安裝廠商Y提供的端到端的解決方案。照此下去，每個解決方案都會安裝一個新的大資料系統。

還有一個問題是，廠商X和廠商Y底層的資料結構可能不是對外公開的，因而它們各自解決自己的問題，雖然開始互不干擾，但是後來就造成了資料孤島和煙囪。這個時候，由於各個子系統的資料標準不一、資料格式不同，各部門之間資料無法互聯互通，很難根據資料做出全域性決策。

解決上面的問題，正是資料中臺方法論和架構的任務。TotalPlatform保證所有資料應用的統一管理，OneID、OneModel確保各子系統中資料的互聯互通，OneService負責資料能力的共享，TotalInsight確保全域性資料運營的高效和價值量化。

1)全域性的資料治理

必須有全域性的資料治理系統來管理所有子系統的資料，確保它們能互聯互通。例如，OneID要求所有關於使用者的資料都必須使用同一個ID，OneModel要求所有資料倉儲的模型都必須符合同樣的標準。

但是這裡要指出，解決資料孤島和應用孤島的問題，除了技術方案以外，明確責權利也很重要。出現孤島的原因之一就是各部門的責權利不明晰。如何在使用資料中臺解決孤島問題的同時保證責權利的明晰，是一個非常重要的問題，我們將在第6章中詳細描述。

2)資料能力的複用和共享

在進行全域性的資料治理的同時，治理的結果必須能為公司創造價值。這個時候就類似於OneService的功能，既要求能進行全域性的資料能力的複用和共享，也需要類似TotalInsight的功能，管理全域性的資料資產，量化資料能力的投入產出。主要的工作如下：

建立資料能力共享的責權利機制;

提供全域性的資料能力目錄和訪問機制;

提供資料能力共享的工具、機制和流程;

對共享的資料能力的管控和審計;

確保共享的資料能力的高效執行。

3)雲原生架構的支撐

在這個階段隨著業務的不斷增長，越來越多的應用程式被新增到大資料系統中。先有Spark、Kafka，後有Flink、TensorFlow，現在又有各種新的大資料和人工智慧元件。

這些就是在雲基礎架構上執行大資料系統的根本原因。而云平臺為分析工作負載和一般工作負載提供了極大支援，並提供了雲端計算技術的所有好處：易於配置和部署、彈性擴充套件、資源隔離、高資源利用率、高彈性、自動恢復。

在雲端計算環境中執行大資料系統的另一個原因是大資料工具的發展。傳統的分散式系統(如MySQL叢集、Hadoop和MongoDB叢集)傾向於處理自己的資源管理和分散式協調，但是現在由於Kubernetes、Mesos、YARN等分散式資源管理器和排程程式的出現，越來越多的分散式系統(如Spark)將依賴底層分散式框架來提供這些資源分配和程式協調排程的分散式操作原語。