下一个十年，你还在用 Big Data 搭建数据中台吗？

引言：数据中台的存在是有合理性的，企业需要中台帮助他们来有效管理企业的数据资产，为业务所用。但在经历过大数据时代的热度之后，你在为企业构建数据中台的时候可以考虑另外一种比较务实的 DaaS 架构。 其实 DaaS 可以理解为海外的“数据中台”，只不过相较于我们的数据中台，DaaS 更加专注于数据层面：打通企业内部的孤岛数据，在中台构建共享模型，以API方式快速发布数据服务。至于数据驱动的业务，无论是AI ，BI 还是分析等，都可以作为DaaS的下游。

最近，美国数据产品公司 Cloudera 从纽交所退市，可以算得上是告别上一个十年大数据鼎盛时代的里程碑事件。早在17年的时候我曾经写过一篇文章： “后Hadoop时代的大数据技术思考”，就是意识到了基于Hadoop的大数据平台由于其设计初衷，对很多企业的关键业务场景特别是面向外部客户或者内部运营的场景支撑是有限的。果不其然，2018年，   Hortonworks 并入 Cloudera，整个团队基本解散; 2019年，MapR被我老东家惠普基本上是白菜价收购； 2021 年，大数据(Big Data) 三驾马车（Cloudera, Hortonworks, MapR)的最后一驾也终于黯然从舞台上退居二线。

切换视角， 同样是一个时期的NoSQL数据库MongoDB, Elastic, 以及Kafka等却在二级市场上备受追捧，MongoDB 股价更是扶摇直上，从上市之际的24美元 一路狂飙到550多美元。 Elastic则是160多，Kafka（Confluent)是接近100。 相比之下，Cloudera一直在几美元左右股价徘徊。

我们都说，市场是检验技术的最好的度量。从这个角度，大家已经已然可以知道一些端倪。

从经济学的本质逻辑来看，这样的结果其实只是反映了企业在OLTP和OLAP 系统上的投入比例。基于Hadoop的大数据（分析）平台，是典型的OLAP系统，而MongoDB/Elastic Search，更多是为TP型业务应用服务的。几年前Gartner的一份报告，说到了企业在Operational 和 Analytical 系统上的预算比例是9：1。我找了两个CIO朋友，他们在不知道这个报告的情况下，分别给出了90/10 和 80~90/10~20的估计。

TP系统（Transaction Processing）关注的是企业的日常运营。比如说你开个奶茶店，开始的时候你只需要用个Excel来管理一下每天的销售情况和成本支出等。后来你越做越大，一家门店一天卖出几千杯，Excel已经无法处理这么多的订单记录，于是你可能会委托一家IT服务商帮你定做一个简单的销售系统，用来记录每天的销售情况。后来你越做越成功，开了几十几百家门店，你又开始构建专门管理门店，员工，原料等系统。为了方便顾客手机下单，你又雇人开发一套小程序系统用来下单和送外卖。这些，都是TP型业务系统的例子。

现在来看下，当你开始有了几十家门店的时候，你可能会关心一些什么呢？哪家门店最赚钱？什么时间段生意最好、最不好？什么品类最好卖？要回答这些问题，我们就需要对上面应用系统内已经产生的业务数据进行一些聚合分析，从而获得我们想要的答案。因为做这些分析需要的数据往往在不同时间构建的不同业务系统之内，所以我们需要将数据汇总到一个中央化的数据平台，比如说数据仓库或者大数据平台。这就是一个典型的AP型场景。

综上所述，我们就可以有一些这样的观察：

首先，TP 永远先于AP 系统建设。 因为AP用以产生价值的数据，首先要来自企业运营的TP型系统。所以一个企业早期的IT预算，几乎毫无例外都是投于TP系统。

其次，TP系统的数量要远多于AP系统。AP系统由于有数据汇聚以后分析的属性，而一般企业只需要少量的汇聚系统来完成企业级的分析需求。

最后，TP业务系统的SLA要远高于AP系统： 订单系统停止5分钟，CEO就会来过问了。而如果你的大数据平台停止工作一天，可能只是一个部门级的问题。

有了这些理解，我们再来看下前几年阿里带起来的数据中台架构，在潮水慢慢褪去的时候，也在显露出它在企业业务价值体现上的实际短板。

Don't take me wrong, 数据中台是一个真命题。

过去的 20 多年，传统企业投入了大量资源在信息化系统的建设上。根据美国著名企业F5的一次为期数年的调查，有接近一半的企业内运行着200套以上的应用系统。另一半的企业则有数套到200套之间。这些系统往往是由应用程序和其对应的数据库系统组成一体，互相之间并不联通，逐渐形成一个个的企业内数据孤岛。最近几年的微服务化，更加深了孤岛式数据的现象。 数据孤岛对企业最大的影响就是数据不统一、不完整、不一致，小到影响用户体验，大到直接导致新业务无法开展，阻碍了企业数字化转型的进展。

