关于数据库:数据接入平台DIP系列文章之一功能及架构浅析

导语

腾讯云音讯队列 CKafka 推出数据接入平台（Data Import Platform），旨在构建数据源和数据处理系统间的桥梁。

为了让开发者们更加深刻的理解数据接入平台（DIP），腾讯云音讯队列团队将组织系列文章，为大家详解数据接入平台（DIP）的性能及架构。

数据实时接入和剖析面临的挑战

随着大数据时代的到来，企业在生产和经营流动中产生的各类数据正以前所未有的速度增长，通过对实时及历史数据的交融剖析，及时开掘业务洞察和辅助决策，已成为企业的广泛口头。

有一种观点认为大数据存在“3V”个性：Volume, Velocity, Variety。这三个“V”表明大数据的三方面特色：量大，实时和多样。这三个次要特色对数据链路零碎的影响尤为突出。多种多样的数据源，海量的数据以及实时高效的采集传输是数据链路零碎次要面对的几个问题。即零碎须要在满足实时性指标的同时，也具备生产环境下的高可用性和易用性。

下图是一个十分经典的数据链路的架构图。从左到右，顺次是数据源、数据接入层、数据缓冲层、数据散发层、数据指标，能够看出，搭建一个残缺的数据链路非常复杂繁琐。

在云原生的浪潮下，企业须要聚焦业务，迫切需要简单易行，零代码地配置搭建起本人的数据链路零碎。因而数据链路零碎须要如下几个特色：SAAS 化、低代码化、简略易用、稳固牢靠、高性能、按量付费 ，以达到整体上的 降本增效。

基于上述诉求，咱们推出了数据接入平台（Data Import Platform）。

对于数据接入平台

数据接入平台定义

腾讯云音讯队列 CKafka 推出的数据接入平台（Data Import Platform），是腾讯云上 SAAS 化的数据接入和解决平台，帮助客户方便快捷地实现一站式的数据接入、解决和散发。平台提供基于 HTTP/TCP 协定的 SDK 帮助客户疾速实现数据上报、基于 CDC（Change Data Capture）机制疾速订阅、存储多款数据库（MySQL、PostgreSQL、MongoDB 等）变更信息，买通了多款云产品的日志投递。并提供了简略可配置的数据荡涤 (ETL) 能力，以及丰盛的数据流出渠道，帮助客户低成本搭建数据流转链路，构建数据源和数据处理系统间的桥梁。

DIP 相似于传统大数据解决方案中 Kafka+Flink 的角色，提供了通用的数据连贯、解决、流转的性能。外围诉求是心愿能够帮助客户低成本的搭建整条的数据链路。依据二八准则，DIP 心愿解决大部分通用的数据连贯场景。而对于业务属性强，逻辑简单的还是须要依赖 Flink 等流式计算引擎来实现。

在离线计算场景，DIP 提供了一个缓冲队列的作用，同时因为 DIP 提供了各种 MQ 与其余腾讯云上下游产品的对接性能，所以又表演了数据散发枢纽的角色。

DIP 和 Kafka 的关系

DIP 是由腾讯云上 CKafka 孵化出的数据接入产品，底层基于开源 Kafka Connector 和自研接入散发层。从实质上来看，Kafka 是音讯队列，属于存储产品。而 DIP 是数据接入散发平台，定位为存储层（MQ）的上下游数据连贯。

DIP 与 Kafka 的区别

DIP 旨在围绕音讯队列（MQ）生态，做好上下游的数据连贯。音讯队列属于 PAAS 产品，DIP 定位为 SAAS 产品，提供一站式的数据链路搭建计划。DIP 心愿达到低代码、免运维、按量付费、Serverless 化的成果，后续会反对多种音讯队列协定接入。

DIP 劣势

• 易用性
  仅需通过简略的界面配置，轻松实现数据上报、荡涤，存储的链路搭建。屏蔽数据接入过程中底层简单的零碎搭建、组件运维过程。
