关于数据库:Kafka-ETL-之后我们将如何定义新一代实时数据集成解决方案

上一个十年，以 Hadoop 为代表的大数据技术倒退热火朝天，各种数据平台、数据湖、数据中台等产品和解决方案层出不穷，这些计划最罕用的场景包含对立汇聚企业数据，并对这些离线数据进行剖析洞察，来达到辅助决策或者辅助营销的目标，像传统的 BI 报表、数据大屏、标签画像等等。

但企业中除了这样的剖析型业务（OLAP），还同时存在 对数据实时性要求更高的交互型业务场景（OLTP 或 Operational Applications），例如电商行业常见的对立商品或订单查问、金融行业的实时风控、服务行业的客户 CDP 等，这些场景对企业来说往往都是要害工作类型。

除了 OLTP 场景，很多 新一代的经营型剖析 （Operational Analytics）也在逐步成为支流数据利用，经营剖析的特点是同样 须要来自业务零碎的最新的实时数据，以帮忙客户做一些较为及时的业务响应。

针对这些交互式 APP 或者经营剖析的场景，传统的大数据平台因为其对实时数据反对度无限，无奈予以无效撑持。明天咱们就来探讨对于实时数据的问题：

• 什么是实时数据？
• 如何获取实时数据，目前有哪些解决方案？别离是怎么解决问题的？有什么利弊？
• 一个现实的实时数据架构应该具备哪些特色？
• 如何利用新一代实时架构，对传统解决方案进行降级或替换？

一、什么是实时数据

一般来说，实时数据指的是对数据的传输、解决或最初交付产生在数据刚产生的短暂霎时，如实时同步、实时音讯解决等。用来掂量实时的指标是 数据从产生端到生产端的传输时延 。另外一种实时数据，则指的是对查问或者计算的响应是否足够疾速，更多针对于数据库的内建剖析或者查问引擎。这种实时数据技术的掂量指标是 响应工夫 。 如果传输时延或者响应工夫可能管制在亚秒或者数秒内，咱们能够称这些技术是”实时数据”技术。 从用户的角度看，他们可能感触到的是一个“交互”式的体验，例如我执行一次查问，或者调取一个最新统计数字，后果通常在 1-3 秒之内返回，就是一种较为理想的实时体验。

如果咱们把实时数据技术放到一个数据架构的残缺幅员外面，可能更容易来了解实时数据到底意味着什么。A16Z 的 Matt Bornstein 在 Emerging Architectures for Modern Data Infrastructure 这篇文章里，很好地演绎了新一代数据基础架构的次要组成部分。他把数据基础架构全生命周期分成了几个阶段: Ingestion, Storage, Query & Processing, Transformation, Analysis & Output。

以这个框架作为参考，咱们能够做一个离线数据技术和实时数据技术的比照：

如图所示，实时数据蕴含了 实时采集同步、实时计算、实时存储、实时查问和服务等 领域。在理论工作中，这些技术撑持的场景案例别离如下：

实时采集同步 / 实时集成

以 数字化防疫场景 为例，疫情防控非凡阶段，“核酸码”、“衰弱码”已成日常出行的必需品，特地是在核酸检测频率较高的期间，因检测结果显示不及时而影响日常工作生存的状况亘古未有。而应答这一问题的外围环节，就是核酸检测数据的实时、精准采集。

实时计算

以 数据可视化大屏 的利用场景为例，作为传统制造业实现数字化转型的常见辅助工具，实时产能大屏能够为实现自动化生产提供数据根据；实时监控运行状况，及时预警；帮忙企业剖析产品周期，实现精准洞察，辅助业务开辟。而实现这些指标的根底就是实时数据——通过对全副零碎数据的实时采集、实时计算，让数据分析展现更高效。

实时剖析

以 金融行业的反欺诈平台 为例，随着用户体量一直增大，客户历史行为数据也在继续累积，为了在数据分析解决的同时不对交易行为产生影响，新时代的风控工作面临着更多实时性挑战，传统数仓架构逐步无奈满足相应需要。因而，须要联结多渠道体现，对客户行为数据进行实时剖析与反馈，疾速辨别欺诈交易与失常交易，助力疾速决策。

实时查问、服务