数据孤岛是怎么形成的？ 有几个关键的因素。

首先是企业功能和组织架构决定。软件系统是在某个时间点为公司中的某个特定部门的场景编写的，比如为业务团队构建一个CRM系统，或者为市场团队建设CMS系统。在资源有限的世界中，应用程序只会针对其主要功能进行建设和优化。数据共享，互联互通，从来不是应用架构师的一个主要设计考量。好的架构师，可能会设计好一套开放接口，在功能上允许第三方进行集成。但是接口的设计，也仅仅局限于架构师当时的战略思考和能力范畴，难以满足。

其次是自然的发展。任何一家历史悠久的公司都经历了几代技术领导者、不同理念和兼并收购的成长历史，导致了多个互不兼容的系统。即使在集成数据时不存在内部政治问题，协调和集成体现重要业务概念的不同方法的数据集的成本也很高。

然后就是软件供应商锁定。软件供应商是最先知道访问数据就是力量的人之一，他们的策略并不鼓励用户简单地导出他们系统包含的数据。大家看看公有云厂商的数据同步工具知道了，正如一首脍炙人口的名曲Hotel California里面唱的： You can check out any time you like, but you can never leave.

而数据中台，是在企业在信息化向数字化演进历程中解决数据孤岛问题的一个理想架构。通过数据采集工具，把各个业务系统的数据复制到中央化数据存储平台，然后使用数据治理手段，包括质量，安全，元数据管理等对数据进行统一的治理并资产化，结合服务能力为企业的数据业务场景提供可复用的数据支撑。

架构没问题，但是技术选型上，国内在数据中台热潮下奋勇而起的数据产品厂商和集成商们，几乎无一例外的选用了以Hadoop 大数据平台为主要载体的技术方案。上面我们已经谈到了，Hadoop Big Data是一个大数据分析系统，主要为分析场景提供一个基础数据平台。排除掉其他一切的不说，Big Data Platform里面的数据，是一份离线的，T+1的数据。

T+1数据意味着什么？很多对数据实时性要求高的场景就没法做了。比如说，中台将客户的订单数据进行了统一，可以用来做一些订单分析。但是如果你想做一个跨系统客户统一订单管理的小程序，中台的数据就无法为你服务了。谁愿意用一个小程序，看不到我今天刚下的单呢？

数据中台的理念是打造一个提供一个中央化的，可复用的，面向企业所有业务的数据平台。但是因为Big Data Platform的设计初衷，它只能解决历史数据的洞察和分析，极大的限制了中台的价值。怎么办？常见的做法就是把BI，大屏，推荐，标签，AI 甚至属于业务范畴的营销等模块都放到数据中台项目里，从而把一个数据项目硬生生做成了一个包打天下的全家桶。

但是数据中台模块堆砌的越多，系统越复杂，使用成本越高，数据链路问题也更难排查。由于在一个平台里采用多套数据存储方案，如使用Hive作为主数据存储， Hbase用来做实时查询， Kudu用来做分析，Elastic 用来做搜索，往往是企业整体的数据孤岛问题没有解决好，在中台内部已经出现几个数据系统不统一的新问题了。

除了离线数据的局限性，以Hadoop为存储的中台服务的性能也是直接导致无法支撑高并发的交互式应用。分析场景由于需要对大量的历史数据进行扫描，在设计上对压缩，存储模式有比较多的考量。而事务型的应用，因为面向很多最终用户，往往是在索引，主键查询上面有比较多的优化。

数据中台的存在是有合理性的，我们不能妄然否定甲方CIO/CDO们的判断力：他们理解他们数据孤岛对企业的制约和束缚，他们需要中台帮助他们来有效管理起企业的数据资产，为业务所用。 在经历过大数据时代的热度之后，你在为企业构建数据中台的时候可以考虑另外一种比较务实的DaaS架构。 其实DaaS 可以理解为海外的“数据中台”，只不过相较于我们的数据中台，DaaS 更加专注于数据层面：打通企业内部的孤岛数据，在中台构建共享模型，以API方式快速发布数据服务。至于数据驱动的业务，无论是AI ，BI 还是分析等，都可以作为DaaS的下游。所以你可以考虑这样的一条路线：

• 放弃Hadoop 大数据平台作为存储，改用高并发低延迟的分布式数据库（MongoDB或者TiDB）。

• 用T+0，而不是T+1的数据来装载中台。和源系统高度一致的数据集，为你解锁企业真正需要的业务价值：360度客户视图，全渠道商品及库存中心，会员中心，实时风控等

• 下游数据业务，甚至是数据治理，都可以等需求明确的时候逐渐建设。当然在中台建设初期，还是需要一个业务价值锚点，作为中台成功的检验指标。

  
  

Tapdata Real Time DaaS 正是基于数据即服务（Data as a Service，简称 DaaS）架构理念、面向 OLTP 业务或场景的企业实时数据服务平台。申请试用：tapdata.net‍