首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >数据模型⽆法复⽤,归根结底还是设计问题

数据模型⽆法复⽤,归根结底还是设计问题

作者头像
王知无-import_bigdata
发布于 2020-08-20 03:03:30
发布于 2020-08-20 03:03:30
9200
举报

如果把指标⽐喻成⼀棵树上的果实,那模型就是这棵⼤树的躯⼲,想让果实结得好,必须让树⼲变得粗壮。真实场景举例:

⼤多数公司的分析师会结合业务做⼀些数据分析(需要⽤到⼤量的数据),通过报表的⽅式服务于业务部⻔的运营。但是在数据中台构建之前,分析师经常发现⾃⼰没有可以复⽤的数据,不得不使⽤原始数据进⾏清洗、加⼯、计算指标。

由于他们⼤多是⾮技术专业出⾝,写的SQL质量⽐较差,甚⾄⻅过5层以上的嵌套。这种SQL对资源消耗⾮常⼤,会造成队列阻塞,影响其他数仓任务,会引起数据开发的不满。数据开发会要求收回分析师的原始数据读取权限,分析师⼜会抱怨数仓数据不完善,要啥没啥,⼀个需求经常要等⼀周甚⾄半个⽉。分析师与数据开发的⽭盾从此开始。

这个⽭盾的根源在于数据模型⽆法复⽤,数据开发是烟囱式的,每次遇到新的需求,都从原始数据重新计算,⾃然耗时。⽽要解决这个⽭盾,就要搞清楚我们的数据模型应该设计成什么样⼦。

什么才是⼀个好的数据模型设计?


来看⼀组数据,这两个表格是基于元数据中⼼提供的⾎缘信息,分别对⼤数据平台上运⾏的任务和分析查询(Ad-hoc)进⾏的统计。

表1:

表2:

下图是数仓分层架构图,⽅便回忆数据模型分层的设计架构:

表1

表1中有2547张未识别分层的表,占总表6049的40%,它们基本没办法复⽤。

重点是在已识别分层的读表任务中,ODS:DWD:DWS:ADS的读取任务分别是1072:545:187:433,直接读取ODS层任务占这四层任务总和的47.9%,这说明有⼤量任务都是基于原始数据加⼯,中间模型复⽤性很差。

表2

在已识别的分层的查询中,ODS:DWD:DWS:ADS的命中的查询分别是892:1008:152:305,有37.8%的查询直接命中ODS层原始数据,说明DWD、DWS、ADS层数据建设缺失严重。尤其是ADS和DWS,查询越底层的表,就会导致查询扫描的数据量会越⼤,查询时间会越⻓,查询的资源消耗也越⼤,使⽤数据的⼈满意度会低。

最后,进⼀步对ODS层被读取的704张表进⾏分解,发现有382张表的下游产出是DWS,ADS,尤其是ADS达到了323张表,占ODS层表的⽐例45.8%,说明有⼤量ODS层表被进⾏物理深加⼯。

通过上⾯的分析,我们似乎已经找到了⼀个理想的数仓模型设计应该具备的因素,那就是“数据模型可复⽤,完善且规范”。

如何衡量完善度


DWD层完善度:衡量DWD层是否完善,最好看ODS层有多少表被DWS/ADS/DM层引⽤。因为DWD以上的层引⽤的越多,就说明越多的任务是基于原始数据进⾏深度聚合计算的,明细数据没有积累,⽆法被复⽤, 数据清洗、格式化、集成存在重复开发。因此,我提出⽤跨层引⽤率指标衡量DWD的完善度。

跨层引⽤率:ODS层直接被DWS/ADS/DM层引⽤的表,占所有ODS层表(仅统计活跃表)⽐例。

跨层引⽤率越低越好,在数据中台模型设计规范中,要求不允许出现跨层引⽤,ODS层数据只能被DWD引⽤。

