从美股史上最大软件IPO,看数据仓库市场的增长逻辑

硅谷独角兽Snowflake上月创造美股史上规模最大软件公司IPO,市值一度突破700亿美元。数据仓库市场经历20余年发展变革后,在云原生浪潮下即将迎来大洗牌?回顾历史,我们试图找到一条推动数据仓库市场发展的内在逻辑。

本文来自微信公众号:爱分析ifenxi(ID:ifenxicom),原标题《美股史上最大软件公司IPO诞生,数据仓库市场未来充满想象 | 爱分析洞见》,指导:黄勇,调研:李喆、冯伟,撰写:冯伟

硅谷数据仓库厂商Snowflake于2020年9月17日正式登陆纽交所,上市首日市值一度突破700亿美元。市场对于Snowflake有如此高估值,很大因素在于投资者对其“云原生”模式和中立地位在云计算时代所具备的独特优势的认可,以及对其业绩持续高速增长的良好预期。

据财报数字显示,截至2020年1月31日的2020财年全年,Snowflake实现了高达174%的同比业绩增长,而2021财年上半年的业绩增长同样高达133%。

事实上,Snowflake的本次上市已经是美股史上最大规模的软件公司IPO,这无论在整个企业级软件市场,还是在数据库与数据仓库市场,都是一件足以深刻影响行业格局的重大事件。

相比于美国市场,中国市场中以云原生模式作为主打的独立数据仓库厂商处于加速发展阶段,例如诞生于Apache HAWQ开源项目的偶数科技(其核心产品为OushuDB云原生数据库)是中国市场中的佼佼者。

为了阐明云原生数据仓库的独特价值,爱分析将依次在本文中阐述以下几点问题:

  • 数据库的分类逻辑与发展历程

  • 分析型数据库(数据仓库)的代际演进与驱动因素

  • 海外数据仓库市场的规模预测与主要玩家

  • 中国数据仓库市场的规模预测与主要玩家

一、数据库的分类逻辑与发展历程

数据库管理系统(DBMS,一般简称“数据库”)的萌芽始于1960年代。当时,随着计算机广泛地被应用于数据管理,人们对数据在计算机上的组织形式提出了越来越高的要求,传统文件系统已经不能满足需求,希望能够基于一套系统对数据进行统一管理和共享,数据库由此诞生。

经过超过半个世纪的发展,数据库形成了非常丰富而庞杂的类别,面向的应用场景也千差万别。一般而言,人们会从数据模型、应用场景两个维度对DBMS进行分类。

  • 数据模型:即DBMS底层数据的组织形式,一般分为关系型和非关系型两大类别;

  • 应用场景:DBMS的应用场景一般分为联机事务处理(OLTP)和联机分析处理(OLAP)两大类别,这两类DBMS也分别被称之为事务型数据库和分析型数据库(也称“数据仓库”)

从数据模型演化的视角来看,数据库市场经历了萌芽阶段、成熟阶段、丰富阶段三个主要阶段。

1960年代是数据库市场的萌芽阶段,网状模型、层次模型引领了最早的一代数据库的诞生。

1970到1990年代是数据库市场逐步走向成熟的阶段。1970年,IBM研究员E.F.Codd提出了关系模型,标志着数据库市场开始走向成熟。从1979年开始到1980年代,Oracle(1979年)、IBM(1983年)、微软(1989年)三大巨头先后推出自己的关系型数据库,Teradata也推出基于专有硬件的MPP架构的关系型数据库,关系型数据库逐步成为市场主流。到1990年代,MySQL、PostgreSQL等开源数据库的出现进一步壮大了关系型数据库的阵营。

2000年以后是数据库市场的丰富阶段。这一阶段,数据库面临的重要挑战是数据量明显增加,数据类型和应用场景越来越复杂。因此,Greenplum、Vertica等基于x86服务器的MPP架构关系型数据库,Hive、SparkSQL、HAWQ等SQL-on-Hadoop体系的关系型数据库,以及键值数据库(如HBase,Cassandra)、文档存储(如MongoDB)、图数据库(如Neo4j)等非关系型数据库纷纷出现。这使得关系型数据库阵营的类型进一步丰富,也使得非关系型数据库阵营迎来了崛起,数据库市场因此呈现出关系型、非关系数据库并存发展的局面。

二、分析型数据库的代际演进与驱动因素

在另一个维度上,数据库的架构也在随着应用场景的变化在演进。

在1990年代以前,应用场景以联机事务处理(OLTP)场景为主,数据库以事务型(又称“交易型”)数据库为主。随着E.F.Codd于1993年正式提出联机分析处理(OLAP)的概念,数据分析的场景不断发展变化,从而推动了分析型数据库(即“数据仓库”)的不断发展和成熟,并与事务型数据库呈现长期并存的局面。

数据仓库从诞生至今,经历了20余年的发展历程,大体经历了四代的演进。这一过程中,技术架构的变化是推动演进过程的内在力量,而场景与需求的变化,则是推动演进过程的外在力量。

因此,我们将从技术因素、需求因素两个主要方面,对数据仓库演进的驱动因素进行分析。

  • 技术因素:包括硬件架构、软件架构、功能优化、性能优化等四个层次;

  • 需求因素:包括应用场景、功能与性能要求两个层次。

1)第一代数据仓库:共享存储架构数据仓库

从1970年代末到1980年代,数据库主要应用于OLTP场景,并采用共享存储架构,因此被称为事务型数据库。这一阶段,由于OLAP场景尚不成熟,因此分析型数据库(即“数据仓库”)尚未完全从事务型数据库中完全脱离出来,同样以采用Oracle、DB2等共享存储架构的事务型数据库为主。

