数据治理：走出数据孤岛！

数据已成为数字经济的重要生产要素，这意味着，整合更多数据、拥有更强的数据分析和处理能力，以数据资产化、数据服务化、数据知识化驱动业务，将是组织获得核心竞争力的关键。

 

然而，在构建数据驱动型组织的道路上，数据孤岛已成为释放数据价值的关键障碍，主要表现在数据整合与治理、组织运营、数字创新等各个层面。
 

 

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）将依赖底层分布式框架来提供这些资源分配和程序协调调度的分布式操作原语。在这样的统一框架中运行它们将大大降低复杂性并提高运行效率，如下图所示。

 

 

写在最后的话

数据孤岛是企业中与企业的其他部分隔离且无法访问的数据集合，走出数据孤岛可以帮助企业在正确的时间获取正确的数据以便辅助企业做出正确的决策，解决企业数据的不一致问题，提升沟通效率，并帮助企业降低重复数据的存储问题来节约成本。

如何走出数据孤岛？不同的时期，不同的场景可能需要不同的解决方案，您可以选择基于痛点需求的数据集成融合方案，也可以选择大而全的数据中台方案，具体怎么选，需要结合企业的需求，没有最好的只有更合适的。

 

 

来源：大数据架构师

作者：谈数据