DWS/ADS/DM层完善度:考核汇总数据的完善度,主要看汇总数据能直接满⾜多少查询需求(也就是⽤汇总层数据的查询⽐例衡量)。如果汇总数据⽆法满⾜需求,使⽤数据的⼈就必须使⽤明细数据,甚⾄是原始数据。

汇总数据查询⽐例:DWS/ADS/DM层的查询占所有查询的⽐例。

要明确的是,这个跟跨层引⽤率不同,汇总查询⽐例不可能做到100%,但值越⾼,说明上层的数据建设越完善,对于使⽤数据的⼈来说,查询速度和成本会减少,⽤起来会更爽。

如何衡量复⽤度


数据中台模型设计的核⼼是追求模型的复⽤和共享,通过元数据中⼼的数据⾎缘图,可以看到,⼀个⽐较差的模型设计,⾃下⽽上是⼀条线。⽽⼀个理想的模型设计,它应该是交织的发散型结构。

模型引⽤系数作为指标,衡量数据中台模型设计的复⽤度。引⽤系数越⾼,说明数仓的复⽤性越好。

模型引⽤系数:⼀个模型被读取,直接产出下游模型的平均数量。

⽐如⼀张DWD层表被5张DWS层表引⽤,这张DWD层表的引⽤系数就是5,如果把所有DWD层表(有下游表的)引⽤系数取平均值,则为DWD层表平均模型引⽤系数,⼀般低于2⽐较差,3以上相对⽐较好(经验值)。

如何衡量规范度


表1中,超过40%的表都没有分层信息,在模型设计层⾯,这显然是不规范的。除了看这个表有没有分层,还要看它有没有归属到主题域(例如交易域)如果没有归属主题域,就很难找到这张表,也⽆法复⽤。

其次,要看表的命名。拿stock这个命名为例,当看到这个表时,知道它是哪个主题域、业务过程?是全量数据的表,还是每天的增量数据?总的来说,通过这个表名获取的信息太有限了。⼀个规范的表命名应该包括主题域、分层、表是全量快照,还是增量等信息。

除此之外,如果在表A中⽤⼾ID的命名是UserID,在表B中⽤⼾ID命名是ID,就会对使⽤者造成困扰,这到底是不是⼀个东西。所以我们要求相同的字段在不同的模型中,它的命名必须是⼀致的。

经验和建议:

1. 可以拿着这些指标去评估⼀下,⾃⼰的数仓现状如何。

2. 然后制订⼀些针对性的改进计划,⽐如把这些不规范命名的表消灭掉,把主题域覆盖的表⽐例提⾼到90%以上。

3. 在尝试完⼀段时间的模型重构和优化后,再拿着这些指标去测⼀测是不是真的变好了。

模型重构到底对数据建设有多少帮助?有没有⼀些量化的指标可以衡量?基于上面的知识已经可以很好回答这两个问题了。

如何从烟囱式的⼩数仓到共享的数据中台

建设数据中台本质就是构建企业的公共数据层,把原先分散的、烟囱式的、杂乱的⼩数仓,合并成⼀个可共享、可复⽤的数据中台。

第⼀,接管ODS层,控制源头。

ODS是业务数据进⼊数据中台的第⼀站,是所有数据加⼯的源头,控制住源头,才能从根本上防⽌⼀个重复的数据体系的出现。

数据中台团队必须明确职责,全⾯接管ODS层数据,从业务系统的源数据库权限⼊⼿,确保数据从业务系统产⽣后进⼊数据仓库时,只能在数据中台保持⼀份。这个可以跟业务系统数据库管理者达成⼀致,只有中台团队的账号才能同步数据。

ODS层表的数据必须和数据源的表结构、表记录数⼀致,⾼度⽆损,对于ODS层表的命名采⽤ODS_业务系统数据库名_业务系统数据库表名⽅式,⽐如ods_warehous_stock,warehous是业务系统数据库名,stock是该库下⾯的表名。

第⼆,划分主题域,构建总线矩阵。

