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

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

实时数据仓库也引入了类似于离线数据仓库的分层理念,主要是为了提高模型的复用率,同时兼顾易用性、一致性以及计算成本。通常离线数据仓库采用空间换取时间的方式,所以层级划分比较多,从而提高数据计算效率。实时数据仓库的分层架构在设计上考虑到时效性问题,分层设计尽量精简,避免数据在流转过程中造成不必要的延迟响应,并降低中间流程出错的可能性。实时数据仓库分层架构如图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构建实时数据仓库实践》,内容发布获得作者和出版社授权。

 

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
要想在百度八亿网页的数据海洋中找到你所要的信息, 人工方式需要1200 多人年,而百度搜索技术不到1 秒钟。人 们被数据淹没,却渴望知识。商务智能技术已成为当今企业 获取竞争优势的源泉之一。商务智能通常被理解为将企业中 现有的数据转化为知识,帮助企业做出明智决策的IT工具集。 其中数据仓库、OLAP和数据挖掘技术是商务智能的重要组成 部分。商务智能的关键在于如何从众多来自不同企业运作系 统的数据中,提取有用数据,进行清理以保证数据的正确性, 然后经过抽取、转换、装载合并到一个企业级的数据仓库里, 从而得到企业数据的一个全局视图,并在此基础上利用适当 的查询分析、数据挖掘、OLAP等技术工具对其进行分析处理, 最终将知识呈现给管理者,为管理者的决策过程提供支持。 可见,数据仓库技术是商业智能系统的基础,在智能系统开 发过程中,星型模式设计又是数据仓库设计的基本概念之一。 星型模式是由位于中央的事实表和环绕在四周的维度表 组成的,事实表中的每一行与每个维度表的多行建立关系, 查询结果是通过将一个或者多个维度表与事实表结合之后产 生的,因此每一个维度表和事实表都有一个“一对多”的连 接关系,维度表的主键是事实表中的外键。随着企业交易量 的越来越多,星型模式中的事实表数据记录行数会不断增加, 而且交易数据一旦生成历史是不能改变的,即便不得不变动, 如对发现以前的错误数字做修改,这些修改后的数据也会作 为一行新纪录添加到事实表中。与事实表总是不断增加记录 的行数不同,维度表的变化不仅是增加记录的行数,而且据 需求不同维度表属性本身也会发生变化。本文着重讨论数据 仓库维度表的变化类型及其更新技术。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值