实时数据平台设计

1 相关概念背景

1.1 从现代数仓架构角度看实时数据平台

现代数仓由传统数仓发展而来，对比传统数仓，现代数仓既有与其相同之处，也有诸多发展点。首先我们看一下传统数仓（图1）和现代数仓（图2）的模块架构：

图1 传统数仓

图2 现代数仓

传统数仓大家都很熟悉，这里不做过多介绍，一般来说，传统数仓只能支持T＋1天时效延迟的数据处理，数据处理过程以ETL为主，最终产出以报表为主。

现代数仓建立在传统数仓之上，同时增加了更多样化数据源的导入存储，更多样化数据处理方式和时效（支持T＋0天时效），更多样化数据使用方式和更多样化数据终端服务。

现代数仓是个很大的话题，在此我们以概念模块的方式来展现其新的特性能力。

首先我们先看一下图3中Melissa Coates的整理总结：

图3

在图3 Melissa Coates的总结中我们可以得出，现代数仓之所以“现代”，是因为它有多平台架构、数据虚拟化、数据的近实时分析、敏捷交付方式等等一系列特性。

在借鉴Melissa Coates关于现代数仓总结的基础上，加以自己的理解，我们也在此总结提取了现代数仓的几个重要能力，分别是：

数据实时化（实时同步和流式处理能力）
数据虚拟化（虚拟混算和统一服务能力）
数据平民化（可视化和自助配置能力）
数据协作化（多租户和分工协作能力）

1.1.1 数据实时化（实时同步和流式处理能力）

数据实时化，是指数据从产生（更新至业务数据库或日志）到最终消费（数据报表、仪表板、分析、挖掘、数据应用等），支持毫秒级／秒级／分钟级延迟（严格来说，秒级／分钟级属于准实时，这里统一称为实时）。这里涉及到如何将数据实时的从数据源中抽取出来；如何实时流转；为了提高时效性，降低端到端延迟，还需要有能力支持在流转过程中进行计算处理；如何实时落库；如何实时提供后续消费使用。实时同步是指多源到多目标的端到端同步，流式处理指在流上进行逻辑转换处理。

但是我们要知道，不是所有数据处理计算都可以在流上进行，而我们的目的，是尽可能的降低端到端数据延迟，这里就需要和其他数据流转处理方式配合进行，后面我们会进一步讨论。

1.1.2 数据虚拟化（虚拟混算和统一服务能力）

数据虚拟化，是指对于用户或用户程序而言，面对的是统一的交互方式和查询语言，而无需关注数据实际所在的物理库和方言及交互方式（异构系统／异构查询语言）的一种技术。用户的使用体验是面对一个单一数据库进行操作，但其实这是一个虚拟化的数据库，数据本身并不存放于虚拟数据库中。

虚拟混算指的是虚拟化技术可以支持异构系统数据透明混算的能力，统一服务指对于用户提供统一的服务接口和方式。

图4 数据虚拟化

注：图1-4均选自“Designing a Modern Data Warehouse + Data Lake” - Melissa Coates, Solution Architect, BlueGranite

1.1.3 数据平民化（可视化和自助配置能力）

普通用户（无专业大数据技术背景的数据从业人员），可以通过可视化的用户界面，自助的通过配置和SQL方式使用数据完成自己的工作和需求，并无需关注底层技术层面问题（通过计算资源云化，数据虚拟化等技术）。以上是我们对数据平民化的解读。

对于Data Democratization的解读，还可以参见以下链接：

https://www.forbes.com/sites/bernardmarr/2017/07/24/what-is-data-democratization-a-super-simple-explanation-and-the-key-pros-and-cons

文中提到技术层面如何支持数据平民化，并给出了几个例子：

Data virtualization software；
Data federation software；
Cloud storage；
Self-service BI applications等。

其中数据虚拟化和数据联邦本质上是类似技术方案，并且提到了自助BI这个概念。

1.1.4 数据协作化（多租户和分工协作能力）

技术人员应该多了解业务，还是业务人员应该多了解技术？这一直是企业内争论不休的问题。而我们相信现代BI是一个可以深度协作的过程，技术人员和业务人员可以在同一个平台上，发挥各自所长，分工协作完成日常BI活动。这就对平台的多租户能力和分工协作能力提出了较高要求，一个好的现代数据平台是可以支持更好的数据协作化能力的。

