其他分享
首页 > 其他分享> > 实时数据平台设计:技术选型与应用场景适配模式

实时数据平台设计:技术选型与应用场景适配模式

作者:互联网

实时数据平台(RTDP,Real-time Data Platform)是一个重要且常见的大数据基础设施平台。在上篇《实时数据平台设计:解决从OLTP到OLAP实时流转缺失》中,我们从现代数仓架构角度和典型数据处理角度介绍了RTDP,并探讨了RTDP的整体设计架构。

 

本文作为下篇,则是从技术角度入手,介绍RTDP的技术选型和相关组件,探讨适用不同应用场景的相关模式。RTDP的敏捷之路就此展开:

 

一、技术选型介绍

 

上篇中,我们给出了RTDP的一个整体架构设计(图1),而本文我们则会推荐整体技术组件选型,对每个技术组件做出简单介绍,尤其对我们抽象并实现的四个技术平台(统一数据采集平台、统一流式处理平台、统一计算服务平台、统一数据可视化平台)着重介绍设计思路;对Pipeline端到端切面话题进行探讨,包括功能整合、数据管理、数据安全等。

 

(图1)

 

1整体技术选型

 

(图2)

 

首先,我们简要解读一下图2:

 

 

下面我们会进一步细化图2涉及到的技术组件和切面话题,介绍技术组件的功能特性,着重讲解我们技术组件的设计思想,并对切面话题展开讨论。

 

2技术组件介绍

 

(1) 数据总线平台DBus

 

图3 RTDP架构之DBus

 

DBus设计思想

 

从外部角度看待设计思想:

 

 

从内部角度看待设计思想:

 

 

DBus功能特性

 

 

DBus技术架构

 

图4 DBus数据流转架构图

 

更多DBus技术细节和用户界面,可以参看:

 

 

(2) 分布式消息系统Kafka

 

Kafka已经成为事实标准的大数据流式处理分布式消息系统,当然Kafka在不断的扩展和完善,现在也具备了一定的存储能力和流式处理能力。关于Kafka本身的功能和技术已经有很多文章信息可以查阅,本文不再详述Kafka的自身能力。

 

这里我们具体探讨Kafka上消息元数据管理(Metadata Management)和模式演变(Schema Evolution)的话题。

 

图5 图片来源:

http://cloudurable.com/images/kafka-ecosystem-rest-proxy-schema-registry.png

 

图5显示,在Kafka背后的Confluent公司解决方案中,引入了一个元数据管理组件:Schema Registry。这个组件主要负责管理在Kafka上流转消息的元数据信息和Topic信息,并提供一系列元数据管理服务。

 

之所以要引入这样一个组件,是为了Kafka的消费方能够了解不同Topic上流转的是哪些数据、以及了解数据的元数据信息,并进行有效的解析消费。任何数据流转链路,不管是在什么系统上流转,都会存在这段数据链路的元数据管理问题,Kafka也不例外。

 

Schema Registry是一种中心化的Kafka数据链路元数据管理解决方案,并且基于Schema Registry,Confluent提供了相应的Kafka数据安全机制和模式演变机制。更多关于Schema Registry的介绍,可以参看:

 

Kafka Tutorial:Kafka, Avro Serialization and the Schema Registry

http://cloudurable.com/blog/kafka-avro-schema-registry/index.html

 

那么在RTDP架构中,如何解决Kafka消息元数据管理和模式演变问题呢?

 

元数据管理(Metadata Management):

 

 

模式演变(Schema Evolution):

 

 

 

由上文可以看出,Schema Registry和DBus+UMS是两种不同的解决元数据管理和模式演变的设计思路,两者各有优势和劣势,可以参考表1的简单比较:

 

表1 Schema Registry与DBus+UMS对比 

 

这里给出一个UMS的例子:

 

图6 UMS消息举例

 

(3) 流式处理平台Wormhole

 

图7 RTDP架构之Wormhole

 

Wormhole设计思想

 

从外部角度看待设计思想:

 

 

从内部角度看待设计思想:

 

 

Wormhole功能特性

 

 

Wormhole技术架构

 

图8 Wormhole数据流转架构图

 

更多Wormhole技术细节和用户界面,可以参看:

 

 

(4) 常用数据计算存储选型

 

RTDP架构对待数据计算存储选型的选择采取开放整合的态度。不同数据系统有各自的优势和适合的场景,但并没有一个数据系统可以适合各种各样的存储计算场景。因此当有合适的、成熟的、主流的数据系统出现,Wormhole和Moonbox会按照需要相应的扩展整合支持。

 

这里大致列举一些比较通用的选型:

 

 

(5) 计算服务平台Moonbox

 

图9 RTDP架构之Moonbox

 

Moonbox设计思想

 

从外部角度看待设计思想:

 

 

从内部角度看待设计思想:

 

 

Moonbox功能特性

 

 

Moonbox技术架构

 

图10 Moonbox逻辑模块

 

更多Moonbox技术细节和用户界面,可以参看:

 

 

(6) 可视应用平台Davinci

 