主题域是业务过程的抽象集合。可能这么讲,稍微有点⼉抽象,但其实业务过程就是企业经营过程中⼀个个不可拆分的⾏为事件,⽐如仓储管理⾥⾯有⼊库、出库、发货、签收,都是业务过程,抽象出来的主题域就是仓储域。

主题域划分要尽量涵盖所有业务需求,保持相对稳定性,还具备⼀定的扩展性(新加⼊⼀个主题域,不影响已经划分的主题域的表)。

主题域划分好以后,就要开始构建总线矩阵,明确每个主题域下的业务过程有哪些分析维度,举个例⼦:

第三,构建⼀致性维度。

售后团队的投诉⼯单数量有针对地区的分析维度,⽽配送团队的配送延迟也有针对地区的分析维度,你想分析因为配送延迟导致的投诉增加,但是两个地区的分析维度包含内容不⼀致,最终会导致⼀些地区没办法分析。所以我们构建全局⼀致性的维表,确保维表只存⼀份。

维度统⼀的最⼤的难题在于维度属性(如果维度是商品,那么商品类别、商品品牌、商品尺⼨等商品的属性,我们称为维度属性)的整合。是不是所有维度属性都要整合到⼀个⼤的维表中,也不⻅得,我给你⼏个 建议。

1. 公共维度属性与特有维度属性拆成两个维表。在⾃营平台中,通常也会有⼀些第三⽅的商家⼊驻,但是数 量很少。⼤部分商品其实都没有店铺的属性,这种情况,就不建议将店铺和商品的其他维度属性,⽐如商品类别、品牌设计成⼀个维表。

2. 产出时间相差较⼤的维度属性拆分单独的维表,⽐如有些维度属性产出时间在凌晨2点,有些维度属性产出时间在凌晨6点,那2点和6点的就可以拆成两个维表,确保核⼼维表尽早产出。

3. 出于维表稳定性产出的考虑,你可以将更新频繁的和变化缓慢的进⾏拆分,访问频繁的和访问较少的维表 进⾏拆分。

对于维表的规范化命名,建议⽤“dim_主题域_描述_分表规则”⽅式。分表可以这样理解:⼀个表存 储⼏千亿⾏记录实在是太⼤了,所以需要把⼀个表切割成很多⼩的分区,每天或者每周,随着任务被调度,会⽣成⼀个分区。常⻅的分区规则(用时查询)。

第四,事实表整合。

事实表整合遵循的最基本的⼀个原则是,统计粒度必须保持⼀致,不同统计粒度的数据不能出现在同

⼀个事实表中。来看⼀个例⼦:

在数据中台构建前,供应链部⻔、仓储部⻔和市场部⻔都有⼀些重复的事实表,我们需要将这些重复的内容进⾏去除,按照交易域和仓储域,主题域的⽅式进⾏整合

对于仓储部⻔和供应链部⻔都有的库存明细表,因为仓储部⻔的统计粒度是商品加仓库,⽽供应链部⻔的只有商品,所以原则上两个表是不能合并,⽽是应该独⽴存在。

对于市场部⻔和供应链部⻔的两张下单明细表,因为统计粒度都是订单级别,都归属于交易域下的下单业务过程,所以可以合并为⼀张事实表。

除此之外,还应该考虑将不全的数据补⻬。对于ODS层直接被引⽤产出DWS/ADS/DM层的任务,通过⾎缘,找到任务清单,逐个进⾏拆解。没有ODS对应的DWD的,应该⽣成DWD表,对于已经存在的,应该迁移任务,使⽤DWD层表。

DWD/DWS/ADS/DM的命名规则适合采⽤“[层次][主题][⼦主题][内容描述][分表规则]”的命名⽅式。

第五,模型开发。

模型设计完成后,就进⼊模型开发阶段,需要注意的点:

1. 所有任务都必须严格配置任务依赖,如果没有配置任务依赖,会导致前⼀个任务没有正常产出数据的情

况下,后⼀个任务被调度起来,基于错误的数据空跑,浪费资源,同时增加了排查故障的复杂度;