我们希望可以设计出一个现代实时数据平台，满足以上提到的实时化、虚拟化、平民化、协作化等能力，成为现代数仓的一个非常重要且必不可少的组成部分。

1.2 从典型数据处理角度看实时数据处理

典型的数据处理，可分为OLTP、OLAP、Streaming、Adhoc、Machine Learning等。这里给出OLTP和OLAP的定义和对比：

注：图5选自文章“Relational Databases are not Designed for Mixed Workloads”-Matt Allen

从某种角度来说，OLTP活动主要发生在业务交易库端，OLAP活动主要发生在数据分析库端。那么，数据是如何从OLTP库流转到OLAP库呢？如果这个数据流转时效性要求很高，传统的T＋1批量ETL方式就无法满足了。

我们将OLTP到OLAP的流转过程叫Data Pipeline（数据处理管道），它是指数据的生产端到消费端之间的所有流转和处理环节，包括了数据抽取、数据同步、流上处理、数据存储、数据查询等。这里可能会发生很复杂的数据处理转换（如重复语义多源异构数据源到统一Star Schema的转换，明细表到汇总表的转换，多实体表联合成宽表等）。如何支持实时性很高的Pipeline处理能力，就成了一个有挑战性的话题，我们将这个话题描述为“在线管道处理”（OLPP, Online Pipeline Processing）问题。

因此，本文所讨论的实时数据平台，希望可以从数据处理角度解决OLPP问题，成为OLTP到OLAP实时流转缺失的课题的解决方案。下面，我们会探讨从架构层面，如何设计这样一个实时数据平台。

2 架构设计方案

2.1 定位和目标

实时数据平台（Real-time Data Platform，以下简称RTDP），旨在提供数据端到端实时处理能力（毫秒级／秒级／分钟级延迟），可以对接多数据源进行实时数据抽取，可以为多数据应用场景提供实时数据消费。作为现代数仓的一部分，RTDP可以支持实时化、虚拟化、平民化、协作化等能力，让实时数据应用开发门槛更低、迭代更快、质量更好、运行更稳、运维更简、能力更强。

2.2 整体设计架构

概念模块架构，是实时数据处理Pipeline的概念层的分层架构和能力梳理，本身是具备通用性和可参考性的，更像是需求模块。图6给出了RTDP的整体概念模块架构，具体每个模块含义都可自解释，这里不再详述。

图6 RTDP整体概念模块架构

下面我们会根据上图做进一步设计讨论，给出从技术层面的高阶设计思路。

图7 整体设计思想

由图7可以看出，我们针对概念模块架构的四个层面进行了统一化抽象：

统一数据采集平台
统一流式处理平台
统一计算服务平台
统一数据可视化平台

同时，也对存储层保持了开放的原则，意味着用户可以选择不同的存储层以满足具体项目的需要，而又不破坏整体架构设计，用户甚至可以在Pipeline中同时选择多个异构存储提供支持。下面分别对四个抽象层进行解读。

2.2.1 统一数据采集平台

统一数据采集平台，既可以支持不同数据源的全量抽取，也可以支持增强抽取。其中对于业务数据库的增量抽取会选择读取数据库日志，以减少对业务库的读取压力。平台还可以对抽取的数据进行统一处理，然后以统一格式发布到数据总线上。这里我们选择一种自定义的标准化统一消息格式UMS（Unified Message Schema）做为统一数据采集平台和统一流式处理平台之间的数据层面协议。

UMS自带Namespace信息和Schema信息，这是一种自定位自解释消息协议格式，这样做的好处是：

整个架构无需依赖外部元数据管理平台；
消息和物理媒介解耦（这里物理媒介指如Kafka的Topic, Spark Streaming的Stream等），因此可以通过物理媒介支持多消息流并行，和消息流的自由漂移。

平台也支持多租户体系，和配置化简单处理清洗能力。

2.2.2 统一流式处理平台

统一流式处理平台，会消费来自数据总线上的消息，可以支持UMS协议消息，也可以支持普通JSON格式消息。同时，平台还支持以下能力：

