喜马拉雅 PC端文章详情页顶部23-26

Databricks中国启示录:一场蓄谋已久的技术与商业战 | 企服国际观察

深度
伴随逐渐增长起来的用户市场,Databricks为国内外湖仓架构及产品解决方案的创新派们带来了一定的示范性作用。

6月底,刚刚结束的Data+AI Summit上,Databricks宣布将数据湖表格式Delta Lake的API完全开源。

进入2022年以来,无论是Snowflake发布UniStore,还是Databricks巩固Delta开源计划,都是在面对极大的市场空间前景下做出的积极决策。

相比于第一代表格式Hive,Databricks的Delta Lake和Apache Iceberg、Apache Hudi被认为新一代数据湖在开源表格式应用上的“三剑客”。对于其他企业而言,基于成熟的开源架构进行改造,使用社区发布的最佳工具,能够最大限度降低企业构建数据湖的成本,避免重复造轮子。

钛媒体App获悉,从截至2022年3月份的一份有关GitHub存储库的贡献数据来看,目前Netflix、Apple、AWS等主要基于Apache Iceberg,国内如阿里巴巴、字节跳动、蚂蚁、中移苏研、华为、腾讯等企业则主要热衷于Hudi,而对Delta Lake的贡献维护,81.3%都来自于Databricks。

事实上,三大开源项目各自有其发展的历史背景及优势特征,但相比于早在2016、2017年就已经开源的Apache项目,Delta Lake因其商业化公司Databricks的强势发力,在近些年显得格外耀眼,并且越来越引起其主要竞争对手的眼热。Cloudera、Snowflake就曾表示,Delta Lake自2019年开源(虽然是部分开源)以来,就已经吸引了一批潜在客户。此外,Iceberg和Hudi的主要创始人也于最近一年相继创立了其商业化公司,即Tabular和Onehouse。

Delta Lake的出现是本身基于湖仓架构演进而来:从最早的传统数仓(EDW),到为满足低成本存储的数据湖(Data Lake),再到如今的云原生湖仓、湖仓一体(Lakehouse),可以看到过去40年里大数据架构仍在不断演进。

那么谁能够成为当下Lakehouse架构的最早受益者?从用户侧的反馈,湖仓架构的最大短板其实不完全在于技术,如果企业对数据处理要求不高,传统的数仓就能够满足,对升级到湖仓并非迫切性需求。

但Databricks作为开源+云原生数据存储时代重要的创业代表,伴随逐渐增长起来的用户市场,仍为国内外湖仓架构及产品解决方案的创新派们带来了一定的示范性作用。

在中国市场,尽管企业对云上调用产品、管理研发资源、运维调度等需求明显,但从资金投入、人才积累以及实际应用案例的深度来看,多年以来,中国企业大数据产业基础领域的发展,始终面临着的是一个全方位激烈竞争的市场局面。

Delta Lake应运而生

Databricks成立于2013年的美国旧金山,由加州大学的几位教授和五位伯克利大学的博士生共同创立。其联合创始人兼首席执行官Ali Ghodsi,也是开源平台Apache Spark的创建者之一。

据了解,Ali Ghodsi从8岁起就热衷于编程,长大后攻读计算机工程专业,并获得了分布式计算领域的博士学位。2009年,他与Ion Stoica合作共同成立了Spark。后来他们又与另一支机器学习团队合作,共同推出了基于Apache Spark开源版本的商业化服务。起初,这并没有激起丝毫水花,市场几乎少有人知晓。2013年,A16z联合创始人Ben Horowitz一笔1400万美元的投资给带来了希望,Ben Horowitz鼓励他们创立一家公司,基于Apache Spark平台进行商业化产品运营。也就是在这一年,Databricks成立了。

创立之初,Databricks面临的最大一个挑战是,如何得到商业世界对Spark的关注。当时外界认为Spark只能用于内存计算的数据集,这种认知实际上打击了企业使用Spark的积极性。为了粉碎这种偏见,2015年团队通过一项竞赛,以最短时间内处理1PB+数据规模的破记录,一炮而红。