• 上下游生态交融
  反对云上、云下（跨云、混合云）场景、反对自建和云上服务的数据连贯。实现了五大类(数据库、文件、MQ、被动上报、日志)，15+ 云上产品买通，一站式实现数据的接入和流动。
• 高可用
  接入层、解决层、散发层均为分布式跨可用区部署，遇到故障即可主动切换，服务可用性不低于 99.9%。
• 实时性
  在数据采集、上报和流转整条链路过程中，实现秒级的接管、解决、并散发到上游零碎。
• 安全性
  数据接入平台反对不同租户间网络隔离，反对数据上报集成 CAM 鉴权、数据流转集成 SASL 权限管制，严格控制拜访权限，保障数据安全。
• 弹性伸缩
  无需预估业务容量，零碎会依据流量规模主动弹性伸缩，保障波峰时零碎可用性。按需应用，Serverless 化的实现数据接入、解决、转储的整个流程。

DIP 利用场景

数据上报

在零碎开发中，会有一些数据对立上报的需要，比方监控数据、用户行为数据、APP 操作数据等，须要将数据对立上报到服务端，供业务进行查问、解决、剖析等。如手机 APP 的操作行为剖析、前端页面的 Bug 日志上报、业务数据的上报等等。

个别状况下，这些上报的数据都须要转储到上游的存储剖析零碎外面进行解决（如 Elasticsearch，HDFS，数据湖等）。在惯例操作中，咱们须要搭建 Server、购买存储系统、并在两头自定义代码进行数据接管、解决、转储等。而 server 端须要思考性能、稳定性、扩缩容等工作，理论工作量较大。

DIP 旨在用 SaaS 化的思路解决这个问题，指标是通过如下两步：界面配置、SDK 上报，实现整个链路的搭建，并基于 Serverless 理念，以按量计费，弹性伸缩，无需预估容量等形式，简化客户的研发投入老本和理论的应用老本。

申请一个接入点 ID 即可实现数据接入，DIP 提供了两种协定的 SDK，HTTP 协定及 kafka 协定。通过 HTTP 协定能够将数据上报到 Kafka/Pulsar 或其余音讯队列，能够屏蔽多种音讯队列的简单 SDK 应用。

数据库变更信息订阅

DIP 反对基于 CDC（Change Data Capture）机制订阅多款数据库的变更数据。如订阅 MySQL 的 Binlog，MongoDB 的 Change Stream，PostgreSQL 的行级的数据变更（Row-level Change），SQL Server 的行级的数据变更（Row-level Change）等。例如，在理论业务应用过程当中，业务常常须要订阅 MySQL 的 Binlog 日志，获取 MySQL 的变更记录（Insert、Update、Delete、DDL、DML 等），并针对这些数据进行对应的业务逻辑解决，如查问、故障复原、剖析等。

在默认状况下，客户往往须要自定义搭建基于 CDC 的订阅组件如（Canal、Debezium、Flink CDC 等）来实现对数据库的数据订阅。而在搭建、运维这些订阅组件的过程中，人力投入老本较高，须要搭建配套的监控体系，保障订阅组件的稳固运行。

基于此种状况，DIP 提供 SaaS 化的组件，通过界面配置化的实现数据的订阅、解决、转储等整个流程。

数据荡涤和散发

大多数状况下，数据接入后，须要进行简略的解决过滤和归一化，能力往上游进行下一步存储、查问和剖析。简略的解决过滤和归一化就是数据的荡涤与散发，数据荡涤是指数据 A 变成数据 B，数据散发就是指 Kafka 有一份数据既想散发到 ES 又想散发到 COS，同时也心愿计算平台能够计算。

例如，在简略的数据群里，在自建的场景中，对原始的日志进行格式化，进行宰割重新组合、类型转换等这些操作，荡涤完一个数据，再存到下一轮去。惯例的做法就是须要写代码或者应用 Logstash 等开源组件进行 ETL 操作，但解决效率低，老本高，需大量配置能力解决海量数据，经常性遇到性能问题导致上有数据沉积。