支持可视化／配置化／SQL化方式降低流式逻辑开发／部署／管理门槛
支持配置化方式幂等落入多个异构目标库以确保数据的最终一致性
支持多租户体系，做到项目级的计算资源／表资源／用户资源等隔离

2.2.3 统一计算服务平台

统一计算服务平台，是一种数据虚拟化／数据联邦的实现。平台对内支持多异构数据源的下推计算和拉取混算，也支持对外的统一服务接口（JDBC／REST）和统一查询语言（SQL）。由于平台可以统一收口服务，因此可以基于平台打造统一元数据管理／数据质量管理／数据安全审计／数据安全策略等模块。平台也支持多租户体系。

2.2.4 统一数据可视化平台

统一数据可视化平台，加上多租户和完善的用户体系／权限体系，可以支持跨部门数据从业人员的分工协作能力，让用户在可视化环境下，通过紧密合作的方式，更能发挥各自所长来完成数据平台最后十公里的应用。

以上是基于整体模块架构之上，进行了统一抽象设计，并开放存储选项以提高灵活性和需求适配性。这样的RTDP平台设计，体现了现代数仓的实时化／虚拟化／平民化／协作化等能力，并且覆盖了端到端的OLPP数据流转链路。

2.3 具体问题和考量思路

下面我们会基于RTDP的整体架构设计，分别从不同维度讨论这个设计需要面对的问题考量和解决思路。

2.3.1 功能考量

功能考量主要讨论这样一个问题：实时Pipeline能否处理所有ETL复杂逻辑？

我们知道，对于Storm／Flink这样的流式计算引擎，是按每条处理的；对于Spark Streaming流式计算引擎，按每个mini-batch处理；而对于离线跑批任务来说，是按每天数据进行处理的。因此处理范围是数据的一个维度（范围维度）。

另外，流式处理面向的是增量数据，如果数据源来自关系型数据库，那么增量数据往往指的是增量变更数据（增删改，revision）；相对的批量处理面向的则是快照数据（snapshot）。因此展现形式是数据的另一个维度（变更维度）。

单条数据的变更维度，是可以投射收敛成单条快照的，因此变更维度可以收敛成范围维度。所以流式处理和批量处理的本质区别在于，面对的数据范围维度的不同，流式处理单位为“有限范围”，批量处理单位为“全表范围”。“全表范围”数据是可以支持各种SQL算子的，而“有限范围”数据只能支持部分SQL算子，具体支持情况如下：

join：

✔ left join：支持。“限制范围”可以left join外部lookup表（通过下推，类似hashjoin效果）

✔ right join：不支持。每次从lookup拿回所有lookup表数据，这个计算是不可行的也是不合理的

✔ inter join：支持。可以转化为left join ＋filter，可以支持

✔ outer join：不支持。存在right join，因此不合理
union：支持。可以应用在拉回局部范围数据做窗口聚合操作。
agg：不支持。可以借助union做局部窗口聚合，但无法支持全表聚合操作。
filter：支持。没有shuffle，非常适合。
map：支持。没有shuffle，非常适合。
project：支持。没有shuffle，非常适合。

Join往往需要shuffle操作，是最费计算资源和时间的操作，而流上join（left join）将join操作转化成hashjoin的队列操作，将批量处理join的集中数据计算资源和时间平摊在数据流转过程中，因此在流上做left join是最划算的计算方式。

复杂的ETL并不是单一算子，经常会是由多个算子组合而成，由上可以看出单纯的流式处理并不能很好的支持所有ETL复杂逻辑。那么如何在实时Pipeline中支持更多复杂的ETL算子，并且保持时效性？这就需要“有限范围”和“全表范围”处理的相互转换能力。

设想一下：流式处理平台可以支持流上适合的处理，然后实时落不同的异构库，计算服务平台可以定时批量混算多源异构库（时间设定可以是每隔几分钟或更短），并将每批计算结果发送到数据总线上继续流转，这样流式处理平台和计算服务平台就形成了计算闭环，各自做擅长的算子处理，数据在不同频率触发流转过程中进行各种算子转换，这样的架构模式理论上即可支持所有ETL复杂逻辑。

