Tapdata 技术博客
Tapdata 技术博客

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

2021-11-10 14:11Tapdata 创始人唐建法 TJ

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


大数据时代的鼎盛行将落幕.jpg


最近,美国数据产品公司 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 甚至属于业务范畴的营销等模块都放到数据中台项目里,从而把一个数据项目硬生生做成了一个包打天下的全家桶。


传统数据中台庞大的模块结构.jpg


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


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


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


更聚焦数据的 DaaS 架构.jpg

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

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

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



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


Tapdata Real Time DaaS 架构图



推荐阅读

DTCC 干货分享:Real Time DaaS - 面向TP+AP业务的数据平台架构

2021年10月20日,Tapdata 创始人唐建法(TJ)受邀出席 DTCC 2021(中国数据库技术大会),并在企业数据中台设计与实践专场上,发表主旨演讲“Real Time DaaS :打造面向 TP+AP 业务的数据平台架构”,从 AP 业务场景 vs. TP 业务场景、常见数据平台优劣势、如何打造面向 TP+AP 业务的数据平台等角度,全面分享了 Tapdata 在全链路实时数据融...

Tapdata 在数字化防疫场景的最佳实践

在“动态清零”总方针的指导下,国内疫情防控工作渐趋规范化、常态化,各类防疫应用和手段层出不穷,防疫战也是数据战。Tapdata 基于数据虚拟化和主数据管理能力的防疫专项解决方案,助力张家港市卫健委高效落地疫情防控数字化,实现精准防疫。

Tapdata 在线研讨会:DaaS vs 大数据平台,是竞争还是共处?

我们为什么需要一个Real Time DaaS?它和大数据平台技术上有什么区别?如果企业还没有构建数据平台,我是应该考虑DaaS还是Big Data?如果已经有了大数据平台,我是否还需要DaaS?如果你想了解更多,请参加本次的在线研讨会。

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

数据中台的存在是有合理性的,企业需要中台帮助他们来有效管理企业的数据资产,为业务所用。但在经历过大数据时代的热度之后,你在为企业构建数据中台的时候可以考虑另外一种比较务实的 DaaS 架构。DaaS 更加专注于数据层面:打通企业内部的孤岛数据,在中台构建共享模型,以API方式快速发布数据服务...

解锁5大应用场景,最新实时同步实现方案分享

数字化时代的到来,企业业务敏捷度的提升,对传统的数据处理和可用性带来更高的要求,实时数据同步技术的发展,给基于数据的业务创新带来了更多的可能。 Tapdata 产品合伙人徐亮带来实时数据同步的5大典型场景以及4种主流的技术模式分享,并一起了解作为新生代实时数据同步的 Tapdata Cloud 如何更轻松灵活的满足各种实时数据场景。

Tapdata 钛铂数据的产品理念

Tapdata 是全球首个基于数据即服务架构理念、面向 TP 场景的企业实时主数据服务平台,可以帮助企业快速实现主数据的统一管理和发布,并为所有数据库、数仓、大数据平台提供最实时的源数据,让数据随时可用。

Tapdata 数据库实时同步的技术要点

Tapdata 专注于实时数据的处理技术,在数据库迁移和同步方面,Tapdata 的表现非常优秀,实时、多元、异构,尤其在关系数据库到非关系数据库之间的双向同步方面,无论是从操作上,还是效率上,都体现了业界领先的水平。本文重点阐述 Tapdata 在数据库实时同步方面的技术要点。

教育中台与第三方系统对接整合数据案例

最近, 南京秦淮区教育中台系统,成功地和市系统进行了一次圆满对接。通过教育中台提供的统一数据能力和低代码API对接能力,实现了对市系统数据的实时推送和拉取,以及各类业务逻辑上的处理。这次对接为南京市中小学生创客大赛的成功举办提供了及时可靠的数据支撑, 体现了中台系统在快速响应业务方面的优越性。

周生生 | 全渠道商品中心建设

通过Tapdata 构建全渠道商品中心,实现: - 支持中国大陆港澳台的上千家门店的生产环境; - 使用JS脚本来进行流处理计算,业务需求从开发到上线过程快至 1 天以内; - 任务配置与执行监测全程可视化操作,不懂技术也能完成操作,极大降低维护成本; - 一套产品可满足不同需求,根据业务需求产出不同类型的业务模型节省大量人力物力。

关系型数据库到MongoDB实时数据同步解决方案

使用MongoDB作为主机下行或新一代数据库的选择,将业务数据从已有主机或Oracle等关系型数据库复制到MongoDB; 使用Tapdata Replicator的CDC技术,实时监听现有业务库的数据变动并同步至MongoDB; 使用Tapdata 的RDM技术将关系型表合并转型到MongoDB JSON数据结构,并保持和源库的高度数据一致; 在MongoDB上进行新业务的开发。

Tapdata肖贝贝:实时数据引擎系列(一)-新鲜的数据流

前言2006 年诞生的 hadoop 和 她周边的生态, 在过去的这些年里为大数据的火热提供了足够的能量, 十几年过去了, 场景在变化, 技术在演变, 大家对数据的认知已经不再局限于 T+1 与 高吞吐高延迟 为主要特征的上一代框架理念, 在真实的场景里, 实时, 准确, 多变 的数据也发挥着越来越重要的作用为满足这些新的需求, 各种框架和中间件如雨后春笋般不断涌出hive 的出现让这头大象...

Tapdata 肖贝贝:实时数据引擎系列(六)-从 PostgreSQL 实时数据集成看增量数据缓存层的必要性

对于 PostgreSQL 的实时数据采集, 业界经常遇到了包括:对源库性能/存储影响较大, 采集性能受限, 时间回退重新同步不支持, 数据类型较复杂等等问题。Tapdata 在解决 PostgreSQL 增量复制问题过程中,获得了一些不错的经验和思考,本文将分享 Tapdata 自研的 TAP-CDC-CACHE,和其他几种市面常见的解决方案的优势和特性。

搭建企业级实时数据融合平台难吗?Tapdata + ES + MongoDB 就能搞定

如何打造一套企业级的实时数据融合平台?Tapdata 已经找到了最佳实践,下文将以 Tapdata 的零售行业客户为例,与您分享:基于 ES 和 MongoDB 来快速构建一套企业级的实时数据融合平台。