设计实时数据平台（技术篇）

《设计实时数据平台（技术篇）》由会员分享，可在线阅读，更多相关《设计实时数据平台（技术篇）（18页珍藏版）》请在金锄头文库上搜索。

1、 如何设计实时数据平台（技术篇） 敏捷之歌我抽数故我存在 | DBus人人玩转流处理 | Wormhole就当吾是数据库 | Moonbox颜值最后十公里 | Davinci导读：实时数据平台（RTDP，Real-time Data Platform）是一个重要且常见的大数据基础设施平台。在上篇（设计篇）中，我们从现代数仓架构角度和典型数据处理角度介绍了RTDP，并探讨了RTDP的整体设计架构。本文作为下篇（技术篇），则是从技术角度入手，介绍RTDP的技术选型和相关组件，探讨适用不同应用场景的相关模式。RTDP的敏捷之路就此展开拓展阅读：以企业级实时数据平台为例，了解何为敏捷大数据如何设计实时

2、数据平台（设计篇）一、技术选型介绍在设计篇中，我们给出了RTDP的一个整体架构设计（图1）。在技术篇里，我们则会推荐整体技术组件选型；对每个技术组件做出简单介绍，尤其对我们抽象并实现的四个技术平台（统一数据采集平台、统一流式处理平台、统一计算服务平台、统一数据可视化平台）着重介绍设计思路；对Pipeline端到端切面话题进行探讨，包括功能整合、数据管理、数据安全等。图1 RTDP架构1.1 整体技术选型图2 整体技术选型首先，我们简要解读一下图2： 数据源、客户端，列举了大多数数据应用项目的常用数据源类型。 数据总线平台DBus，作为统一数据采集平台，负责对接各种数据源。DBus将数据以增量或

3、全量方式抽取出来，并进行一些常规数据处理，最后将处理后的消息发布在Kafka上。 分布式消息系统Kafka，以分布式、高可用、高吞吐、可发布-订阅等能力，连接消息的生产者和消费者。 流式处理平台Wormhole，作为统一流式处理平台，负责流上处理和对接各种数据目标存储。Wormhole从Kafka消费消息，支持流上配置SQL方式实现流上数据处理逻辑，并支持配置化方式将数据以最终一致性（幂等）效果落入不同数据目标存储（Sink）中。 在数据计算存储层，RTDP架构选择开放技术组件选型，用户可以根据实际数据特性、计算模式、访问模式、数据量等信息选择合适的存储，解决具体数据项目问题。RTDP还支持同

4、时选择多个不同数据存储，从而更灵活的支持不同项目需求。 计算服务平台Moonbox，作为统一计算服务平台，对异构数据存储端负责整合、计算下推优化、异构数据存储混算等（数据虚拟化技术），对数据展示和交互端负责收口统一元数据查询、统一数据计算和下发、统一数据查询语言（SQL）、统一数据服务接口等。 可视应用平台Davinci，作为统一数据可视化平台，以配置化方式支持各种数据可视化和交互需求，并可以整合其他数据应用以提供数据可视化部分需求解决方案，另外还支持不同数据从业人员在平台上协作完成各项日常数据应用。其他数据终端消费系统如数据开发平台Zeppelin、数据算法平台Jupyter等在本文不做介绍

5、。 切面话题如数据管理、数据安全、开发运维、驱动引擎，可以通过对接DBus、Wormhole、Moonbox、Davinci的服务接口进行整合和二次开发，以支持端到端管控和治理需求。下面我们会进一步细化上图涉及到的技术组件和切面话题，介绍技术组件的功能特性，着重讲解我们自研技术组件的设计思想，并对切面话题展开讨论。1.2 技术组件介绍1.2.1 数据总线平台DBus图3 RTDP架构之DBus1.2.1.1 DBus设计思想1）从外部角度看待设计思想 负责对接不同的数据源，实时抽取出增量数据，对于数据库会采用操作日志抽取方式，对于日志类型支持与多种Agent对接。 将所有消息以统一的UMS消息

6、格式发布在Kafka上，UMS是一种标准化的自带元数据信息的JSON格式，通过统一UMS实现逻辑消息与物理Kafka Topic解耦，使得同一Topic可以流转多个UMS消息表。 支持数据库的全量数据拉取，并且和增量数据统一融合成UMS消息，对下游消费透明无感知。2）从内部角度看待设计思想 基于Storm计算引擎进行数据格式化，确保消息端到端延迟最低。 对不同数据源数据进行标准化格式化，生成UMS信息，其中包括： 生成每条消息的唯一单调递增id，对应系统字段ums_id_ 确认每条消息的事件时间戳（event timestamp），对应系统字段ums_ts_ 确认每条消息的操作模式（增删改，或

7、insert only），对应系统字段ums_op_ 对数据库表结构变更实时感知并采用版本号进行管理，确保下游消费时明确上游元数据变化。 在投放Kafka时确保消息强有序（非绝对有序）和at least once语义。 通过心跳表机制确保消息端到端探活感知。1.2.1.2 DBus功能特性 支持配置化全量数据拉取 支持配置化增量数据拉取 支持配置化在线格式化日志 支持可视化监控预警 支持配置化多租户安全管控 支持分表数据汇集成单逻辑表1.2.1.3 DBus技术架构图4 DBus数据流转架构图更多DBus技术细节和用户界面，可以参看：GitHub： 1.2.2 分布式消息系统KafkaKafk