2017年,Databricks的估值已达5亿美元,但年收入却低得多,只有100万美元,这让他们开始关注服务大型企业客户,以及在产品和销售策略上的调整。2018年,Databricks的年收入就有了非常漂亮的翻盘,首次达到1亿美元。而后在湖仓功能Lakehouse上线后,Databricks在2019年的年收入达到2亿美元。到2021年,其年经常性收入为8亿美元,投资者认为到2022年年底,Databricks的收入可能达到10亿美元。在全球Databricks已拥有约6000家客户,包括壳牌、CVS健康、再生元、T-Mobile、汇丰银行、康卡斯特等。

同样,Databricks的融资脚步也非常之快,截至最近一轮的公开融资,是于2021年8月完成的16亿美金的H轮融资,融资总额超过36亿美元。这个惊人的融资速度和额度背后,还有非常良好的资本背书,除了A16z和老虎资本,还有非传统风投如Fidelity、T.Rowe Price、Baillie Gifford和Franklin Templeton,以及微软、谷歌、亚马逊等科技公司。这一年,Databrick的估值已经达到380亿美元。

外界推测Databricks可能会在2022年晚些时候启动上市,并且有望超过软件公司有史以来最大的IPO项目——由Snowflake保持的记录——当时,Snowflake上市首日收盘飙升超过100%,市值超700亿美元。

总结起来,Databricks的成功离不开三点优势:一是产品理念上始终坚持的统一架构模式,面向数据科学、人工智能领域的不断探索;二是在开源(COSS)运营手段上的推动和北美环境的独特优势,有庞大且忠诚的开发者社区;三是基于按订阅制付费的SaaS模式,且面向多云环境提供服务。

目前Databricks最为核心的产品就是基于Apache Spark、Delta Lake、MLflow等开源组件构建出的Lakehouse功能。其中,数据湖表格式Delta Lake,侧重于为Apache Spark和其他大数据引擎提供可伸缩的ACID事务,让用户可以基于HDFS和云存储构建数据湖;开发和维护AI生命周期管理开源平台MLflow,用于进行机器学习模型的部署和训练;数据分析工具Koalas,可让使用Pandas进行编程的数据科学家直接切换到Spark上,用于大型分布式集群应用。值得一提的是,Databricks去年还还收购了一家低代码工具平台8080 Labs,以增强在Lakehouse功能上的能力。

这种在湖仓能力上的持续进化,也让Databricks在2021年Gartner魔力象限图有两个关键变化:一个是在DBMS(云数据库管理系统,Cloud Database Management Systems),另一个则在DSML(数据科学和机器学习平台,Data Science and Machine Learning),Databricks均处于领导者象限。

Ali Ghodsi指出,“开放的数据湖仓正迅速成为企业处理数据的标准。Delta Lake、MLflow和Spark都是这一数据架构的核心。”可以预见,Delta Lake正成为Spark之后下一个火热的大数据项目。

实际上,新的数据存储、处理和分析技术的到来,也不断催生出以数据库、数仓为代表的大数据基础层面的商业创新。

当湖仓的创业热被点燃

根据Fortune Business Insights近期公布的《大数据分析市场报告,2021-2028年》,目前大量初创公司正在争夺全球大数据分析市场的份额,预计2028年将达到5497.3亿美元。根据资本流动趋势和观察到的客户需求,大数据分析市场中最热门的领域无疑是数据仓库、数据湖、数据湖仓、数据网格、DataOps和超快速大数据查询引擎。

据艾瑞数据统计,2020年云原生数据湖市场规模(含生态)达124亿,预计未来三年将以39.7%的复合增长率快速扩张。现阶段,云原生数据湖主要应用于泛互联网行业(40.7%)及传统行业的互联网场景,包括泛政务、金融、工业、医疗、汽车等。

