如果你也想做实时数仓…
作者:郭华(付空)
数据仓库也是公司数据发展到一定规模后必然会提供的一种基础服务,数据仓库的建设也是“数据智能”中必不可少的一环。本文将从数据仓库的简介、经历了怎样的发展、如何建设、架构演变、应用案例以及实时数仓与离线数仓的对比六个方面全面分享关于数仓的详细内容。
1.数据仓库简介
数据仓库是一个面向主题的(Subject Oriented)、集成的(Integrate)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合,用于支持管理决策。
数据仓库是伴随着企业信息化发展起来的,在企业信息化的过程中,随着信息化工具的升级和新工具的应用,数据量变的越来越大,数据格式越来越多,决策要求越来越苛刻,数据仓库技术也在不停的发展。
数据仓库的趋势:
- 实时数据仓库以满足实时化&自动化决策需求;
- 大数据&数据湖以支持大量&复杂数据类型(文本、图像、视频、音频);
2.数据仓库的发展
数据仓库有两个环节:数据仓库的构建与数据仓库的应用。
早期数据仓库构建主要指的是把企业的业务数据库如 ERP、CRM、SCM 等数据按照决策分析的要求建模并汇总到数据仓库引擎中,其应用以报表为主,目的是支持管理层和业务人员决策(中长期策略型决策)。
随着业务和环境的发展,这两方面都在发生着剧烈变化。
- 随着IT技术走向互联网、移动化,数据源变得越来越丰富,在原来业务数据库的基础上出现了非结构化数据,比如网站 log,IoT 设备数据,APP 埋点数据等,这些数据量比以往结构化的数据大了几个量级,对 ETL 过程、存储都提出了更高的要求;
- 互联网的在线特性也将业务需求推向了实时化,随时根据当前客户行为而调整策略变得越来越常见,比如大促过程中库存管理,运营管理等(即既有中远期策略型,也有短期操作型);同时公司业务互联网化之后导致同时服务的客户剧增,有些情况人工难以完全处理,这就需要机器自动决策。比如欺诈检测和用户审核。
总结来看,对数据仓库的需求可以抽象成两方面:实时产生结果、处理和保存大量异构数据。
注:这里不讨论数据湖技术。
3.数据仓库建设方法论
3.1 面向主题
从公司业务出发,是分析的宏观领域,比如供应商主题、商品主题、客户主题和仓库主题
3.2 为多维数据分析服务
数据报表;数据立方体,上卷、下钻、切片、旋转等分析功能。
3.3 反范式数据模型
以事实表和维度表组成的星型数据模型
注:图片来自 51 CTO
4.数据仓库架构的演变
数据仓库概念是 Inmon 于 1990 年提出并给出了完整的建设方法。随着互联网时代来临,数据量暴增,开始使用大数据工具来替代经典数仓中的传统工具。此时仅仅是工具的取代,架构上并没有根本的区别,可以把这个架构叫做离线大数据架构。
后来随着业务实时性要求的不断提高,人们开始在离线大数据架构基础上加了一个加速层,使用流处理技术直接完成那些实时性要求较高的指标计算,这便是 Lambda 架构。
再后来,实时的业务越来越多,事件化的数据源也越来越多,实时处理从次要部分变成了主要部分,架构也做了相应调整,出现了以实时事件处理为核心的 Kappa 架构。
4.1 离线大数据架构
数据源通过离线的方式导入到离线数仓中。下游应用根据业务需求选择直接读取 DM 或加一层数据服务,比如 MySQL 或 Redis。数据仓库从模型层面分为三层:
- ODS,操作数据层,保存原始数据;
- DWD,数据仓库明细层,根据主题定义好事实与维度表,保存最细粒度的事实数据;
- DM,数据集市/轻度汇总层,在 DWD 层的基础之上根据不同的业务需求做轻度汇总;
典型的数仓存储是 HDFS/Hive,ETL 可以是 MapReduce 脚本或 HiveSQL。
4.2 Lambda 架构
随着大数据应用的发展,人们逐渐对系统的实时性提出了要求,为了计算一些实时指标,就在原来离线数仓的基础上增加了一个实时计算的链路,并对数据源做流式改造(即把数据发送到消息队列),实时计算去订阅消息队列,直接完成指标增量的计算,推送到下游的数据服务中去,由数据服务层完成离线&实时结果的合并。
注:流处理计算的指标批处理依然计算,最终以批处理为准,即每次批处理计算后会覆盖流处理的结果。(这仅仅是流处理引擎不完善做的折中)
Lambda 架构问题:
- 同样的需求需要开发两套一样的代码:这是 Lambda 架构最大的问题,两套代码不仅仅意味着开发困难(同样的需求,一个在批处理引擎上实现,一个在流处理引擎上实现,还要分别构造数据测试保证两者结果一致),后期维护更加困难,比如需求变更后需要分别更改两套代码,独立测试结果,且两个作业需要同步上线。
- 资源占用增多:同样的逻辑计算两次,整体资源占用会增多(多出实时计算这部分
4.3 Kappa 架构
Lambda 架构虽然满足了实时的需求,但带来了更多的开发与运维工作,其架构背景是流处理引擎还不完善,流处理的结果只作为临时的、近似的值提供参考。后来随着 Flink 等流处理引擎的出现,流处理技术很成熟了,这时为了解决两套代码的问题,LickedIn 的 Jay Kreps 提出了 Kappa 架构。
- Kappa 架构可以认为是 Lambda 架构的简化版(只要移除 lambda 架构中的批处理部分即可)。
- 在 Kappa 架构中,需求修改或历史数据重新处理都通过上游重放完成。
- Kappa 架构最大的问题是流式重新处理历史的吞吐能力会低于批处理,但这个可以通过增加计算资源来弥补。
Kappa 架构的重新处理过程:
重新处理是人们对 Kappa 架构最担心的点,但实际上并不复杂:
- 选择一个具有重放功能的、能够保存历史数据并支持多消费者的消息队列,根据需求设置历史数据保存的时长,比如 Kafka,可以保存全部历史数据。
- 当某个或某些指标有重新处理的需求时,按照新逻辑写一个新作业,然后从上游消息队列的最开始重新消费,把结果写到一个新的下游表中。
- 当新作业赶上进度后,应用切换数据源,读取 2 中产生的新结果表。
- 停止老的作业,删除老的结果表。
4.4 Lambda 架构与 Kappa 架构的对比
- 在真实的场景中,很多时候并不是完全规范的 Lambda 架构或 Kappa 架构,可以是两者的混合,比如大部分实时指标使用 Kappa 架构完成计算,少量关键指标(比如金额相关)使用 Lambda 架构用批处理重新计算,增加一次校对过程。
- Kappa 架构并不是中间结果完全不落地,现在很多大数据系统都需要支持机器学习(离线训练),所以实时中间结果需要落地对应的存储引擎供机器学习使用,另外有时候还需要对明细数据查询,这种场景也需要把实时明细层写出到对应的引擎中。参考后面的案例。
- 另外,随着数据多样性的发展,数据仓库这种提前规定 schema 的模式显得越来难以支持灵活的探索&分析需求,这时候便出现了一种数据湖技术,即把原始数据全部缓存到某个大数据存储上,后续分析时再根据需求去解析原始数据。简单的说,数据仓库模式是 schema on write,数据湖模式是 schema on read。
5.实时数仓案例
菜鸟仓配实时数据仓库本案例参考自菜鸟仓配团队的分享,涉及全局设计、数据模型、数据保障等几个方面。
注:特别感谢缘桥同学的无私分享。
5.1 整体设计
整体设计如下图,基于业务系统的数据,数据模型采用中间层的设计理念,建设仓配实时数仓;计算引擎,选择更易用、性能表现更佳的实时计算作为主要的计算引擎;数据服务,选择天工数据服务中间件,避免直连数据库,且基于天工可以做到主备链路灵活配置秒级切换;数据应用,围绕大促全链路,从活动计划、活动备货、活动直播、活动售后、活动复盘五个维度,建设仓配大促数据体系。
5.2 数据模型
不管是从计算成本,还是从易用性,还是从复用性,还是从一致性等等,我们都必须避免烟囱式的开发模式,而是以中间层的方式建设仓配实时数仓。与离线中间层基本一致,我们将实时中间层分为两层。
- 第一层 DWD 公共实时明细层
实时计算订阅业务数据消息队列,然后通过数据清洗、多数据源 join、流式数据与离线维度信息等的组合,将一些相同粒度的业务系统、维表中的维度属性全部关联到一起,增加数据易用性和复用性,得到最终的实时明细数据。这部分数据有两个分支,一部分直接落地到 ADS,供实时明细查询使用,一部分再发送到消息队列中,供下层计算使用;
- 第二层 DWS 公共实时汇总层
以数据域+业务域的理念建设公共汇总层,与离线数仓不同的是,这里汇总层分为轻度汇总层和高度汇总层,并同时产出,轻度汇总层写入 ADS,用于前端产品复杂的 olap 查询场景,满足自助分析和产出报表的需求;高度汇总层写入 Hbase,用于前端比较简单的 kv 查询场景,提升查询性能,比如实时大屏等;
注:
- ADS 是一款提供 OLAP 分析服务的引擎。开源提供类似功能的有,Elastic Search、Kylin、Druid 等;
- 案例中选择把数据写入到 Hbase 供 KV 查询,也可根据情况选择其他引擎,比如数据量不多,查询压力也不大的话,可以用 MySQL;
- 因主题建模与业务关系较大,这里不做描述;
5.3 数据保障
阿里巴巴每年都有双十一等大促,大促期间流量与数据量都会暴增。实时系统要保证实时性,相对离线系统对数据量要更敏感,对稳定性要求更高。所以为了应对这种场景,还需要在这种场景下做两种准备:
- 大促前的系统压测;
- 大促中的主备链路保障;
菜鸟双11「仓储配送数据实时化」详情了解~
6. 实时数仓与离线数仓的对比
在看过前面的叙述与菜鸟案例之后,我们看一下实时数仓与离线数仓在几方面的对比:
- 首先,从架构上,实时数仓与离线数仓有比较明显的区别,实时数仓以 Kappa 架构为主,而离线数仓以传统大数据架构为主。Lambda 架构可以认为是两者的中间态。
- 其次,从建设方法上,实时数仓和离线数仓基本还是沿用传统的数仓主题建模理论,产出事实宽表。另外实时数仓中实时流数据的 join 有隐藏时间语义,在建设中需注意。
- 最后,从数据保障看,实时数仓因为要保证实时性,所以对数据量的变化较为敏感。在大促等场景下需要提前做好压测和主备保障工作,这是与离线数据的一个较为明显的区别。
▼ Apache Flink 社区推荐 ▼
Apache Flink 及大数据领域顶级盛会 Flink Forward Asia 2019 重磅开启,目前正在征集议题,限量早鸟票优惠ing。了解 Flink Forward Asia 2019 的更多信息,请查看:
https://developer.aliyun.com/special/ffa2019
首届 Apache Flink 极客挑战赛重磅开启,聚焦机器学习与性能优化两大热门领域,40万奖金等你拿,加入挑战请点击:
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
KGB知识图谱,利用科技解决传统知识图谱问题
随着互联网巨头对知识图谱领域的重视度提高,知识图谱的发展也在增快。现在的知识图谱应用还处在初期的阶段,还未实现大规模应用,但是知识图谱的运用已经在一些领域实现了高价值运用,解决了大数据处理中的诸多难题。我们可以预想到,知识图谱在之后的前沿研究中也将不断实现新的应用,其重要性的问题也将得到学术界和产业界的协力解决。在知识图谱的构建方面,传统知识图谱存在局限性。传统知识图谱不具有深度知识结构,无法解决专业的业务问题。将专业领域知识赋予机器,让机器代替业务人员从事简单知识工作,实现重复性、基础性劳动的智能化过程。同时,传统领域知识图谱主要采用专家人工构建费时费力的方式,投入极大且效率不高,急需自动化、智能化构建行业知识图谱的工具。KGB(Knowledge Graph Builder)知识图谱引擎是自主研发的知识图谱构建与推理引擎,基于汉语词法分析的基础上,采用KGB语法实现了实时高效的知识生成,可以从非结构化文本中抽取各类知识,并实现了从表格中抽取指定的内容等。KGB同时可以定义不同的动作,如抽取动作,并能自定义各类后处理程序。利用KGB知识图谱引擎可以抽取到产品的详细报价信息,方便进行下...
- 下一篇
RocketMQ 主从同步若干问题答疑
温馨提示:建议参考代码RocketMQ4.4版本,4.5版本引入了多副本机制,实现了主从自动切换,本文并不关心主从切换功能。 1、初识主从同步 主从同步基本实现过程如下图所示: RocketMQ 的主从同步机制如下: A. 首先启动Master并在指定端口监听;B. 客户端启动,主动连接Master,建立TCP连接;C. 客户端以每隔5s的间隔时间向服务端拉取消息,如果是第一次拉取的话,先获取本地commitlog文件中最大的偏移量,以该偏移量向服务端拉取消息;D. 服务端解析请求,并返回一批数据给客户端;E. 客户端收到一批消息后,将消息写入本地commitlog文件中,然后向Master汇报拉取进度,并更新下一次待拉取偏移量;F. 然后重复第3步; RocketMQ主从同步一个重要的特征:主从同步不具备主从切换功能,即当主节点宕机后,从不会接管消息发送,但可以提供消息读取。 温馨提示:本文并不会详细分析RocketMQ主从同步的实现细节,如大家对其感兴趣,可以查阅笔者所著的《RocketMQ技术内幕》或查看笔者博文:https://blog.csdn.net/prestigedin...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS关闭SELinux安全模块
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- Hadoop3单机部署,实现最简伪集群
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS6,CentOS7官方镜像安装Oracle11G
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS8编译安装MySQL8.0.19
- CentOS6,7,8上安装Nginx,支持https2.0的开启