如何设计实时数据平台 —— 技术选型与架构设计

上篇-设计篇

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

图1 传统数仓

图2 现代数仓

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

图3

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

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

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

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

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

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

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

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

图4 数据虚拟化

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

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

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

图5

图6 RTDP整体概念模块架构

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

图7 整体设计思想

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

• 统一数据采集平台

• 统一流式处理平台

• 统一计算服务平台

• 统一数据可视化平台

（1）统一数据采集平台

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

• 整个架构无需依赖外部元数据管理平台；

• 消息和物理媒介解耦（这里物理媒介指如Kafka的Topic, Spark Streaming的Stream等），因此可以通过物理媒介支持多消息流并行，和消息流的自由漂移。

（2）统一流式处理平台

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

• 支持可视化／配置化／SQL化方式降低流式逻辑开发／部署／管理门槛

• 支持配置化方式幂等落入多个异构目标库以确保数据的最终一致性

• 支持多租户体系，做到项目级的计算资源／表资源／用户资源等隔离

（3）统一计算服务平台

（4）统一数据可视化平台

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

（1）功能考量

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

单条数据的变更维度，是可以投射收敛成单条快照的，因此变更维度可以收敛成范围维度。所以流式处理和批量处理的本质区别在于，面对的数据范围维度的不同，流式处理单位为“有限范围”，批量处理单位为“全表范围”。“全表范围”数据是可以支持各种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，非常适合。

图8 数据处理架构演化

（2）质量考量

（3）稳定考量

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

• 高可用HA

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

• SLA保障

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

• 弹性反脆弱

  ✔ 基于规则和算法的资源弹性伸缩

  ✔ 支持事件触发动作引擎的失效处理

• 监控预警

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

• 自动运维

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

• 上游元数据变更抗性

  ✔上游业务库要求兼容性元数据变更

  ✔ 实时Pipeline处理显式字段

（4）成本考量

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

• 人力成本

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

• 资源成本

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

• 运维成本

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

• 试错成本

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

（5）敏捷考量

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

（6）管理考量

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

下篇-技术篇

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

图1

图2

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

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

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

(1) 数据总线平台DBus

GitHub地址：https://bridata.github.io/DBus/

图3 RTDP架构之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技术架构

(2) 分布式消息系统Kafka

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

图5 

图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

• 元数据管理（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) 流式处理平台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技术架构

GitHub地址：https://github.com/edp963/wormhole

图8 Wormhole数据流转架构图

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

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

• 关系型数据库（Oracle/MySQL等）：适合小数据量的复杂关系计算

• 分布式列存储系统

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

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

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

  ✔ ClickHouse：高性能计算，适合只有insert写入场景（后期将支持更新删除操作）

• 分布式文件系统

  HDFS/Parquet/Hive：append only，适合海量数据批量计算场景

• 分布式文档系统

  MongoDB：平衡能力，适合大数据量中等复杂计算

• 分布式索引系统

  ElasticSearch：索引能力，适合做模糊查询和OLAP分析场景

• 分布式预计算系统

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

(5) 计算服务平台Moonbox

GitHub地址：https://github.com/edp963/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逻辑模块

(6) 可视应用平台Davinci

图11 RTDP架构之Davinci

Davinci设计思想

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

  ✔ 负责各种数据可视化展示功能

  ✔ 支持JDBC数据源

  ✔ 提供平权用户体系，每个用户可以建立属于自己的Org、Team和Project

  ✔ 支持SQL编写数据处理逻辑，支持拖拽式编辑可视化展示，提供多用户社交化分工协作环境

  ✔ 提供多种不同的图表交互能力和定制化能力，以应对不同数据可视化需求

  ✔ 提供嵌入整合进其他数据应用的能力

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

  ✔ 围绕View和Widget展开。View是数据的逻辑视图；Widget是数据可视化视图

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

Davinci功能特性

• 数据源

  ✔ 支持JDBC数据源

  ✔ 支持CSV文件上传

• 数据视图

  ✔ 支持定义SQL模版

  ✔ 支持SQL高亮显示

  ✔ 支持SQL测试

  ✔ 支持回写操作

• 可视组件

  ✔ 支持预定义图表

  ✔ 支持控制器组件

  ✔ 支持自由样式

• 交互能力

  ✔ 支持可视组件全屏显示

  ✔ 支持可视组件本地控制器

  ✔ 支持可视组件间过滤联动

  ✔ 支持群控控制器可视组件

  ✔ 支持可视组件本地高级过滤器

  ✔ 支持大数据量展示分页和滑块

• 集成能力

  ✔ 支持可视组件CSV下载

  ✔ 支持可视组件公共分享

  ✔ 支持可视组件授权分享

  ✔ 支持仪表板公共分享

  ✔ 支持仪表板授权分享

• 安全权限

  ✔ 支持数据行列权限

  ✔ 支持LDAP登录集成
  

(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的日志归集，可以基于此建设企业级血缘分析系统。

(2) 数据安全

图12 RTDP数据安全

(3) 开发运维

• 运维管理

  ✔ 实时数据处理的运维管理向来是个痛点，DBus和Wormhole通过可视化UI提供了可视化运维管理能力，让人工运维变得简单。

  ✔ DBus和Wormhole提供了健康检查、操作管理、Backfill、Flow漂移等RESTful服务，可以基于此研发自动化运维系统。

• 监控预警

  ✔ DBus和Wormhole均提供可视化监控界面，可以实时看到逻辑表级的吞吐和延迟等信息。

  ✔ DBus和Wormhole提供了心跳、Stats、状态等RESTful服务，可以基于此研发自动化预警系统。

(1) 模式描述

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

• 后续数据处理逻辑不再执行在业务备库上，减少了对业务备库的使用压力

• 提供了将不同物理业务备库数据实时同步到同一物理数据存储的可能性

(2) 技术难点

具体实施比较简单。

(3) 运维管理

运维管理比较简单。

(4) 适用场景

• 跨部门数据实时同步共享

• 交易数据库和分析数据库解耦

• 支持数仓实时ODS层建设

• 用户自助实时简单报表开发

• 等等

(1) 模式描述

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

• 流上计算将批量计算集中功耗分散在流上增量计算持续功耗，极大降低了结果快照的时间延迟

• 流上计算提供了跨异构系统混算的新的计算入口（Lookup）

(2) 技术难点

(3) 运维管理

(4) 适用场景

• 对低延迟要求较高的数据应用项目或报表

• 需要低延迟调用外部服务（如流上调用外部规则引擎、在线算法模型使用等）

• 支持数仓实时事实表+维度表的宽表建设

• 实时多表融合、分拆、清洗、标准化Mapping场景

• 等等

(1) 模式描述

(2) 技术难点

(3) 运维管理

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

(4) 适用场景

• 低延迟的多步骤的复杂数据处理逻辑场景

• 公司级实时数据流转处理网络建设

(1) 模式描述

可以智能化的点：

• Wormhole Flow的智能漂移（智能化自动化运维）

• Moonbox预计算的智能优化（智能化自动化调优）

• 全量计算逻辑智能转换成流式计算逻辑，然后部署在Wormhole + Moonbox（智能化自动化开发部署）

• 等等

(2) 技术难点

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

(3) 运维管理

(4) 适用场景

大数据常用技术栈

如何获取流式应用程序中checkpoint的最新offset

关注大数据学习与分享，获取更多技术干货