企业实时数据服务平台建设最佳实践

在过去的 30 年，企业投入了大量的资金和人力在信息化系统的建设上。这些信息化系统往往是有应用程序和其对应的数据库系统组成一体，互相之间并不联通，渐渐就形成一个个的企业内数据孤岛。而今日的企业，面临激烈的同质化竞争，都在拥抱数字化转型的战略举措，通过数据为企业赋能，产生新的价值，提高用户体验和改善客户留存等。通过数据，企业可以洞察在销售，市场，渠道，运营和生产中的真实情况。数据也可以为数据科学家和机器学习，人工智能提供宝贵的输入，为企业创造更多更大的价值提供可能。

但是，数据孤岛的问题正在成为这些企业数字化转型的一个主要的阻碍。例如，国内某航空公司仅乘客相关的系统就有 80 多套。客户的信息散落在平时互不联通的业务系统内，无论是哪个渠道，都无法的获得某个客户完整的个人信息、行程信息或交互信息。这导致了企业无法提供最好的客服体验，无法做到精准推送等业务场景，直接影响客户留存和销售增值等场景。

除此之外，企业对数据的需求日益增多，传统的数据的交付已经是大多数企业在数据变现方面的最大瓶颈。再加上今日日益复杂的云上云下的生态环境，有效，快速，高效且实时的数据能力，将会是企业竞争力中最重要的因素之一。

当企业需要构建数据驱动的新型业务的时候并且需要获取到已有业务系统的数据时候, 传统的数据解决方案包括：

1. 直接在原有数据库系统上使用

2. 从源库里使用工具将数据导出，再导入到新的库里

3. 为新业务的数据需求，使用 ETL 工具或者编写程序进行数据抽取及同步

4. 如果对数据的时效性要求比较高，通常会使用 CDC + Kafka + Java 代码方式来搭建实时管道

第一种和第二种模式的最大问题有两点：

1. 是对源库的压力增大，影响已有业务的使用；

2. 源库的数据结构通常难以修改（缺乏文档、中断已有业务可能性）。因为如此，所以很少会采用第一种方案；

3. 开发成本比较高，难以协调。

第三种方案，就是在每一个新的业务需要的时候, 就去从各个源系统进行一次性或者定期的抽取，这种方式的不足点有：

1. 复用不足，每次新的业务都需要进行 ETL 开发；

2. 对有实时数据需求的场景支持不足；

3. ETL 通常使用脚本或者零星的工具完成，无统一管理，容易出错。

第四种基于 Kafka 的方案，是针对实时数据场景较为常见的解决方案，其有以下特点及不足点：

1. 通常需要采购一个额外的 CDC 工具或者侵入式修改原来的业务代码来推送实时数据到 Kafka；

2. 目标端依然需要使用 Java 代码来拉取数据；

3. 整体的开发和维护成本较高。

随着流处理数据技术的成熟, 企业对数据快速交付, 实时交付, 灵活交付的需求越来越明显传统的应用及架构无法满足企业数据需求, 但是由于这些应用仍然在支撑着企业的核心运营业务, 我们无法在短时间内对它们进行革新换代一个新的思路就是使用数据实时同步+实时数据处理+实时数据发布的新一代数据平台, 在保留原有系统基础上, 构建一个高度一致的数据镜像 , 并采用主数据管理技术, 形成企业的完整、准确、可信的统一数据模型，结合无代码发布及实时推送方式，将数据发布到下游业务系统。