本文探讨了数据治理面临的困境，包括执行难度大、缺乏业务方支持和难以量化成效。同时，提到了数据湖在应对快速变化的业务需求方面的挑战，如灵活性与标准化之间的平衡。文章指出，成功的数据治理需要高层领导的支持、组织协调能力和明确的落地机制，而数据湖的实施则需解决数据的实时反馈和多源整合问题。提出了数据治理应关注数据的使用效率、安全和质量，并强调了数据治理与业务协同的重要性。
前言
最近在写书，12万字了，还有三章，全都要落地的东西，要全情投入了。
这几天继续让大佬们代班，把群内聊天内容整理一下，供您参考。感谢@则则 和@赖总 的辛苦整理。
都是群里聊天实录，直接复制粘贴的。肯定有错别字、语句不通顺的问题。您将就着看哈。
数据治理的前途怎样？
问题：
大佬们，数据治理前途怎么样？
一句话总结：
前途堪忧！
持久战！
吃力不讨好容易背锅！
数据治理啊，我是不想搞了。nnd斗智斗勇，太难了！
能学本事，没前途属于一专多能的多能范畴彭总都要落泪的工种，入行的慎重吧。
提起治理就难受。从规划到实施都很难。
主要问题：
我们公司之前搞过主数据这一块的治理 ，结果就是梳理完流程，给了建议方案，最终到推动流程优化落地标准时就不了了之了，业务方没人愿意做总牵头，谁都只想使用数据不愿意承担维护数据标准的职能，高层如果没有魄力 是很难落地的。
提到数据治理大家都一个感觉啊，我们这做数据治理也都是扯皮，提出概念理论都好长时间了，会经常开，就是没人愿意去落地，推动不下去。
收到过这样的简历，讲自己数据治理多牛逼其实就是基于阿里云的dms掉了接口自己搞了一层。
治理大部分都是不了了之，干的不好也没有这事没弄好然后带来特别大的直接损失那种，干的再好也没有觉得特有成就感，而是觉得好像比从前好点，但可优化的还有一堆一堆的，诚惶诚恐
大佬建议：
组织协调能力，各种拉通对齐。
如果你的志向是做总监/vp，那么有数据治理的经验，对你之后对问题的定位和判断，会有很好的帮助，很快就能判断问题的核心连哄带骗带吓唬，连横合纵，在利益纠葛中周期性的挖掘合作者打击对手这才是核心能力，看书就瞎了可以磨练 借力打力 四两拨千斤 借刀杀人 等技能唯一见过成功的例子起vp牵头，将近200人的hc（专人）也不见牵头，vp专职就干这个。
数据治理，整好了是一呼百应的大佬；整不好就是谁都可以否定你，谁都不能肯定你的背锅侠，遇到的大部分是整不好的，整好的少之又少。
其实懂不懂数据治理，不用问啥大理论，只要让他给你举个生活中的例子，差不多就明白这人几斤几两了，如彭总的河道治理。
治理是一个综合体系可以找几个突破口在互联网公司，一半是从安全，质量，成本入手对于不同公司侧重点不一样，比如金融关注质量安全，但是互联网企业几十万台机器成本也很重要这个主要是能不能有实际的效果价值呈现出来比如安全，你不做关乎存亡，比如质量，业务方天天提要求数据质量怎么提现，看治理效果度量衡搞好了，结果呈现出来每个公司实际情况不一样不是凌驾于业务之上，而是协助业务把事情作对，很安全更省钱更准确。
落地建议：
所以大家做的数据治理，落地的都是数据稽查这一步
可以用这个交差，但是数据治理的核心是：“你们必须按老子的规则写入和变更数据”，也就是把新增指标，新增页面这种日常的运营流程，纳入到数据管理范围。做不到这点成效不大。相当于只一个pm要新增页面的时候，知道影响那些数据域/分析域，然后走申请流程，把相关规范落实完毕，才能上线需要组织能力的大幅提升，对管理水平要求大大大于技术要求网上做数据治理的，简历成果一般都是做了指标地图，血缘地图指标地图我们这儿各个bg做了十几个，最后都是死的系统，只能看看最难的指标变更与运营流程绑定这一步做不到，时间长了就是一堆过期界面。
保险的数据治理，能落地真心能产生很大的效益。但是你就断了一些人的财路。所以利益理不清，就落不了地。
治理的一般是离线数据团队，永远也不可能凌驾于线上业务系统之上。能管住埋点就挺好的了。
感谢@Robert**、@ga**、@whyme @漫** @Evan @bus** @罗* @Nee** @常** @跨越** @春** @涛** @一百个** @隽** @清 等一众大佬的绝世好问题和精彩讨论！
注：之所以打码，是因为群内有朋友曾经因隐私泄露，影响工作。再次感谢各位大佬
数据湖
问题：
上数据湖的大佬们，你们当初的痛点是啥？
数仓痛点：
数仓结构化讲的是规范，数据湖保存的是原始数据，没有预处理，用的时候再处理，比如特征工程中对null值不同的业务有不同的处理或补数，数仓ETL就先确定处理规则了，不够灵活
报表需要准确性，数仓标准化、规范化维度和建模正好满足，但不能支撑灵活的海量的数据挖掘
数据工作当下的困难，本质还是线上系统的快速进化传统的分层清洗一个是速度跟不上，另一个维度建模这种数据组织方式，对保持邻接网络/关系图/矩阵结构等无能为力以前的线上系统：用户输入目的地 -> 给出价格现在的线上系统：用户输入目的地 -> 统计活跃画像(大量聚合计算) -> 统计社会关系网络(图计算) -> 调度优化(线性规划近似解) -> 折扣（大数据杀熟）现在需要的数据建设方法也变了。
数据湖解题思路：
hudi数据湖的全称就是他要做事 Hadoop Upserts and Incrementals
以前：oltp -> 维度建模 -> olap：两套数据是隔离的现在：仓库能力会实时反馈到oltp里，双方有合流趋势批量数据的快速处理能力(聚合计算/图计算/规划近似解)会几乎实时的反馈到oltp系统里
ods把需要建模的源端数据copy了过来。但是还有非结构化的语音 视频等等没整进来。数据挖掘时，会出现ods取一点+其他源数据副本取一点，再跑模型。这样一来用数方就希望所有数据放一块，不用多源取数！把所有数据放一块了，里面也有源数据，ods也不必要再备份一次了，徒增流程。去掉ods，留下一堆数据的域，就是湖。这是我的理解
现在数据的使用更加民主化，A部门产生的非结构化数据，或者完全没有组织的结构化数据比如设备观测之类的，可能A自己不用，但B用。但这种数据A以及中央集权的数据开发中心都没精力和动力搞，而B又急需，因此上这种原始数据干脆就先统一入库再说，满足B眼下的需求，未来逐渐根据公司整体的实际需求在逐步结构化以及放入数仓。变化主要有两点，一个是各个部门都有越来越多并且越来越主动的底层数据需求，二是各个部门都有自己的开发团队，三是中心化还是必须的，但先数据入湖，后面逐步精进需求，中心重点关注是公共基础数据平台能力，以及元数据中心化的管理，数据开发权利下放
数仓的概念已经发生巨大的变化，实时化的增强，需要它能反哺业务系统，已经不能按它最初始时的定位看它了
感谢@史*、@阿*、@bus**、@一百个**、@春* 等各位大佬的绝世好问题和精彩讨论！
结语
用一个哥们的私信作为结语吧：
感谢阅读，本次分享的内容就结束了。
欢迎大家加我微信好友，尽个点赞之交，一起进化吧!
推荐阅读：
更多精彩：
209
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