如果应用 DIP，咱们会提供产品化配置界面，能够实现一键化配置，低代码实现数据的过滤和荡涤。也无需关注扩缩容的问题，省去开源组件的学习老本，同时缩小组件运维老本，反对用函数进行高级荡涤，咱们旨在打造一个更 SAAS 化的产品。

数据链路搭建

在理论业务过程中，用户常常须要将多个数据源的数据汇总到音讯队列中，比方业务客户端数据、业务 DB 数据、业务的运行日志数据汇总到音讯队列中进行剖析解决。失常状况下，须要先将这些数据进行荡涤格式化后，再做对立的转储、剖析或解决，创立整个数据链路就比拟长。

DIP 反对将不同环境（腾讯私有云、用户自建 IDC、跨云、混合云等）的不同数据源（数据库、中间件、日志、利用零碎等）的数据集成到私有云的音讯队列服务中，以便进行数据的解决和散发。

DIP 提供了数据聚合、存储、解决、转储的能力。简而言之，就是提供数据连贯集成的能力，将不同的数据源连贯到上游的数据指标中，这样搭建数据链路就比拟不便。创立工作后，整个工作的运行状态都是齐全通明的，比方全链路监控、数据审计等，以保证数据在数据链路中不会失落。

在整个数据链路搭建中，客户能够感知到的老本简直为零，在这个根底上客户还能够享受到其余的服务，咱们采纳的是以 serverless 为底层的机制，主动扩缩容按量付费，既节俭人工成本，又节俭经济老本。

DIP 技术架构

DIP 的数据架构分为两层，一层是数据面，一层是管控面。管控面是指资源管理、监控调度，主动扩缩容、迁徙等管控的操作。比方监控采集，客户能够把整个工作各个环节进行监控采集，配置告警。

DIP 的外围还是数据面的，下图是 DIP 零碎架构图：能够看到依据数据流转的链路，分为数据接入、数据处理、数据流出三大块。

数据接入的形式有三种：被动订阅、数据上报、自建 IDC 到混合云、跨云或私有云等多种云场景下获取数据。整个数据层面是多个引擎运行的。

在数据接入模块，DIP 反对的数据源又能够分为三大类。一类是像 mongodb、mysql 这样的服务类数据，第二类是通过咱们保护的日志采集器，采集到的 TKE、CVM 等等的日志数据；第三类是 HTTP 上报的、WEB、APP 产生的数据。前两类数据源咱们都会提供齐全产品化的配置界面，在控制台简略点击配置就能够连通，用户不须要关怀底层实现。第三类被动上报类的咱们会提供 SDK 和接入点，把接入点写入到 SDK 就能够实现数据上报。

下面提到的异构数据源接入之后，咱们提供数据荡涤归一化的能力。对于通用的荡涤模板，咱们会提供齐全产品化的配置界面，对于一些高级的自定义荡涤规定，咱们反对应用灵便的函数计算。

通过数据接入和实时计算，能够把多种数据源的异构数据实时荡涤成对立的结构化数据投递到上游 es、clickhouse 等多种大数据系统或者存储系统。投递过程也是齐全产品化的配置界面，只须要抉择数据源和数据指标，点点点即可。

对这些数据流转工作，反对查看监控，能够查问在工作中投递的音讯。之后 DIP 会反对工作编排，在管制台上能够清晰地看到数据流转链路，也能够对这个链路进行一些像退出和删除节点、编辑和查看监控的操作，同时反对指定 schema，指定音讯数据的格局。

通过下面这几大模块，咱们就能够实时接入 APP、WEB、IoT 和数据库等产生的异构数据，对立治理，并投递到上游的剖析、归档等零碎，构建清晰的数据流，更好地开释数据的价值。

数据流引擎 – Kafka Connector

DIP 底层的外围引擎，是基于 Kafka 的生态做的数据连贯引擎。在 Kafka 的原生社区中有 Kafka Connector 的概念，Connector 就是把各个数据的数据源导进来，提供插件化的开发方式，定义一套接口，能够实现不同的插件（JDBC、MQTT、MongoDB 等）协定，而后把数据从数据源拉进来。

