数据治理，请对oltp开炮！

与数据同行 2022-10-16

The following article is from 大鱼的数据人生 Author 讨厌的大鱼先生

在我从事数据这个专业多年以后，发现一个奇怪的现象，就是大多数搞数据管理的人，都在OLAP领域，而在浩瀚的OLTP领域，少有专业的搞数据管理的人，为什么？

也许跟OLTP和OLAP的使命相关。

企业为实现价值创造，从输入客户要求开始到交付产品及服务给客户获得客户满意并实现企业自身价值的E2E（端对端）业务过程是业务流。业务流是客观存在的，每家公司在设计自身业务流程时都是想办法要找到真实合理的业务流，去适配这个业务流。

IT承载和使能的就是业务流，这里的IT就是OLTP，OLTP得让流程顺利run起来，而数据只是衔接流程各个环节的媒介，对于OLTP来说，业务流的治理是第一位的，至少开始的时候是这样。

OLTP说得最多的就是业务管理，本质就是确保业务流run起来的业务规则的管理，而数据的治理则无足轻重。

OLAP即联机分析处理，其要run起来跟业务流无关，只跟业务流记录的数据有关，数据就是OLAP的生命线，为了让数据分析的准确高效，OLTP需要高质量的数据，因此，OLAP说得最多的是数据管理，DAMA通过对数据管理活动的总结，形成了数据管理的方法论。

自然而然的，数据仓库成了数据管理方法实践的最佳场所，你会发现，当前国内大多数企业的数据管理实践，都发生在数据仓库领域，从元数据、数据质量管理、参考数据、数据标准、数据开发、数据应用、数据安全再到数据架构，不一而足，甚至连主数据管理，大家都想的是在数据仓库里搞一个，然后对外去提供服务。

数据管理也好，数据治理也好，成了OLAP的专属品。

可惜的是，数据管理光有OLAP的参与，不仅是缺了一半的，而且先天不足，为什么？

数据创造价值分为三个阶段：数据产生，数据处理及数据消费，后面两个跟OLAP相关，而第一个，只跟OLTP相关。

很多公司数据价值创造过程受阻，不是OLAP不行，而是OLTP不行，因此，无论后端怎么努力，都是事倍功半，因为是根子出了问题。

以数据架构为例：

无论是数据模型、数据分布或是数据标准，OLTP当前都缺乏有效的管理，OLAP系统为了汇聚数据，只能一次又一次的采取项目化的方式对OLTP的系统进行梳理，并通过主题域、概念模型、逻辑模型、物理模型等模型来实现OLTP业务的重新抽象，美其名曰，OLAP是从分析角度看问题，需要不同的建模方式。

但这些工作按道理是OLTP本身就该干的事情啊，业务理解永远是老大，你离业务越远，做事就越事倍功半。

数据仓库以前经常几年要推倒重来一次，为啥呀，因为OLTP变了啊，OLAP以前的抽象不行了啊。

现在OLTP领域DDD设计的兴起，无论是领域，子域、限界上下文，实体、值对象等等，其实都是为了解决OLTP领域抽象太差的问题。

差到什么程度？

阻碍OLTP架构演进，影响了码农的开发效率，但这种抽象，数据仓库可一直都在做。

又比如以数据质量为例：

OLTP以业务流为核心的管理原则导致其几乎不用关注自己留存的数据是否符合质量六性（完整性、及时性、准确性、一致性、唯一性和有效性），只要流程能运转下去，业务继续能开展，那数据质量就是最后需要考虑的事情，“垃圾数据进垃圾数据出”每天都在OLTP和OLAP中演绎。

下游的OLAP除了擦屁股，也没啥办法，只能在报表指标上不断内卷，除非指标数据爆了大雷。

OLTP在数据管理上的不作为不仅影响到了下游OLAP，随着OLTP自身的发展，也开始对自身流程的运营效率产生影响。

虽然每一段的OLTP流程都可以做到最优，但每一段的OLTP的流程也有自己的上游和下游，如果上游交付给你的数据不清晰，你就开始骂娘，因为要做大量的映射和转换，但你在骂娘的同时，却也很少想到要为你的下游交付清晰的数据。

最后公司发现，从全局的角度看，这个业务流并不是最优的，流程存在大量的堵点卡点，最终影响了运营效率。

可以看到，数据管理缺位的OLTP，不仅对下游的OLAP产生影响，而且开始反噬自身，更要命的是，在数字化的背景下，OLTP还需要OLAP给其变革的动力，这是很滑稽的事情。

天下苦OLTP久矣！

《华为数据之道》这本书的价值，并不在于技术牛逼，而在于顶层设计牛逼，其给出了全新的数据管理视角，可以这么说，它就是来解决OLTP的不作为而生的。

为了克服OLTP基因的缺陷，那么好，就制定一本覆盖所有领域的数据法律，确立一些数据管理的原则，比如华为数据管理总纲第一条：建立企业级信息架构，统一数据语言；第二条：所有变革项目须遵从数据管控要求，对于不遵从管控要求的变革项目，数据管控组织拥有一票否决权。

OLTP既然事不关己高高挂起，那么好，就设立领域数据owner的角色，明确领域数据owner要为OLTP系统的信息架构、数据质量、数据入湖等负责，这意味着OLTP不仅要关注自己业务跑的爽不爽，也要关注别人爽不爽，无论是上下游的流程还是OLAP，这补齐了数据管理缺失的另一半。

OLTP的信息架构是数据管理的关键，那么好，就把信息架构的要求明确告诉你，即运营好数据目录、数据模型、数据标准和数据分布四大组件，信息架构的构建方法论也告诉你，即基于业务对象进行信息架构的设计和落地。

OLTP既然是很多数据管理问题的根源，那么好，数据管理的手段就尽量往OLTP前移。比如数据质量不是经常出现问题吧，干脆，把传统的数据质量评估方法改了，除了执行阶段数据质量的评估，将信息架构的设计质量也纳入数据质量评估的范畴。比如汇聚数据不是不及时吗，干脆，我给你制定一些入湖的规范，入湖的动作OLTP自己做吧，因为你最清楚数据的变更。

既然OLTP对数据管理这么重要，在华为之前难道没人知道这个道理吗？

当然不是，自己就曾经为推进OLTP系统的数据字典建立做过努力，但OLTP有理由不做，因为那个时候的业务流是老大。

为什么现在华为提了，大家更多的会去思考这个问题了呢？

原因可能有3个：

第一、数据成生产要素了，大家对数据价值的认识更深刻了，OLAP的地位同步在提升，话语权在增加。

第二、数字化大势所趋，OLTP要自我革命。

第三、华为给了一个最佳实践，告诉大家，可以向OLTP开炮。

人人都在讲数据治理而不问业务，这很危险 by 傅一平

数据管理咨询为什么难以成功？

谈谈华为数据之道的“不能”

华为数据之道为什么这么有吸引力？by 傅一平

部门不开放自己的数据，到底在怕什么？