10 月 20 日，IT 桔子邀请到 DataPipeline 合伙人 & CPO 陈雷先生，面向 IT 桔子用户带来「企业实时数据管理问题与实践」为主题的分享。
DataPipeline 是一家数据领域的独立软件提供商。已成功服务了包括但不限于星巴克、百胜中国、民生银行、中国人寿等重点领域的近百家客户。
陈雷 | DataPipeline 合伙人 & CPO，曾任 IBM 大中华区认知物联网实验室服务部首席数据科学家、资深顾问经理。十五年数据科学领域与金融领域经验。综合交通大数据应用技术国家工程实验室产业创新部主任，中国电子学会区块链专委会委员。
以下为本次活动的干货观点：
为什么要构建实时数据平台？
2000 年左右甚至更早一些，我们的交易系统和分析系统是不分家的。随着业务需求的不断提升，对 7*24 小时联机交易的要求，交易系统服务压力越来越大。为了避免分析系统影响交易系统，逐渐从业务系统中分离出了分析系统，OLTP（联机事务处理）和 OLAP（联机分析处理）两类系统概念就此产生。同时产生了两个概念，一个是 ODS（把交易系统里的全部原始数据复制一份出来，然后在 ODS 上做各种加工、处理与分析）；另外一个是 Data Mart（数据集市，按照业务实际需求要把要分析的部分数据从交易系统中取出来做整理）。
ODS 和数据集市都是基于核心业务系统/交易系统的数据模型和数据规范的，随着业务的不断发展，交易系统也要不断进行迭代，而当交易系统升级换代的时候，ODS 和数据集市都要被推翻重建。面对高昂的建设费用和剧烈的系统震荡，大家发现建立一个相对独立而全面的数据仓库是一个非常有效的解决方式。
随着存储和计算资源的成本越来越低，计算能力和计算要求都在不断的发展，是否还需要一个中心化的数据仓库的质疑甚嚣尘上。因为数据仓库通常采用 T+1 批量加载数据的方式处理数据，时效性不够高，很难满足业务上越来越高的时效性要求，除此之外，大量的外部数据无法整合，大数据平台随之应运而生。随着各行业数据量高速增长，逐渐形成数据湖的概念 [数据湖的概念也随之形成]。数据可以先进到数据湖，按需取用。
随着技术演进，数据仓库、数据集市、ODS、大数据平台和数据湖等都归类到了非实时数据处理分析系统里面。近几年，由于业务对时效性的要求越来越高，分布式计算、流计算兴起，实时数据融合逐渐被推动起来。当前获取数据模式，要求在不影响业务系统正常运行的情况下实现实时、准确、全面的数据获取。可以在同一个平台上对数据进行加工、融合以及计算，然后推送到下游的实时应用系统。
以上内容就是为什么要构建一个实时数据平台的发展理念。
实时数据领域三大常见问题
2000 年左右，一家大型企业所应用数据库类型比较少，从品牌角度讲，Oracle、IBM DB2、Sybase、MS SQL Server 是应用比较多的，但哪怕是多个品牌，也基本上都是关系型数据库。而数据技术发展到今天，从全球范围来看，能归类到数据库的技术品牌有 200 余种，包括传统的关系型的数据库、时序数据库、图数据库、搜索引擎、消息队列、大数据平台与对象存储等，主流的数据库就有 40 多种。
随着业务的不断发展，为了应对不同的应用场景，交易系统、账务系统、管理系统等会采用不同的数据库技术，无形中构建了大量的技术壁垒。而数据本身在一个企业域内都是独一无二的，是需要相互融合的。在不断发展的数据技术和每种技术的差异性逐步增大的过程中，如何能够打破技术壁垒，让数据不会因为技术栈的选择而阻碍其价值释放，是今天摆在我们面前的一个主要问题。
无论是技术人员还是互联网从业者，都能明显感觉到用户的交互时间越来越短，注意力经济越来越凸显，谁能抓住用户注意力谁就能获得相应的流量和回报。在这个过程中如何能够在较短的交互时间里抓住用户的注意力，整个实时数据链路打通至关重要。但是这又跟实际的研发管理、IT 的数据管理有天然的一些矛盾。研发管理需要进行开发、测试、上线等整套流程，而业务则要求数据要有更高的敏捷性。多数的 IT 管理系统对敏捷的业务场景的支撑、数据融合或者底层的数据集成反而成为了阻碍。一个端到端的实时链路，一般的交付周期以月为单位。同时，十几种甚至几十种数据技术混合使用，存储于其间的数据如何能够快速的构建链路？能够把增量数据、全量数据进行有效的融合，成为了 IT 部门核心要解决的问题。
把不同的技术壁垒打通之后，紧接着需要构建数据融合平台。实时数据链路兼具着业务运营和后台业务分析、管理的作用，需要具备非常高的稳定性、容错性来应对外部组织结构的变化和内部对平台的要求。当数据融合本身非集中式时，一定会受到数据链路、上游系统、下游系统的影响。上游系统是重要程度更高的业务系统。上游数据结构的变化以及数据的大规模处理不会过多顾及下游数据链路的实际情况。例如上游一个简单的更新操作，对下游系统可能造成百万、千万级别的增量数据。下游系统的稳定性不仅仅源于自身的稳定性，更多是通过一些预设规则有效地应对上游系统带给它的影响。当上下游系统都稳定了，运行在底层的系统，如网络环境、存储环境、CPU 内存等环境也会影响到整个系统运行的稳定性。此时，就需要考虑跨网传输/大规模的数据链路如何屏蔽以上不稳定因素。
总结，企业在实施数据管理过程中碰到的三项主要问题。第一个问题，当越来越多的数据库技术应用在企业内部，出现了大量的技术壁垒，我们如何打破这些技术壁垒，把数据做有效融合驱动业务的发展。第二个问题，业务部门对数据处理的时效性要求变得越来越高，但数据处理实时应用的构建过程依然需要一个科学严谨的构建逻辑，业务部门对数据时效性的要求和 IT 部门构建高质量数据链路的效率之间的平衡。最后，实时数据链路构建起来后，因为其兼具业务运营和管理支持的要求，所以稳定性和容错性的要求很高，而这个过程中又受上下游系统及系统环境的制约，如何保证高效稳定的运行，保证高容错性应对各种突发状况。
实时数据管理的主要问题、如何应对
下图展示的是一个标准的金融行业企业级实时数据平台的整体架构。它的上游是存储于不同的数据库技术或外部数据节点的数据，DataPipeline 可以通过不同的技术栈把这些数据融合到平台里面来，然后再推送到下游的各类业务系统中。
近二十年来，数据源类型发生了巨大变化。早期整合的数据大部分都是业务系统数据，企业域内的数据会比较多。而现在，需要整合的数据不仅增加了大量的非结构化数据，而且大量来源于外部。
除了业务系统数据，还有客户行为数据、电子设备、APP、摄像头、传感器等的客户端数据也会进入到实时数据链路，而且这一类实时数据的分析价值非常高。
如今每家企业都会关注其整个产业链的上下游。大量合作伙伴，除了在生意层面的合作，还有 IT 系统之间的合作。这就要求实时数据处理平台，能够应对外部业务系统的实时增量和全量数据的融合。
企业还在采集大量的外部数据，例如天气数据、资讯数据等，这些数据如何有效地进入到企业域内进行整合，进入实时数据链路如何发挥作用，也是一个企业在构建实时数据平台需要关注、解决的问题。
每一项数据源采用的数据库技术/数据处理技术可能都不尽相同，因此涉及到多源异构数据处理问题。如何在不影响系统正常运行的前提下获取全域实时 [全面实时的] 数据。这里我们就要谈到 Log Base Change Data Capture 概念，它是 DataPipeline 自主研发的基于日志增量数据获取技术。我们现在也在与 IBM 合作，集成 IBM InfoSphere Data Replication 的产品来采集包括大型机、中型机（AS400 系统）的数据库日志。针对主流 的 MySQL、MS SQL Server 等数据库都可以使用日志解析的方式获取数据。当然，基于日志的实时增量获取也不是单一的种类，例如 MS SQL Server 有两种实时增量获取模式：CT 模式和 CDC 模式。
多源异构的增量数据准确获取问题解决以后，接下来需要解决的第二个问题，快速支持 IT 系统的敏捷开发。
我们将整个实时数据融合平台解构为数据节点、数据链路、融合任务与系统资源四个逻辑概念，通过对数据节点注册、数据链路配置、融合任务构建、系统资源分配等各个环节进行分层管理，在有效地满足系统运维管理需求的前提下，提升实时数据获取与管理在各个环节的配合效率。
数据节点，数据节点是数据的原始载体。数据节点可以是数据库、文件系统、数据仓库、文件、应用，一切存储数据的载体都能成为数据节点。在数据融合过程中，数据节点既可以做数据源节点也可以做数据目的地节点，在通过数据节点管理注册一个数据节点时，它是没有被分配角色的，数据链路的存在才会赋予相关数据节点「数据源节点」和「数据目的地节点」的角色属性。
数据链路，数据链路是对实时数据融合过程的逻辑描述，既描述了具体业务场景涉及到的数据对象关系，也描述了在执行具体数据融合任务时需要遵循的限制与策略。
在数据融合过程中，数据链路作为分隔数据管理与数据应用的逻辑层次，既保护了数据节点的安全、稳定与数据语义的一致、准确、完整，也保证了数据融合过程中的监控、日志、预警等基础运维工作遵循企业整体的信息化管理机制。
融合任务，融合任务是实时数据融合的最小管理单位。融合任务通过选择数据链路确定要执行的具体数据融合内容及基本规则，在保障数据资源可控的前提下，融合任务为数据应用提供更多的自主性。实际使用数据的业务部门或应用开发人员可以自主选择数据获取的范围、融合任务的生命周期、系统资源投入的多寡。在遵循数据链路配置的基础上，可以自行定义自动重启策略、预警策略、日志策略、读取限制、写入限制、传输队列限制等配置选项。
系统资源，系统资源是系统平台及融合任务执行的载体。系统资源即是指执行融合任务的融合引擎所使用的资源组，同时也是指保障整个系统正常运转的各个功能模块所使用的系统资源。在数据融合过程中，融合任务只要关心执行任务所需的系统资源是否满足性能、效率等影响数据时效性的系统资源即可，而消息队列、错误数据存储、日志存储、预警存储乃至平台配置持久化等功能模块所使用的系统资源则由管理数据链路的数据工程师与管理系统资源的运维工程师统一管理即可。
为什么要把数据任务和数据链路拆分呢？业务部门/数据使用方不关注数据是怎么映射的，更关注的是什么时间点用什么方式可以获取什么样的数据，是全量数据还是实时的变化数据可以获取到，是定时模式还是监听模式，执行的时候要不要帮我清空，这些是数据使用方比较关心的内容。DBA 和数据链路的维护方和数据使用方之间，可以通过数据任务、数据链路和数据节点这三个逻辑概念来拆分清楚各自应该负责的内容。
DBA 可以把日常所用到的全企业域内的所有数据节点迅速地定义到平台，数据组就可以基于这些数据节点，按照业务部门的需求或者 IT 系统的规划，把相应的数据链路进行配置，如映射规则、链路执行策略、日志策略、预警策略、配置策略。数据使用方可以基于已经配置好的数据链路，按照自己的需求，在合适的时间用合适的方式获取合适的数据。这样，实时数据融合参与的各方都可以通过无代码配置的方式快速地完成各自的任务与管理控制要求。
在支持了 IT 系统的敏捷多速开发要求之后，我们再来一起关注一下系统的稳定、高容错性如何做到。
数据链路构建成功后，其运行的容错性和稳定性如何保证？实时数据链路受数据链路上下游节点和运行时的影响。我们需要给到实时数据链路有效地、符合用户预期的相应处理策略和规则。比如上游发生了数据结构变化，针对数据链路的下游应该执行什么模式？如果是非常重要的数据，结构不应该丢失，可以让任务停下来。但并不是每一个数据任务都应该停下来，数据任务都停下来可能会影响业务推进，这时就可以为链路预设一些规则，比如当上游数据库的表增加或者减少了字段的时候，可以把这些变化同步到下游，为用户提供一个选项是暂停任务、忽略变化或者应用变化。
另外，大概有 5% 的 IT 系统故障是找不到原因的，且通过重启的方式就可以自然恢复，DataPipeline 平台也支持自动重启模式。但在分布式系统中，某些情况下的频繁重启会导致情况越来越糟。因此，DataPipeline 会预设一些规则，告诉用户在遇到某些故障时不建议自动重启，应该停下来处理故障。
在数据节点、数据链路、数据任务上预设的策略配置和限制配置有几十种，可以有效的帮助用户应对可能在数据链路执行过程中出现的各种已知或未知情况。
除了在系统预设策略提升容错性以外，DataPipeline 实时数据融合平台采用分布式引擎，系统组件与计算组件都经过严格的高可用测试，支持组件级高可用，保证了整体的容错性，同时可以非常动态灵活地做扩缩容，允许不同的计算任务重新分布到不同的机器上，而不影响其他部分的运行。
下图左侧是在 DataPipeline 分布式集群中，当某个节点出现问题的时候，剩余的节点就可以把相应的任务接管过来继续运行。当中间的节点恢复的时候被重新注册了进来，这时可以选择两个不同的策略，如果另外两台机器的负载已经很高了，有新的节点被注册进来，要做一次重平衡，把这六个任务再重新均匀分布出去。另外一种策略是，两个节点运行的负担还在理想范围内，可以持续运行下去就可以不做重平衡，而是等到有新的任务产生再被分配，因为重平衡也是很消耗系统资源的。
在分布式集群的基础上，DataPipeline 支持通过划分独立资源组方式，确保高优先级的任务能够稳定、高效运行，比如有一些跟客户有关的数据任务，对其数据处理效率有很高的要求，就可以独立划分出一个资源组，不让其他的融合任务来抢占系统资源。
DataPipeline 基于日志 CDC 技术打破各类纷繁复杂的数据技术壁垒，通过数据语义的各种映射解决多源异构问题，帮助企业打破由于采用不同数据库技术而导致的数据融合壁垒问题。通过数据节点、数据链路、数据任务和系统资源来保证不同的角色可以在平台上有效地分工合作。通过低代码配置方式，提升数据链路尤其是实时数据链路的敏捷性，能在 5 分钟之内构建出一个实时数据链路。最后，通过各类的预设规则和分布式架构的高容错性，来保障整个系统稳定正常的运行。
-End-
