很可惜 T 。T 您现在还不是作者身份，不能自主发稿哦～
如有投稿需求，请把文章发送到邮箱tougao@appcpx.com，一经录用会有专人和您联系
咨询如何成为春羽作者请联系：鸟哥笔记小羽毛（ngbjxym）
最近在写书，实在是没时间更新了。前两天更了两篇文章，导致写书速度下降了好多，快赶不上进度了。
不过还好，我这大佬多啊，今天继续让大佬们代班，把群内聊天内容整理一下，供您参考。
都是群里聊天实录，直接复制粘贴的。肯定有错别字、语句不通顺的问题。您将就着看哈。
问题：
明细宽表怎么理解，选择好业务过程后，直接从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有点像?
也有人直接写J**A搞一个主数据管理系统。
收到，感谢，目前我们按主数据管理在实践的，但是落地的时候遇到这样的问题。
很多厂商，数据治理产品，数据资产管理和主数据管理都是分开的。
客户主数据要有对应数据拥有者去统一管理，不同领域的变更的话你可以考虑用某个领域为主导，正常来说，所有变更都应该发生在同一个主数据管理系统里面，然后同步到所有业务领域，这样才不会产生冲突。
感谢@李瑞-数据治理、@倪武龙-数据治理-深圳、@胡俊-爱保科技-数据平台-北京、@NULL-数据开发-深圳、@刘继峰-金山云架构师-北京 等各位大佬的绝世好问题和精彩讨论！
问题：
能否在大数据组织架构设计上有所探讨？数据平台团队（基础平台和数据湖层）和数据应用团队（数据集市、数据分析及产品）分离会带来哪些问题？ 。
讨论：
数据平台团队多以技术比较牛逼的开发人员组成，重视平台的高可用高性能高可靠，往往只着眼于如何解决问题，很少会关注为什么有这样的问题？数据应用团队以业务场景需求为导向，关注如何灵活取数，如何适配快速变化的业务。
前者追求高度抽象，通用的架构，后者追求个性化，迅速的响应，这两者在共性和个性的关系上往往会有不一致的情况，这个时候一般是要一个桥梁一样的角色，比如架构师，权衡折中。
不然平台建了人家业务也不认可你，人家业务自己从业务系统取数分析，效率也不高。
好的产品经理好的架构师，都可以很好地解决这个问题，找到折衷的最优解。
2张皮的问题，用考核和评价指标来解决？平台好不好 得有应用团队说了算？
应用团队天生就不会对平台团队说好话。
我个人觉得，首先第一点这个平台初期建设的时候应该就是双方的事儿，收集好应用方的痛点，平台的构建也是为了数据更好的管理和使用，是给自己团队和应用团队使用的
第二点，后期投入使用由于着力点不一样导致的摩擦，确实是需要一些指标来管控的，既然平台团队是服务于应用的，那么应用端提的不管是到位时间上的需求还是数据准备的需求，提工单，平台团队评估完给你做，能做不能做也事先说好，到时候工单都在那儿，可以拿出来说话。
但是一般离钱越近话语权越大，这个比较靠后的平台团队还是要全力以赴支持应用团队的，只是有些说不清的还是要流程化，比如提交工单，审批之类的。
离钱越近越有话语权，说得对！
反之，享有背锅义务。正因为要承担背锅的这个责任，所以距离钱近。
你说的分离是拆分部门吗？
基础平台 ：底层开发（理解为底层hadoop源码开发）独立，因为不涉及业务（可以一个团队）；
基础的元数据和主数据你必须知道业务和后面的存储（仓、湖） 是一体的 （可以一个团队）。
应用层是用数据的，集市、分析、产品设计倒是可以单独去做（可以多个不同团队）。
业务大了分离是必然，带来的最主要问题就是沟通成本增加。
如果没有一个中间的应用平台层（中台），应用层还是有可能重复造轮子。
可以看看数据中台的三个阶段。
不过当中台赶不上前台敏捷需要时，有时候不得不重复造轮子。
重复造轮子有时候也不是坏事呀，特别对于新业务线，随时在变化的业务线来说，毕竟中台也好，重复造轮子也好，最终都想实现降本增效，若是中台还给业务线拉了后腿，也就是去它的意义了。
感谢@建辉、@阿姣-上海-数仓架构、@林钰鑫-数据架构-深圳、@赖志明-金融监管大数据-北京、@Jack-数仓-北京、@胡俊-爱保科技-数据平台-北京 等各位大佬的绝世好问题和精彩讨论！
用一个哥们的私信作为结语吧：
感谢阅读，本次分享的内容就结束了。
欢迎大家加我微信好友，尽个点赞之交，一起进化吧!
推荐阅读：
更多精彩：
本文为作者独立观点，不代表鸟哥笔记立场，未经允许不得转载。
《鸟哥笔记版权及免责申明》 如对文章、图片、字体等版权有疑问，请点击 反馈举报
Powered by QINGMOB PTE. LTD. © 2010-2022 上海青墨信息科技有限公司 沪ICP备2021034055号-6
我们致力于提供一个高质量内容的交流平台。为落实国家互联网信息办公室“依法管网、依法办网、依法上网”的要求，为完善跟帖评论自律管理，为了保护用户创造的内容、维护开放、真实、专业的平台氛围，我们团队将依据本公约中的条款对注册用户和发布在本平台的内容进行管理。平台鼓励用户创作、发布优质内容，同时也将采取必要措施管理违法、侵权或有其他不良影响的网络信息。
一、根据《网络信息内容生态治理规定》《中华人民共和国未成年人保护法》等法律法规，对以下违法、不良信息或存在危害的行为进行处理。
1. 违反法律法规的信息，主要表现为：
1)反对宪法所确定的基本原则；
2)危害国家安全，泄露国家秘密，颠覆国家政权，破坏国家统一，损害国家荣誉和利益；
3)侮辱、滥用英烈形象，歪曲、丑化、亵渎、否定英雄烈士事迹和精神，以侮辱、诽谤或者其他方式侵害英雄烈士的姓名、肖像、名誉、荣誉；
4)宣扬恐怖主义、极端主义或者煽动实施恐怖活动、极端主义活动；
5)煽动民族仇恨、民族歧视，破坏民族团结；
6)破坏国家宗教政策，宣扬邪教和封建迷信；
7)散布谣言，扰乱社会秩序，破坏社会稳定；
8)宣扬淫秽、色情、赌博、暴力、凶杀、恐怖或者教唆犯罪；
9)煽动非法集会、结社、游行、示威、聚众扰乱社会秩序；
10)侮辱或者诽谤他人，侵害他人名誉、隐私和其他合法权益；
11)通过网络以文字、图片、音视频等形式，对未成年人实施侮辱、诽谤、威胁或者恶意损害未成年人形象进行网络欺凌的；
12)危害未成年人身心健康的；
13)含有法律、行政法规禁止的其他内容；
2. 不友善：不尊重用户及其所贡献内容的信息或行为。主要表现为：
1)轻蔑：贬低、轻视他人及其劳动成果；
2)诽谤：捏造、散布虚假事实，损害他人名誉；
3)嘲讽：以比喻、夸张、侮辱性的手法对他人或其行为进行揭露或描述，以此来激怒他人；
4)挑衅：以不友好的方式激怒他人，意图使对方对自己的言论作出回应，蓄意制造事端；
5)羞辱：贬低他人的能力、行为、生理或身份特征，让对方难堪；
6)谩骂：以不文明的语言对他人进行负面评价；
7)歧视：煽动人群歧视、地域歧视等，针对他人的民族、种族、宗教、性取向、性别、年龄、地域、生理特征等身份或者归类的攻击；
8)威胁：许诺以不良的后果来迫使他人服从自己的意志；
3. 发布垃圾广告信息：以推广曝光为目的，发布影响用户体验、扰乱本网站秩序的内容，或进行相关行为。主要表现为：
1)多次发布包含售卖产品、提供服务、宣传推广内容的垃圾广告。包括但不限于以下几种形式：
2)单个帐号多次发布包含垃圾广告的内容；
3)多个广告帐号互相配合发布、传播包含垃圾广告的内容；
4)多次发布包含欺骗性外链的内容，如未注明的淘宝客链接、跳转网站等，诱骗用户点击链接
5)发布大量包含推广链接、产品、品牌等内容获取搜索引擎中的不正当曝光；
6)购买或出售帐号之间虚假地互动，发布干扰网站秩序的推广内容及相关交易。
7)发布包含欺骗性的恶意营销内容，如通过伪造经历、冒充他人等方式进行恶意营销；
8)使用特殊符号、图片等方式规避垃圾广告内容审核的广告内容。
4. 色情低俗信息，主要表现为：
1)包含自己或他人性经验的细节描述或露骨的感受描述；
2)涉及色情段子、两性笑话的低俗内容；
3)配图、头图中包含庸俗或挑逗性图片的内容；
4)带有性暗示、性挑逗等易使人产生性联想；
5)展现血腥、惊悚、残忍等致人身心不适；
6)炒作绯闻、丑闻、劣迹等；
7)宣扬低俗、庸俗、媚俗内容。
5. 不实信息，主要表现为：
1)可能存在事实性错误或者造谣等内容；
2)存在事实夸大、伪造虚假经历等误导他人的内容；
3)伪造身份、冒充他人，通过头像、用户名等个人信息暗示自己具有特定身份，或与特定机构或个人存在关联。
6. 传播封建迷信，主要表现为：
1)找人算命、测字、占卜、解梦、化解厄运、使用迷信方式治病；
2)求推荐算命看相大师；
3)针对具体风水等问题进行求助或咨询；
4)问自己或他人的八字、六爻、星盘、手相、面相、五行缺失，包括通过占卜方法问婚姻、前程、运势，东西宠物丢了能不能找回、取名改名等；
7. 文章标题党，主要表现为：
1)以各种夸张、猎奇、不合常理的表现手法等行为来诱导用户；
2)内容与标题之间存在严重不实或者原意扭曲；
3)使用夸张标题，内容与标题严重不符的。
8.「饭圈」乱象行为，主要表现为：
1)诱导未成年人应援集资、高额消费、投票打榜
2)粉丝互撕谩骂、拉踩引战、造谣攻击、人肉搜索、侵犯隐私
3)鼓动「饭圈」粉丝攀比炫富、奢靡享乐等行为
4)以号召粉丝、雇用网络水军、「养号」形式刷量控评等行为
5)通过「蹭热点」、制造话题等形式干扰舆论，影响传播秩序
9. 其他危害行为或内容，主要表现为：
1)可能引发未成年人模仿不安全行为和违反社会公德行为、诱导未成年人不良嗜好影响未成年人身心健康的；
2)不当评述自然灾害、重大事故等灾难的；
3)美化、粉饰侵略战争行为的；
4)法律、行政法规禁止，或可能对网络生态造成不良影响的其他内容。
二、违规处罚
本网站通过主动发现和接受用户举报两种方式收集违规行为信息。所有有意的降低内容质量、伤害平台氛围及欺凌未成年人或危害未成年人身心健康的行为都是不能容忍的。
当一个用户发布违规内容时，本网站将依据相关用户违规情节严重程度，对帐号进行禁言 1 天、7 天、15 天直至永久禁言或封停账号的处罚。当涉及欺凌未成年人、危害未成年人身心健康、通过作弊手段注册、使用帐号，或者滥用多个帐号发布违规内容时，本网站将加重处罚。
三、申诉
随着平台管理经验的不断丰富，本网站出于维护本网站氛围和秩序的目的，将不断完善本公约。
如果本网站用户对本网站基于本公约规定做出的处理有异议，可以通过「建议反馈」功能向本网站进行反馈。
(规则的最终解释权归属本网站所有)