本文來自數據學堂。

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

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

01“數據孤島”是什么？

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

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

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

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

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

02“數據孤島”的危害

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

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

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

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

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

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

03為何會產生“數據孤島”現象？

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

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

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

04企業如何走出數據孤島？

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

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

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

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

經過多年的實踐研究發現，基于靜態數據中心的數據交換架構，可以實現這一訴求。構建基于靜態數據中心的數據治理平臺，并以其為中心構建雪花狀數據交換架構，如圖1所示：

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

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

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

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

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

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

05基于數據中臺的數據孤島解決方案

部門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）將依賴底層分布式框架來提供這些資源分配和程序協調調度的分布式操作原語。在這樣的統一框架中運行它們將大大降低復雜性并提高運行效率，如下圖所示。

寫在最后的話

數據孤島是企業中與企業的其他部分隔離且無法訪問的數據集合，走出數據孤島可以幫助企業在正確的時間獲取正確的數據以便輔助企業做出正確的決策，解決企業數據的不一致問題，提升溝通效率，并幫助企業降低重復數據的存儲問題來節約成本。

如何走出數據孤島？不同的時期，不同的場景可能需要不同的解決方案，您可以選擇基于痛點需求的數據集成融合方案，也可以選擇大而全的數據中臺方案，具體怎么選，需要結合企業的需求，沒有最好的只有更合適的。