将 ETL 任务减少 30.docx
《将 ETL 任务减少 30.docx》由会员分享,可在线阅读,更多相关《将 ETL 任务减少 30.docx(16页珍藏版)》请在得力文库 - 分享文档赚钱的网站上搜索。
1、京东零售数据仓库演进之路导读:京东零售十年交易额快速增长的背后,不仅是京东零售高速开展 的十年,也是数据仓库技术架构演进创新的十年,EB级数据如何进行资 产化沉淀和治理?如何支撑业务高速开展、精细化运营、规模化创新的 不同阶段?在未来更加复杂多变的环境下,将如何持续演进? 尹翔编辑:老鱼今天的提供主要分为以下三个局部。第一局部:首先回顾一下大数据在国内的开展历程第二局部:介绍随着京东的快速开展,大数据在内部经历的几个主要阶段第三局部:京东零售数仓核心能力和场景实践01大数据在国内的开展历程大数据的开展,大体来讲可以分为三个阶段:DTCC;as,匿,木,东中国壮曙感技术大会数据资产管理:基于元数
2、据的数据资产化服务浦盖数据资产规划、建设、采集.盘点、治理、评估、应用等环节从数据的可有可用,升级到对质、平安.服务的全面贯通技术元B道甘璟元麦纲分析S数据资产管理方面,我们的思路是,围绕数据的全生命周期,去构建丰富的元数据, 基于元数据进行数据治理、并提供资产化的服务。整个过程链接了数据生产者和数 据消费者两端,我们涵盖了从数据资产的规划、建设、采集、盘点、评估、应用、 销毁等环节。元数据分类上,我们切分了两个维度,一方面包括了元数据的范围,比方模型元数 据、指标元数据、标签元数据等,尽可能的丰富,另一方面从类型上,也划分成技 术元数据、业务元数据、管理元数据等,从更丰富的分析数据资产情况。
3、基于元数据的治理方面上,我们从数据生命周期管理、数据质量、数据平安共享、 数据地图、数据百科、数据血缘这几个方面为数据治理提供更多的抓手,来保证数 据资产的高质量,最后再将这些高质量的数据资产,通过服务化的方式提供给数据 消费者,降低数据消费门槛。I数据质保障:“前中后”的数据质和时效保障QICC 2021中国殴蟠JC技术大会生产与开发WW 独立开发环境 版本管理 联布匹濠基于基线管理的时效预警 基找管理 数据质量校版 执行时长监控的警 基线影噫分析快跑通道 队列/任务快蹈 一做快跑 -Mie开发区域(独立)执行失败说控影响分析快速发现仲打包审批场It开发流程-事前发布上线一健回滚生产区域段,
4、皓,木,木用户请求快速修一事后OiindLkMx质量保证方面,我们覆盖了从数据开发过程、到上线后的日常保障,不管是数据质 量,还是数据时效,我们从事前、事中、事后,都提供了高标准的保障能力。事前,在开发阶段,我们有标准的开发流程,并且做到了生产与开发隔离,部署了 独立的开发环境,对任务和脚本也都进行版本管理,并且能够一键发布上线,发也 支持一键回滚,能够快速恢复。事中,在上线后,我们的目标是快速发现问题,通过时间基线去管理任务时效,通 过一些配置化的校验规那么,通过旁路数据质量,一旦发现时效和质量的异常情况, 会 到值班的同学去处理,而且对于不同等级的任务,有不通的预警策略,如果 任务没有被处
5、理,会一直上升到leader,知道任务在处理。所以不管是数据质量的 问题,还是时效性问题,都可以快速发现。事后,也就是发生后问题后,我们通过快跑通道,来到达快速恢复的目标。夜间任 务出现问题产生延迟时,会预测撞线的概率,去触发队列的一件快跑,和一键推迟 的功能,给核心任务让路,来保障时效。I离线:海据快速更新实践-刷面DICC中数鬣鹰技术大会DICC中数鬣鹰技术大会什么是刷惘?背景W感W感百亿数据级的两张甚至多张大 宓表进行关联刷新业务钥要求的丽范图不断扩大, 甚至个另此题希望全量进行刷新明蛔场后上千维度田合下 揖标需要至新进行加利/去重计 苜每日依照新状态下的聚合抠标 来指导当日的运营策略将
6、发生在该sku的历史事实数据,按照最新的sku及岗位等维度信息,进行历史数据回溯接下来,我会介绍一下我们在离线、实时和批流一体上的场景实践和探索。首先是离线上,关于超大数据量快速更新的一个实践,叫刷岗。什么叫做刷岗呢? 简单来说,就是刷新sku、岗位、业务人员的关系,来控制权限。他是京东零售内 部非常典型的业务场景,京东上有几百亿的sku,成千上万的品类,京东的采销业 务人员,管理商品的颗粒度非常细,在行业内基本都是按照类目、或者按照店铺去 管理,但是在京东特有的自营和pop模式的特点下,就需要按照sku的颗粒度去管 理生意,并且控制权限,每个人只能看到自己管理的商品。这样就需要建立Sku和
7、岗位和人的关系,比方采销员可以看哪些sku,部门经理可以看哪些,总监可以看 哪些都不一样。但是,采销业务经常会发生岗位调整,每次调整就需要去刷新sku和 岗位的关系。举个例子,一个采销员之前负责小米,今天负责华为,那么就需要按 照华为对应的岗位,去更新历史数据,这样才能保障调整岗位之后,可以正常看到 历史数据。而且每天都有大量的岗位调整,小到采销员,大到部门品类负责人,这 就是刷刚的场景。I离线:海睢快速更新实践-刷岗融合数据刷新服务OLAP : Okkhouse local joinSpark 预计菖:bloom filter iceberg融合数据刷新服务OLAP : Okkhouse l
8、ocal joinSpark 预计菖:bloom filter iceberg峥层服务层相际计算睡察诊图 多燃分析cf响应时长限滋 烟距 踣由 一.日近分析热点的g坳斟”DIM Metric政妪刷新政妪刷新任务分发全量刷新 Spark, Hive 全更廉增昆刷新OLAP S凌济dickhouse ohp -优化18件 . | Job Distributor分发策吟字段西轻度震合增H表优化组件bloom filtercustomDaMonrripAft RSSSparK Hive Chckhoyse local join 数粼质处理: 字段被剪、磔合 增量维衷:时间分区结*非结大概分成四个阶段,
9、最开始数据量并不大,我们就简单粗暴的全量刷新。到后来, 我们发现数据量增长的特别快,作业跑的越来越慢,而且经常跑不出来,所以后来 我们想了一些方法,对数据进行预处理,比方对事实表做一些列的裁剪、轻度聚合, 对商品维表,只保存那些变化的信息,这样可以大幅缩小数据量,我们把这个方案 叫增量刷岗,刷完之后,进行各种维度的计算,存在hive里,再提供到业务。第三个阶段,我们发现业务看数据的视角越来越丰富,维度组合非常的多,甚至上 千种,而且遇到uv、用户数这种需要去重的指标,每种维度组合都需要计算出来结 果,过去通过离线预计算的方式,不管是带来的资源消耗、存储消耗、以及人力投 入都是巨大的,因此我们拆
10、分出来一些细颗粒度的维度场景,把事实和维度都导入 到olap中,我们使用的是ck,通过local join根据查询需求随时进行刷岗、聚合, 大大降低了维护本钱、以及资源本钱。到现在,我们已经形成了融合多种刷刚方案的服务,我们也在尝试利用iceberg的 事务更新的特性,进行优化,只更新有变化的那些条记录,也能够大幅减少数据量。在实时数仓上的实践,我们目前主要也是用业内主流的Flink+kafka的方案,来搭 建数仓。原来的方式,我们会设计三层,每一层都物化成topic,发到kafka里, 我们发现,这种方式建数仓,层级比拟多,而且也很难像离线一样建设大宽表,因 为这样会导致时延性增加,而且消耗
11、的存储和计算资源也比拟多。因此我们也是借 鉴视图的思路,把实时数仓的建模过程全部逻辑化,将逻辑模型的定义、结构、处 理逻辑片段等信息,存储在元数据中,通过这种方式把逻辑模型体系搭建起来。最后会跟据应用层需要的计算的数据,将使用到的逻辑模型的代码片段,进行裁剪 利优化,生成最优的执行计划,并生成任务。并且呢,当我们也会识别数仓中的热 点路径和关键模型节点,再进行数仓模型的物化。这样我们在前期就可以参照离线 模型体系,比拟低本钱的构建逻辑化的实时数仓模型。从前面的提供也可以看到,我们现在还是非常典型的lambda架构,实时和离线分 开去计算,使用的都是不同的存储和计算框架,最后再放到统一的存储引擎
12、中,给 上层应用提供给数据服务。这种方案,目前看还是存在了一些痛点:1、需要同时维护了实时、离线两套计算 框架,运维的本钱比拟高,2、实时和离线数据口径要对齐,因此在两套开发框架 上,要实现两套业务逻辑相同的代码,开发本钱也很高,而且随时时间的推移,链 条链路上都在各自迭代,非常容易造成数据的不一致;3、另外,如果完全依赖实时数据,对消息队列的存储要求又很高,持久化存储带来的本钱非常高,而且数据 回溯的能力也不如离线。因此,我们内部也在实践流批一体的数据湖解决方案,在一些场景上去落地。数据 湖和数仓有什么区别呢,基于hive的数仓的方案上其实也是有些痛点,比方不支 持事物,并发往数仓读写入数据
13、,可能会存在一些问题,不支持数据的更新,数据 修正的本钱就比拟大,需要重写分区,schame变更的本钱也比拟大,变更了之后需 要重写数据,整体的数据时效也是比拟长的。数据湖的特性,在一定程度上是可以 解决这些问题,支持ACID的事物读写,这样读和写就可以并发的进行,没有提交 的数据就不会被读取到,支持upsertt,很方便的进行数据行级别的更新,table revolution,可以很低本钱的变更schame,并且不需要重写数据,同时批流的读写 接口,可以增量读取数据,来提升时效性。我们最终是选取iceberg的方案,delta lake是深度绑定spark的,不支持其他计 算引擎。hudi
14、一开始也是深度绑定spark,底层直接使用spark的rdd,后来才重 构的。iceberg一开始架构就比拟独立,有自己的数据类型和schema,不依赖其他 计算引擎。利用Iceberg表的增量读取更新,以及对批流都有友好的接口支持,来构建批流一 体的实时数据湖。上游实时数据,经过Flink或者spark streaming的加工,存储 到Iceberg中,Iceberg又作为实时源,供下一层使用,最终通过hbase、ck这些 引擎,给上层应用提供服务,整体的数据延迟,基本上是分钟级的,而且每一层Iceberg表,也都是持久化的存储,上面这些spark、fl ink等等计算引擎,也都是可以读写
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- ETL 任务减少 30 任务 减少
限制150内