据钛媒体App观察,尽管市场对新一代大数据架构的关注,可能是这一两年才火热起来,但有关大数据架构平台的技术和开源实践其实更早。

这个新架构也就是我们所讲的新范式“数据湖仓”(Data Lakehouses)——数据湖(Data Lake)+数据仓库(Data Warehouse)架构的统一。数据湖是一种单一的数据存储库,目的是为了数据的保存和分析,数仓则是一种分析型数据库,通常是关系型数据库,由两个或多个数据源构建。在过去,原本数据湖和数仓是完全不同的两个技术概念,但现在,这个两个技术方案开始有融合趋势。

“湖仓是数据+AI时代一个特别好的解决方案,但湖仓也不是一个新鲜事物。从大数据平台架构的演进史来看,尤其是从2003年Google‘三驾马车’发布以来,这个赛道还是有点内卷的。”滴普科技FastData产品线总裁杨磊指出。“数据湖理论早就于2010年提出,并且在2015年得到比较大的发展,但一直处于不温不火的状态。当时的数据湖只解决了存储的问题,没有解决计算的问题,实际上放到如今计算、存储是需要同时解决的。”

例如,Databricks于2019年提出的Delta Lake引擎,基于Apache Spark构建,集成了数据湖(低成本和灵活性)和数据仓库(性能效率)的最佳实践,可用于存储海量结构化和非结构化数据,同时具备数据分析和AI的能力。

火山引擎湖仓一体分析服务LAS团队负责人则告诉钛媒体App,“以Oracle为代表的传统数仓,依赖硬件配置、成本高,且存在物理上线难以拓展的瓶颈。互联网发展推动下,数据类型异构化,企业数据量呈现井喷趋势,传统数仓架构越来越难以满足需求。也由此出现了如Hadoop等大数据存储、处理和分析框架,可以存储任何形式、格式的原始数据,一定程度上解决了数据存储的成本问题。”

“湖仓一体架构结合了数据湖和数据库两者优势,以标准服务简化数据集成与开发,提供对数据的自由访问,能够以低成本支持高性能的数据服务。”该负责人称。

可以见得,湖仓理论的提出,其实就是要解决传统数据存储,以及针对各类数据提供分析场景,以一种统一的手段进行处理。基于这样一个背景,也让大数据平台架构发展推向了新的历史高潮。

目前,湖仓赛道被越来越多提供大数据相关服务的企业看上,纷纷开始下探筹备研发,或直接基于自身云平台,将湖仓产品集成进行售卖,或基于开源组件进行能力拓展和部分自研。如Databricks最早基于Azure云托管合作构建出了Azure Databricks,同时也与AWS的Redshift Spectrum、微软的Azure Synapse Analytics进行集成。发展到如今,包括国内很多企业在内,阿里云的EMR+DataWorks+DLF解决方案、字节火山引擎的Lakehouse Analysis Services,都基本在选择一些Spark、Flink、Hudi等大数据平台领域的开源组件进行能力封装。不久前中国信息通信研究院公布的首批云原生数据湖能力评测结果中,国内多家企业也通过评测认证。

在亚马逊云科技给钛媒体App的一份资料中,智能湖仓架构以Amazon Simple Storage Service(Amazon S3)构建数据湖作为中央存储库,围绕数据湖集成专门的“数据服务环”,包括数据仓库、机器学习、大数据处理、日志分析等数据服务,然后再利用Amazon Lake Formation、Amazon Glue、Amazon Athena、Amazon Redshift Spectrum等工具,实现数据湖的构建、数据的移动和管理等。

而火山引擎的湖仓一体分析服务LAS在离线分析、实时分析、数据湖表分析等领域都用到了开源项目。例如,火山引擎基于流式数据湖平台Apache Hudi打造了一个秒级数据可见支持的实时数仓。但除了提供Hudi社区的所有功能外,LAS还支持基于数据湖的元数据管理系统、行列级别的并发更新、Bucket Index和Append模式等特性。

