看完了这篇实时数仓建设，才发现以前的都白看了.pdf-资料库

weixin_38698863-15441586-4744300845389762593.pdf-第1页.png

第1页 / 共9页

weixin_38698863-15441586-4744300845389762593.pdf-第2页.png

第2页 / 共9页

weixin_38698863-15441586-4744300845389762593.pdf-第3页.png

第3页 / 共9页

weixin_38698863-15441586-4744300845389762593.pdf-第4页.png

第4页 / 共9页

weixin_38698863-15441586-4744300845389762593.pdf-第5页.png

第5页 / 共9页

weixin_38698863-15441586-4744300845389762593.pdf-第6页.png

第6页 / 共9页

weixin_38698863-15441586-4744300845389762593.pdf-第7页.png

第7页 / 共9页

weixin_38698863-15441586-4744300845389762593.pdf-第8页.png

第8页 / 共9页

看完了这篇实时数仓建设，才发现以前的都白看了看完了这篇实时数仓建设，才发现以前的都白看了 1、数据仓库的发展趋势 1.1 数据仓库的趋势关于数据仓库的概念就不多介绍了。数据仓库是伴随着企业信息化发展起来的，在企业信息化的过程中，随着信息化工具的升级和新工具的应用，数据量变得越来越大，数据格式越来越多，决策要求越来越苛刻，数据仓库技术也在不停的发展。数据仓库的趋势：实时数据仓库以满足实时化&自动化决策需求大数据&数据湖以支持大量&复杂数据类型? 1.2 数据仓库的发展数据仓库有两个环节：数据仓库的构建与数据仓库的应用。早期数据仓库构建主要指的是把企业的业务数据库如 ERP、CRM、SCM 等数据按照决策分析的要求建模并汇总到数据仓库引擎中，其应用以报表为主，目的是支持管理层和业务人员决策（中长期策略型决策）。随着业务和环境的发展，这两方面都在发生着剧烈变化。随着IT技术走向互联网、移动化，数据源变得越来越丰富，在原来业务数据库的基础上出现了非结构化数据，比如网站 log，IoT 设备数据，APP 埋点数据等，这些数据量比以往结构化的数据大了几个量级，对 ETL 过程、存储都提出了更高的要求。互联网的在线特性也将业务需求推向了实时化，随时根据当前客户行为而调整策略变得越来越常见，比如大促过程中库存管理，运营管理等（即既有中远期策略型，也有短期操作型）；同时公司业务互联网化之后导致同时服务的客户剧增，有些情况人工难以完全处理，这就需要机器自动决策，比如欺诈检测和用户审核。

总结来看，对数据仓库的需求可以抽象成两方面：实时产生结果、处理和保存大量异构数据。 2、数据仓库架构的演变从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混合架构上述架构各有其适应场景，有时需要综合使用上述架构组合满足实际需求。当然这也必将带来架构的复杂度。用户应根据自身需求，有所取舍。在一般大多数场景下，是可以使用单一架构解决问题。现在很多产品在流批一体、海量、实时性方面也有非常好的表现，可以考虑这种“全能手”解决问题。 3、三种大数据数据仓库架构 3.1 离线大数据架构数据源通过离线的方式导入到离线数据中。下游应用根据业务需求选择直接读取 DM 或加一层数据服务，比如 MySQL 或 Redis。数据仓库从模型层面分为三层： ODS，操作数据层，保存原始数据； DWD，数据仓库明细层，根据主题定义好事实与维度表，保存最细粒度的事实数据； DM，数据集市/轻度汇总层，在 DWD 层的基础之上根据不同的业务需求做轻度汇总；典型的数仓存储是 HDFS/Hive，ETL 可以是 MapReduce 脚本或 HiveSQL。

3.2 Lambda 架构 Lambda 架构问题：同样的需求需要开发两套一样的代码：这是 Lambda 架构最大的问题，两套代码不仅仅意味着开发困难（同样的需求，一个在批处理引擎上实现，一个在流处理引擎上实现，还要分别构造数据测试保证两者结果一致），后期维护更加困难，比如需求变更后需要分别更改两套代码，独立测试结果，且两个作业需要同步上线。资源占用增多：同样的逻辑计算两次，整体资源占用会增多，多出实时计算这部分

