前言
最近在写书，实在是没时间更新了。前两天更了两篇文章，导致写书速度下降了好多，快赶不上进度了。
不过还好，我这大佬多啊，今天继续让大佬们代班，把群内聊天内容整理一下，供您参考。
都是群里聊天实录，直接复制粘贴的。肯定有错别字、语句不通顺的问题。您将就着看哈。
怎么理解宽表？
问题：
明细宽表怎么理解，选择好业务过程后，直接从ods取数到一张宽表里吗？
如果是，那这种宽表岂不是耦合了度量值和维度值。也没有独立的维度表了，模型上岂不是很无章法？
讨论：
具体看情况吧，并不是必须按照你讲的那样来，大多数宽表都是空间换时间。
我理解，建模不可能严格按照第三范式，适当的冗余是OK的。
都是混合建模方式，没有绝对，适合自己业务，好用就行。
我们曾经在dw层想过用范式来应对上层变化的业务需求 后来发现有点天真了。
共享维度层必须要有。
不然怎么保证一致性维度？
宽表算不上模式，就是实在搞不定了，先拉个大表用着。实在搞不定了指的是现有技术和方法生态搞不定，不是指哪个团队那个人。
维度建模这种数据抽象方式对olap场景表现出了强劲的适应性。但是数据科学这今年突飞猛进，策略算法，图算法，运筹，数字化运营，需要的数据组织方式远远不是一两种建模方式能搞定的。
从来都是先有问题，再有大神站出来把问题抽象掉形成方法，不是反过来。
对于新出现的问题，现有的不管是方法论还是技术生态还远远不够。
你们这根本不叫建模，纯粹宽表，最后依赖会很混乱。后期风险很大，更不用说保证数据一致性了。
本来就是不得已为之，几个十亿级别的表，谁来了也得这么干。算不上什么方法，被逼的野狐禅。
没有所谓的混合建模方式，必须以一种建模方式为指导，基于业务做权衡，建模过程必须很清楚的指导这个权衡的优缺点，以及为什么要这么权衡，另外维度建模不等于冗余。
维度建模的核心是一致性维度，不能保证维度一致性不能叫维度建模。
大宽表就是容易造成依赖关系的混乱。
问题就是不做冗余sql有些写起来太复杂了 join一大堆的表，换个人来看文档都要崩溃了有些字段不知道去哪儿找。所以我们后面还是放弃了严格的范式。
宽表在dws和dwt吧。基于dwd模型层。
dws我们都是通用的派生指标，ads层才是宽表，直接面向后端。
所以我一直都比较好奇 维度冗余的边界在哪儿。
首先要能解决问题，解决不了问题，再规范也不实用。很多东西都是一次性的，根本做不到复用也没必要复用。其实还是得看各自的业务场景，有的场景适合，有的场景不适合。
维度冗余没有边界，但是所有事实里冗余的维度属性都要保证从共享维度里来。
把纬度冗余进事实表，如果纬度变化了，也要更新纬度表，这也增加了工作量呀。
变化了就要重跑下游依赖的所有的表……
我觉得靠冗余字段来提高访问效率这个出发点，现在已经不应该采用了。因为后面我们不是有kylin这些工具帮我们提高速度了嘛。
你就想明白你这个模型的定位，使用时你允许使用这张表进行关联扩充维度属性那就保留ID，如果不允许那就不需要，如果很纠结，那就思辨，允许会带来什么样的好处和坏处，不允许会带来什么样的好处和坏处，然后做权衡。
我现在公司里面在做集市项目，他们做了个汇总层，没有dwd，直接ods采数去做“明细宽表”，也没有维度表。我在想他们这样下去，这模型还是模型吗？
这就是最原始的ods+ads两层的做法吧。
宽表对业务来说主要是解决清单关联过多查询慢和不方便导出的问题吧。
统计来说宽表也是减少join(太耗时间)的目的。
id还是要有的，不然以后追溯和冲刷数据，以及对数简直就是噩梦。再说也不差那点存储吧？
感谢@何同学-数据建模-广州、@赖志明-金融监管大数据-北京、@北京-数据开发-郭东、@sun-上海_大数据、@L Y-消金数仓-北京、@Luka-数仓-深圳、@魏涛－数据产品经理－长沙、@sqlboy-大数据开发-杭州、@Old-数仓-杭州、@生命不息取数不止-指标设计-北京、@碎星-信息化-德阳、@陶瓷鱼、@倪武龙-数据治理-深圳 等一众大佬的绝世好问题和精彩讨论！
公共数据治理
问题：
有个不太成熟的问题向大家请教一下：如果客户管理从集团层面出发，不同领域对同一个客户数据进行管理或者变更，具体哪个领域对共用数据维护和质量负责？
讨论：
主数据管理。
这个就需要指定负责部门了。公共数据将信息的变更历史详细记录，如果必要可以分级和审批。
这部分数据是否要统一管理？业界有没有好的实践？
数据治理里面有专门一块叫做主数据管理，你可以看看。
ibm ecif就是干这个的？IBM有相关的产品 IBM MDM。
这一块是不是和 用户画像里面的 id-mapping有点像?
也有人直接写JAVA搞一个主数据管理系统。
收到，感谢，目前我们按主数据管理在实践的，但是落地的时候遇到这样的问题。
很多厂商，数据治理产品，数据资产管理和主数据管理都是分开的。
客户主数据要有对应数据拥有者去统一管理，不同领域的变更的话你可以考虑用某个领域为主导，正常来说，所有变更都应该发生在同一个主数据管理系统里面，然后同步到所有业务领域，这样才不会产生冲突。
感谢@李瑞-数据治理、@倪武龙-数据治理-深圳、@胡俊-爱保科技-数据平台-北京、@NULL-数据开发-深圳、@刘继峰-金山云架构师-北京 等各位大佬的绝世好问题和精彩讨论！
数据组织架构
问题：
能否在大数据组织架构设计上有所探讨？数据平台团队（基础平台和数据湖层）和数据应用团队（数据集市、数据分析及产品）分离会带来哪些问题？ 。
讨论：
数据平台团队多以技术比较牛逼的开发人员组成，重视平台的高可用高性能高可靠，往往只着眼于如何解决问题，很少会关注为什么有这样的问题？数据应用团队以业务场景需求为导向，关注如何灵活取数，如何适配快速变化的业务。
前者追求高度抽象，通用的架构，后者追求个性化，迅速的响应，这两者在共性和个性的关系上往往会有不一致的情况，这个时候一般是要一个桥梁一样的角色，比如架构师，权衡折中。
不然平台建了人家业务也不认可你，人家业务自己从业务系统取数分析，效率也不高。
好的产品经理好的架构师，都可以很好地解决这个问题，找到折衷的最优解。
2张皮的问题，用考核和评价指标来解决？平台好不好 得有应用团队说了算？
应用团队天生就不会对平台团队说好话。
我个人觉得，首先第一点这个平台初期建设的时候应该就是双方的事儿，收集好应用方的痛点，平台的构建也是为了数据更好的管理和使用，是给自己团队和应用团队使用的
第二点，后期投入使用由于着力点不一样导致的摩擦，确实是需要一些指标来管控的，既然平台团队是服务于应用的，那么应用端提的不管是到位时间上的需求还是数据准备的需求，提工单，平台团队评估完给你做，能做不能做也事先说好，到时候工单都在那儿，可以拿出来说话。
但是一般离钱越近话语权越大，这个比较靠后的平台团队还是要全力以赴支持应用团队的，只是有些说不清的还是要流程化，比如提交工单，审批之类的。
离钱越近越有话语权，说得对！
反之，享有背锅义务。正因为要承担背锅的这个责任，所以距离钱近。
你说的分离是拆分部门吗？
基础平台 ：底层开发（理解为底层hadoop源码开发）独立，因为不涉及业务（可以一个团队）；
基础的元数据和主数据你必须知道业务和后面的存储（仓、湖） 是一体的 （可以一个团队）。
应用层是用数据的，集市、分析、产品设计倒是可以单独去做（可以多个不同团队）。
业务大了分离是必然，带来的最主要问题就是沟通成本增加。
如果没有一个中间的应用平台层（中台），应用层还是有可能重复造轮子。
可以看看数据中台的三个阶段。
不过当中台赶不上前台敏捷需要时，有时候不得不重复造轮子。
重复造轮子有时候也不是坏事呀，特别对于新业务线，随时在变化的业务线来说，毕竟中台也好，重复造轮子也好，最终都想实现降本增效，若是中台还给业务线拉了后腿，也就是去它的意义了。
感谢@建辉、@阿姣-上海-数仓架构、@林钰鑫-数据架构-深圳、@赖志明-金融监管大数据-北京、@Jack-数仓-北京、@胡俊-爱保科技-数据平台-北京 等各位大佬的绝世好问题和精彩讨论！
结语
用一个哥们的私信作为结语吧：
感谢阅读，本次分享的内容就结束了。