图8 数据处理架构演化

图8给出了数据处理架构的演化，和OLPP的一种架构模式。其中wormhole和moonbox分别是我们开源的流式处理平台和计算服务平台，后面会具体介绍。

2.3.2 质量考量

上面的图也引出了两个主流实时数据处理架构：Lambda架构和Kappa架构，具体两个架构的介绍网上有很多资料，这里不再赘述。Lambda架构和Kappa架构各有其优劣势，但都支持数据的最终一致性，从某种程度上确保了数据质量，如何在Lambda架构和Kappa架构中取长补短，形成某种融合架构，这个话题会在新起文章中详细探讨。

当然数据质量也是个非常大的话题，只支持重跑和回灌并不能完全解决所有数据质量问题，只是从技术架构层面给出了补数据的工程方案。关于大数据数据质量问题，我们也会起一个新的话题讨论。

2.3.3 稳定考量

这个话题涉及但不限于以下几点，这里简单给出应对的思路：

高可用HA

整个实时Pipeline链路都应该选取高可用组件，确保理论上整体高可用；在数据关键链路上支持数据备份和重演机制；在业务关键链路上支持双跑融合机制
SLA保障

在确保集群和实时Pipeline高可用的前提下，支持动态扩容和数据处理流程自动漂移
弹性反脆弱

基于规则和算法的资源弹性伸缩；支持事件触发动作引擎的失效处理。
监控预警

集群设施层面，物理管道层面，数据逻辑层面的多方面监控预警能力
自动运维

能够捕捉并存档缺失数据和处理异常，并具备定期自动重试机制修复问题数据
上游元数据变更抗性

上游业务库要求兼容性元数据变更；实时Pipeline处理显式字段。

2.3.4 成本考量

这个话题涉及但不限于以下几点，这里简单给出应对的思路：

人力成本

通过支持数据应用平民化降低人才人力成本
资源成本

通过支持动态资源利用降低静态资源占用造成的资源浪费
运维成本

通过支持自动运维／高可用／弹性反脆弱等机制降低运维成本
试错成本

通过支持敏捷开发／快速迭代降低试错成本

2.3.5 敏捷考量

敏捷大数据是一整套理论体系和方法学，在前文已有所描述，从数据使用角度来看，敏捷考量意味着：配置化、SQL化、平民化。

2.3.6 管理考量

数据管理也是一个非常大的话题，这里我们会重点关注两个方面：元数据管理和数据安全管理。如果在现代数仓多数据存储选型的环境下统一管理元数据和数据安全，是一个非常有挑战的话题，我们会在实时Pipeline上各个环节平台分别考虑这两个方面问题并给出内置支持，同时也可以支持对接外部统一的元数据管理平台和统一数据安全策略。

本文我们探讨了实时数据平台RTDP的相关概念背景和架构设计方案。在架构设计方案中，我们尤其着重讲了RTDP的定位和目标，整体设计架构，以及涉及到的具体问题和考量思路。有些话题很大，可以后续单独形成文章进行专题讨论，但整体上，我们给出了一整套RTDP的设计思路和规划。在下篇技术篇中，我们会将RTDP架构设计具体化落地化，给出推荐的技术选型和我们的开源平台方案，并会结合不同场景需求探讨RTDP的不同模式应用。

如想了解更多，您还可以到Github浏览更多平台信息：

DBus地址：https://github.com/BriData/DBus
Davinci地址：https://github.com/edp963/davinci
Wormhole地址：https://github.com/edp963/wormhole
Moonbox地址：https://github.com/edp963/moonbox

实时数据平台（RTDP，Real-time Data Platform）是一个重要且常见的大数据基础设施平台。在上篇中，我们从现代数仓架构角度和典型数据处理角度介绍了RTDP，并探讨了RTDP的整体设计架构。

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

3 技术选型介绍

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

（图1）

3.1 整体技术选型

（图2）

首先，我们简要解读一下图2：

