一个简化、落地的实时数据仓库解决方案

从传统的经验来讲，数据仓库有一个很重要的功能是记录数据变化历史。通常，数据仓库都希望从业务上线的第一天开始有数据，然后一直记录到现在。但实时处理技术，又是强调当前处理状态的一门技术，所以当这两个相互对立的方案重叠在一起的时候，注定不是用来解决一个比较广泛问题的方案。于是，我们把实时数据仓库建设的目标定位为解决由于传统数据仓库数据时效性低而解决不了的问题。

实时数据仓库也引入了类似于离线数据仓库的分层理念，主要是为了提高模型的复用率，同时兼顾易用性、一致性以及计算成本。通常离线数据仓库采用空间换取时间的方式，所以层级划分比较多，从而提高数据计算效率。实时数据仓库的分层架构在设计上考虑到时效性问题，分层设计尽量精简，避免数据在流转过程中造成不必要的延迟响应，并降低中间流程出错的可能性。实时数据仓库分层架构如图1-9所示。

 

图1-9  实时数据仓库分层架构

1. ODS层：以Kafka为支撑，将所有需要实时处理的相关数据放到Kafka队列中来实现贴源数据层。这一层是数据输入层，主要是埋点、流量、日志等消息数据的接入。
2. DWD（Data Warehouse Detail）层：实时计算订阅业务数据消息队列，然后通过数据清洗、多数据源连接、流式数据与离线维度信息的组合等，将一些相同粒度的业务系统、维表中的维度属性全部关联到一起，增加数据易用性和复用性，得到最终的实时明细数据。
3. DIM（Dimension）层：存放用于关联查询的维度信息，可以根据数据现状来选择存储介质，例如使用HBase或者MySQL。对于实时ETL、实时统计，或者特征加工时需要进行流数据和静态维表数据关联处理等情况，这一层是必须的。
4. DWS（Data WareHouse Service）层：轻度汇总层是为了便于面向即席查询或者实时OLAP分析构建的轻度汇总结果集合，适合数据维度、指标信息比较多的情况。为了方便根据自定义条件的快速筛选和指标聚合，推荐使用MPP类型数据库进行存储。此层可视场景情况决定是否构建。
5. APP层：面向实时数据场景需求构建的高度汇总层，可以根据不同的数据应用场景决定所使用的存储介质或者引擎。APP层已经脱离了数据仓库，这里虽然作为一个独立分层，但实际APP层的数据已经分布存储在各种介质中以供使用。

图1-10显示的是一个简化的、落地的，并基于MySQL、Canal、Kafka、Greenplum构建的实时数据仓库架构。本书后面讨论的实践部分都基于此架构进行设计开发。

 

图1-10  基于MySQL、Canal、Kafka、Greenplum的实时数据仓库架构

在真实的数据仓库项目中会涉及多种数据源，不同数据源产生的数据质量可能差别很大，数据库中的格式化数据可以直接导入大数据存储系统，而日志或爬虫产生的数据就需要进行大量的清洗、转化处理才能有效使用。几乎在所有领域的业务数据源中，关系数据库都占有绝对比重，而其中MySQL毋庸置疑是当今最流行的关系数据库系统。本书将MySQL作为唯一数据源，一是出于简化目的，因为后面的实践均给出代码级别的实操，不可能面面俱到；二是MySQL具有典型性，搞定MySQL的数据采集就可以解决实际应用中的大部分问题。

Canal Server从MySQL从库产生的binlog（开启log_slave_updates）抽取增量数据变更日志，这样做有两个好处。首先，最重要的是它不会影响线上业务，因为Canal Server只是在从库创建一个Binlog Dump线程，对MySQL Server的影响微乎其微。其次，从库可以随时启停复制，这样可以很容易地为下游组件确定一个增量数据同步起点，在进行首次全量数据同步时就可以有效利用这一点来实现。

Canal Server作为数据生产者将记录数据变化的binlog以消息形式传递给Kafka。Kafka一方面可以将消息持久化存储，避免数据丢失，另一方面可以充当数据入仓前的缓冲区。Canal Adapter作为数据消费者从Kafka接收消息，然后将数据写入Greenplum数据库。

数据进入Greenplum后，就可以利用它提供的规则（rule）、用户自定义函数（UDF）、物化视图（MV）等功能，自动、实时、对用户透明地执行一些复杂的ETL过程，以及对维度表和事实表的数据维护。Greenplum是一种成熟的MPP架构的分布式数据库，提供了丰富全面的功能，并且性能优良，比较适合当作实时数据仓库的数据存储、数据处理和数据查询引擎。作为数据库管理系统，还可以利用Greenplum统一管理元数据。

图1-10所示架构具有门槛低、上手易、实施快的特点，整个构建过程只需要适当安装配置相关的软件，再利用SQL即可完成，不需要其他任何编程工作。当然，从来没有完美的架构，只有适合的解决方案。本架构明显的一个局限是只能处理MySQL一个数据源，而且始终以数据库提供的功能为核心。如果涉及非常复杂的处理逻辑，可以引入类似Flink的实时计算引擎，并在其上开发自己的应用程序是更好的选择。

本文节选自《Greenplum构建实时数据仓库实践》，内容发布获得作者和出版社授权。