Connector 能够简略了解为是一个依靠于 Kafka 的分布式工作管理器，JDBC 等不同的插件以线程的形式运行在整个分布式工作引擎中。

比方当创立工作的时候，如果指定三个并行度，Connector 就会创立三个线程，它的工作就会调度到集群的每台机器上运行。Sink 也实用于这套机制，Connector 自身反对很多插件（如 HDFS、HBase、S3、ES 等）。这些插件就会在集群中运行，主动调度，会注册很多监控指标。咱们的监控平台就会采集这些指标，依靠这些指标去告警，扩缩容等，保障整个集群的稳定性，比方负载是否达到了一个阈值，以后的资源是否须要扩容，以后的工作是否存在异样等。

数据流引擎 – HTTP 接入层

数据流引擎反对 HTTP 和 HTTPS 的协定接入，咱们提供了各个语言丰盛的 SDK，当客户拿到 SDK 后，简略来说新创建一个对象，发送数据就能够了，数据就会上报到服务端进行存储。

服务端有几层，首先接管层分布式部署，能够程度扩容，每台机器节点都会保护底层和 Kafka 缓冲的连接池，在连接池中接管到的数据会间接转发存储到音讯缓冲层中。数据流尽管从流程上看比较简单，但其实须要思考很多状况，比方是不是有负载歪斜，是不是有一些申请须要有一批独占的节点去保护等等。

从实质上来讲，咱们在 HTTP 接入层要做的就是把数据接进来，做一个 producer，导到音讯队列外面，两头咱们就会做很多高可用、主动复原、主动扩缩容的事件来保障整个接入层的稳定性。

CDC & Transform Engine

