前言
今天让架构建模群的大佬代个班~~~
以下为研讨实录，请查收：
数据血缘分析
提问：
大家在数仓里表的血缘关系是用怎么工具管理的？
有没有开源的现成的血缘关系字管理和血缘关系可视化工具？
讨论：
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**、@专*！、@一百个******** 等大佬的深度研讨。
结语
用一个哥们的私信作为结语吧：
加油，数字人，今天又是美好的一天！
感谢阅读，本次分享的内容就结束了。也欢迎大家加我微信，咱俩私聊啊
推荐阅读：
更多精彩：
938
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