银行个贷、互金小额贷、保险等在线金融业务须要对客户进行 实时危险管控。通过实时数据服务，能够将来自于金融零碎和内部零碎（信用、司法、公安等）的集体数据进行对立汇聚，在申请流程中实时查问客户的危险信息并提供给算法引擎做决策。

二、实时数据技术之源：实时数据集成

无论是哪一种实时数据处理技术，都离不开一个事实：咱们须要有实时的数据起源。Doris 作为一个实时数仓，只有获取到第一工夫的陈腐数据，能力得出即时无效的洞察；Flink 的实时流计算，须要 Kafka 为其供数；而 Kafka 作为音讯队列，须要用户本人负责将源头数据推到 Kafka 的 Topic。能够说，所有的实时数据技术，都离不开源头——实时数据的获取和集成。

实时数据的集成，常见的技术计划有以下几种：

• 定制 API 集成或者应用低代码 API
• ETL 工具
• ESB 或者 MQ
• Kafka

咱们别离来看看这几种解决方案的 Pros & Cons。

API、ETL 和 ESB

API 集成 是一个不须要第三方工具的解决方案。通常能够由研发团队依照数据共享的诉求，定制开发相应的 API 接口，测试上线来反对上游业务。

这种形式的 Pros：

• 无需购买商业计划，就地制宜
• 能够高度定制

Cons 也比拟显著：

• 需要变多时，开发成本会比拟高，API 的治理也会出新的问题
• 对源库性能有不小的影响，这是外围业务零碎个别不能容忍的
• API 形式不太适宜有全量或者大量数据交付的场景

ETL 是通过抽取的形式将须要的数据复制到上游的零碎内。取决于需求量，能够通过本人写一些定期运行的脚本，或者应用一些成熟的 ETL 工具来实现。

Pros：

• 对源库性能影响较小，能够安顿在业务低峰如中午执行
• 实现绝对简略，也能够有很多的开源或者商业工具

Cons：

• 定期执行，无奈撑持对数据时效性要求比拟高的场景
• ETL 无奈复用，每个新起业务都须要不少数量的 ETL 链路，导致数量激增，治理艰难

ESB 作为一个企业数据总线，通过一系列的接口标准，将独立的软件系统以一个地方总线形式连贯在一起。每个零碎如果须要将数据或者消息传递给另外一个零碎，能够通过 ESB 进行直达。ESB 的架构劣势体现在：

• 移除了多个零碎之间进行两两交互的反复工作
• 升高了零碎之间的对接老本，都只须要和规范的 ESB 中间件交互就够了
• 数据实时可达

然而 ESB 曾经被证实是“明日黄花”，它次要的锅在于：

• 接口定义异样繁琐
• 性能较低，无奈撑持新一代大量的实时数据处理诉求
• 和零碎耦合比拟高，更新一个上游零碎可能会影响到上游零碎
• 老本较高，只有商业化计划

明天的支流：Kafka ETL

十年前，随着大数据技术的倒退，一个叫做 Kafka 的消息中间件开始流行起来，并疾速在实时数据集成畛域占据架构主导地位。作为最支流的音讯事件平台代表，Apache Kafka 最后只是一个分布式的日志存储。起初逐步减少了 Kafka Connect 和 Kafka Streams 性能。基于这些能力，咱们能够用 Kafka 来搭建一个实时 ETL 链路，满足企业内业务零碎之间数据实时集成的需要。

然而这种基于 Kafka 来做实时 ETL 的架构，有余点非常明显：

• 须要本人对接、实现数据采集的能力，很多时候意味着利用双写（代码侵入！）或额定的开源组件
• 须要 Java 代码开发，超出个别数据工程师的能力范畴
• 节点多、链路长、数据容易中断、排查不容易

DaaS：以服务化的形式来解决数据集成的问题

总结下来，已有的技术计划在肯定水平上满足需要的前提下，都有一些明确的痛点：

• API 开发太繁琐，对源端性能侵入影响高
• ETL 实时性不够，无奈无效复用，造成意大利面的摊子
• ESB 有地方化的劣势，太贵性能太弱，曾经 out
• Kafka 架构简单，开发成本不低，要害数据排错很艰难

DaaS（Data as a Service，数据即服务）是一种新型的数据架构，通过将企业的外围数据进行物理或者逻辑的汇总，而后通过一个标准化的形式为上游提供数据的撑持，如下图所示：