2. 任务中创建的临时表,在任务结束前应该删除,如果不删除,会发现有⼤量的临时表存在,占⽤空间;

3. 任务名称最好跟表名⼀致,⽅便查找和关联;

4. ⽣命周期的管理,对于ODS和DWD,⼀般尽可能保留所有历史数据,对于DWS/ADS/DM需要设置⽣命周期,7〜30天不等;

5. DWD层表宜采⽤压缩的⽅式存储,可⽤lzo压缩。

第六,应⽤迁移。

最后⼀步就是应⽤的迁移,这个过程的核⼼是要注意数据的⽐对,确保数据的完全⼀致,然后进⾏应⽤迁移,删除⽼的数据表。

总的来说,建设数据中台不是⼀⼝⽓就能吃成⼀个胖⼦,它的建设往往是滚雪球的⽅式,随着⼀个个应⽤的迁移,中台的数据也越来越丰满,发挥的价值也越来越⼤。

数仓建模⼯具EasyDesign


上述步骤的实现,离不开⼀个好⽤的⼯具作为⽀撑,为了规范化数据模型的设计,研发了EasyDesign的模型设计产品,让这些流程实现系统化管理。EasyDesign的设计思路和功能:

网易有数:

https://bigdata.163yun.com/product/easydesign

EasyDesign构建于元数据中⼼之上,通过API调⽤元数据中⼼的数据⾎缘接⼝,结合数仓模型设计的指标,给出了模型设计度量。

EasyDesign按照主题域、业务过程、分层的⽅式管理所有的模型。

它还提供了维度、度量和字段基础字典的管理,同时具备模型设计审批流程的控制。

总结


本文主要了解了数据中台的模型设计。从确⽴设计⽬标,到通过⼀系列步骤,将⼀个个分散的、杂乱的、烟囱式的⼩数仓逐步规整到⼀个可复⽤、可共享的数据中台,最后通过产品化的⽅式实现系统化的管理。最后,再强调⼏个点:

1. 完善度、复⽤度和规范度构成了衡量数据中台模型设计的度量体系,可以帮助你评估数仓设计的好坏。

2. 维度设计是维度建模的灵魂,也是数据中台模型设计的基础,维度设计的核⼼是构建⼀致性维度。

3. 事实表的统计粒度必须保持⼀致,不同统计粒度的数据不能出现在同⼀个事实表中。

数据中台的构建往往需要花费半年甚⾄⼀年以上的时间,但是数据中台建成后,对研发效率的提升效果⾮常明显,在⽹易电商业务中,中台构建后相⽐构建前,数据需求的平均交付时间从⼀周缩短到3天内,需求响应速度的提升,为企业运营效果提升提供了数据⽀撑。

思考

在数据中台实际实施落地的过程中,数据团队不但要建设公共数据层,形成数据中台,还要承担着巨⼤的新需求的压⼒。⽽且,往往需求的优先级都⾼于建设公共数据层的优先级,导致中台建设的进度难以保障。

对这个问题,你有什么解决⽅法呢?

比如:

1、先满⾜需求(活下去),再研发公共数据层(构建美好未来)。

2、获得⾼层领导的⽀持,以获得更多的研发资源。

3、在满⾜业务需求的过程中,根据业务需求不断对公共数据层进⾏迭代和优化。

4、随着时间的推移,越来越多的⽇常业务需求可以⽤公共数据层(中台来完成)。

5、⽇常业务需求开发和公共数据层构建是相互促进的循环。

