陈雷 | DataPipeline 合伙人 & CPO，曾任 IBM 大中华区认知物联网实验室服务部首席数据科学家、资深参谋经理。十五年数据迷信畛域与金融畛域教训。综合交通大数据利用技术国家工程实验室产业翻新部主任，中国电子学会区块链专委会委员。
DataPipeline 是一家数据畛域的独立软件提供商。已胜利服务了包含但不限于星巴克、百胜中国、民生银行、中国人寿等重点畛域的近百家客户。
10 月 20 日，IT 桔子邀请到 DataPipeline 合伙人 & CPO 陈雷先生，面向 IT 桔子用户带来“企业实时数据管理问题与实际”为主题的分享，以下为本次流动的干货观点。（文末附 PPT 下载地址）
为什么要构建实时数据平台
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 InfoSphereData Replication 的产品来采集包含大型机、中型机（AS400 零碎）的数据库日志。针对支流的 MySQL、MS SQL Server 等数据库都能够应用日志解析的形式获取数据。当然，基于日志的实时增量获取也不是繁多的品种，例如 MS SQL Server 有两种实时增量获取模式：CT 模式和 CDC 模式。
IT 零碎的麻利开发
多源异构的增量数据精确获取问题解决当前，接下来须要解决的第二个问题，疾速反对 IT 零碎的麻利开发。
咱们将整个实时数据交融平台解构为数据节点、数据链路、交融工作与系统资源四个逻辑概念，通过对数据节点注册、数据链路配置、交融工作构建、零碎资源分配等各个环节进行分层治理，在无效地满足零碎运维治理需要的前提下，晋升实时数据获取与治理在各个环节的配合效率。
数据节点 ，数据节点是数据的原始载体。数据节点能够是数据库、文件系统、数据仓库、文件、利用，所有存储数据的载体都能成为数据节点。在数据交融过程中，数据节点既能够做数据源节点也能够做数据目的地节点，在通过数据节点治理注册一个数据节点时，它是没有被调配角色的，数据链路的存在才会赋予相干数据节点「数据源节点」和「数据目的地节点」的角色属性。
数据链路 ，数据链路是对实时数据交融过程的逻辑形容，既形容了具体业务场景波及到的数据对象关系，也形容了在执行具体数据交融工作时须要遵循的限度与策略。
在数据交融过程中，数据链路作为分隔数据管理与数据利用的逻辑档次，既爱护了数据节点的平安、稳固与数据语义的统一、精确、残缺，也保障了数据交融过程中的监控、日志、预警等根底运维工作遵循企业整体的信息化管理机制。
交融工作 ，交融工作是实时数据交融的最小治理单位。交融工作通过抉择数据链路确定要执行的具体数据交融内容及根本规定，在保障数据资源可控的前提下，交融工作为数据利用提供更多的自主性。理论应用数据的业务部门或利用开发人员能够自主抉择数据获取的范畴、交融工作的生命周期、系统资源投入的多寡。在遵循数据链路配置的根底上，能够自行定义主动重启策略、预警策略、日志策略、读取限度、写入限度、传输队列限度等配置选项。
系统资源 ，系统资源是零碎平台及交融工作执行的载体。系统资源即是指执行交融工作的交融引擎所应用的资源组，同时也是指保障整个零碎失常运行的各个功能模块所应用的系统资源。在数据交融过程中，交融工作只有关怀执行工作所需的系统资源是否满足性能、效率等影响数据时效性的系统资源即可，而音讯队列、谬误数据存储、日志存储、预警存储乃至平台配置长久化等功能模块所应用的系统资源则由治理数据链路的数据工程师与管理系统资源的运维工程师对立治理即可。
为什么要把数据工作和数据链路拆分呢？业务部门 / 数据应用方不关注数据是怎么映射的，更关注的是什么工夫点用什么形式能够获取什么样的数据，是全量数据还是实时的变动数据能够获取到，是定时模式还是监听模式，执行的时候要不要帮我清空，这些是数据应用方比较关心的内容。DBA 和数据链路的保护方和数据应用方之间，能够通过数据工作、数据链路和数据节点这三个逻辑概念来拆分分明各自应该负责的内容。
DBA 能够把日常所用到的全企业域内的所有数据节点迅速地定义到平台，数据组就能够基于这些数据节点，依照业务部门的需要或者 IT 零碎的布局，把相应的数据链路进行配置，如映射规定、链路执行策略、日志策略、预警策略、配置策略。数据应用方能够基于曾经配置好的数据链路，依照本人的需要，在适合的工夫用适合的形式获取适合的数据。这样，实时数据交融参加的各方都能够通过无代码配置的形式疾速地实现各自的工作与管理控制要求。
IT 零碎的稳固、高容错性
在反对了 IT 零碎的麻利多速开发要求之后，咱们再来一起关注一下零碎的稳固、高容错性如何做到。
数据链路构建胜利后，其运行的容错性和稳定性如何保障？实时数据链路受数据链路上上游节点和运行时的影响。咱们须要给到实时数据链路无效地、合乎用户预期的相应解决策略和规定。比方上游产生了数据结构变动，针对数据链路的上游应该执行什么模式？如果是十分重要的数据，构造不应该失落，能够让工作停下来。但并不是每一个数据工作都应该停下来，数据工作都停下来可能会影响业务推动，这时就能够为链路预设一些规定，比方当上游数据库的表减少或者缩小了字段的时候，能够把这些变动同步到上游，为用户提供一个选项是暂停工作、疏忽变动或者利用变动。
另外，大略有 5% 的 IT 系统故障是找不到起因的，且通过重启的形式就能够天然复原，DataPipeline 平台也反对主动重启模式。但在分布式系统中，某些状况下的频繁重启会导致状况越来越糟。因而，DataPipeline 会预设一些规定，通知用户在遇到某些故障时不倡议主动重启，应该停下来解决故障。
在数据节点、数据链路、数据工作上预设的策略配置和限度配置有几十种，能够无效的帮忙用户应答可能在数据链路执行过程中呈现的各种已知或未知状况。
除了在零碎预设策略晋升容错性以外，DataPipeline 实时数据交融平台采纳分布式引擎，零碎组件与计算组件都通过严格的高可用测试，反对组件级高可用，保障了整体的容错性，同时能够十分动静灵便地做扩缩容，容许不同的计算工作从新散布到不同的机器上，而不影响其余局部的运行。
下图左侧是在 DataPipeline 分布式集群中，当某个节点呈现问题的时候，残余的节点就能够把相应的工作接管过去持续运行。当两头的节点复原的时候被从新注册了进来，这时能够抉择两个不同的策略，如果另外两台机器的负载曾经很高了，有新的节点被注册进来，要做一次重均衡，把这六个工作再从新均匀分布进来。另外一种策略是，两个节点运行的累赘还在现实范畴内，能够继续运行上来就能够不做重均衡，而是等到有新的工作产生再被调配，因为重均衡也是很耗费系统资源的。
在分布式集群的根底上，DataPipeline 反对通过划分独立资源组形式，确保高优先级的工作可能稳固、高效运行，比方有一些跟客户无关的数据工作，对其数据处理效率有很高的要求，就能够独立划分出一个资源组，不让其余的交融工作来抢占系统资源。
DataPipeline 基于日志 CDC 技术突破各类纷繁复杂的数据技术壁垒，通过数据语义的各种映射解决多源异构问题，帮忙企业突破因为采纳不同数据库技术而导致的数据交融壁垒问题。通过数据节点、数据链路、数据工作和系统资源来保障不同的角色能够在平台上无效地分工合作。通过低代码配置形式，晋升数据链路尤其是实时数据链路的敏捷性，能在 5 分钟之内构建出一个实时数据链路。最初，通过各类的预设规定和分布式架构的高容错性，来保障整个零碎稳固失常的运行。
获取完整版 PPT，请关注公众号 DataPipeline 并回复关键词“陈雷”。