实时数据平台设计：解决从OLTP到OLAP实时流转缺失
|
典型的数据处理，可分为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实时流转缺失的课题的解决方案。下面，我们会探讨从架构层面，如何设计这样一个实时数据平台。 二、架构设计方案 1定位和目标 实时数据平台(Real-time Data Platform，以下简称RTDP)，旨在提供数据端到端实时处理能力(毫秒级/秒级/分钟级延迟)，可以对接多数据源进行实时数据抽取，可以为多数据应用场景提供实时数据消费。作为现代数仓的一部分，RTDP可以支持实时化、虚拟化、平民化、协作化等能力，让实时数据应用开发门槛更低、迭代更快、质量更好、运行更稳、运维更简、能力更强。 2整体设计架构 概念模块架构，是实时数据处理Pipeline的概念层的分层架构和能力梳理，本身是具备通用性和可参考性的，更像是需求模块。图6给出了RTDP的整体概念模块架构，具体每个模块含义都可自解释，这里不再详述。
下面我们会根据上图做进一步设计讨论，给出从技术层面的高阶设计思路。
由图7可以看出，我们针对概念模块架构的四个层面进行了统一化抽象：
同时，也对存储层保持了开放的原则，意味着用户可以选择不同的存储层以满足具体项目的需要，而又不破坏整体架构设计，用户甚至可以在Pipeline中同时选择多个异构存储提供支持。下面分别对四个抽象层进行解读。 (1)统一数据采集平台 统一数据采集平台，既可以支持不同数据源的全量抽取，也可以支持增强抽取。其中对于业务数据库的增量抽取会选择读取数据库日志，以减少对业务库的读取压力。平台还可以对抽取的数据进行统一处理，然后以统一格式发布到数据总线上。这里我们选择一种自定义的标准化统一消息格式UMS(Unified Message Schema)做为统一数据采集平台和统一流式处理平台之间的数据层面协议。 UMS自带Namespace信息和Schema信息，这是一种自定位自解释消息协议格式，这样做的好处是：
(2)统一流式处理平台 统一流式处理平台，会消费来自数据总线上的消息，可以支持UMS协议消息，也可以支持普通JSON格式消息。同时，平台还支持以下能力：
(3)统一计算服务平台 统一计算服务平台，是一种数据虚拟化/数据联邦的实现。平台对内支持多异构数据源的下推计算和拉取混算，也支持对外的统一服务接口(JDBC/REST)和统一查询语言(SQL)。由于平台可以统一收口服务，因此可以基于平台打造统一元数据管理/数据质量管理/数据安全审计/数据安全策略等模块。平台也支持多租户体系。 (4)统一数据可视化平台 统一数据可视化平台，加上多租户和完善的用户体系/权限体系，可以支持跨部门数据从业人员的分工协作能力，让用户在可视化环境下，通过紧密合作的方式，更能发挥各自所长来完成数据平台最后十公里的应用。 以上是基于整体模块架构之上，进行了统一抽象设计，并开放存储选项以提高灵活性和需求适配性。这样的RTDP平台设计，体现了现代数仓的实时化/虚拟化/平民化/协作化等能力，并且覆盖了端到端的OLPP数据流转链路。 3具体问题和考量思路 下面我们会基于RTDP的整体架构设计，分别从不同维度讨论这个设计需要面对的问题考量和解决思路。 (1)功能考量 功能考量主要讨论这样一个问题：实时Pipeline能否处理所有ETL复杂逻辑? （编辑：拼字网 - 核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
