如何设计实时数据平台（设计篇）

导读：本文将会分上下两篇对一个重要且常见的大数据基础设施平台展开讨论，即“实时数据平台”。 在上篇设计篇中，咱们首先从两个维度介绍实时数据平台：从现代数仓架构角度看待实时数据平台，从典型数据处理角度看待实时数据处理；接着咱们会探讨实时数据平台总体设计架构、对具体问题的考量以及解决思路。 在下篇技术篇中，咱们会进一步给出实时数据平台的技术选型和相关组件介绍，并探讨不一样模式适用哪些应用场景。但愿经过对本文的讨论，读者能够获得一个有章可循、可实际落地的实时数据平台构建方案。

1、相关概念背景

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

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

图1 传统数仓

图2 现代数仓

传统数仓你们都很熟悉，这里不作过多介绍，通常来讲，传统数仓只能支持T＋1天时效延迟的数据处理，数据处理过程以ETL为主，最终产出以报表为主。

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

现代数仓是个很大的话题，在此咱们以概念模块的方式来展示其新的特性能力。首先咱们先看一下图3中Melissa Coates的整理总结：

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

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

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

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

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

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

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

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

可是咱们要知道，不是全部数据处理计算均可以在流上进行，而咱们的目的，是尽量的下降端到端数据延迟，这里就须要和其余数据流转处理方式配合进行，后面咱们会进一步讨论。

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

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

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

图4 数据虚拟化

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

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

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

对于Data Democratization的解读，还能够参见如下连接：

www.forbes.com/sites/berna…

文中提到技术层面如何支持数据平民化，并给出了几个例子：Data virtualization software，Data federation software，Cloud storage，Self-service BI applications等。其中数据虚拟化和数据联邦本质上是相似技术方案，而且提到了自助BI这个概念。

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中同时选择多个异构存储提供支持。下面分别对四个抽象层进行解读。

1)统一数据采集平台

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

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

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

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

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

2)统一流式处理平台

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

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

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

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

3)统一计算服务平台

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

4)统一数据可视化平台

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

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

2.3 具体问题和考量思路

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

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)质量考量

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

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

3)稳定考量

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

• 高可用HA

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

• SLA保障

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

• 弹性反脆弱

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

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

• 监控预警

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

• 自动运维

可以捕捉并存档缺失数据和处理异常，并具有按期自动重试机制修复问题数据

• 上游元数据变动抗性

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

✔ 实时Pipeline处理显式字段

4)成本考量

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

• 人力成本

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

• 资源成本

经过支持动态资源利用下降静态资源占用形成的资源浪费

• 运维成本

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

• 试错成本

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

5)敏捷考量

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

6)管理考量

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

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

拓展阅读：以企业级实时数据平台为例，了解何为敏捷大数据

做者：卢山巍

来源：宜信技术学院