在这一阶段,数仓存在的问题是价格昂贵,且受到共享存储架构影响,可扩展性较差,扩展到十几个节点就会遇到存储瓶颈,仅能适应面向管理层的报表分析需求,但无法适应更大规模、更多用户的数据分析场景。

驱动因素:技术

  • 硬件架构/软件架构:在软硬件层面都采取共享存储架构,计算节点能够访问到任意的存储节点,由此保证对性能的良好优化;

  • 功能优化:对各类SQL标准、ACID特性(指数据库事务的四个属性,包括原子性、一致性、隔离性、持久性)的支持都相当完善,因此带来了很强的稳定性。但是,共享存储架构带来的缺点是可扩展性差,一般只能扩展到十几节点就会遇到瓶颈;

  • 性能优化:主导第一代数仓的Oracle、IBM等IT巨头公司具备深厚的基础研究和性能优化能力,但是由于共享存储架构在可扩展性方面的不足,使得第一代数仓尽管十分擅长传统报表分析等场景,但在大数据分析场景中的性能表现相对一般。

驱动因素:需求

  • 应用场景:以传统的报表分析场景为主,主要面向企业管理层提供顶层业务数据的报表展现,数据量相对较小;

  • 功能与性能要求:传统报表分析场景更看重分析的稳定性和可靠性,因此对SQL标准、ACID特性等影响分析过程的稳定性、分析结果的可靠性的技术功能与性能要求更高;第一代数仓对传统报表分析场景的满足性较好,但是随着大数据分析场景的出现和增加,扩展性不足的第一代数仓开始难以满足企业需求。

2)第二代数据仓库:MPP无共享架构数据仓库

1984年,Teradata首次推出了面向分析型场景的无共享架构的MPP数据仓库,在一定程度上解决了因共享存储架构带来的扩展性难题。但是由于它基于大型机、专有硬件,还有软件架构的限制,因此扩展性仍然难以达到数千节点级别,且扩展成本昂贵。

进入新世纪以后,随着数据分析场景的不断丰富,以及数据量的不断提升,基于专有硬件的MPP数据库已经难以满足扩展需求。到2006年,基于x86通用服务器的MPP数据仓库Greenplum、Vertica几乎同时出现,进一步降低了扩展成本。

MPP数仓在经过长期发展后,由于其对传统事务型数据库ACID特性的良好支持,以及相对较低的运维管理门槛,逐步在企业数据仓库市场中占据主导地位。但是,MPP也存在固有缺陷,一方面,无共享架构导致了其难以实现上千节点的扩展,另一方面,计算与存储节点的绑定也使得其扩展灵活性不够,难以适应工作负载变化更快的数据分析场景的需求。

驱动因素:技术

  • 硬件架构:在硬件层面采取了无共享的存储架构,每个计算节点都有自己独有的存储节点;其中,Teradata采用专有硬件,而Greenplum、Vertica等则采用x86通用服务器;

  • 软件架构:基于大规模并行处理(MPP)架构,数据并均匀打散到所有节点存储,并将多个并行任务分散到不同的节点上执行;

  • 功能优化:无共享和MPP架构消除了在大数据场景下的性能瓶颈,提升了负载均衡能力,更加适应于大数据分析场景;无共享架构使得节点扩展变得更加容易,而不再受到共享存储架构的制约,节点数量上限一般能达到数百个;基于x86通用服务器的无共享架构,降低了扩展成本,提升了灵活性;

  • 性能优化:主导第二代数仓的Teradata、EMC(收购Greenplum)、惠普(收购Vertica)等公司,在整体实力上同样较为雄厚,具备较强的基础研究和性能优化能力,再加上MPP固有的高性能数据处理优势,使得第二代数仓在大数据分析场景中有着超越第一代数仓的性能表现。

驱动因素:需求

  • 应用场景:随着企业中的数据分析场景增加,分析需求的复杂度提升,面向企业各个部门的大数据分析场景成为数据仓库的主要应用场景;

  • 功能与性能要求:大数据分析场景的典型特征是数据量大,而且数据量会不断增长,使得高并发、弹性扩容需求越来越强烈;第二代数仓经过长期发展,与企业核心、传统业务结合得十分紧密,因此企业对SQL标准、ACID特性等影响稳定性、可靠性的指标的要求也越来越高;第二代数仓在这两方面,一开始都能较好地满足企业需求,但随着数据量的进一步提升,MPP架构的限制使得第二代数仓难以进一步提升节点数量。

3)第三代数据仓库:SQL-on-Hadoop数据仓库

2007~2009年间,也就是几乎在Greenplum、Vertica等MPP数据库出现的同时期,以Hive开始的SQL-on-Hadoop数据仓库开始出现。尽管SQL-on-Hadoop数仓在硬件架构上仍然基于无共享架构,但在软件架构层面实现了计算与存储的完全分离。因此,相比于MPP数仓,SQL-on-Hadoop数仓进一步提升了扩展灵活性,降低了存储节点的管理难度,节点规模上限被提升到几千节点。

但是,由于底层存储系统HDFS的只读特点,SQL-on-Hadoop数仓普遍存在一系列缺点,比如对传统SQL兼容性不足,对Update/Delete等更新操作和混合工作负载(OLTP+OLAP场景)支持性较差,对事务型数据库所必备的ACID特性缺乏支持,稳定性较差。由于这些缺陷的存在,SQL-on-Hadoop数仓尽管替代了一部分MPP数仓,但仍然以支撑相对边缘的数据分析业务为主,难以撼动MPP数仓的主导地位。