另外,为了保障数据中台的推进速度,可以尝试成⽴专⼈团队,这些⼈的⽬标明确就是中台构建,模型的重构和整合,指标的梳理。这些⼈不接业务需求,这样可以避免⽇常业务需求对数据团队的中台建设的⼲扰;合理设置KPI和KPI权重,给予充足的中台建设的动⼒。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2020-08-16,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 大数据技术与架构 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
数据中台实战(06)-数据模型无法复用,归根结底还是设计问题
分析师一般结合业务做数分(需用大量数据),通过报表服务于业务部门运营。但数据中台构建前,分析师经常发现自己没有可复用的数据,不得不使用原始数据进行清洗、加工、计算指标。
JavaEdge
2023/10/07
8110
数据中台实战(06)-数据模型无法复用,归根结底还是设计问题
「06」数据仓库基础知识
数仓,DataWarehouse,是一个 面向主题的、集成的、稳定的、与时间相关的 数据集合。
巡山猫说数据
2021/05/18
6560
「06」数据仓库基础知识
关于构建数据仓库的几个问题
数据仓库(Data Warehouse)是一个面向主题的(Subject Oriented)、集成的(Integrated)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合,用于支持管理决策(Decision Making Support)。近年来,随着大数据的应用不断深入,构建企业级数据仓库成为了企业进行精细化运营的一种趋势。
大数据老哥
2021/03/05
1.1K0
关于构建数据仓库的几个问题
数仓如何设计
  合理的数据仓库分层一方面能够降低耦合性,提高重用性,可读性可维护性,另一方面也能提高运算的效率,影响到数据需求迭代的速度,近而影响到产品决策的及时性。建立数据分层可以提炼公共层,避免烟囱式开发,可见一个合适且合理的数仓分层是极其重要。