数据源、客户端，列举了大多数数据应用项目的常用数据源类型。
数据总线平台DBus，作为统一数据采集平台，负责对接各种数据源。DBus将数据以增量或全量方式抽取出来，并进行一些常规数据处理，最后将处理后的消息发布在Kafka上。
分布式消息系统Kafka，以分布式、高可用、高吞吐、可发布-订阅等能力，连接消息的生产者和消费者。
流式处理平台Wormhole，作为统一流式处理平台，负责流上处理和对接各种数据目标存储。Wormhole从Kafka消费消息，支持流上配置SQL方式实现流上数据处理逻辑，并支持配置化方式将数据以最终一致性（幂等）效果落入不同数据目标存储（Sink）中。
在数据计算存储层，RTDP架构选择开放技术组件选型，用户可以根据实际数据特性、计算模式、访问模式、数据量等信息选择合适的存储，解决具体数据项目问题。RTDP还支持同时选择多个不同数据存储，从而更灵活的支持不同项目需求。
计算服务平台Moonbox，作为统一计算服务平台，对异构数据存储端负责整合、计算下推优化、异构数据存储混算等（数据虚拟化技术），对数据展示和交互端负责收口统一元数据查询、统一数据计算和下发、统一数据查询语言（SQL）、统一数据服务接口等。
可视应用平台Davinci，作为统一数据可视化平台，以配置化方式支持各种数据可视化和交互需求，并可以整合其他数据应用以提供数据可视化部分需求解决方案，另外还支持不同数据从业人员在平台上协作完成各项日常数据应用。其他数据终端消费系统如数据开发平台Zeppelin、数据算法平台Jupyter等在本文不做介绍。
切面话题如数据管理、数据安全、开发运维、驱动引擎，可以通过对接DBus、Wormhole、Moonbox、Davinci的服务接口进行整合和二次开发，以支持端到端管控和治理需求。

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

3.2 技术组件介绍

3.2.1 数据总线平台DBus

图3 RTDP架构之DBus

DBus设计思想

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

负责对接不同的数据源，实时抽取出增量数据，对于数据库会采用操作日志抽取方式，对于日志类型支持与多种Agent对接。
将所有消息以统一的UMS消息格式发布在Kafka上，UMS是一种标准化的自带元数据信息的JSON格式，通过统一UMS实现逻辑消息与物理Kafka Topic解耦，使得同一Topic可以流转多个UMS消息表。
支持数据库的全量数据拉取，并且和增量数据统一融合成UMS消息，对下游消费透明无感知。

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

基于Storm计算引擎进行数据格式化，确保消息端到端延迟最低。
对不同数据源数据进行标准化格式化，生成UMS信息，其中包括：

生成每条消息的唯一单调递增id，对应系统字段ums_id_；

确认每条消息的事件时间戳（event timestamp），对应系统字段ums_ts_；

确认每条消息的操作模式（增删改，或insert only），对应系统字段ums_op_；
对数据库表结构变更实时感知并采用版本号进行管理，确保下游消费时明确上游元数据变化。
在投放Kafka时确保消息强有序（非绝对有序）和at least once语义。
通过心跳表机制确保消息端到端探活感知。

DBus功能特性

支持配置化全量数据拉取；
支持配置化增量数据拉取；
支持配置化在线格式化日志；
支持可视化监控预警；
支持配置化多租户安全管控；
支持分表数据汇集成单逻辑表。

DBus技术架构

图4 DBus数据流转架构图

3.2.2 分布式消息系统Kafka

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

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

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）：

DBus会自动将实时感知的数据库元数据变化记录下来并提供服务；
DBus会自动将在线格式化的日志元数据信息记录下来并提供服务；
DBus会发布在Kafka上发布统一UMS消息，UMS本身自带消息元数据信息，因此下游消费时无需调用中心化元数据服务，可以直接从UMS消息里拿到数据的元数据信息。

模式演变（Schema Evolution）：

UMS消息会自带Schema的Namespace信息，Namespace是一个7层定位字符串，可以唯一定位任何表的任何生命周期，相当于数据表的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]作为*处理，意味着当某表上游Schema变更时，Version会自动升号，但Wormhole会无视这个Version变化，将会消费此表所有版本的增量/全量数据，那么Wormhole如何做到兼容性模式演变支持呢？在Wormhole里可以配置流上处理SQL和输出字段，当上游Schema变更是一种“兼容性变更”（指增加字段，或者修改扩大字段类型等）时，是不会影响到Wormhole SQL正确执行的。当上游发生非兼容性变更时，Wormhole会报错，这时就需要人工介入对新Schema的逻辑进行修复。

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