对比来看,MPP与SQL-on-Hadoop各有优劣势,为此许多人希望能够将两者的优势结合在一起,并抵消两者的劣势。Apache HAWQ就是这样一个开源项目,它从2011年开始启动,脱胎于已经被EMC收购的MPP数据库Greenplum。

早期的HAWQ是将Greenplum搭载在HDFS存储系统之上的一个改进版本,从而一方面具备MPP数据库固有的SQL标准兼容、ACID特性支持等能力,另一方面又具备SQL-on-Hadoop的计算存储分离架构带来的可扩展性优势。

驱动因素:技术

  • 硬件架构:与第二代数仓类似,第三代数仓在硬件层面采取了无共享的存储架构,每个计算节点都有自己独有的存储节点;

  • 软件架构:与第二代数仓不同,第三代数仓基于Hadoop体系内的HDFS等存储系统,在软件层面实现了存储系统的完全独立,即计算、存储的完全分离,可以独立实现扩展;

  • 功能优化:由于计算存储分离架构的特点,第三代数仓能够实现计算、存储分别扩展,因此在扩展性、在线扩容等方面有明显优势;由于计算、存储节点的独立,第三代数仓较适合迁移到云上,借助云固有的特性实现计算存储分别扩展,但是大部分厂商并未对数仓进行深度的云原生优化和改造,弹性伸缩能力未得到充分发挥;由于HDFS的只读限制,第三代数仓在对传统事务型数据库所具备的SQL标准、ACID特性支持较差;这也使得应用从事务型数据库、MPP数据库向第三代数仓迁移的过程中,存在大量不兼容的问题,即应用易迁移性较差;

  • 性能优化:第三代数仓由开源项目、互联网公司、初创型公司所主导,生态相比于前两代数仓更加开放,但是由于缺乏针对性能和功能的深度优化,在传统企业客户中一直未达到能够全面取代传统数仓的要求。

驱动因素:需求

  • 应用场景:随着企业数字化进程的加深,企业大数据分析场景对数据量、节点数量的要求都进一步提升;除了核心业务和传统业务场景之外,大量创新型、边缘型业务也诞生了大数据分析的需求;

  • 功能与性能要求:企业中新出现的创新型、边缘型的大数据分析场景,往往与终端用户数据与行为结合紧密,因此数据量相对传统业务、核心业务的数据分析场景反而更庞大,而且工作负载的波动性也更加明显,因此对于扩展性、在线扩容、弹性扩容等灵活性指标的要求更高;第三代数仓基于计算存储分离架构,对这些要求的满足性较好,但HDFS的只读限制,使得第三代数仓在SQL标准、ACID特性等方面的支持性不足,影响了其数据一致性和易用性,在进一步向企业核心与传统业务场景延伸过程中遇到困难。

4)第四代数据仓库:云原生数据仓库

2010年之后,随着云计算的兴起,数据仓库逐步开始云化。相比于部署在物理硬件上的数仓,云数仓的优势在于能够支持云的按需取用、弹性扩容特性,有效提升数仓的扩展效率,降低扩展成本和运维难度。

但是,早期的云数仓更像是将物理硬件环境的数仓打包到云环境中,并没有基于云环境的许多特性对数仓进行深度原生优化。比如,许多基于MPP无共享架构的数仓,即使被迁移到云平台上,仍然面临计算与存储资源完全绑定,难以单独扩展的问题,无法充分利用对象存储等云计算具备的独特资源,弹性优势难以完全发挥,因此仍然难以称之为“云原生数仓”。

2014年,随着Snowflake推出云原生数据仓库,实现了多集群共享数据的存储与计算分离架构,真正开始与云平台实现深度融合。

2016年,源于Apache HAWQ的OushuDB诞生,它从设计之初就定位为新一代的云原生数据仓库。OushuDB基于计算存储分离架构,多集群可以共享数据,在支持HDFS的同时,还实现了可插拔存储,支持对象存储等云存储技术,充分适应云计算时代的弹性需求。此外,OushuDB能够很好的支持Update/Delete与混合工作负载,充分克服了SQL-on-Hadoop数仓在这方面的劣势,其新一代SIMD执行器比传统MPP数仓要快5~10倍,比一般的SQL-on-Hadoop数仓要快20倍左右,进一步的满足了企业海量数据处理的需求。

驱动因素:技术

  • 硬件架构:硬件架构为无共享的x86服务器,与前三代不同的是,第四代数仓原生支持云化的环境;

  • 软件架构:第四代数仓一般会综合第二、三代各自的技术优势,有的是基于SQL-on-Hadoop体系融合MPP在SQL标准、ACID、负载均衡等方面的支持性优势,有的则是基于MPP架构融合SQL-on-Hadoop在扩展性等方面的优势;

  • 功能优化:Snowflake、OushuDB等第四代数仓具备了前三代数仓的所有优势,而且基于云的固有特性,在扩展性、弹性伸缩、在线扩容等方面,在成本、效率上都达到了最优;

  • 性能优化:Snowflake、OushuDB等数仓充分改进了SQL-on-Hadoop体系的第三代数仓在性能优化方面的不足,融合MPP架构的优势,并在其基础上进行了大量优化,性能表现超越了前三代数仓的表现。

