前言
今天让架构建模群的大佬代个班~~~
以下为研讨实录，请查收：
指标拆分原则
提问：
请教一下，如果在建立财务指标的时候，某一个指标下都有境内境外的区分，比如同业拆借，下面分境内同业拆借，同业拆借，在存到数据库的时候，境内同业拆借和境外同业拆借也算做指标存下来吗？
讨论：
建议底表拆开，同时保留因子和结果。便于后面需求扩展和数据验证。
针对你说的这种情况，我们这边是分开国内国际（即境内境外）两个指标分别进行计算的，因为国内国际业务规则有些不同，我们这边实际放在两个过程分别进行计算的
最终有需要的话可以汇总指标至一个表也可以，不过，我们这边是分别存储在两个DM表的，手机APP上分开国内国际分别显示对应的指标。
可以底层按照国内国际数据分别存储计算指标数据，最后合并国内国际数据至一张汇总表中，增加字段以区分国内国际。
感谢 @X* 大佬的好问题，感谢@刘天佑、李优 等大佬的精彩回答。
如何应对指标爆炸
提问：
指标很多，那涉及到存储和计算是不是也会很庞大，另外还会有etl的任务，mysql数据库进行，这个压力会不会太大了
讨论：
mysql处理任务肯定费劲了，Oracle处理还好些，上T的数据也不行。
业务复杂，涉及的过程ETL就多就会很庞大，我们这边目前现状也是很庞大。MySQL存储百万级别用，数据量若太大考虑其他的如HBase、ElasticSearch、PG等加速存储引擎。我们这边目前加速层即应用系统DM表是存储在MySQL、HBase、ElasticSearch、PG等的，之后制作数据服务封装数据，业务系统直接访问数据服务进行数据请求的
感谢 @X* 大佬的好问题，感谢@刘天佑、李优 等大佬的精彩回答。
数仓领域
提问：
领域建设具体指的什么，我一直搞不太清楚。
还有个领域模型，什么是领域？
讨论：
不是什么
比如银行业务划分为贷款模型 存款模型这些 主要看业务
我觉得不能叫按领域建设，叫面向需求建设，被业务牵着鼻子走，然后底层一塌糊涂
那就是，ods-dm这种烟囱式的开发了，或者直接ods出数，我们也这样，领导要的急，直接从ods出的。ods取数，重复轮子多，搞不好改一个指标，改好多etl脚本。
我们这边大部分的需求是从dw，dm出的，目前有条新业务线的需求是直接从ods出的
初期业务变更频繁，需求又比较紧急，来不及等到我们建模完，所以直接从ods出了
都是来一个需求就搞一条链路出来
复杂度的降低，必然会在其他地方补偿回来。
是什么
领域 就是范围、区域的意思
应该是按主题建。即便是有数总线管着，通常也会死的很惨。因为决定做什么的不是总线，而是业务。
大的方向，主题划分，表，字段规范命名等，需要在设计阶段规划好，其他初期需求多，变化频繁，有些烟筒式建模，面向需求，等稳定了再抽象公共层吧
实现的路径
1.总线矩阵
总线矩阵还是很有必要的，模型复用率高
很多人懒得整理这个总线矩阵，这个工程量想想也挺大的，特别是大公司，各种业务线
2.永远在重构
我对建模的观点是，你要舍得重做，一个时间段，有契机就把原来有问题的地方修理一遍，我坚持的是不可尽知论，不可能啥都知道你再建模，不现实，当然啥都不知道就建模更是坑
所以数据服务类似这种东西没有是不行的，整个表都开放给下游，就傻傻都改不了
必须永远在重构
需要数据总监能让其他团队理解和配合这种文化
不断重构、不断返工，必经之路。
感谢 @x*、@风在**、@142**、@ot*、@史*、@隽*、@Jas**、@春*、@L *、@涛*、@专供*、@whyme、@bus**。
结语
加油，数字人，今天又是美好的一天！
感谢阅读
推荐阅读：
更多精彩：
