上一个十年，以 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 产品发布暨开源说明会——朴实的技能共享，干货式的理念交流，更有实时数据“运送者”和“运用者”等多方代表参加的圆桌论坛——敬请期待！点击报名