驱动因素:需求

  • 应用场景:随着企业传统业务、核心业务与创新业务、边缘业务的全面数字化转型,许多企业希望建设面向全企业、覆盖全业务线的大数据平台;随着企业的智能化水平提升,基于AI进行预测性分析,从而支持业务决策的场景越来越多;IoT技术的成熟,使得线上线下数据融合,从而共同进行决策支持的趋势也越来越明显;

  • 功能与性能要求:面向全企业、全业务线的大数据平台建设,需要数据仓库在稳定性与可靠性指标,比如SQL标准、ACID特性,以及灵活性指标,比如扩展性、在线扩容、弹性扩容,都具备较强的表现;AI在预测性分析场景的落地,以及IoT带来的线下数据量的爆发式增长,都使得企业对数据仓库的性能要求进一步提升;第四代数仓在这些方面,均能够较好地满足企业需求,因此将成为未来数仓的最新发展趋势。

  • 其他要求:相比于前三代数仓,推动第四代数仓的一项重要因素,还在于企业对于降本增效的诉求进一步提升,期望通过云计算固有的按需取用、灵活弹性等优势,推动IT部门在数据分析过程中敏捷转型,推动IT部门由过往的“成本中心”向产生更多业务价值的“价值中心”转变。

三、海外数据仓库市场的发展情况

IDC在2020年8月发布的《IDC全球大数据支出指南》预测,2020年全球大数据相关硬件、软件、服务市场的整体收益将达到1878.4亿美元,较2019年同比增长3.1%。爱分析推算,其中大数据相关软件市场规模约600亿美元,而软件市场中,数据仓库市场规模约为200~300亿美元。

IDC预测,2020~2024年间,全球大数据技术与服务相关收益将实现9.6%的年均复合增长率,预计2024年将达到2877.7亿美元。爱分析预测,届时全球数据仓库市场规模将达到400~500亿美元。

按照代际划分来看,海外数据仓库市场的主要厂商包括四类:

1)第一代数据仓库厂商:Oracle、IBM

作为事务型数据库市场中占据主导地位的厂商,Oracle、IBM早期并没有推出独立的数据仓库产品,而是将分析型数据库的特性融入到其事务型数据库产品中。但是,Oracle、IBM后来都分别推出独立的数据仓库产品。

Oracle Exadata是Oracle于2008年推出的数据库一体机产品,可以和Oracle数据库兼容。Exadata采取与MPP、Hadoop生态体系不同的路径,通过共享高端存储架构、高端Infiniband网络等超强硬件的融合实现了在一定数据量级下的极限性能提升,但缺点是可扩展性差等,一般只能扩展到十几节点。

IBM曾于2010年收购数据库一体机厂商Netezza,但于2019年正式停止Netezza的生产和技术支持,并将数据仓库产品IBM Db2 Warehouse作为替代方案。

2)第二代数据仓库厂商:Teradata、EMC、惠普

基于无共享MPP架构的第二代数仓,从早期基于专有硬件,发展到后来的基于x86通用服务器,跨越了约20年的发展历程。

Teradata成立于1979年,仅仅比Oracle的成立晚了两年。Teradata于1984年首次推出数据仓库产品,是最早采用无共享的MPP架构的数据仓库厂商。但是由于Teradata基于专有硬件,以及MPP架构固有的计算和存储绑定的特点,节点规模上限只能达到百级别。

Greenplum公司成立于2003年,于2006年推出了首款产品,并于2010年被EMC收购。Greenplum基于PostgreSQL开发,采取无共享的MPP架构,且基于x86通用服务器,扩展成本相对Teradata较低,但由于计算存储绑定的特点没有改变,节点规模上限仍然只能达到百级别。

Vertica是数据库先驱Stonebraker在MIT期间,基于C-Store架构开发的商业版本,首次发布于2006年,并于2011年被惠普收购。Vertica基于无共享MPP架构和列存储技术,同时与Greenplum类似,它能够部署在x86服务器上,而不依赖于专有硬件。

3)第三代数据仓库厂商:Cloudera、Facebook

第三代数仓的特点是基于Hadoop开源体系发展而来,具备天然的开放性,因此许多公司都推出了各自版本的Hadoop,也有一些公司则围绕Hadoop开发产品。

在Hadoop生态体系中,规模最大、知名度最高的公司是成立于2008年的Cloudera。Impala是Cloudera公司主导开发的SQL-on-Hadoop引擎,能够查询存储在Hadoop的HDFS和HBase中的PB级大数据,实现了计算与存储分离,扩展性较好,一般能够达到上千节点。

Presto是Facebook开发的数据查询引擎,于2012年开始开发,并于2013年宣布开源。Presto同样是一种SQL-on-Hadoop引擎,实现了计算存储的完全分离。其中,存储层采用HDFS,而计算层没有采用MapReduce,而是使用Java语言重新实现了计算引擎。

4)第四代数据仓库厂商:Snowflake、AWS、Azure

相比于前三代数仓,第四代数仓的特点是深度融合了云计算的特性,增强了数仓的弹性和扩展灵活性,降低了数仓的获取和运维成本,因此又被称为“云原生数据仓库”。

Snowflake等独立厂商以及云厂商都是云原生数据仓库市场的主要玩家。其中,Snowflake将产品在云计算环境中进行了深度的优化,而且具有较强的中立性。而AWSRedshift和Azure Synapse Analytics等云厂商产品的中立性较差,而且技术路线是拿传统MPP直接在云环境部署,存储与计算耦合,和云原生的第四代数据仓库比较依然有着较大的差距。因为数据库的架构变动研发周期较长,往往需要几年的时间,难于短期追赶,Snowflake的技术优势比较明显。

