现在已经有很多关于台湾在数据上的价值的讨论，但凡事有利也有弊。今天我们反其道而行之，谈谈台湾在数据上的原罪。了解这些“罪”，有助于权衡利弊，做出正确的选择，这对数据中心的发展非常重要。1.资料上有“名不正言不顺”之嫌。中国儒家强调仁，但如果要你给仁一个明确的定义，没有人能解释清楚。这反映了中国哲学与西方哲学的差异。康德说：“我追求一切概念的明确定义，一切推理都不允许大胆的跳跃，而是力求用规律的原理和严格的证明来勾勒出整个研究领域的范围、部门的划分，以及所有的五漏。”内容，并为未知部分设置明确的边界标记。”概念的模糊很容易造成类似于中国哲学的问题，比如孔子在《论语》中提出：“君臣父子”，本来孔子的意思是每个人在每个职位上都应该各司其职应该做，校长应该像校长，教授应该像教授，等等。然而，汉代董仲舒出于政治需要提出三纲五常，将孔子的这段话曲解为“君为臣，父为子，夫为妻”。新文化运动的时候，孔子被批判的很厉害，真的很委屈。老外中没有中台这个词，中台这个词有点中国哲理在里面。2015年阿里拜访欧洲公司SuperSell后，提出中台战略。数据中国-台湾、商务中国-台湾、科技中国-台湾等词也被创造出来。我相信这些概念的引入是对各个专业领域的推动。为了工作的需要，没有人会在概念的严谨上下功夫，差不多就够了。可如今这话炒作起来了，就会有利益，有利益就会有江湖。各方都会因为这种利益去解读他们对中国和台湾的认识，从而形成概念上的混乱。读者眼中有一千个哈姆雷特。可以说，中泰这个词给了业界无限的想象空间，但模糊性也带来了很多问题。比如我们说中国和台湾的本质是共享和再利用，但这只是一个概念，不能当食物吃。一般需要转化为具体的动作，但是没有人能说清楚实现共同复用概念的标准动作是什么，比如对于数据中心来说，数据领域有哪些东西可以共享和重用？更大的范围，平台有这个性质，工具也有这个性质，数据也可以有这个性质。数据仓库本身似乎是为了共享复用而搭建的，那么对于已经搭建了数据仓库的企业来说，为什么还要搭建数据中台呢？数据中台具体带来哪些增量价值？很多业务和技术发展到一定阶段都会有白皮书，至少还有中立的组织想要标准化，但是没有中台，更没有数据中台。偶尔有几本数据中台的书想尝试一下，但很难说对整个行业有什么指导意义。我只能想到一种解决方案。回到业务本身，看看有哪些优化可以提升数据赋能的效率。如果未来能力积累的价值是可以期待的，那就去做吧，比如API，就是数据中台；如果能力沉淀的价值不大，也没必要强求。2、数据中台违反了奥卡姆剃刀原则。数据仓库是OLTP发展到一定阶段的自然演进，但数据中台不是。很多企业的数据仓库被动要求升级到数据中台，进而被迫推动复用和共享。或者用新概念来装饰门面。显然，这样的数据中心无法创造出数据仓库之外的新价值。数据中心在原始数据和应用数据之间增加了一层数据实体。过程增加，信息衰减，连接变弱。这就需要更多的外力来补偿。因此，如果这些新增实体不能创造增量价值来弥补引入新实体带来的成本增加，这就违反了奥卡姆剃刀原则，即“非必要勿增实体”，直白的解释就是“不要浪费更多的事情去做，用更少的事情做好同样的事情”。如果数据中心实际上没有超越数据仓库，那么它就无法避免奥卡姆剃刀的诅咒。为了对抗它，我们必须做一些数据中心应该做的事情，比如API，这是每个数据中心的操作。或者想清楚，你要有使命感，做出不一样的有价值的东西。3、数据中心需要巨大的成本投入。数据中心希望通过共享和复用的理念来积累能力，进而基于能力更快地支持应用创新。但是，快速支撑应用创新的前提是要有足够的积累资源。出来的能力。可惜在数据中心的初期，根本没有能力展现出来。大家都喜欢用数据中心的结尾来表达它的价值，但很少有人能真正体会到数据中心能力建设过程的艰辛，也不知道前期要付出多少代价.就像我说去IOE独立管控一样，老板认为可以减少IT投入，其实完全错了。最近业务方需要我们开一批原表。我说：“你能说出原来的业务需求，数据中心是由融合模型支撑的吗？”业务方说：“这个你不用担心，我等不及你修改融合模型了，到时候沟通成本会很高，我们自己搭建模型就可以了。”为了兼顾能力的积累和反应的速度，我说：“可以这样吗，我会安排两倍的资源来支持你的需求？”业务方后来妥协了，但额外的资源需要由公司支付。无论从哪个角度来看，运营数据中心都要付出巨大的代价，包括规章制度的建立、组织建设、能力建设、迭代优化等等。4、数据中心的投资风险仍然很高。数据中心的概念依然存在，是因为我们坚信数据中心积累的能力在未来有机会创造更多的价值，足以弥补初期的投资，但从潜力的角度来看受市场、回报周期、价值产出等因素的影响，企业投资数据中心确实是一项高风险的业务。首先，狭义的数据中心仅限于数据模型和服务。这些数据模型和服务打上了企业和业务的烙印，很难复制到其他领域，这实际上限制了数据中心的投资回报。现在卖数据中心的公司卖的不是数据模型和服务，而是工具平台，不属于数据中心的核心内容。第二，参考大厂商，数据中心需要三年时间才能小有成就。这还是在人才充足的前提下。因此，普通企业不一定有足够的耐心。正如凯恩斯经济学派在反驳市场学派所谓的自由市场最终会实现资源的优化配置时所说的那样：“长远来看是对时事的错误指导，从长远来看，我们都死定了””3、数据中心和平台概念不清晰，对企业的文化、组织、机制、流程、数据、平台要求高，输入输出关系不明显，这也是比较忌讳的投资。当然，企业不必如此专注于自己的投资。毕竟不是一件简单的生意，但他们心里还是要掂量掂量的。5、数据平台能力难以标准化。在15年前的数据仓库时代，业界曾经提出一个非常先进的概念：数据封装，就是将数据封装成API供业务调用，类似于编程语言中的函数。比如将某种ad-hoc查询封装成API，而不是和应用程序强绑定，我认为这是数据中心最早的雏形，但后来我质疑数据封装的复用性。数据不同于函数。数据的指标和维度可以有上万种，组合方式更是数不胜数。可能日常1000个函数可以满足基本的编程需求，但是对于数据封装，不知道需要多少数据。封装可以满足一个数据分析应用的需求，大部分是通过自定义访问来满足的。功能的贡献来自所有程序员，超越行业，所以可以快速更新迭代，但数据封装很难超越行业，能贡献经验的也仅限于企业中的某些人。我总觉得数据封装的功能可能还没来得及大规模使用就被新业务淘汰了，或者企业根本就没有那么多的标准化能力复用的场景。正因如此，或许只有大型企业才能从数据中心的能力标准化中获益。6、数据中台导致系统存在漏洞。现在云原生如火如荼，微服务、容器化、DevOps既保证了业务中台的敏捷性，又保证了它的连续性。数据中心不享受任何持续分红。对于大多数公司来说，数据中心一般没有灾备，甚至可能没有应急，因为数据的灾备意味着成倍的投资。在一般公司是做不到的。Hadoop虽然有三次数据备份策略，但对人为错误和数据逻辑错误无能为力。数据中心的目标是将分散的数据能力集中共享，实现能力“一点释放，全部共享”的理想。但是，在数据中心的连续性问题不能彻底解决之前，集中式数据中心也会带来中心化的风险。例如，集中式数据一旦被删除，对企业应用的影响是全方位的。数据中心做得越好，共享能力越高，风险就越大。这就是悬在数据中心连续性上的“达摩克利斯之剑”，即“一点故障，全面影响”。我自己也经历过这样的hadoop事故，现在估计是灾难。我们有两个GIS应用程序。一个GIS应用由于历史原因采集了大量数据，另一个GIS应用是根据数据中心提供的数据构建的。某日，运维人员误删除了数据中心内所有GIS相关数据。Hadoop无法恢复数据。由于在另一个应用程序中存在重复数据，因此避免了核心数据的丢失。所谓祸在福处，福在祸处。数据平台确实有很大的价值，但也隐含着很多风险。我们已经多谈了它的优点，少谈了它的缺点。这不是写实风格。更可怕的是，这些事情我们自己可能都不知道。风险的存在。
