共计 5258 个字符，预计需要花费 14 分钟才能阅读完成。
导语
2022 腾讯寰球数字生态大会已圆满闭幕，大会以“数实翻新、产业共进”为主题，聚焦数实交融，摸索以全真互联的数字技术助力实体经济高质量倒退。大会设有 29 个产品技术主题专场、18 个行业主题专场和 6 个生态主题专场，各业务负责人与客户、合作伙伴独特总结经验、凝固共识，推动数实交融新倒退。
本次大会设立了微服务与中间件专场，本专场从产品研发、运维等最佳落地实际登程，具体论述云原生时代，企业在开发微服务和构建云原生中间件过程中应该怎么少走弯路，聚焦业务需要，助力企业倒退翻新。
随着大数据时代的到来，企业在生产和经营流动中产生的各类数据正以前所未有的速度增长，通过对实时及历史数据的交融剖析，及时开掘业务洞察和辅助决策，已成为企业的广泛口头。在云原生的浪潮下，企业须要聚焦业务，迫切需要简单易行，零代码地配置搭建起本人的能够达到将本增效成果的数据链路零碎。
本篇文章将从以下几个方面对围绕着音讯队列如何疾速搭建数据链路的落地实际进行分享。
- 数据链路构建的挑战
- 技术架构体系的建设
- 客户实际和落地案例
视频：https://www.zhihu.com/zvideo/…
数据链路构建的挑战与开源生态
数据链路构建的挑战
如下图所示，这是一张经典的数据链路的架构图，从左到右顺次能够分为数据源、数据接入层、数据缓冲层、数据处理层和左边的数据指标。在这样一个典型的数据链路里，技术组件十分多，导致整个图非常复杂，这会减少运维老本。
图 1
接下来看另一张图，如果把两头局部全副屏蔽掉，这个数据链路变为一款 SaaS 化的数据接入组件，那它就会十分轻量。
图 2
所以在开源生态中，多样的数据源和数据指标，泛滥开源组件的学习老本，数据链路的搭建和运维是整个数据链路零碎次要面对的问题。
企业须要聚焦业务，因而数据链路零碎须要：SAAS 化、低代码化、简略易用、稳固牢靠、高性能、按量付费。以达到整体上的的降本增效。
咱们再回到图 1，能够看到，它的缓冲层在业界次要都是 Kafka，而后围绕 Kafka 生态，具备丰盛的上下游，那复杂度、学习老本、保护老本这些问题要如何解决呢？持续往下看。
数据链路性能矩阵
图 3
图 4
如上图 3 所示，数据链路由数据源、数据库两局部组成。
- 数据源
文本日志、CVM、容器、平安等
- 数据库
数据库数据、被动上报数据等
这些数据须要解决上报而后发到上游，在业界更多的是 Filebeat、Flink、Logstash 等社区组件。想要达到图 3 这张图的成果，就须要图 4 这一堆组件，这就波及到下面提到过的问题。所以就衍生出了一个 SaaS 化 的数据链路的计划。
Saas 化的数据链路计划
CKafka 连接器是腾讯云上 SaaS 化的数据接入和解决解决方案，一站式提供对数据的接入、解决和散发性能。
提供基于 HTTP/TCP 协定的 SDK 帮助客户实现数据上报；基于 CDC 机制订阅、存储多款数据库变更信息；简略可配置的数据荡涤 (ETL) 能力；丰盛的数据散发渠道；买通了混合云 / 跨云的丰盛的数据源 (MQ, 数据库，事件等) 数据接入。
帮助客户低成本搭建数据流转链路，构建数据源和数据处理系统间的桥梁。
利用场景
数据链路构建
在失常业务当中，用户须要将多种数据源的数据通过客户单采集，实时处理缓冲，传到上游的搜寻，这时就能够通过这套链路间接把数据一条链路齐全买通，间接把数据源打到上游的存储，这就十分便当了。
在理论业务过程中，用户常常须要将多个数据源的数据汇总到音讯队列中，比方业务客户端数据、业务 DB 数据、业务的运行日志数据汇总到音讯队列中进行剖析解决。失常状况下，须要先将这些数据进行荡涤格式化后，再做对立的转储、剖析或解决。
CKafka 连接器反对将不同环境（腾讯私有云、用户自建 IDC、跨云、混合云等）的不同数据源（数据库、中间件、日志、利用零碎等）的数据集成到私有云的音讯队列服务中，以便进行数据的解决和散发。提供了数据聚合、存储、解决、转储的能力，即 数据集成 的能力，将不同的数据源连贯到上游的数据指标中。
数据接入散发
另外三个场景别离是数据上报、数据库订阅和数据的清理和散发。
客户、业务端或者运维端可能有很多数据须要上报，须要本人搭建一个上报的 Server，但如果应用 Sass 化数据接入产品，它就能够很轻量化的实现数据上报。
数据库订阅和数据的清理散发等性能是一样的原理，须要做的就是把数据从各种数据源很 Saas 化的接进来，而后简略轻量的荡涤进来。
数据上报
数据库数据订阅
数据库荡涤和散发
接下来分享如何从技术上实现轻量级 Saas 化数据链路搭建，会遇到什么问题，业界有什么通用的做法。
技术架构体系的建设
零碎架构
从上图可知，数据链路整体分为 4 个层面：接入层、缓冲层、数据处理层和数据散发层。
从左到右，在数据面能够看到数据源、客户端、APP，会通过订阅、上报等接口把数据上报到接入层外面；而后接入层会把数据缓冲到缓冲层，缓冲层个别是 MQ，比方 Kafka、Pulsar 等音讯队列产品；接着在数据处理层，会解决生产缓存层的数据，把数据通过简略的 ETL 重组、重装、裁剪等等散发到上游的各种数据指标。
管制面会提供一些 API 管制调度监控、扩缩容、治理、运维、迁徙等等这些管控面的能力，这时会提供 API 给大家调用，这就是管制面和数据面的大体架构。如果本人去搭建这么一套数据链路的产品也是须要这么多的工作的。
界面化的 ETL 引擎
在数据处理层个别是通过编码，比方 Logstash 的语法，或者 Python 和 Flink 的 代码，或者 ETL 函数的语法等解决形式。但对用户来说，他可能不须要这么多的性能，也不想投入这么多的学习老本，用户就能够应用 CKafka 连接器，在通过 CKafka 连接器组件解决数据流入流出工作时，通常须要对数据进行简略的荡涤操作，比方格式化原始数据，格式化解析特定字段，数据格式转换等。开发者往往须要本人搭建一套数据荡涤的服务（ETL）。
如下图所示，从数据进来当前会通过多层的转换存在缓冲层而后再生产到上游，这是数据处理一个体系化的链路图。咱们能够提供一个齐全界面化的解决引擎来反对 JSON 的繁难操作、JSON 的格式化解析、数据的裁剪替换等通用的 ETL 的行为。这个界面化的 ETL 引擎底层是基于 Transform 接口、Interface 等机制来实现的。
多引擎架构 — Kafka Connector
怎么样来解决整个数据流的连贯和接入呢？从研发层面来讲，从过程或者线程的层面，从数据研发数据写到缓冲层再打到上游，整个不同工作的维度是须要调度的，以后的业界没有一种通用的引擎去解决所有问题，所以 CKafka 连接器计划底层实现的是多引擎的一套架构，那相当于有多套引擎同时并行的提供服务、调度、分布式的迁徙和启动、进行、变更等行为。
首先来看引擎 1：Kafka Connector，它是 Kafka 社区提供的一款计算调度的产品。这款产品次要解决的问题就是它提供了一个分布式的任务调度的框架，会同时凋谢出很多 Interface 的接口，会从数据源提供很多插件，比方 JDBC、Syslog、MQTT、MongoDB 等，这些插件会把数据从源端一直的拉到 Kafka 外面来，而后在上游再对接 HBRSE、S3、Elastic、Cassandra 等一些 Sink 的服务。Kafka Connector 分为两个层面，一个是调度层面，调度层面就整个框架，会提供分布式的部署，分布式的容灾。另一个是跨可用区的部署、跨可用区容灾等，提供各种不同的插件，Source、Sink 等，造成一套数据流。Kafka 引擎一个买通一个引擎，如果开发者自建，能够本人去搭建的，这时候更多要关注稳定性、扩缩容，以及内核问题的及时修复等。
多引擎架构 – Flink Connector
接着看引擎 2：Flink Connector，Flink 大家都用的十分熟，其实 Flink Connector 也十分弱小，它会提供很多计算框架，其实跟 Kafka Connector 相似，它也提供了很多分布式计算层的服务，也提供了很多 Connector 和 Extract 函数、UTF 等操作，它的 Connector 会对接各种数据源，也会对接各种 ES，它在数据源会定个数据库的 CDC，更多的是服务类的，比方数据源是 Kafka、DFS、Cassandra 等，这时它会通过外部的散布式调度和解决把数据源打到上游的 ES，这里是一个 Load 的过程，外面有很多算子等的概念。如果用户想要本人去搭建的话是比较复杂的。多引擎架构是为了解决两款技术体系 Flink 和 Connector 具备的不足之处，将两款技术体系交融在一起，进行不同的调度和迁徙。从数据源来看，它执行的就是为不同的数据源拿数据，没有缓冲层，间接到上游的 ES，区别在于，如果你须要存或者不须要存，工作的数据量、并行度这些都是咱们管制的。
多引擎架构 – MQTT 协定接入
接下来看引擎 3：MQTT 协定接入，MQTT 协定是指数据接入平台会提供整个 MQTT 的软件层，各种 Connector 端会连贯到 MQTT 的整个 Proxy 层，它会提供 MQTT 3、MQTT 5 的一流量管制、语音版音讯服务等一个体系，也会反对 QS 1、QS 2 等，也反对通过 MQTT 把音讯打到上游的 Bridge 这些数据桥阶层，转发到 Kafka 或者其余 MQ。
多引擎架构 – HTTP 协定接入
最初看多引擎架构 4：反对 HTTP 协定接入，数据可能通过 HTTP 协定从数据源导进来。
如下图所示，看一下 HTTP 协定的架构，第一层是网关，它有各种 Report，通过接收数据在外部保护 API 连接池，把数据散发到 Database、Monitor、Report 等，最终是把数据存到各种 MQ 外面。
从总体来看，CKafka 连接器会提供多种数据流的引擎，Kafka Connector、Flink Connector 等，这些对用户都齐全屏蔽了，用户用到的只是一个 Saas 化的轻量级组件计划，还能够提供 MQTT 协定和 HTTP 协定，用户能够间接接入，接入后用户就能够十分轻量的解决问题。
客户实际
场景 1 – 数据入湖
数据入湖的概念当初十分火，就是把屏蔽底层的各种 HDFS、COS 等长久存储的数据或者异构的数据进行对立查问剖析。
客户业务数大部分都存在 MongoDB 外面。有一部分客户行为数据，须要上报后进行剖析。客户心愿将这些数据对立到数据湖 (iceberg) 进行剖析。
自建链路遇到的问题，链路太长，波及的组件十分多。大多数组件是分布式部署，扩缩容简单，保护链路的稳定性，通明监控须要破费大量精力。应用连接器组件后，只须要简略配置，SAAS 化，链路的稳定性，扩缩容依靠平台解决。
看上面的架构图，有 Mongo 的数据源，在接入层通过 Mongo 的 Connector 去 Mongo 里拿数据，订阅 MongoStream 的数据，须要先把数据存到 Kafka 的 Topic 里，因为原始订阅数据是有 Schema 标准的，这时在 Iceberg 里，是一个存储一个解析的层，所以须要简略的解决，通过 Kafka Connector 的 Sink 把数据存到 DLC 外面去。
场景 2 – 数据上报和多协定接入
数据接入
某教育客户须要将直播课学生上下课、签到、浏览等一些行为信息上传到后盾进行剖析、解决和检索。数据在后盾次要有两种业务逻辑：
1. 自定义代码拿到上报数据，进行对应业务逻辑解决
2. 原始数据进入 Elasticsearch 进行检索剖析
因开发人力无限，心愿有一种不便的数据接入服务，简略疾速地实现数据的上报、存储。
这个客户的数据源是各种客户端，通过数据上报接入到 HTTP 接入层中，而后通过连接器存储，数据散发到 ES，而后客户本人的代码去生产。
多协定接入
某保险客户的中台团队迁徙上云，因上游团队泛滥，应用多款 MQ 产品（Kafka，RocketMQ，RabbitMQ）。各个 MQ 都是 TCP 协定接入，有各自的 SDK。SDK 学习、应用、以及后续切换老本较高。
基于中台思考，心愿上云后可能通过简略的 HTTP 协定进行接入，屏蔽底层的具体引擎细节。
有三个要求：1. 简化客户端的应用，最好是 HTTP 协定。2. 底层 MQ 引擎切换对业务无感知。3. 最好有现成的反对 HTTP 协定的 SDK.
应用连接器组件就解决了十分理论的上报、订阅和散发的场景。
场景 3 – 数据库订阅
某迅销平台外部多有多套零碎并行运行，某套零碎存储引擎为 PGSQL。须要将 PGSQL 的变更数据存量导入到 Elasticsearch 外面进行查问。有如下几个需要：1. 数据写入 ES 的时候须要依据工夫分索引 2. 因为某个数据量大，心愿在某个工夫区间内只保留某个惟一 ID 标识的最新数据（update）。3. 须要依据不同的表将数据散发到不同的索引外面。
自建的架构：PGSQL + DebeziumPGSQL+KafkaConnector+Kafka+Logstash+ Elasticsearch
CKafka 连接器架构：PGSQL + 连接器 + Elasticsearch
从下面的架构能够看的进去，应用连接器计划能够将数据链路中的很多细节间接屏蔽，间接打到上游，十分轻量化。