四、中国数据仓库市场的发展情况

相比于海外市场,中国数据仓库市场存在三点特征:

1)市场规模尚小,但发展潜力巨大,未来增速可期

IDC在2020年8月发布的《IDC全球大数据支出指南》预测,中国大数据相关市场的总体收益将达到104.2亿美元,其中硬件、软件、服务占比分别为41.0%、25.4%和33.6%,即大数据相关软件市场规模约26亿美元,而软件市场中,数据仓库市场约为10亿美元,仅占全球市场的3%~5%。

IDC预测,2020-2024年间,中国大数据相关技术与服务市场将实现19.0%的年均复合增长率,即2024年将达到209亿美元。爱分析预测,到2024年,软件、硬件、服务三个细分市场在大数据市场中占比将各自趋近于三分之一,即大数据相关软件市场规模将达约70亿美元,其中数据仓库市场将达30~35亿美元,占全球市场的比例将提升到7%左右。

此外,在美国数据库市场中,分析型数据库的份额已经达到40%~50%,但中国市场的这一数字仅是10%左右。但相比于美国,中国企业的数字化场景更加丰富,数字化的需求也更加迫切。

整体来看,中国数据仓库市场的发展潜力十分巨大,在未来较长时间内将经历快速增长。

2)厂商发展历史较短,产品以第二、三代数仓为主

由于中国企业级IT市场的发展较晚,本土厂商中尚没有产生像Oracle、IBM这样的在传统的事务型数据库市场中占据垄断地位的巨头,因此也跳过了第一代数仓的发展阶段,而是以第二、三代数仓产品为主。

基于无共享MPP架构的本土厂商有华为、南大通用等,华为GaussDB、南大通用GBase都是类Greenplum的产品,优势和缺点也与Greenplum类似。基于SQL-on-Hadoop引擎的典型本土厂商是星环科技,其数据仓库产品Inceptor是从SparkSQL演化而来。

3)上云进程相对美国滞后,但未来趋势不可改变

目前,中国尚未出现和Snowflake一样体量的云原生数仓独角兽公司。这背后的原因之一在于中国企业,尤其是传统型企业的云化进程相对滞后,使得大量业务数据仍然停留在传统IT环境中,进一步延后了企业对于云原生数据仓库的需求。

与美国市场类似,中国市场中主要的云原生数据仓库玩家,既包括阿里云、华为云这样的云厂商,也存在偶数科技等独立厂商。阿里云和华为云和AWS和Azure类似,采用了传统MPP搬上云的方式。

偶数科技的OushuDB起源于Apache开源项目HAWQ,采用了存储与计算分离的架构,多集群可以共享数据,计算节点之间通过高速互联网络连接,可以进行大规模并行处理,存储层独立可插拔,使用云对象存储、HDFS、或者自研的本地存储来存储数据,实现了云原生。

爱分析认为,以下几点因素将推动中国本土的独立云原生数据仓库厂商的快速发展,中国出现类似Snowflake百亿美金级的中立型数据仓库独角兽只是时间问题

  • 国家层面对信创产业空前重视,中国企业对于国产化替代的需求也日益增加,迫切需要本土厂商来满足企业数字化转型过程中的数据平台建设需求;

  • 中国企业上云和数字化转型不断推进,两者互相融合,因此企业需要能够适应高弹性的云计算环境的数据仓库;

  • 多云策略的逐步普及,企业为了在多云之上的数据仓库的功能、体验与管理的一致性,需要数据仓库厂商具备一定的中立性。

本文来自微信公众号:爱分析ifenxi(ID:ifenxicom),指导:黄勇,调研:李喆、冯伟,撰写:冯伟

数据湖,比“数据中台”更需要重视的概念

本文来自微信公众号:腾讯研究院(ID:cyberlawrc),作者:火雪挺(腾研识者、腾讯CSIG资深架构师),头图来自:视觉中国

一件事物若能经得起时间的推敲,经得起历史的选择,回过头去看仍能矗立在长河之中,那我们通常会称它为“经典”。

10年前,Pentaho公司(一家开源BI公司)的CTO詹姆斯·迪克森在他的博客中第一次提出“数据湖”(Data Lake)的概念;10年后的今天,在业界“数据中台”大火的时代背景下,再来讨论“数据湖”,应该别有一番韵味。

本文将会以“数据湖”为中心,展开讨论数据仓库、数据湖和数据中台这几个概念之间的藕断丝连。

从“数据仓库”到“数据湖”:历史的演变

事物总是在不断演化的,唯一不变的就是变化,因此为了讨论这些概念,我们首先要了解其历史流变。

“数据仓库”,由比尔·恩门(Bill Inmon)于1990年提出,其被广泛接受的定义是,一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合,用于支持管理决策,通常也被认为是决策支持型应用的必要条件。

此处的定义大多都是针对事务型数据系统而制定的。所谓事务型数据系统,是指记录业务交易的系统,这个名词先是在金融业,特别是银行实施信息化IT系统时使用的。例如银行的交易流水数据库,每分每秒都有大量的交易被数据库所记录并持久化的保存下来,其最小的颗粒度就是一笔“交易”。后来信息化系统在各行各业开花结果,“业务”渐渐演变为现在的“事务”概念,例如员工刷卡进入办公室,后台就会记录员工的这一“事务行为”。

事务性数据系统存在诸多劣势:试想,如果一个银行的分行长想知道今天到目前为止共有多少现钞存款入账,那么系统就需要遍历今天截止到目前的所有交易行为,并筛选其中的存款行为进行汇总。查询交易的行为需要遍历当前系统的所有记录,因此当这一行为频率变高时,会对数据系统造成巨大的读取压力。