图11 RTDP架构之Davinci

 

Davinci设计思想

 

从外部角度看待设计思想:

 

 

从内部角度看待设计思想:

 

 

Davinci功能特性

 

数据源:

 

 

数据视图:

 

 

可视组件:

 

 

 

交互能力:

 

 

集成能力:

 

 

安全权限:

 

 

更多Moonbox技术细节和用户界面,可以参看:

 

 

3切面话题讨论

 

(1) 数据管理

 

元数据管理:

 

 

数据质量:

 

 

血缘分析:

 

 

(2) 数据安全

 

图12 RTDP数据安全

 

上图给出了RTDP架构中,四个开源平台覆盖了端到端数据流转链路,并且在每个节点上都有对数据安全各个方面的考量和支持,确保了实时数据管道端到端的数据安全性。

 

另外,由于Moonbox成为了面向应用层数据访问的统一入口,因此基于Moonbox的操作审计日志可以获得很多安全层面的信息,可以围绕操作审计日志建立数据安全预警机制,进而建设企业级数据安全系统。

 

(3) 开发运维

 

运维管理:

 

 

监控预警:

 

 

二、模式场景探讨

 

在介绍了RTDP架构各个技术组件的设计架构和功能特性之后,相信各位读者已经对RTDP架构如何落地有了具体的认识和了解。那么RTDP架构可以解决哪些常见数据应用场景呢?下面我们会探讨几种使用模式以及不同模式适应何种需求场景。

 

1同步模式

 

(1) 模式描述

 

同步模式,是指只配置异构数据系统之间的数据实时同步,在流上不做任何处理逻辑的使用模式。

 

具体而言,通过配置DBus将数据从数据源实时抽取出来投放在Kafka上,然后通过配置Wormhole将Kafka上数据实时写入到Sink存储中。同步模式主要提供了两个能力:

 

 

(2) 技术难点

 

具体实施比较简单。

 

IT实施人员无需了解太多流式处理的常见问题,不需要考虑流上处理逻辑实现的设计和实施,只需要了解基本的流控参数配置即可。

 

(3) 运维管理

 

运维管理比较简单。

 

需要人工运维。但由于流上没有处理逻辑,因此容易把控流速,无需考虑流上处理逻辑本身的功耗,可以给出一个相对稳定的同步管道配置。并且也很容易做到定时端到端数据比对来确保数据质量,因为源端和目标端的数据是完全一致的。

 

(4) 适用场景

 

 

2流算模式

 

(1) 模式描述

 

流算模式,是指在同步模式的基础上,在流上配置处理逻辑的使用模式。

 

在RTDP架构中,流上处理逻辑的配置和支持主要在Wormhole平台上进行。在同步模式的能力之上,流算模式主要提供了两个能力:

 

 

(2) 技术难点

 

具体实施相对较难。

 

用户需要了解流上处理能做哪些事,适合做哪些事,如何转化全量计算逻辑成为增量计算逻辑等。还要考虑流上处理逻辑本身功耗和依赖的外部数据系统等因素来调节配置更多参数。

 

(3) 运维管理

 

运维管理相对较难。

 

需要人工运维。但比同步模式运维管理更难,主要体现在流控参数配置考虑因素较多、无法支持端到端数据比对、要选择结果快照最终一致性实现策略、要考虑流上Lookup时间对齐策略等方面问题。

 

(4) 适用场景

 

 

3轮转模式

 

(1) 模式描述

 

轮转模式,是指在流算模式的基础上,在数据实时落库中,同时跑短时定时任务在库上进一步计算后,将结果再次投放在Kafka上跑下一轮流上计算,这样流算转批算、批算转流算的使用模式。

 

在RTDP架构中,可以利用Kafka→Wormhole→Sink→Moonbox→Kafka的整合方式实现任何轮次任何频次的轮转计算。在流算模式的能力之上,轮转模式提供的主要能力是:理论上支持低延迟的任何复杂流转计算逻辑。

 

(2) 技术难点

 

具体实施难。

 

Moonbox转Wormhole能力的引入,比流算模式进一步增加了考虑的变量因素,如多Sink的选择、Moonbox计算的频率设定、如何拆分Wormhole和Moonbox的计算分工等方面问题。

 

(3) 运维管理

 

运维管理难。

 

需要人工运维。和流算模式比,需要更多数据系统因素的考虑、更多参数的配置调优、更难的数据质量管理和诊断监控。

 

(4) 适用场景

 

 

4智能模式

 

(1) 模式描述

 

智能模式,是指利用规则或算法模型来进行优化和增效的使用模式。

 

可以智能化的点:

 

 

(2) 技术难点

 

具体实施在理论上最简单,但有效的技术实现最难。

 

用户只需要完成离线逻辑开发,剩下交由智能化工具完成开发、部署、调优、运维。

 

(3) 运维管理

 

零运维。

 

(4) 适用场景

 

全场景。

标签:Wormhole,适配,DBus,Moonbox,支持,Kafka,选型,实时,数据
来源: https://blog.csdn.net/shujuelin/article/details/94554706