表1 Schema Registry与DBus+UMS对比

这里给出一个UMS的例子：

图6 UMS消息举例

3.2.3 流式处理平台Wormhole

图7 RTDP架构之Wormhole

Wormhole设计思想

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

消费来自Kafka的UMS消息和自定义JSON消息。
负责对接不同的数据目标存储 (Sink)，并通过幂等逻辑实现Sink的最终一致性。
支持配置SQL方式实现流上处理逻辑。
提供Flow抽象，Flow由一个Source Namespace和一个Sink Namespace定义，且具备唯一性，Flow上可以定义处理逻辑，是一种流上处理的逻辑抽象，通过与物理Spark Streaming、Flink Streaming解耦，使得同一个Stream可以处理多个Flow处理流，且Flow可以在不同Stream上任意切换。
支持基于回灌（backfill）的Kappa架构；支持基于Wormhole Job的Lambda架构。

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

基于Spark Streaming、Flink计算引擎进行数据流上处理。Spark Streaming可支持高吞吐、批量Lookup、批量写Sink等场景；Flink可支持低延迟、CEP规则等场景。
通过ums_id_, ums_op_实现不同Sink的幂等入库逻辑。
通过计算下推实现Lookup逻辑优化。
抽象几个统一以支持功能灵活性和设计一致性：

统一DAG高阶分形抽象；

统一通用流消息UMS协议抽象；

统一数据逻辑表命名空间Namespace抽象；
抽象几个接口以支持可扩展性：

SinkProcessor：扩展更多Sink支持；

SwiftsInterface：自定义流上处理逻辑支持；

UDF：更多流上处理UDF支持；
通过Feedback消息实时归集流式作业动态指标和统计。

Wormhole功能特性

支持可视化、配置化、SQL化开发实施流式项目；
支持指令式动态流式处理的管理、运维、诊断和监控；
支持统一结构化UMS消息和自定义半结构化JSON消息；
支持处理增删改三态事件消息流；
支持单个物理流同时并行处理多个逻辑业务流；
支持流上Lookup Anywhere、Pushdown Anywhere；
支持基于业务策略的事件时间戳流式处理；
支持UDF的注册管理和动态加载；
支持多目标数据系统的并发幂等入库；
支持多级基于增量消息的数据质量管理；
支持基于增量消息的流式处理和批量处理；
支持Lambda架构和Kappa架构；
支持与三方系统无缝集成，可作为三方系统的流控引擎；
支持私有云部署，安全权限管控和多租户资源管理。

Wormhole技术架构

图8 Wormhole数据流转架构图

3.2.4 常用数据计算存储选型

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

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

关系型数据库（Oracle/MySQL等）：适合小数据量的复杂关系计算；
分布式列存储系统：

Kudu：Scan优化，适合OLAP分析计算场景；

HBase：随机读写，适合提供数据服务场景；

Cassandra：高性能写，适合海量数据高频写入场景；

ClickHouse：高性能计算，适合只有insert写入场景（后期将支持更新删除操作）；
分布式文件系统：

HDFS/Parquet/Hive：append only，适合海量数据批量计算场景；
分布式文档系统：

MongoDB：平衡能力，适合大数据量中等复杂计算；
分布式索引系统：

ElasticSearch：索引能力，适合做模糊查询和OLAP分析场景；
分布式预计算系统：

Druid/Kylin：预计算能力，适合高性能OLAP分析场景。

3.2.5 计算服务平台Moonbox

图9 RTDP架构之Moonbox

Moonbox设计思想

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

负责对接不同的数据系统，支持统一方式跨异构数据系统即席混算。
提供三种Client调用方式：RESTful服务、JDBC连接、ODBC连接。
统一元数据收口、统一查询语言SQL收口、统一权限控制收口。
提供两种查询结果写出模式：Merge、Replace。
提供两种交互模式：Batch模式、Adhoc模式。
数据虚拟化实现、多租户实现，可看作是虚拟数据库。

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

