分层
ods：合规，高效，成本
敏感数据处理
平台工具提效
增量，全量，存储生命周期
dwd：建模方式方法，可扩展性，稳定性，复用性
方法：维度建模
方式：自底向上（面向业务过程，设计阶段），自项向下（面向需求分析，后期迭代）相结合
可扩展性：细粒度，，
稳定性：解耦，扁平化设计，冷热维度分离
复用性：细粒度，规范，逻辑下沉（公共核心逻辑下沉，活动玩法不宜下沉）
dws
ads
分域
规范
数仓分层规范
命名规范
流程
数据资产管理
工具
流转平台，代码开发平台
评价
建模方法
模型治理
一、用户核心行为表和用户通用行为表
二、灵活分层
三、累积快照保留用户首次行为信息表
业务痛 - 开发痛
边治边防、防治结合
工具平台
可扩展性：最细粒度的事实表
Q：核心公共层的建设是自顶向下还是自底向上？
A：采用的是两者相结合的方式。以需求为驱动，没有需求就会导致过渡设计，在应用层有复用之后再下沉到公共层，这是自顶向下的。在公共层设计阶段是面向业务过程的，这时是自底向上的。
Q：多BU公共层是否需要统一规范？怎么去做？怎么量化价值？
A：需要做统一的规范，规范利于数据流通，才能体现数据价值。但是具体怎么规范需要具体去看，如电商、本地生活，业务和目标不一样，很难做到统一的规范。
Q：怎么判断指标需要下沉到公共层？
A：公共层的开发是需要成本的，是否需要下沉到公共层核心是看是否需要复用，可以从两个方面入手。
专家经验判断：如电商交易环节数据，这类数据是核心数据，是要建设到公共层的。
事后判断：如玩法之类的业务稳定性不强，那一开始不需要下沉到公共层，避免过度设计，事后再去判断是否需要下沉。
Q：关于表、字段的命名规范，是否需要先定义好词根再开发？
A：需要分开看。对于公共层设计到的业务过程是有限的，对于公共部分要先定义好再开发。对于应用层，维度采用的是总建架构所以还需要先定义，对于指标特别是派生指标是多的，不建议先定义在开发。
Q：如何解决口径一致命名不一致，或者口径不一致或者命名一致的场景。
A：模型是演变的。对于应用层，80%都是自定义的，第一次出现的时候都是不标准的，这部分如果采用先定义后开发的方式，效率是很低的，只有在下沉到公共层的时候才能够管控。对于公共层，能做的是保障核心指标90%的规范与定义统一，剩下的那部分也无法保证。
Q：跨集市依赖下沉到公共层的必要性？
A：短期来看没影响，新增效率高。
长期来会给数据的运维、治理带来很多影响，在数据下线、变更、治理过程中不得不考虑到下游依赖，会影响全流程的开发效率。
网友评论