8、a已经成为事实标准的大数据流式处理分布式消息系统，当然Kafka在不断的扩展和完善，现在也具备了一定的存储能力和流式处理能力。关于Kafka本身的功能和技术已经有很多文章信息可以查阅，本文不再详述Kafka的自身能力。这里我们具体探讨Kafka上消息元数据管理（Metadata Management）和模式演变（Schema Evolution）的话题。图5图片来源：图5显示，在Kafka背后的Confluent公司解决方案中，引入了一个元数据管理组件：Schema Registry。这个组件主要负责管理在Kafka上流转消息的 元数据信息和Topic信息，并提供一系列元数据管理服务。之所以要

9、引入这样一个组件，是为了Kafka的消费方能够了解不同Topic上流转的是哪些数据，以及数据的元数据信息，并进行有效的解析消费。任何数据流转链路，不管是在什么系统上流转，都会存在这段数据链路的元数据管理问题，Kafka也不例外。Schema Registry是一种中心化的Kafka数据链路元数据管理解决方案，并且基于Schema Registry，Confluent提供了相应的Kafka数据安全机制和模式演变机制。更多关于Schema Registry的介绍，可以参看：Kafka Tutorial:Kafka, Avro Serialization and the Schema Registr

10、y那么在RTDP架构中，如何解决Kafka消息元数据管理和模式演变问题呢？1.2.2.1 元数据管理（Metadata Management） DBus会自动将实时感知的数据库元数据变化记录下来并提供服务 DBus会自动将在线格式化的日志元数据信息记录下来并提供服务 DBus会发布在Kafka上发布统一UMS消息，UMS本身自带消息元数据信息，因此下游消费时无需调用中心化元数据服务，可以直接从UMS消息里拿到数据的元数据信息1.2.2.2 模式演变（Schema Evolution） UMS消息会自带Schema的Namespace信息，Namespace是一个7层定位字符串，可以唯一定位任何

11、表的任何生命周期，相当于数据表的IP地址，形式如下：Datastore.Datastore Instance.Database.Table.TableVersion.Database Partition.Table Partition例：oracle.oracle01.db1.table1.v2.dbpar01.tablepar01其中Table Version代表了这张表的某个Schema的版本号，如果数据源是数据库，那么这个版本号是由DBus自动维护的。 在RTDP架构中，Kafka的下游是由Wormhole消费的，Wormhole在消费UMS时，会将TableVersion作为*处理，意

12、味着当某表上游Schema变更时，Version会自动升号，但Wormhole会无视这个Version变化，将会消费此表所有版本的增量/全量数据，那么Wormhole如何做到兼容性模式演变支持呢？在Wormhole里可以配置流上处理SQL和输出字段，当上游Schema变更是一种“兼容性变更”（指增加字段，或者修改扩大字段类型等）时，是不会影响到Wormhole SQL正确执行的。当上游发生非兼容性变更时，Wormhole会报错，这时就需要人工介入对新Schema的逻辑进行修复。由上文可以看出，Schema Registry和DBus+UMS是两种不同的解决元数据管理和模式演变的设计思路，两者各

13、有优势和劣势，可以参考表1的简单比较。表1 Schema Registry 与 DBus+UMS 对比这里给出一个UMS的例子：图6 UMS消息举例1.2.3 流式处理平台Wormhole图7 RTDP架构之Wormhole1.2.3.1 Wormhole设计思想1)从外部角度看待设计思想 消费来自Kafka 的UMS消息和自定义JSON消息 负责对接不同的数据目标存储 (Sink)，并通过幂等逻辑实现Sink的最终一致性 支持配置SQL方式实现流上处理逻辑 提供Flow抽象。Flow由一个Source Namespace和一个Sink Namespace定义，且具备唯一性。Flow上可以定义

14、处理逻辑，是一种流上处理的逻辑抽象，通过与物理Spark Streaming、Flink Streaming解耦，使得同一个Stream可以处理多个Flow处理流，且Flow可以在不同Stream上任意切换。 支持基于回灌（backfill）的Kappa架构；支持基于Wormhole Job的Lambda架构2)从内部角度看待设计思想 基于Spark Streaming、Flink计算引擎进行数据流上处理。Spark Streaming可支持高吞吐、批量Lookup、批量写Sink等场景；Flink可支持低延迟、CEP规则等场景。 通过ums_id_, ums_op_实现不同Sink的幂等入库逻辑 通过计算下推实现Lookup逻辑优化 抽象几个统一以支持功能灵活性和设计一致性 统一DAG高阶分形抽象 统一通用流消息UMS协议抽象 统一数据逻辑表命名空间Namespace抽象 抽象几个接口以支持可扩展性 SinkProcessor：扩展更多Sink支持 SwiftsInterface：自定义流上处理逻辑支持 UDF：更多流上处理UDF支持 通过Feedback消息实时归集流式作业动态指标和统计1.2.3.2 Wormhole功能特性 支持可视化，配置化，SQL化开发实施流式项目 支持指令式动态流式处理的管理、运维、诊断和监控 支持统一结