对SQL进行解析，经过常规Catalyst处理解析流程，最终生成可下推数据系统的逻辑执行子树进行下推计算，然后将结果拉回进行混算并返回。
支持两层Namespace：database.table，以提供虚拟数据库体验。
提供分布式服务模块Moonbox Grid提供高可用高并发能力。
对可全部下推逻辑（无混算）提供快速执行通道。

Moonbox功能特性

支持跨异构系统无缝混算；
支持统一SQL语法查询计算和写入；
支持三种调用方式：RESTful服务、JDBC连接、ODBC连接；
支持两种交互模式：Batch模式、Adhoc模式；
支持Cli Command工具和Zeppelin；
支持多租户用户权限体系；
支持表级权限、列级权限、读权限、写权限、UDF权限；
支持YARN调度器资源管理；
支持元数据服务；
支持定时任务；
支持安全策略。

Moonbox技术架构

图10 Moonbox逻辑模块

3.2.6 可视应用平台Davinci

图11 RTDP架构之Davinci

Davinci设计思想

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

负责各种数据可视化展示功能。
支持JDBC数据源。
提供平权用户体系，每个用户可以建立属于自己的Org、Team和Project。
支持SQL编写数据处理逻辑，支持拖拽式编辑可视化展示，提供多用户社交化分工协作环境。
提供多种不同的图表交互能力和定制化能力，以应对不同数据可视化需求。
提供嵌入整合进其他数据应用的能力。

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

围绕View和Widget展开。View是数据的逻辑视图、Widget是数据可视化视图。
通过用户自定义选择分类数据、有序数据和量化数据，按照合理的可视化逻辑自动展现视图。

Davinci功能特性

数据源：

支持JDBC数据源；
支持CSV文件上传。

数据视图：

支持定义SQL模版；
支持SQL高亮显示；
支持SQL测试；
支持回写操作。

可视组件：

支持预定义图表；
支持控制器组件；
支持自由样式。

交互能力：

支持可视组件全屏显示；
支持可视组件本地控制器；
支持可视组件间过滤联动；
支持群控控制器可视组件；
支持可视组件本地高级过滤器；
支持大数据量展示分页和滑块。

集成能力：

支持可视组件CSV下载；
支持可视组件公共分享；
支持可视组件授权分享；
支持仪表板公共分享；
支持仪表板授权分享。

安全权限：

支持数据行列权限；
支持LDAP登录集成。

3.3 切面话题讨论

3.3.1 数据管理

元数据管理：

DBus可以实时拿到数据源的元数据并提供服务查询；
Moonbox可以实时拿到数据系统的元数据并提供服务查询；
对于RTDP架构来说，实时数据源和即席数据源的元数据信息可以通过调用DBus和Moonbox的RESTful服务归集，可以基于此建设企业级元数据管理系统。

数据质量：

Wormhole可以配置消息实时落入HDFS（hdfslog）。基于hdfslog的Wormhole Job支持Lambda架构；基于hdfslog的Backfill支持Kappa架构。可以通过设置定时任务选择Lambda架构或者Kappa架构对Sink进行定时刷新，以确保数据的最终一致性。Wormhole还支持将流上处理异常或Sink写入异常的消息信息实时Feedback到Wormhole系统中，并提供RESTful服务供三方应用调用处理。
Moonbox可以对异构系统进行即席混算，这个能力赋予Moonbox“瑞士军刀”般的便利性。可以通过Moonbox编写定时SQL脚本逻辑，对关注的异构系统数据进行比对，或对关注的数据表字段进行统计等，可以基于Moonbox的能力二次开发数据质量检测系统。

血缘分析：

Wormhole的流上处理逻辑通常SQL即可满足，这些SQL可以通过RESTful服务进行归集；
Moonbox掌管了数据查询的统一入口，并且所有逻辑均为SQL，这些SQL可以通过Moonbox日志进行归集；
对于RTDP架构来说，实时处理逻辑和即席处理逻辑的SQL可以通过调用Wormhole的RESTful服务和Moonbox的日志归集，可以基于此建设企业级血缘分析系统。