作为一家创业厂商,滴普科技最早基于提供数据中台进行产品打磨,后来伴随企业不断成长开始逐步涉足整个湖仓技术体系的搭建,从存算引擎到数据开发、治理以及分析应用等场景。

总结来看,这种趋势大约在2020年开始被点燃,在国内直到过去两年才开始有一定程度上的落地。

不重复造轮子,但难度还不少

那么,湖仓这件事情,本身的一个难点会是什么?

首先,厂商和企业目前在开发湖仓架构时,会普遍基于一些开源技术技术栈进行开发,但选择不同的技术方案都有其优劣性,从企业目前构建的情况来看,正处于湖仓架构改造和优化的关键期。

一是生态问题,这件事情重要性其实远远大于商业应用本身,回顾过去就不难发现,很多开源工具本身是靠着生态才带动起来的。而湖仓技术当前仍处于一个比较早期的发展阶段,要形成一个新的标准,生态要足够繁荣。

“湖仓本身在整个数据场景里属于偏小众的,虽然很多人在关注,但从客户角度来看,他们当前的系统基于Hadoop 或分析型数据库构建的数仓,其实已经很完备了。如果让他们升级到湖仓,正如前面提到的,一定要有很强的业务需求拉动,而不是单纯的技术补强。”杨磊指出。

二是在解决湖仓问题时,能不能以比较简单的方式,大幅度降低整个应用组件的复杂度。

“湖仓涉及的技术难点还是比较深入的,Delta Lake/Iceberg/Hudi只是表引擎,湖仓要真正形成战斗力,还有如分析引擎、实时计算引擎、数据入湖工具、数据开发DataOps工具链、统一元数据管理等相关的引擎或组件需要优雅的放在一块使用。”杨磊指出。

“虽然现在有很多开源版本可以投入,但如果任凭混搭,那就跟早期Cloudera Hadoop一样,大量复杂的技术组件,导致整个客户的商业运行成本是非常高的,同时还需要有一定的运维人员进行维护。对于传统行业或非科技领域企业,如果不具备专业的人才团队,根本解决不了这样的问题。”

其次则是数据湖与数仓的功能兼容性问题。

自此之前,企业通常将日常运营过程中留存的各种数据,存储在原始数据湖中,经过一番提取、处理之后,将这些数据的关键部分转换成为可以存储在数仓中的格式。在这个过程中,业务和用户都可以从数据中获得相应的业务洞察力,但保持数据湖和数仓之间的一致性即困难且昂贵,同时还可能会影响数据的整体质量。大量数据的“堆叠”和变化,也使得存储在数仓中的信息无法保持与数据湖的同步。

正因为如此,Snowflake、Google BigQuery和Amazon Redshift等数仓专家,也在不断调整其数仓以兼容更多数据湖功能的反向思路。

为用户降低数据融合与数据共享时统一的安全管控和数据治理的难度,亚马逊云科技“智能湖仓”架构不止打通了数据湖、数据仓库,还进一步将数据湖、数据仓库以及所有其他数据处理服务组成统一且连续的整体。数据可以在数据服务与数据存储之间、数据服务与数据服务之间移动或访问。Amazon Glue提供数据无缝流动能力,Amazon Lake Formation提供了快速构建湖仓、简化安全和管控的全面数据管理能力。

在杨磊看来,“湖仓一体首先要解决的是数据湖的问题。把‘湖仓一体’理解成湖内建仓,这是不正确的,湖仓本身就是一体的。传统的数据湖只解决了存储的问题,分析计算的问题还得靠数仓。这就会造成两大浪费:一是资源,如何在成本增加不多的情况下,同时兼备数据湖和数仓的能力;二是时间成本,如何提供数据+AI的统一能力平台。”

此外,伴随近年来大数据平台与容器、Serverless等云原生技术的深度融合,也在引导湖仓都走向云原生,实现异构数据灵活存储、计算资源弹性伸缩。