其次,当分析业务时需要的信息变多,也就是查询行为的数据对象范围变广时,例如分行长想知道今天一共有多少人民币现汇(包括外币购汇)入账时,系统需要将每笔外汇交易换算成人民币,再进行全部交易的汇总。假设有一百种外币进行了一万次的交易,数据系统内的计算空间会呈“笛卡尔积”般的增长,造成资源上的重大消耗。

“笛卡尔乘积是指在数学中,两个集合X和Y的笛卡尔积(Cartesianproduct),又称直积,表示为X × Y,第一个对象是X的成员而第二个对象是Y的所有可能有序对的其中一个成员。”

除开查询或分析任务对事务型数据系统造成的资源压力外,系统执行任务时,返回的结果只代表着任务开始运行那一刻的数据状态,假设执行查询任务消耗了1分钟,这1分钟内很有可能发生多次的交易撤销、额度修改,增加交易等行为。有些数据系统允许在读取数据的同时写入数据,那么查询任务返回的结果并不能代表最新的状态;有些数据系统则有“读锁”,即在读取数据的时候不允许写入数据,那么这个长达1分钟的查询任务会使得业务交易失败或者暂缓进入数据系统,如果其中发生业务中断,这些交易数据可能面临丢失的风险。

当然,我们可以通过技术手段来避免或缓解事务型数据系统的不足,因此事务型的数据库并不是不能做业务分析,只是当决策者需要进行经营性的分析和决策时,大多数时候它并非最优方案。此时,数据仓库面向主题且便于分析的优势就体现出来了:


1. 面向主题的:

相对于事务型系统将交易类型(存款)、交易币种(人民币或外币)、交易数值(存款额)以一条事务(Transcation)的方式存储,数据仓库通常会将一条事务中的不同信息拆分到不同的主题域中分别存储,例如交易类型表、交易币种表和交易额度表等。


2. 集成的:

不同主题域中的信息之间以统一的ID,如交易流水号为标识进行链接。

这样的好处是当分行长想知道今天到目前为止一共有多少人民币存款入账时,只需要先筛选出交易类型为存款,交易币种为人民币的交易流水号,再基于这些流水号去汇总交易额度,比起原先需要遍历全部交易记录后才能汇总的方式大大节约了系统资源的开销。


3. 相对稳定的:

通常数据仓库和事务型数据系统会被物理隔离在不同的硬件资源上,前者注重数据的查询(读取),后者注重数据的录入(写入),避免了单一数据系统读写冲突的问题。

事务型数据系统由于直接应对业务的多样性,交易的增加、更改和删除非常频繁,这些变化有时候采用对冲的方式做记录,有时候在原有的记录上直接做更改,导致系统处于一直变化的状态;

而数据仓库通常以时间窗口作为数据批量导入的分区,例如每一小时或一天从事务型系统导入一次数据,在下一次数据导入任务开始之前,系统处于一个相对稳定的状态,有利于进行经营性的业务分析。


4. 反映历史变化的:

正是由于通常数据仓库中的数据是基于预先设定好的时间窗口从事务型系统中获取数据,无论是一分钟、一小时还是一天、一周,它都是可以反映数据整体历史变化的,分行长可以清楚地知道今天银行的人民币存款入账环比昨天增长或减少了多少,同比上个月的今天又发生了什么变化。

因此,比起事务型的数据系统,数据仓库能更有效地对业务数据进行统计分析,无论是在提高效率、稳定性还是降低资源成本上都有其优势,所以被广为接受而大行其道。我们可以清楚地看到,数据仓库是数据处理中一种特定的实施方法。

后来,数据仓库领域的大师Ralph Kimball又演化出“维度建模”的概念,认为数据仓库是一系列数据集市的集合。如果说数据仓库中包含着许多不同的主题域,那么数据集市可以理解为主要面向业务应用的单一主题域。比如,分行长可以建设面向存储部门的、专门提供存款数据的“存款数据集市”,面向商业贷款部门的“贷款数据集市”,面向信用卡部门的“信用卡数据集市”等,其数据都源自数据仓库,但数据集市的汇总程度更高、更注重业务表示。例如“环比存款增长率”这个指标在数据仓库中可能表示为“上月存款额”和“本月存款额”两个不同的数值,而在数据集市或者数据仓库的“集市层”中,就表示为计算后的一个数值,可以直接被业务所用而无需再做多余的计算。

图片来源unsplash

而“数据湖”这个概念,由Pentaho公司的CTO詹姆斯·迪克森于2010年提出,这里渐渐开始有了商业的味道。他认为:

“如果你认为一个数据集市可以看作是桶装水店——提供了清洗、包装和组织等服务以方便用户消费,那‘数据湖’就是一个拥有更自然状态的大的水体。来自源头的内容流补充到湖中,各类客户可以来湖中检测、探索以及获取样本。” 

因为当时业界正兴起“XaaS”的风潮,例如软件即服务(SaaS,Software as a Service),平台即服务(PaaS,Platform as a Service),基础设施即服务(Iaas,Infrastructure as a Service),甚至还有解决方案即服务(SolaaS,Solution as a Service)以及数据中心即服务(DCaaS,Data Center as a Service)。在这一背景下,已发展成熟的公有云能力为数据湖体系架构的发展奠定基础,催生“数据湖”的概念。

