前言
今天让架构建模群的大佬代个班~~~
以下为研讨实录,请查收:
数据血缘分析
提问:
大家在数仓里表的血缘关系是用怎么工具管理的?
有没有开源的现成的血缘关系字管理和血缘关系可视化工具?
讨论:
1.推荐:atlas
目前要么自己写脚本,通过hook解析 或者通过atlas 实现。 自己写场景多,风险大。hook 依赖调度。atlas 有现成结果可用,准确性难以判断。
2.局限性
目前普遍做法都是sql解析。
直接上代码的,解析几乎不可能,代码复杂度太高了。
个人感觉只能先有标准,才能解析。数据治理和规范的的开发相互依赖。所以开发、治理相爱相杀,这也是目前治理难做的原因。
3.从血缘衍生到数据治理
规范先行、把数据提升到资产的高度、统一定义、统一生产、统一消费、统一编码,统一工具。
但是现在好多公司对数据治理的误解是,有了数据治理,数据质量就立竿见影的提升。其实呢,数据治理从来都不是单独存在的。是整个集团内相互协作进行的。所以数据治理必须提到高层主导才有意义。只是数据部门一厢情愿的话,前途渺茫。
数据治理是产品与服务相结合,并且是一个持续性的活儿,并非就是一个交钥匙工程。
很多厂商去给业主领导忽悠,数据治理平台的领先性,导致业主领导期望值过高,太多依赖于产品去解决数据问题,导致后期交付与验收暴露风险,未能达到建设目标。
数据治理属于一把手项目。
懂的人,让精锐做基础性工作,不懂的人,让精锐做上层输出。
销售出身的老板,搭建销售团队非常专业,都是从最基础的销售网路规范做起。技术出身的老板,搞这个就很业余,只会狂招销售人员。
老板成长要交学费,很正常。
好的老板不吝惜交学费。
看什么事儿了,有些事努努力就能做到,就尽力而为。有些不是,就顺其自然。
感谢 @常飞* 大佬的好问题,感谢@昶****、@刘天*、@*供!、@Miss***、@bus** 等大佬的深度研讨。
分区的生命周期
提问:
增量每天一个分区,那集群环境的小文件,会很多,定时清理?每天一个分区保存周期多久呢?
讨论:
嗯。。好问题,小文件当时没考虑,项目过程中没处理。周期的话 3天,7天,30天都有。
最好在建表时增加表的生命周期。
分区过多,感觉泛滥了,dw层的表,我们就遇到了这样的问题,过一段时间,就要手动清理,最后干脆 改成了 不要分区,只保留一分最新的全量快照数据。
嗯 建表的时候可以指定lifecycle 例如是7的话 非分区表会保存7天 分区表会保存最近的7个分区。
分区表一般都要生命周期的。hive好像没有,我们用阿里云的有。
感谢 @b**、@Su*、@de**、@1428**、@br* 等大佬的深度研讨。
数据域和主题域
提问:
什么是数据域?跟主题域又有什么区别?是不是就是一个东西?
讨论:
数据域划分就是对数据分类。而基于不同的目的,有不同的分类标准。
比如开发更倾向于基于数据来源的差异划分,相同功能模块的数据划分在一起。运营更倾向基于数据应用目的的差异划分,解决类似问题的数据划分在一起。
我觉得每个人都应该可以创建满足自己目的的数据域,来方便管理和查找数据。
数据域的划分有几点需要注意的地方
1.不重不漏,确保每个表都在一个域里,且只在一个域里(精确定位)
2.每个域下都可以根据需要再分子域,不限定层级(最自由方便)
3.如果分子域就不能放表,表只放在最底层的域中(树状目录管理时更方便)
4.最好保证每个域下的子域数量或表数量在20个左右(太多了不方便记忆管理,太少了没必要划分)
5.【其他】很好用,不好划分的都放里面(减少域层级数量有理由理解记忆)
6.数据团队分域可以作为分工的标准(数据不重、分工明确、界限清晰)
7.数据团队分域后,可以决定域内表的中间命名(看到表名时可以理解更多信息)
我倾向于这种解释,在数仓的dwd层按数据域划分。再往上可以按主题域划分。
主题域(应该叫分析主题域)之间的指标有可能会有交叉
我理解的就是数据属于哪个域的问题
从业务或者面向分析出发 把业务过程分类成一个个数据域
比如支付订单属于交易域数据
数据域的作用是数据质量管理
比如订单属于交易数据,知道这个数据从哪里来
其实数据域,这玩意数据源就已经划分了 什么生产域,供应链域,财务域,域下面还有子系统
能呈现结构化,共性分堆,快速检索就行了
数据域面向业务过程,主题域面向分析
感谢 @彭文华、@ot*、@Ker**、@1428**、@专*!、@一百个******** 等大佬的深度研讨。
结语
用一个哥们的私信作为结语吧:
加油,数字人,今天又是美好的一天!