某大数据平台创业厂商曾告诉过钛媒体App,大数据的产品一定要用云原生架构,这样整体的ROI会最高、落地速度也会最快,数据的价值也有意义。如果没有云原生化,整个大数据平台中组件管理起来都特别复杂。倒推下来,第一步就需要将大数据平台的各种组件实现容器化。

在中国,撬开客户市场的未完竞演

目前湖仓一体分析服务LAS已经在字节跳动内部大规模应用。当业务中需要构建复杂数据流、数据分析成本高、运维门槛高、各数据孤岛的ETL过程不一致等场景,均可以通过LAS解决。

以推荐场景为例,在该场景下,需要将表格存储数据导入数据湖,进行数据挖掘分析,同时面向业务提供高效OLAP访问。其难点在于面临百GB/s的高吞吐近实时写入且要对大量复杂类型数据进行低成本更新。基于LAS平台,火山引擎通过数据湖构建表格存储CDC实时接入,使得具备提供数十TB表级列拼接的能力,下游分析时效大幅提升。

德比软件则采用Amazon S3作为可扩展的数据湖,存储订单、日志、点击流数据,用Amazon Kinesis实现数据的流式接入后再S3上持久化,用Amazon EMR实现各种S3上数据的ETL,OLTP和OLAP数据分别放入Amazon Aurora和Amazon Redshift存储,需要检索的日志放Amazon ElasticSearch Service,Amazon SageMaker从S3读取数据,预处理后放回S3作为训练数据,推理之后的结果会存入Amazon Aurora,给其他应用消费。

德比软件在“智能湖仓”架构下,更加方便汇集和保存海量业务数据,相对灵活地统筹和调用数据,用于BI、可视化分析、搜索、建模、特征提取、流处理等等,推出了对酒店客户的BI新服务以及异常检测服务,也在利用这个服务快速探索新的业务。

百丽集团遇到的挑战则是,如何在手机终端上构建一个“销售助手”,能够以动态形式为旗下各个门店提供数据分析决策,从而替代掉原来人工数据分析带来的各种不便。基于FastData架构,企业对超过三个PB级的各类数据进行了有效存储,并且形成相应的数据维度,然后再基于Pytorch计算框架中进行模型的训练,最终形成一套数据应用的产品。

伴随企业对云技术需求的日益增长,湖仓正为科技企业构建自身云原生应用平台带来数字化先机,也影响了企业用户进一步加快上云用数的便捷性。之所以传统数仓、数据湖能够向湖仓一体架构持续演进,其实首要原因还是来自实际应用场景中,业务驱动的结果。

杨磊还看到,“当下很多企业客户都是基于业务考虑,在这个过程中,如何打通数据链路,持续优化企业内部的运营效率,是核心关注点。”

在滴普科技的服务案例中,双方第一阶段更多遇到的是数据治理的场景,梳理数据与其业务之间的关系,而非数据应用以及价值发挥的显性阶段,“但很多值得打磨的点,其实是在数据治理过程中就已经碰撞出来了。”

当然,还有更多的客户此前有过类似的技术实践,或因实践的技术路径比较难,也或者方案很难完全解决掉所有的问题,则会希望第三方服务商能够提供统一方案,并且尽量降低运维的难度。

这种转变,实际上也给当下国内的第三方湖仓解决方案提供商带来了市场契机。

(本文首发钛媒体APP 作者 | 杨丽,编辑 | 盖虹达)

转载请注明出处、作者和本文链接
声明:文章内容仅供参考、交流、学习、不构成投资建议。
想和千万钛媒体用户分享你的新奇观点和发现,点击这里投稿 。创业或融资寻求报道,点击这里

敬原创,有钛度,得赞赏

赞赏支持
发表评论
0 / 300

根据《网络安全法》实名制要求,请绑定手机号后发表评论

登录后输入评论内容

扫描下载App