除了两个底层引擎，还有两个小细节须要阐明，一个是 CDC(Change Data Capture），一个是 Transform Engine。
CDC(Change Data Capture）即变更数据订阅, 它是数据库畛域十分常见的技术, 次要用于订阅数据库的一些变更, 而后能够把变更数据发送到上游，这个技术次要是数据库中才有的概念，数据库包含 mysql、pgsql、mongo 等。

数据转换引擎（Transform Engine）是指将源数据 A 转换为源数据 B。从技术上来讲，通过自定义代码、logstash、flink 这些都能够达到这个性能。Kafka 原生内核也集成了这部分性能，同时提供了很多数据处理插件，基于插件实现某个类，这个类就能够实现对应的数据转换性能。

Kafka 的转换引擎与其余引擎的区别在于它是十分轻量的，在数据处理里，它的定位是一个简略的数据处理引擎而不是一个全量的数据处理组件。

客户案例

某教育客户 – 数据上报

某教育客户须要将直播课学生上下课、签到、浏览等一些行为信息上传到后盾进行剖析、解决和检索。数据在后盾次要有两种业务逻辑：

1. 自定义代码拿到上报数据，进行对应业务逻辑解决
2. 原始数据进入 Elasticsearch 进行检索剖析

因开发人力无限，心愿有一种不便的数据接入服务，简略疾速地实现数据的上报、存储。

在经典数据上报架构中，通常须要有如下几个步骤：

1. 搭建 / 购买存储引擎，用来存储上报的数据。
2. 开发部署数据接管的 Server、定义 API、运行服务。
3. 定义客户端和服务端的接口协议、鉴权等信息。
4. 客户端依据协定信息编写相应的代码实现数据上报。

在这个 4 步中，Server 端的工作量是最大的，须要思考代码逻辑开发、server 自身扩缩容、接入层自身的稳定性、上游存储的扩缩容和稳定性等等。而当数据量大时，Server 端问题会更加显著，须要耗费大量的人力物力来进行保护。

从技术上看，这部分工作通用性很高，DIP 能够满足这种场景，提供稳固、弹性、高牢靠、高吞吐的数据接入服务。客户能够通过 Android、iphone、web 这些客户端在咱们的 SDK 把数据间接放到 DIP 中，DIP 目前的缓冲层有两种状态。如果客户用量较大，能够买一个 Kafka 集群，选本人的 topic，不须要为存储付费。量比拟小的话也不须要买整个 Kafka 集群，只须要买单个 topic，按量付费。而后进行数据散发，建一个 sink，存到 es。第二局部会自定义代码，把 Kafka 协定拿下，这样整个研发老本都能够降下来。

某资讯平台 – 数据处理散发

某资讯平台，服务部署在 TKE 外面，日志通过 TKE 的采集器投递到了云上的 Kafka。这些日志数据次要有三个用处。
局部数据须要进入 ElasticSearch 进行检索；局部数据通过简略解决后，须要保留到 COS 进行长久化的存储；局部数据须要进入大数据系统进行业务逻辑方面的解决。以后的做法是写一套大数据处理的 Flink 逻辑代码，一套解决并转储到 ES、COS 的代码，而后在两套代码中进行逻辑解决、荡涤和散发。

因为 Flink 学习保护老本较高，客户晚期没有应用 Flink 时应用的是 Logstash，Logstash 在运维过程中，遇到较多性能、稳定性、扩缩容的问题。而且自编码开发迭代投入的人力较多，运维也须要耗费精力。客户心愿云上可能有服务可能替换这两局部的工作。如果客户应用 DIP 数据散发的性能，就能够间接把数据简略解决，间接散发到 ES，其余部分只能用 Flink，这样就能够省了很多人力老本。

某迅销公司 – PGSQL 数据订阅查问

某迅销平台外部有多套零碎并行运行，某套零碎存储引擎为 PGSQL。须要将 PGSQL 的变更数据存量导入到 Elasticsearch 外面进行查问。有如下几个需要：

1. 数据写入 es 的时候须要依据工夫分索引 
2. 因为某个数据量大，心愿在某个工夫区间内只保留某个惟一 ID 标识的最新数据（update）。
3. 须要依据不同的表将数据散发到不同的索引外面。

自建的架构：PGSQL + Debezium PGSQL + Kafka Connector + Kafka + Logstash + Elasticsearch
DIP 架构：PGSQL + DIP + Elasticsearch

能够看出，客户自建时的链路很长，但如果应用 DIP，两头一部分都被代替了，这时候只须要保护两个工作，从研发层面来看，学习老本升高很多。

某保险客户 – HTTP 协定接入 MQ

某保险客户的中台团队迁徙上云，因上游团队泛滥，应用多款 MQ 产品（Kafka，RocketMQ，RabbitMQ）。各个 MQ 都是 TCP 协定接入，有各自的 SDK。SDK 学习、应用、以及后续切换老本较高。

基于中台思考，心愿上云后可能通过简略的 HTTP 协定进行接入，屏蔽底层的具体引擎细节。
有三个要求：

1. 简化客户端的应用，最好是 HTTP 协定
2. 底层 MQ 引擎切换对业务无感知
3. 最好有现成的反对 HTTP 协定的 SDK

上述客户的需要应用 DIP 都能够满足。

外部视频客户 – 数据入湖

某外部客户，次要的两局部，业务数大部分都存在 MongoDB 外面。有一部分客户行为数据，须要上报后进行剖析。客户心愿将这些数据对立到数据湖 (iceberg) 进行剖析。
自建链路遇到的问题，链路太长，波及的组件十分多。大多数组件是分布式部署，扩缩容简单，保护链路的稳定性，通明监控须要破费大量精力。应用 DIP 后，只须要简略配置，SAAS 化，链路的稳定性，扩缩容依靠平台解决。

总结

数据接入平台（DIP）次要是为各位开发者介绍数据接入平台是做什么的，在什么场景下能够使用到 DIP，底层架构是怎么的。后续的内容会为大家介绍底层各个组件的原理，与其余相似产品的优缺点比照，心愿开发者们对腾讯云音讯队列 CKafka 推出的这款产品有更具体的理解，能更好的用到业务中。

扫码观看本期对应直播回放