接着在2011年,福布斯在文章《Big Data Requires a Big, New Architecture》中报道了“data lake”这个词,并给出了数据仓库与数据湖的对比:数据仓库的数据在被集成时就会被预先分类,并以最优的方式进行存储,以支撑特定的分析;但在大数据时代,我们从源系统抽取数据时可能无法明确知道这些数据的价值,因此无法给出一个最优的存储方式。

例如,分行长从交易系统中将所有的数据都抽取过来,但并不知道业务部门想做什么类型反映业务历史的变化。因此建议将这些数据先保存在一个海量的数据库中。由于数据来源的格式五花八门而且会越存越多,因此这个数据库需要具备容易访问且存储成本低(允许硬件资源扩容的成本而尽可能降低其他成本,例如软件使用费用、人工维护费用等)的特性,需要进行分析时,再来组织和筛选所需数据,这个数据库就是数据湖(Data Lake)

彼时的数据湖概念更多地是关于当企业在处理海量异构的数据时,如何在数据产生实际的应用价值之前,为海量数据构建一个易访问且成本低的存储方式,和数据资产化、资产服务化等当下热点名词并没有太大关系。但事物都是在不断演化的,2014年福布斯杂志上刊登了一篇名为《The Data Lake Dream》的文章,文章作者EddDumbill描述了数据湖的愿景:

  • 融合所有数据,解决系统间数据孤岛、各类应用统一访问问题;

  • 数据可获取性提高,应用部署时间缩短;

  • 具有弹性的分布数据处理的平台,能同时支撑批量和实时数据操作处理和分析;

  • 数据湖增加安全和管控层面的功能;

  • 重视集中、自动的元数据管理和入湖标准,避免成为没有价值的数据。

从这个时候开始,单纯的数据湖就朝向一个“平台级的方案”而演进。为什么说是方案呢,因为时至今日,数据湖仍是个架构概念,是一种架构设计的理念,而不是一种特定的实施方法,更不是一款特定的产品。其所要达成的目标囊括了不止一种数据技术,已经从当初的一种“大数据存算方案”进阶到了“大数据存算+处理分析+资产治理+安全隐私+数据变现”的一揽子方案。

10年前,迪克森曾认为“数据湖”是面向企业的最佳大数据解决方案。从技术上来看,其论点是有根据的,但是从商业价值上来看,这个愿景似乎并没有被实现。实际情况是过去数据仓库的落地实践要远比数据湖来的多和广。而就在现今所有人都在强调数据资产化、资产业务化,强调数据变现和数据商业价值的年代,数据中台的概念似乎又代替了数据湖的概念。

数据中台,由于受到从业者的追捧并在这两年疯狂流行,隔着屏幕应该都可以嗅到浓重的商业气息,但目前对其仍然没有清晰明朗的定义。当大多数人努力想要为数据中台做名词解释时,我倒认为这个局面十分恰当且正常。首先,数据中台的概念如同数据湖一样,是一种架构概念;其次,它不仅是工程设计上的技术架构,还包括了组织架构的变革,因为中台通常会强调其作为一个企业组织运作的“独立性”、“中央性”和“统一性”。

中台作为抽离原来各个数据部门共性业务、由技术和人员并提供统一数据、产品及服务的“共享业务事业部”,无论在业务功能上还是工程技术上都会有其独立运作,数据权威和统一分发的诉求,因此其组织承载的考核目标及衡量标准较原先的数据仓库、数据湖等技术概念而有所不同,特别是在“数据驱动业务”、“数字化转型”的时代大背景下,它们是和企业的总体业务目标紧密相关的,不再只是一个“旁路IT系统”,不再只是一个业务信息化的支撑系统,而是产生并驱动业务的关键环节。数据中台应当是企业组织和技术架构的有机结合体。

技术商业化应用之动力:业务的诉求

科学技术的发展有其自有的原发性,而商业世界里对一项技术的认可并将其广泛商业化应用的动力,仍来自于商业目的的要求。数据技术也是如此,业务诉求的发展推进了技术的革新。

大数据平台,数据湖,数据仓库和数据中台这些概念有什么不同,到底是谁代替了谁?我相信非专业领域的从业人员每当看到这些词汇的时候或多或少有这样的困惑。我认为,这里并没有谁代替了谁,所谓孰优孰劣只是从不同的业务需求出发得出的不同结论而已。

当企业的信息化发展到一定程度,企业流程得以用数据的形式持久化的留存下来,决策者们的判断依据慢慢从经验主义过渡到数据主义,因此90年代初为了更好的支持经营的决策分析,数据仓库的技术就油然而生并被广泛应用。

当企业开始迈向全面数字化的阶段,需要处理的数据越来越多、形式越来越杂,原先使用的数据存算方式其成本越来越高,业务对数据处理的效率要求也越来越快。在这种背景下,企业亟需一种成本更低且效率较高的方式来存算数据、访问数据,因此大数据技术孕育而生。我们通常说的大数据平台就是利用大数据技术而搭建的平台型能力,为企业提供大数据技术服务。

而当企业迈入大数据时代后,纷纷利用大数据技术搭建各自的大数据平台。为了进一步降低数据存储和处理的成本,提升大数据平台的可用性、可靠性和可运营性,解决大数据时代数据分析链路越来越长、数据探索复杂度越来越高、数据资产管理越来越难以及数据变现的路径尚不清晰等问题,基于数据湖的架构概念,我们又开始在大数据平台上尝试搭建各自的数据湖架构。由此可见,数据湖也是由业务诉求催生出的平台架构概念和能力。

图片来源unsplash

