《全链路数据治理-智能数据建模 》——客户案例：大淘系数据模型治理最佳实践（7） https://developer.aliyun.com/article/1230753?groupCode=tech_library
五、 提问
Q：核心公共层的建设是自顶向下还是自底向上？
A：采用的是两者相结合的方式。以需求为驱动，没有需求就会导致过渡设计，在应用层有复用之后再下沉到公共层，这是自顶向下的。在公共层设计阶段是面向业务过程的，这时是自底向上的。
Q：多BU 公共层是否需要统一规范？怎么去做？怎么量化价值？
A：需要做统一的规范，规范利于数据流通，才能体现数据价值。但是具体怎么规范需要具体去看，如电商、本地生活，业务和目标不一样，很难做到统一的规范。
Q：怎么判断指标需要下沉到公共层？
A：公共层的开发是需要成本的，是否需要下沉到公共层核心是看是否需要复用，可以从两个方面入手。
专家经验判断：如电商交易环节数据，这类数据是核心数据，是要建设到公共层的。事后判断：如玩法之类的业务稳定性不强，那一开始不需要下沉到公共层，避免过度设计，事后再去判断是否需要下沉。
Q：关于表、字段的命名规范，是否需要先定义好词根再开发？
A：需要分开看。对于公共层设计到的业务过程是有限的，对于公共部分要先定义好再开发。对于应用层，维度采用的是总建架构所以还需要先定义，对于指标特别是派生指标是多的，不建议先定义在开发。
Q：如何解决口径一致命名不一致，或者口径不一致或者命名一致的场景。
A：模型是演变的。对于应用层，80%都是自定义的，第一次出现的时候都是不标准的，这部分如果采用先定义后开发的方式，效率是很低的，只有在下沉到公共层的时候才能够管控。对于公共层，能做的是保障核心指标90%的规范与定义统一，剩下的那部分也无法保证。
Q：跨集市依赖下沉到公共层的必要性？
A：短期来看，是没影响的，新增效率高。
长期来会给数据的运维、治理带来很多影响，在数据下线、变更、治理过程中不得不考虑到下游依赖，会影响全流程的开发效率。