挽风
2021/04/13
1.5K0
最强最全面的数仓建设规范指南(纯干货建议收藏)
优秀可靠的数仓体系,往往需要清晰的数据分层结构,即要保证数据层的稳定又要屏蔽对下游的影响,并且要避免链路过长。那么问题来了,一直在讲数仓要分层,那数仓分几层最好?
五分钟学大数据
2021/11/16
5.6K0
最强最全面的数仓建设规范指南(纯干货建议收藏)
数据仓库和数据集市详解:ODS、DW、DWD、DWM、DWS、ADS「建议收藏」
Data warehouse(可简写为DW或者DWH)数据仓库,是在数据库已经大量存在的情况下,它是一整套包括了etl、调度、建模在内的完整的理论体系。
全栈程序员站长
2022/09/13
6K0
数仓建设 | ODS、DWD、DWM等理论实战(强烈建议收藏~)
数仓在建设过程中,对数据的组织管理上,不仅要根据业务进行纵向的主题域划分,还需要横向的数仓分层规范。本文作者围绕企业数仓分层展开分析,希望对你有帮助。
大数据老哥
2022/04/07
8K0
数仓建设 | ODS、DWD、DWM等理论实战(强烈建议收藏~)
助力工业物联网,工业大数据之分层总体设计【六】
Oracle:hostname、port、username、password、sid
Maynor
2023/02/17
5860
助力工业物联网,工业大数据之分层总体设计【六】
伴鱼数仓演进
伴鱼离线数仓建立,与伴鱼的业务一起快速发展,从一条业务线,到多条业务线。在演进的过程中,有很多总结和沉淀的内容。本篇文章主要介绍伴鱼离线数据仓库的发展历史,在发展过程中遇到的各种问题,以及针对问题的解决方案。 1业务介绍 首先介绍伴鱼的主要业务线,流量型产品:伴鱼绘本,业务型产品:伴鱼 AI 课,伴鱼少儿英语等十几条业务线: 伴鱼绘本:承担着给其他业务线导流的功能,其核心业务流程是,用户注册 app 为起点,app 内广告访问,app 内听读录绘本功能的使用,以及 VIP 的购买、转化。 伴鱼少儿英语:用
深度学习与Python
2023/04/01
3550
伴鱼数仓演进
一文带你认清数据仓库【维度模型设计】与【分层架构】
本篇博客,博主为大家带来关于数仓项目中纬度模型设计与分层架构的一个说明。
大数据梦想家
2021/01/27
1.6K0
一文带你认清数据仓库【维度模型设计】与【分层架构】
数据仓库模型全景
与数据库的单表基于ER模型构建思路不同,其面向特定业务分析的特性,决定了它的构建需要整合多套数据输入系统,并输出多业务条线的、集成的数据服务能力,需要考虑更全面的因素,包括:
肉眼品世界
2022/06/15
1.4K0
数据仓库模型全景
【Techo Day腾讯技术开放日】数据仓库分层介绍
答案来源:https://cloud.tencent.com/developer/article/2102664
蓦然
2022/11/01
9001
数据仓库(基础篇)——基于维度建模思想
本文来源于A94大佬的关于数据仓库分享,如果感兴趣兴趣可以登录B站自行查看,在此给出链接地址:857数据交流技术峰会之数仓篇
不温卜火
2021/09/23
9410
数据仓库(基础篇)——基于维度建模思想
数据仓库的分层和作用特点_数据仓库的架构以及数据分层
现在说数仓,更多的会和数据平台或者基础架构搭上,已经融合到整个基础设施的搭建上。这里呢,我们不说Hadoop各种组件之间的配合,我们就简单说下数仓分层的意义价值和该如何设计分层。
全栈程序员站长
2022/11/04
2.9K0
数据仓库的分层和作用特点_数据仓库的架构以及数据分层
构建数据中台的三要素:方法论、组织和技术
盖房前,先得设计图纸,知道如何盖这房?然后还要有好用工具(如水泥搅拌机、钢筋切割机)帮你盖好这房。盖房子离不开一个靠谱施工队伍,这里面涉及很多角色(泥瓦工、木工、水电工等等),人须高效协作,才能盖出好房。
JavaEdge
2023/07/21
1K0
构建数据中台的三要素:方法论、组织和技术
经验分享实时数仓实战命名规范和分层设计~~
通常的命名方式是:ODS_应用系统名(或缩写)_数据库类型_(数据库名称可省略)_数据表名_加载方式(增量还是全量),表名不能太长,一般不超过30字。如:
大数据老哥
2022/02/17
5.6K0
经验分享实时数仓实战命名规范和分层设计~~
马蜂窝数据仓库的架构、模型与应用实践
最近几年,数据中台概念的热度一直不减。2018 年起,马蜂窝也开始了自己的数据中台探索之路。
马蜂窝技术
2019/10/09
1.2K0
马蜂窝数据仓库的架构、模型与应用实践
候选人被我这些数仓面试题问懵逼了
4). 数仓架构分层:一般分为操作数据层(ODS)、公共维度模型层(CDM)和应用数据层(ADS),其中公共维度模型层包括明细数据层(DWD和汇总数据层(DWS)
数据社
2021/07/30
1.7K0
数据仓库为什么需要分层建设和管理?
数据仓库是数据化运营和数字化转型的底层基础设施,数据仓库不完善或者建设质量差,再好的上层建筑(数据应用产品或工具)也很难牢固地生存下去。在数据仓库建设时,绕不开开地话题就是数仓分层。
数据干饭人
2022/12/05
6810
数据仓库为什么需要分层建设和管理?
实时数仓 | 你想要的数仓分层设计与技术选型
数据仓库概念的提出都要追溯到上世纪了,我们认为在大数据元年之前的数仓可以称为传统数仓,而后随着海量数据不断增长,以及Hadoop生态不断发展,主要基于Hive/HDFS的离线数仓架构可以兴起并延续至今,近几年随着Storm/Spark(Streaming)/Flink等实时处理框架的更新迭代乃至相互取代,各厂都在着力构建自己的实时数仓,特别是近两年,随着Flink声名鹊起,实时数仓更是名声在外并且还在不断快速发展。
大数据技术架构
2020/04/21
11.8K0
实时数仓 | 你想要的数仓分层设计与技术选型
推荐阅读
相关推荐
数据中台实战(06)-数据模型无法复用,归根结底还是设计问题
更多 >
交个朋友
加入[腾讯云] DeepSeek开发者交流群
前沿技术深度讨论 发展开发者人脉圈
加入腾讯云技术交流站
洞悉AI新动向 Get大咖技术交流群
加入AICoding云开发技术交流群
智能编码实践分享 聚焦AI+云开发
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档