百事3 > 综合排行榜 > 科技 > 数码 > 关于数据仓库建设,了解这7点就够了_架构

百事3专注指数排名,具有影响力的品牌排行榜门户网站之一。

关于数据仓库建设,了解这7点就够了_架构

来 源:时间:2020-08-24阅读量:

之前发了一篇数据仓库的文章,发现大家对数据仓库还是非常感兴趣的。今天再和大家一起聊聊实时数仓吧!

实时数仓可谓是决定性的东西,能决定什么?决定你的报表和BI到底能不能实时展现数据。

01 数据仓库的发展趋势 1.1 数据仓库的趋势

关于数据仓库的概念就不多介绍了。

数据仓库是伴随着企业信息化发展起来的,在企业信息化的过程中,随着信息化工具的升级和新工具的应用,数据量变得越来越大,数据格式越来越多,决策要求越来越苛刻,数据仓库技术也在不停的发展。

数据仓库的趋势:

关于数据仓库建设,了解这7点就够了_架构(www.ppzsb.com)

1.2 数据仓库的发展

数据仓库有两个环节:数据仓库的构建与数据仓库的应用。

早期数据仓库构建主要指的是把企业的业务数据库如 ERP、CRM、SCM 等数据按照决策分析的要求建模并汇总到数据仓库引擎中,其应用以报表为主,目的是支持管理层和业务人员决策(中长期策略性决策)。

随着业务和环境的发展,这两方面都在发生着剧烈变化。

随着IT技术走向互联网、移动化,数据源变得越来越丰富,在原来业务数据库的基础上出现了非结构化数据,比如网站 log,IoT 设备数据,APP 埋点数据等,这些数据量比以往结构化的数据大了几个量级,对 ETL 过程、存储都提出了更高的要求。

互联网的在线特性也将业务需求推向了实时化,随时根据当前客户行为而调整策略变得越来越常见,比如大促过程中库存管理,运营管理等(即既有中远期策略型,也有短期操作型);同时公司业务互联网化之后导致同时服务的客户剧增,有些情况人工难以完全处理,这就需要机器自动决策,比如欺诈检测和用户审核。

关于数据仓库建设,了解这7点就够了_架构(www.ppzsb.com)

总结来看,对数据仓库的需求可以抽象成两方面:实时产生结果、处理和保存大量异构数据。

02 数据仓库架构的演变

从1990年 Inmon 提出数据仓库概念到今天,数据架构经历了最初的传统数仓架构——离线数仓库——离线大数据架构、Lambda 架构、Kappa 架构以及 Flink 的火热带出的流批一体架构,数据架构技术不断演进,本质是在往流批一体的方向发展,让用户能以最自然、最小的成本完成实时计算。

2.1 传统数仓架构

这是比较传统的一种方式,结构或半结构化数据通过离线ETL定期加载到离线数据,之后通过计算引擎取得结果,供前端使用。这里的离线数仓+计算引擎,通常是使用大型商业数据库来承担,例如Oracle、DB2、Teradata等。

2.2 离线大数据架构

随着数据规模的不断增大,传统数仓方式难以承载海量数据。随着大数据技术的普及,采用大数据技术来承载存储与计算任务。当然,也可以使用传传统数据库集群或MPP架构数据库来完成。例如Hadoop+Hive/Spark、Oracle RAC、GreenPlum等。

2.3 Lambda架构

随着业务的发展,随着业务的发展,人们对数据实时性提出了更高的要求。此时,出现了Lambda架构,其将对实时性要求高的部分拆分出来,增加条实时计算链路。从源头开始做流式改造,将数据发送到消息队列中,实时计算引擎消费队列数据,完成实时数据的增量计算。

与此同时,批量处理部分依然存在,实时与批量并行运行。最终由统一的数据服务层合并结果给予前端。一般是以批量处理结果为准,实时结果主要为快速响应。

2.4 Kappa架构

Lambda架构,一个比较严重的问题就是需要维护两套逻辑。一部分在批量引擎实现,一部分在流式引擎实现,维护成本很高。此外,对资源消耗也较大。而后面诞生的Kappa架构,正是为了解决上述问题。其在数据需要重新处理或数据变更时,可通过历史数据重新处理来完成。

方式是通过上游重放完成(从数据源拉取数据重新计算)。Kappa架构最大的问题是流式重新处理历史的吞吐能力会低于批处理,但这个可以通过增加计算资源来弥补。

2.5混合架构

上述架构各有其适应场景,有时需要综合使用上述架构组合满足实际需求。当然这也必将带来架构的复杂度。用户应根据自身需求,有所取舍。在一般大多数场景下,是可以使用单一架构解决问题。现在很多产品在流批一体、海量、实时性方面也有非常好的表现,可以考虑这种“全能手”解决问题。

03 三种大数据数据仓库架构 3.1 离线大数据架构

数据源通过离线的方式导入到离线数据中。下游应用根据业务需求选择直接读取 DM 或加一层数据服务,比如 MySQL 或 Redis。数据仓库从模型层面分为三层:

典型的数仓存储是 HDFS/Hive,ETL 可以是 MapReduce 脚本或 HiveSQL。

3.2 Lambda 架构

Lambda 架构问题:

同样的需求需要开发两套一样的代码:这是 Lambda 架构最大的问题,两套代码不仅仅意味着开发困难(同样的需求,一个在批处理引擎上实现,一个在流处理引擎上实现,还要分别构造数据测试保证两者结果一致),后期维护更加困难,比如需求变更后需要分别更改两套代码,独立测试结果,且两个作业需要同步上线。

资源占用增多:同样的逻辑计算两次,整体资源占用会增多,多出实时计算这部分。

关于数据仓库建设,了解这7点就够了_架构(www.ppzsb.com)

3.3 Kappa 架构

Lambda 架构虽然满足了实时的需求,但带来了更多的开发与运维工作,其架构背景是流处理引擎还不完善,流处理的结果只作为临时的、近似的值提供参考。后来随着 Flink 等流处理引擎的出现,流处理技术很成熟了,这是为了解决两套代码的问题,LickedIn 的 Jay Kreps 提出了 Kappa 架构。

Kappa 架构可以认为是 Lambda 架构的简化版(只要移除 lambda 架构中的批处理部分即可)。

在 Kappa 架构中,需求修改或历史数据重新处理都通过上游重放完成。

Kappa 架构最大的问题是流式重新处理历史的吞吐能力会低于批处理,但这个可以通过增加计算资源来弥补。

关于数据仓库建设,了解这7点就够了_架构(www.ppzsb.com)

Kappa 架构的重新处理过程:

关于数据仓库建设,了解这7点就够了_架构(www.ppzsb.com)

3.4 Lambda 架构与 Kappa 架构的对比

关于数据仓库建设,了解这7点就够了_架构(www.ppzsb.com)

在真实的场景中,很多时候并不是完全规范的 Lambda 架构或 Kappa 架构,可以是两者的混合,比如大部分实时指标使用 Kappa 架构完成计算,少量关键指标(比如金额相关)使用 Lambda 架构用批处理重新计算,增加一次校对过程。

Kappa 架构并不是中间结果完全不落地,现在很多大数据系统都需要支持机器学习(离线训练),所以实时中间结果需要落地对应的存储引擎供机器学习使用,另外有时候还需要对明细数据查询,这种场景也需要把实时明细层写出到对应的引擎中。后面案例会涉及到。

关于数据仓库建设,了解这7点就够了_架构(www.ppzsb.com)

04 实时数仓建设思路

最后分享菜鸟仓配实时数据仓库的案例本,涉及全局设计、数据模型、数据保障等几个方面。

5.1 整体设计

整体设计如下图,基于业务系统的数据,数据模型采用中间层的设计理念,建设仓配实时数仓;计算引擎,选择更易用、性能表现更佳的实时计算作为主要的计算引擎;数据服务,选择天工数据服务中间件,避免直连数据库,且基于天工可以做到主备链路灵活配置秒级切换;数据应用,围绕大促全链路,从活动计划、活动备货、活动直播、活动售后、活动复盘五个维度,建设仓配大促数据体系。

关于数据仓库建设,了解这7点就够了_架构(www.ppzsb.com)

5.2 数据模型

不管是从计算成本,还是从易用性,还是从复用性,还是从一致性等等,都必须避免烟囱式的开发模式,而是以中间层的方式建设仓配实时数仓。与离线中间层基本一致,将实时中间层分为两层。

最底层是收集层,这一层负责收集用户的实时数据,包括 Binlog、后端服务日志以及 IoT 数据,经过日志收集团队和 DB 收集团队的处理,数据将会被收集到 Kafka 中。这些数据不只是参与实时计算,也会参与离线计算。

收集层之上是存储层,这一层除了使用 Kafka 做消息通道之外,还会基于 HDFS 做状态数据存储以及基于 HBase 做维度数据的存储。

存储层之上是引擎层,包括 Storm 和 Flink。实时计算平台会在引擎层为用户提供一些框架的封装以及公共包和组件的支持。

在引擎层之上就是平台层了,平台层从数据、任务和资源三个视角去管理。

架构的最上层是应用层,包括了实时数仓、机器学习、数据同步以及事件驱动应用等。

从功能角度来看,美团点评的实时计算平台主要包括作业和资源管理两个方面的功能。其中,作业部分包括作业配置、作业发布以及作业状态三个方面的功能。

在资源管理方面,则为用户提供了多租户资源隔离以及资源交付和部署的能力。

07 实时数仓与离线数仓的对比

在看过前面的案例之后,我们看一下实时数仓与离线数仓在几方面的对比:

综上,实时数仓主要解决数据时效性问题,结合机器学习框架可以处理实时推荐、实时获取广告投放效果等智能化业务场景。实时数仓的建设应早日提上日程,未来企业对数据时效性的要求会越来越高,实时数仓会很好的解决该问题。

本文由 @李启方 原创发布于人人都是产品经理。未经许可,禁止转载

数码相关文章