邯郸做移动网站的地方,wordpress 页面 父级,彩票网站开发 合法,呼伦贝尔网站建设呼伦贝尔1 数仓分层
1.1 数仓分层的意义
**数据复用#xff0c;减少重复开发#xff1a;**规范数据分层#xff0c;开发一些通用的中间层数据#xff0c;能够减少极大的重复计算。数据的逐层加工原则#xff0c;下层包含了上层数据加工所需要的全量数据#xff0c;这样的加工方…1 数仓分层
1.1 数仓分层的意义
**数据复用减少重复开发**规范数据分层开发一些通用的中间层数据能够减少极大的重复计算。数据的逐层加工原则下层包含了上层数据加工所需要的全量数据这样的加工方式避免了每个数据开发人员都重新从源系统抽取数据进行加工。通过汇总层的引人避免了下游用户逻辑的重复计算 节省了用户的开发时间和精力同时也节省了计算和存储。极大地减少不必要的数据冗余也能实现计算结果复用极大地降低存储和计算成本。**数据血缘追踪**简单来讲可以这样理解我们最终给业务呈现的是一张直接使用的业务表但是它的来源有很多如果有一张来源表出问题了我们希望能够快速准确地定位到问题并清楚它的危害范围。**把复杂问题简单化。**讲一个复杂的任务分解成多个步骤来完成每一层只处理单一的步骤比较简单和容易理解。而且便于维护数据的准确性当数据出现问题之后可以不用修复所有的数据只需要从有问题的步骤开始修复。
1.2 数仓分层规范
数仓从下往上一般分ODS-DWD-DWS-ADS 4层。 2 主流数仓架构
目前主流数据仓库建设主要分两种基于Lakehouse(湖仓一体)的流批一体架构和基于MPP数据库的轻量级数据仓库。 一个企业数仓的整体逻辑如上图所示数仓在构建的时候通常需要 ETL 处理和分层设计基于业务系统采集的结构化和非结构化数据进行各种 ETL 处理成为 DWD 层再基于 DWD 层设计上层的数据模型层形成 DM中间会有 DWB/DWS 作为部分中间过程数据。
从技术选型来说从数据源的 ETL 到数据模型的构建通常需要长时任务也就是整个任务的运行时间通常是小时及以上级别。而 DM 层主要是支持业务的需求对实效性要求比较高通常运行在 DM 层上的任务时间在分钟作为单位。
基于如上的分层设计的架构图可以发现虽然目前有非常多的组件像 PrestoDorisClickHouseHive 等等但是这些组件各自工作在不同的场景下像数仓构建和交互式分析就是两个典型的场景。
交互式分析强调的是时效性一个查询可以快速出结果像 PrestoDorisClickHouse 虽然也可以处理海量数据甚至达到 PB 及以上但是主要还是是用在交互式分析上也就是基于数据仓库的 DM 层给用户提供基于业务的交互式分析查询方便用户快速进行探索。由于这类引擎更聚焦在交互式分析上因此对于长时任务的支持度并不友好为了达到快速获取计算结果这类引擎重度依赖内存资源需要给这类服务配置很高的硬件资源这类组件通常有着如下约束
没有任务级的重试失败了只能重跑 Query代价较高。一般全内存计算无 shuffle 或 shuffle 不落盘无法执行海量数据。架构为了查询速度快执行前已经调度好了 task 执行的节点节点故障无法重新调度。
一旦发生任务异常例如网络抖动引起的任务失败机器宕机引起的节点丢失再次重试所消耗的时间几乎等于全新重新提交一个任务在分布式任务的背景下任务运行的时间越长出现错误的概率越高对于此类组件的使用业界最佳实践的建议也是不超过 30 分钟左右的查询使用这类引擎是比较合适的。
而在离线数仓场景下几乎所有任务都是长时任务也就是任务运行时常在小时及以上这时就要求执行 ETL 和构建数仓模型的组件服务需要具有较高的容错性和稳定性当任务发生错误的时候可以以低成本的方式快速恢复尽可能避免因为部分节点状态异常导致整个任务完全失败。
可以发现在这样的诉求下类似于 PrestoDorisClickHouse 就很难满足这样的要求而像 HiveSpark 这类计算引擎依托于 Yarn 做资源管理对于分布式任务的重试调度切换有着非常可靠的保证。HiveSpark 等组件自身基于可重算的数据落盘机制确保某个节点出现故障或者部分任务失败后可以快速进行恢复。数据保存于 HDFS 等分布式存储系统上自身不管理数据具有极高的稳定性和容错处理机制。
反过来因为 HiveSpark 更善于处理这类批处理的长时任务因此这类组件不擅长与上层的交互式分析对于这种对于时效性要求更高的场景都不能很好的满足。所以在考虑构建数仓的时候通常会选择 HiveSpark 等组件来负责而在上层提供交互式分析查询的时候通常会使用 PrestoDorisClickHouse 等组件。
归纳下来如下
**DorisClickHousePresto**更注重交互式分析对单机资源配置要求很高重度依赖内存缺乏容错恢复任务重试等机制适合于 30 分钟以内的任务通常工作在企业的 DM 层直接面向业务处理业务需求。**SparkHive**更注重任务的稳定性对网络IO 要求比较高有着完善的中间临时文件落盘节点任务失败的重试恢复更加合适小时及以上的长时任务运行工作在企业的的 ETL 和数据模型构建层负责清洗和加工上层业务所需要的数据用来支撑整个企业的数仓构建。
2.1 基于湖仓一体的流批一体架构
目前市面上核心的数据湖开源产品大致有这么几个Apache Hudi、Apache Iceberg和 Delta。国内使用jiao较多的为Apache Hudi。 此架构可以满足目前业务需求
批处理采用Spark 进行批处理加工任务流处理采用Flink Hudi完成流处理任务交互式分析离线数据采用导入到Doris或者Doris联邦查询的方式进行交互式分析实时数据ADS层直接在Doris提供交互式分析能力。机器学习机器学习应用采用分布式机器学习框架Spark ML进行模型训练。
优点 超大规模大数据平台主流架构经过主流大厂验证运行稳定可靠。 实时场景支持数仓分层模型可支持复杂逻辑大量数据的实时增量计算。 实时数仓基于 Flink-SQL 实现了流批一体批处理和流处理同一套代码代码维护成本低 存储数据多元化结构化数据、半结构化数据和非结构化数据都能存储。
缺点
组件过多数据链路长运维成本高对开发人员要求高。组件过多成本高。
2.2 基于MPP数据库的轻量级数据仓库
目前主流开源OLAP MPP数据库有 Doris, ClickHouse, Presto等尤其以Doris势头强劲。 此架构可以满足目前业务需求
批处理采用DorisSQL进行批处理任务加工。流处理采用Flink Doris完成ODS层的实时构建后面采用DorisSQL定时调度完成增量数据的构建。交互式分析使用Doris对外提供服务。机器学习机器学习应用采用分布式机器学习框架Spark ML进行模型训练。但是每次模型训练都需要从Doris中读取数据给Doris造成压力。
优点
组件单一数据链路少运维成本低对开发人员要求低。组件单一建设成本低。
缺点
实时场景不支持数仓分层模型批处理也在Doris加工Doris是基于内存计算的当大规模数据量进行加工时容易遇到瓶颈。
2.3 湖仓一体和MPP对比
开源数仓架构数据量运维成本开发成本团队人数湖仓一体Hudi0-100PB级高高10人以上MPPDoris10PB以下低低10人以下