3.3 Kappa 架构 Lambda 架构虽然满足了实时的需求，但带来了更多的开发与运维工作，其架构背景是流处理引擎还不完善，流处理的结果只作为临时的、近似的值提供参考。后来随着 Flink 等流处理引擎的出现，流处理技术很成熟了，这时为了解决两套代码的问题，LickedIn 的 Jay Kreps 提出了 Kappa 架构。 Kappa 架构可以认为是 Lambda 架构的简化版（只要移除 lambda 架构中的批处理部分即可）。在 Kappa 架构中，需求修改或历史数据重新处理都通过上游重放完成。 Kappa 架构最大的问题是流式重新处理历史的吞吐能力会低于批处理，但这个可以通过增加计算资源来弥补。

Kappa 架构的重新处理过程： 3.4 Lambda 架构与 Kappa 架构的对比在真实的场景中，很多时候并不是完全规范的 Lambda 架构或 Kappa 架构，可以是两者的混合，比如大部分实时指标使用 Kappa 架构完成计算，少量关键指标（比如金额相关）使用 Lambda 架构用批处理重新计算，增加一次校对过程。 Kappa 架构并不是中间结果完全不落地，现在很多大数据系统都需要支持机器学习（离线训练），所以实时中间结果需要落地对应的存储引擎供机器学习使用，另外有时候还需要对明细数据查询，这种场景也需要把实时明细层写出到对应的引擎中。后面案例会涉及到。

4、实时数仓建设思路计算框架选型：storm/flink等实时计算框架，强烈推荐flink，其『批量合一』的特性及活跃的开源社区，有逐渐替代spark的趋势。数据存储选型：首要考虑查询效率，其次是插入、更新等问题，可选择apache druid，不过在数据更新上存在缺陷，选型时注意该问题频繁更新的数据建议不要采用该方案。当然存储这块需要具体问题具体分析，不同场景下hbase、redis等都是可选项。实时数仓分层：为更好的统一管理数据，实时数仓可采用离线数仓的数据模型进行分层处理，可以分为实时明细层写入druid 等查询效率高的存储方便下游使用；轻度汇总层对数据进行汇总分析后供下游使用。数据流转方案：实时数仓的数据来源可以为kafka消息队列，这样可以做到队列中的数据即可以写入数据湖用于批量分析，也可以实时处理，下游可以写入数据集市供业务使。 5、菜鸟实时数仓案例最后分享菜鸟仓配实时数据仓库的案例本，涉及全局设计、数据模型、数据保障等几个方面。 5.1 整体设计整体设计如下图，基于业务系统的数据，数据模型采用中间层的设计理念，建设仓配实时数仓；计算引擎，选择更易用、性能表现更佳的实时计算作为主要的计算引擎；数据服务，选择天工数据服务中间件，避免直连数据库，且基于天工可以做到主备链路灵活配置秒级切换；数据应用，围绕大促全链路，从活动计划、活动备货、活动直播、活动售后、活动复盘五个维度，建设仓配大促数据体系。

5.2 数据模型不管是从计算成本，还是从易用性，还是从复用性，还是从一致性等等，都必须避免烟囱式的开发模式，而是以中间层的方式建设仓配实时数仓。与离线中间层基本一致，将实时中间层分为两层。第一层 DWD 公共实时明细层。实时计算订阅业务数据消息队列，然后通过数据清洗、多数据源 join、流式数据与离线维度信息等的组合，将一些相同粒度的业务系统、维表中的维度属性全部关联到一起，增加数据易用性和复用性，得到最终的实时明细数据。这部分数据有两个分支，一部分直接落地到 ADS，供实时明细查询使用，一部分再发送到消息队列中，供下层计算使用。第二层 DWS 公共实时汇总层。以数据域+业务域的理念建设公共汇总层，与离线数仓不同的是，这里汇总层分为轻度汇总层和高度汇总层，并同时产出，轻度汇总层写入 ADS，用于前端产品复杂的 olap 查询场景，满足自助分析和产出报表的需求；高度汇总层写入 Hbase，用于前端比较简单的 kv 查询场景，提升查询性能，比如实时大屏等。 6、美团点评基于Flink的实时数仓平台实践下图所示的是美团点评实时计算平台的架构

资料库

看完了这篇实时数仓建设，才发现以前的都白看了.pdf

相关推荐

开发技术

热门标签

最新资料