这种架构的劣势是：

• 数据地方化，能够在一个中央为多个业务提供数据，充沛进步数据复用能力
• 接口标准化
• 数据采集只须要一次性实现，联合元数据管理技术，为企业构建一个全面的数据目录，能够疾速发现须要的数据
• 解耦：数据的入库和数据服务离开，不会产生耦合

然而传统的 DaaS 解决方案，如数据中台这样的实现，有一个很大的局限就是数据的入库是通过批量采集形式，导致数据不够陈腐实时，间接影响了传统 DaaS 的业务价值。

三、新一代 DaaS 计划：自带实时 ETL 的数据服务平台

瞻望新的十年，基于齐全自主研发的新一代实时数据平台「Tapdata Live Data Platform」应运而生，作为一个实现 DaaS 架构的新型数据平台，Tapdata LDP 的外围突破点是本人 实现了残缺的基于 CDC 的异构数据实时集成 + 计算建模的能力，通过源源不断对数十种源数据库实时采集并输送到 DaaS 存储的形式，确保数据在 DaaS 里始终失去实时更新，实现了一个 Incremental DaaS，增量数据服务平台的理念。通过这种对 DaaS 的实时加强，Tapdata 将承载着将企业 ETL 数量从 N 降为 1 的使命，凭借“全链路实时”的核心技术劣势，减速连贯并对立数据孤岛，打造一站式的实时数据服务底座，为企业的数据驱动业务“Warehouse Native”提供全面、残缺、精确的陈腐数据撑持。

性能个性

• 首个同时反对 TP 和 AP 业务场景的实时数据平台
• 两大核心技术能力：实时数据集成（ETL) 和 实时数据服务（DaaS）
• 独创以 DaaS 形式解决实时数据集成问题，数倍升高 ETL 链路数量
• 40+ 数据源的实时复制能力，立刻买通企业数据孤岛
• 多流合并、简单宽表构建等实时流计算能力
• 面向程序员：独创 Fluent ETL，用代码而不是 SQL 来解决数据
• 面向数据工程师：全程可视化，利落拽实现开发建模
• 凋谢 + 开源，应用 PDK 自助扩大更多对接和解决能力，在收费取得实时能力同时回馈社区

实时利用场景

• 实时数据管道 ：Tapdata 能够用来 替换 CDC + Kafka + Flink，几分钟疾速构建残缺的数据采集 + 流转的管道，避开 CDC 数据采集易错、Kafka 阻塞、链路排查艰难等大坑小坑。
• 实时 ETL：Tapdata 能够用来 替换 Kettle / Informatica 或 Python 这样的 ETL 工具或脚本。基于 JS 或 Python 的 UDF 性能能够有限扩大解决能力；分布式部署能力能够提供更高的解决性能；基于利落拽的新一代数据开发更加简便。此外，还反对通过自定义算子疾速扩大平台的数据处理及加工能力。
• 实时构建宽表 ：从大数据分析到数仓建设，再到 Dashboard，数据工程人员应用大量批处理工作来生成用于展示和剖析的宽表或视图。这些宽表构建通常须要消耗大量资源，且数据更新不及时。但若利用 Tapdata 独特的 增量宽表构建能力，即能够最小化的老本提供最陈腐的数据后果。
• 实时数据服务 ：数字化转型过程中企业须要构建大量新型业务，这些业务往往须要来自其余业务零碎的数据。传统基于 ETL 的数据搬运计划局限性较大，如链路繁冗、无奈复用、大量的数据链路对源端产生影响较大等。Tapdata 的实时数据服务能够通过 对数据做最初一次 ETL，同步到基于 MongoDB 或 TiDB 的分布式数据平台，联合 无代码 API，能够为泛滥上游业务间接在数据平台提供疾速的数据 API 撑持。

想要理解更多新一代实时数据集成架构的技术细节，以及实时数据畛域的前沿倒退，举荐关注下周三 6 月 29 日 14:30 的 Tapdata Live Data Platform 产品公布暨开源说明会——纯正的技术分享，干货式的理念交换，更有实时数据“输送者”和“使用者”等多方代表参加的圆桌论坛——敬请期待！点击报名