如何设计实时数据平台(设计篇) (2)

文中提到技术层面如何支持数据平民化,并给出了几个例子: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.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信息,这是一种自定位自解释消息协议格式,这样做的好处是:

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

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wpysfp.html