所谓分久必合,当企业的数字化、数据化成为一种常态时,有些企业发现内部存在纷繁复杂的数据源,存在多个所谓大数据平台甚至是数据湖,导致了很多不必要的重复性建设,包括服务、软件和硬件层面的冗余,或是由于部门壁垒而导致数据无法有效统一来支持前端业务,不统一的数据出处又带来数据不一致的问题,亦或是不同部门各起炉灶导致数据技术人员各自分散的问题。在这种背景下,由高层拍板构建企业级的数据中台,把原有资源剥离和再分配,将共性抽象集成并形成资产,统一面向全组织提供服务。这里的服务包括了数据资产、产品软件、算法算力甚至是技术人力。

因此,我认为这三者没有谁对谁错或是谁替代了谁,只是企业不同的发展背景形成了不同的建设目标,各自有不一样的业务诉求罢了。

技术的革新

业务诉求会推动技术的发展,有时技术本身的革新也会带给业务发展更多的想象空间。

如同前文所述,随着时代的发展,技术也在不断演化,但其演化历程通常是具有连续性而非跳跃性的。当然,跳跃性的原始创新会被历史所铭记并开创一个新的时代,成为时代的主角,例如蒸汽机,发电机,计算机和互联网。但循序渐进的集成创新才是平凡日子里的重要配角,小步蓄力以期待下一次的飞跃。因此大多数时候新概念的产生通常会带有前任的影子而导致傻傻分不清楚,或被误认为是“老瓶装新酒”的现象。

在当下时代对“企业是否一定要建设中台”的争论仍在持续着,我认为里面除技术之外,更多地牵涉到企业本身的发展阶段、组织架构和企业文化等问题。有些管理者能很好的从自身业务和技术角度去辨别组织真正需要的是什么,因此我们回头看数据湖的建设,这个议题仍是舞台上活跃的一份子。而技术的革新,已经使得数据湖的建设目标不止于10年前刚提出时的愿景。

目前在建设数据湖的时候,企业通常会展望以下几个技术目标:

1. 提供高可靠性、高性能、可伸缩的分布式存储系统,在一定程度上降低单位存算成本的同时统一承载海量结构化、半结构化以及非结构化数据。


2. 提供丰富的数据计算分析引擎,具备对结构化、半结构化和非结构化数据进行多层次融合分析的能力。

3. 关键能力包括:

混合处理:支持所有类型数据入湖无需预先设计模型,同时支持事务型和分析型的数据处理,数据入湖就能即席分析、持续迭代。

联邦分析:支持多类型数据格式融合分析,无需额外数据搬迁,可通过标准查询语句实现跨源数据探索计算分析。

弹性伸缩:计算层和存储层可独立弹性扩展,具备大容量存储池和“理论上”无限弹性计算资源能力,快速应对数据和业务变化。

分级存储:支持冷热数据分级存储,数据自动管理,合理利用存储,降低成本。

数据探索:具备集成的算法开发能力,能快速地构建算法模型及数据探索任务,甚至与标准数据库查询语句融合,支持采用标准接口完成算法及AI业务的开发。

展望:更大想象力空间

在万物互联的时代构想数据湖的未来,不乏有许多引人想象的可发展空间,举例来说:


1.  更智能的数据接入:

物联网时代信息进一步爆炸,无论是数据量还是数据种类和复杂度都呈指数级发展,数据湖可以成为整个物联网基建的融合汇聚中心,通过数据感知技术,根据接入的数据类型、更新频率、数据量大小以及预设好的使用场景等信息,智能判别数据接入方式、自动化地进行底层协议及技术的匹配,降低接入数据湖的门槛和整体运维的成本。


2.  更精细的资产管理:

可以从冷热数据(被使用频率低和高的数据)、业务标签等不同角度对数据进行分级分层存储,在预先定义好的数据治理规则和基于日志的机器学习运维任务下,做到半自动甚至全自动的数据管理,合理利用系统资源,实现“数据自治”。

3. 更灵活的数据分析:

纳入“数据不动计算动”的联邦学习能力,解决数据迁移、数据安全和数据权责的问题;

纳入“既能保证数据事务性又能保证数据分析性”的混合事物/分析处理架构(Hybrid Transaction and Analytical Process),解决从事务性数据库导入到数据仓库产生的时效性和一致性问题;

纳入针对“大宽表”的即席多维度分析能力,解决传统上做多维度分析时需要将数据预先按主题拆分和转换处理过程而导致的分析长链路以及低时效问题等。


4. 更直观的数据价值:

在数据应用实现商业变现之前,就数据本身而言,纳入灵活但可控的数据共享工具及平台,加速湖内和湖外、组织内和组织外数据的碰撞,共融互通而形成更完整的数据全景从而为业务服务;

纳入数据商业化/社会化运营工具,例如数据沙箱、智能脱敏、自主订阅、用量统计等,撬动数据资产本身的价值。

虽然无论在功能目标还是项目建设方面,数据湖总体仍处于不断发展的阶段。

我们不知道数据湖的概念还能在商业科技的世界里存在多久,亦不知道若干年后我们回头看待它时,能否将之称为“经典”。但这并不妨碍在当下企业参照数据湖的架构概念和功能目标,去搭建大数据处理平台所带来的积极效果,即使在所谓的“数据中台时代”来反观数据湖的概念,每一个从业者仍有必要保持不断学习的谦逊态度,每一个参与方仍要以包容和发展的目光来审视过去、展望未来。

本文来自微信公众号:腾讯研究院(ID:cyberlawrc),作者:火雪挺(腾研识者、腾讯CSIG资深架构师)