共计 3883 个字符，预计需要花费 10 分钟才能阅读完成。
数据已成为数字经济的重要生产因素，这意味着，整合更多数据、领有更强的数据分析和解决能力，以数据资产化、数据服务化、数据知识化驱动业务，将是组织取得外围竞争力的要害。
然而，在构建数据驱动型组织的路线上，数据孤岛已成为开释数据价值的要害阻碍，次要体现在数据整合与治理、组织经营、数字翻新等各个层面。
数据孤岛”是什么
企业倒退到肯定阶段，必然会追随时代倒退进行信息化建设。而信息化建设的不均衡，催生了“数据孤岛”景象的产生。
企业外部通常存在多个事业部，每个事业部都有各自的数据，事业部之间的数据往往都各自存储，各自定义，造成不同的子系统。而子系统之间并未建设无效的数据交换服务，各业务零碎数据形容规范不一，造成重大的数据不统一。各个子系统内所存储占有的数据，就像一个个孤岛，难以和企业外部的其余数据进行连贯互动。
这样的状况就被称为“数据孤岛”景象。简略来说，就是企业外部的数据间不足关联性，彼此无奈兼容。
组织中所有流动都会产生数据，但这些海量的数据因为组织策略、架构设置、数字化建设等起因，扩散存储在组织的各个部门、业务零碎、利用之中，彼此无奈互联互通、共享，也无奈被利用，造成了一个又一个孤立的数据岛屿。
数据孤岛作为数字化转型的负面产物，已成为一种普遍现象，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）将依赖底层分布式框架来提供这些资源分配和程序协调调度的分布式操作原语。在这样的对立框架中运行它们将大大降低复杂性并进步运行效率，如下图所示。
数据孤岛是企业中与企业的其余局部隔离且无法访问的数据汇合，走出数据孤岛能够帮忙企业在正确的工夫获取正确的数据以便辅助企业做出正确的决策，解决企业数据的不统一问题，晋升沟通效率，并帮忙企业升高反复数据的存储问题来节约老本。
如何走出数据孤岛？不同的期间，不同的场景可能须要不同的解决方案，您能够抉择基于痛点需要的数据集成交融计划，也能够抉择大而全的数据中台计划，具体怎么选，须要联合企业的需要，没有最好的只有更适合的。
