实时分析、融合统一及云原生,现代化数据仓库未来发展必经之路|专访飞轮科技 CEO 马如悦

2023年 9月 12日 41.4k 0

在国内拥有 2500+ 中大型企业用户,用户社群聚集开发者超 3 万人,活跃贡献者数连续数月稳居全球大数据开源项目排行榜第一。毋庸置疑,Apache Doris 已成为全国数据库和大数据领域最为活跃的开源项目之一。Apache Doris 历经近十年的发展,为何还能持续保持竞争力和活力?其背后的核心推动力又是什么?

在 QCon 全球软件开发大会·北京站的现场,基于 Apache Doris 的商业化公司飞轮科技的 CEO、Apache Doris 项目创始人 & PMC 马如悦接受了采访。马如悦曾在百度担任过分布式计算团队、大数据工程团队和 AI 产品工程团队的技术负责人,还主导设计和开发了实时数仓 Apache Doris。他对于 Apache Doris 的技术发展路线以及实时数仓的未来发展有着更加深刻的认知。

Q1:作为一名深耕数据库领域多年的从业者,您观察到企业对于数据仓库的需求点主要集中在哪方面?

马如悦:纵观数据仓库的发展历程,数据仓库的演进经历了三个阶段,第一阶段,即在 2010 年之前,传统数据仓库解决方案包括 Teradata、Greenplum、IBM Netezza 来处理大数据问题。第二阶段,约在 2010 年左右,随着谷歌三驾马车的问世,人们逐步开始使用 Hadoop 大数据平台进行数据分析。如今已经进入了第三阶段,现代化的数据仓库产品开始涌现,这些产品结合了传统数据仓库的可靠性和性能优势,同时具备了对大数据的高效处理和实时分析能力。

作为一个完整经历了第二代大数据平台历史的从业者,在百度早期我主要负责 Hadoop 和 Spark 相关的工作,后来主导设计了 Doris 并将 Doris 贡献至 Apache 基金会。我们认为第三代数据平台的主要特点是实时化、架构的融合统一化以及云原生化。

随着业务需求的不断增长,企业对数据的实时性要求也越来越高,现代化数据仓库需要具备高速的数据处理和分析能力,能够实时响应和处理大规模数据流。同时,企业越来越倾向于将数据存储和分析工作迁移到公有云 / 私有云 /K8s 上,因此现代化数据仓库需要支持云原生架构,具备弹性伸缩、自动化管理和云端部署的能力,以适应云计算环境的需求。除此之外,我认为融合统一是也是现代化数据仓库核心的特征。在大数据领域,存在众多的系统和组件,它们往往在架构中扮演着不同的角色。而随着时代的进步,架构“减负”已成为企业发展的重要目标,因此像融合数据库、超融合数据库、湖仓一体、流批一体等具有“融合统一”特征的数据库开始涌现。结合实际发展来看,过去几年,事务数据库已呈现明显的融合趋势,像 OceanBase、TiDB 以及 PolarDB 等新一代 NewSQL 事务数据库已经出现。同样地,数据仓库走到今天,融合统一也是必经之路。

这些特点其实也就是企业对于实时数据仓库的真实需求,也是 Apache Doris 在过去几年来广受认可的重要原因。

Q2:近期,我们关注到飞轮科技宣布将企业产品 SelectDB Cloud 云原生存算分离架构贡献到 Apache Doris 社区。在云原生存算分离架构的研发过程中,团队遇到过最大的技术难题是什么?又是通过什么方式解决的?

马如悦:有很多人之前就问到 Apache Doris 为什么没有实现存算分离,是因为技术太难了吗?实际不然,存算分离相比于存算一体来说更容易实现,存算分离依赖 HDFS、云上对象存储这样的共享存储系统,在设计实现时无需在存储层有太多投入,只需专注于计算层的实现即可。

那么回到问题本身,我们在云原生存算分离架构的研发过程中遇到了哪些问题:

一是如何实现存储和计算的状态剥离。在存算分离架构下,计算节点不再存储主数据,而是将共享存储层作为统一的数据主存储空间,这样计算节点可以做到无状态,可以实现完全关机,同时可实现更便捷的数据共享,不同的集群之间以及不同的仓库可以便捷地进行数据共享。

二是如何解决读取效率下降问题。存算分离依赖从网络上读取存储系统的数据来进行计算,在一定程度上会造成计算性能的下降,为了解决这一问题,我们利用 SSD 提供高速缓存来应对底层对象存储系统性能不佳和网络传输带来的性能下降。其次我们在存算分离模式下,提供了同一个仓库多个物理计算集群的隔离方式。计算集群可以独立扩缩容,其计算节点的本地高速缓存都是隔离的,这样尽可能保证了比较好的隔离性,从而避免集群间的影响,保证整体计算性能不下降。

三是解决对象存储读取带宽限制的问题。当用户购买公有云之后,云厂商会为每个企业账号分配资源配额,并提供对象存储访问平台供用户访问。然而我们作为一家软件服务商,我们希望产品能够被上万家甚至更多的企业使用,这就需要更多的带宽资源。过去,大部分云厂商都是直接服务终端用户,很少针对我们这类型的软件服务商做设计。而通过我们与各大云厂商的积极沟通,已经争取到了更大的带宽资源配合,足以满足当前各企业的需求。

此外,安全问题也是企业非常关心的问题。对于数据安全和合规性有着更高要求的企业,希望在享受自动化管理特性的同时,能够将数据存放在自己的账号下进行管控。因此,SelectDB 预计在 9 月底推出云上的一种新的产品形态,这款新的产品形态将实现数据面在客户账户,而管控面仍然在我们账户运行,这可以很好满足相关行业对数据安全管理的要求。

Q3:选择将存算分离架构贡献回开源社区,这一决策的出发点是什么?

马如悦:在回答这个问题之前,我想先分享一些我的所见所知。做开源的公司一般都会遇到这个经典的提问:云厂商会不会免费用你的代码来进行托管赚钱?

过去几年,我们观察到 MongoDB、Redis、ElasticSearch 等项目在不断变更许可证,但我认为这些调整无法解决根本问题,云厂商并不会因为许可证的改变而选择必须与这些项目合作,反而可能会推动他们自己开发与之兼容的产品。例如亚马逊云科技就推出了 DocumentDB、OpenSearch,这反而加剧了竞争局面。

我们的路线与之完全不同,我们致力于构建更加开放的生态系统。相比于和云厂商进行存量竞争,我们更愿意与云厂商携手合作,共同扩展市场。我们的目标是将蛋糕做得更大,让整个市场蓬勃发展。我们希望将 Apache Doris 打造成 AP 领域事实上的“MySQL”,只要 Apache Doris 成功了、做大了,全面拥抱 Doris 的所有商业厂商都能获益。我们只要努力保证我们的商业产品有足够的竞争力,能在市场上占领足够大的份额,我们的收益也是最大的。所以,我们选择了一个更开放的道路,与各家云厂商敞开怀抱合作,有竞争有合作。这种合作共赢的态度将促进整个生态系统的健康发展。

那么话说回来,如何才算更加开放?举一个简单的例子,当我们打通上下游生态时,我们是应该打通 Apache Doris 还是 SelectDB?许多人可能会认为,作为一家商业公司,我们应该打通 SelectDB,而我认为这种思路是不正确的。实际上我们花费了很多精力来帮助所有的上下游打通 Doris,这样当用户无论使用哪一家基于 Doris 开发的商业分发版的厂商都能顺利使用。这样一来,上下游厂商也更有动力去打通 Apache Doris,云厂商也愿意持续拥抱 Apache Doris 社区,广大的用户也能不被任何一个商业公司锁定,因为大家都遵守了 Apache Doris 的开源标准,也就不需要去学习每家商业厂商的不同。所以一旦秉着开放的心态做事,不是两方、三方共赢,而是所有方共赢。

回到最初的提问,飞轮科技选择将存算分离架构贡献给 Apache Doris 社区,其本质目的也是为了进一步让更多用户收益,如果大家都需要,我们就希望在内核层面提供支持,而不是希望各家分发商提供自己的实现,然后造成未来这块各方产品的不一致。而在这样的背景下,用户也可以获得兼容性更好、性价比更高的产品使用体验。

Q4:对于 Apache Doris 社区用户而言,新的存算分离架构在使用上有什么差异?如果用户想从存算一体的架构切到存算分离的架构,迁移方式与迁移成本是怎样的?

马如悦:Apache Doris 在国内有大约 2500 家企业使用,任何一个功能不兼容的问题都会对广泛的用户产生重大影响。因此,我们必须认真考虑企业升级的问题。因此,当 Apache Doris 推出存算分离架构时,我们非常谨慎地进行规划。目前,我们采取逐步迭代的方式,以确保最大程度地保护已有大量用户的利益。

在 Apache Doris 2.0 中,我们开始引入部分存算分离的能力,来解决大多数用户所面临存储成本高昂和计算弹性不足的问题。通过冷热数据分层(Tiered Storage),可以把将冷数据下沉到存储成本更加低廉的对象存储中。其次还引入了无状态的计算节点 Compute Node,Compute Node 不保存任何本次持久数据,在集群扩缩容时无需进行数据分片的负载均衡,因此在数据湖分析这种具有明显高峰的场景中可以灵活扩容、快速加入集群分摊计算压力。虽然这个版本并不没有实现纯粹的存算分离,但已经能解决用户许多问题。

在即将发布的社区 2.1 版本中,会发布更加彻底的存算分离架构。该版本将采用两种模式之一运行:存算一体的部署模式和存算分离的部署模式。在两种模式下运行的 Apache Doris 将以不同的方式来存储主数据。从用户使用体验上而言,绝大部分功能都是一致的,但是也会因为实现架构和部署模式的不同,带来一些功能细节上的差异。如果用户想要使用这个版本,就需要在搭建集群之初明确采用哪种模式。

我们也计划在明年,更进一步优化存算一体和存算分离的融合过程,为用户提供更加丝滑的架构切换体验。

Q5:现在市场上数据库产品越来越多,您觉得对于飞轮科技这家公司来说,我们的机遇和挑战分别是什么?

马如悦:放眼全球,中国数据库市场可以说是竞争最为激烈的。全球大约有五六百款数据库产品,而仅中国市场就占据了其中的两到三百款,这足以表明中国数据库市场的多样性和竞争程度。

面对如此激烈的竞争压力,我们最大的挑战是如何在众多企业中持续保有核心竞争力,这与未来数据仓库的发展趋势密切相关。正如前文所述,我们认为当前数据仓库未来的发展趋势一定是朝着实时分析、融合统一和云原生化分析方向发展的。而在这三个方面,我认为我们是国内目前相对领先、且理解较为深刻的厂商。

以湖仓融合体系为例,很多厂商也都在谈自己的湖仓融合,词是一个词,但是每个厂商落地到产品上就会不一样。Apache Doris 社区有自己的务实理解。Apache Doris 已经提供了高性能的计算引擎,使企业能够灵活地查询数据湖中的计算格式。同时,Apache Doris 还可以作为一个开放的数据湖,提供更加原生的能力,被其他查询引擎高速查询,目前为止,同类数据库产品中这一点只有 Apache Doris 在践行。

由此可见,实时分析、融合统一和云原生化这三个特性对于我们来说,不仅仅是一个概念,更是一个实际可行的目标。在大模型技术异常火热的今天,有很多人问为什么不做向量数据库的支持。一方面,我们对于向量化数据库这个垂直领域的理解还不够透彻,更不会因为热度而脱离主力目标发展方向;另一方面,Apache Doris 已经拥有庞大的用户群体,我们更倾向于将现有问题解决好,坚定地将上述提到的三个特性做扎实,这就足以满足大多数用户的需求。

Q6:去年亚马逊云科技在 re·Invent 提出的“Zero-ETL”,要解决什么问题?飞轮科技是否会有相应的布局?

马如悦:在数据基础设施中,主要包含事务数据库和分析数据库(数据仓库)两类,Zero-ETL 更多是让两者间的数据能够快速导入和贯通。

我认为 Zero-ETL 的出现给出了这个领域另一个问题的可能答案。很长时间,人们一直在谈论  HTAP,特别是以 OceanBase、TiDB、PolarDB 等以 TP 为主的厂商。这些系统以 TP 为主,但也宣称能解决 AP 的问题。从这么多年来实践来看,大量用户更愿意采用类似 MySQL/Oracle + Apache Doris 的组合方案。而 Zero-ETL 的出现也正是同样的思路,提供了实现 HTAP 另外的一种选择,它不认同要在一套系统里同时处理 TP 和 AP 的做法,而是可以采用快速地将 TP 的数据同步到 AP 中的方案。Zero-ETL 通过优化 TP 和 AP 打通的更好体验,提供了 HTAP 一体化的解决方案,而不是试图去在一套系统里解决两个问题。

这与数据仓库的实时分析能力有很大关系。举例来说,对于事务数据库来说,上游 TP 数据库的增删改操作希望能在在秒级以内同步至 AP 数据库,并且希望能够在 AP 数据库中立即查询分析。如果让 TP 的数据以 ETL 的方式进入 AP,数据处理链路的增加,势必造成数据进入数仓的速度也会随着变慢,整体可见性将受到影响。同时,由于越来越多的数据分析需求无法提前预知,所以分析前的预处理也变得无法提前规划,数仓能力的增强,也使得数据可以快速进入,然后在查询时按需对数据进行转化处理即可。现代化数据仓库提供实时分析能力,就需要类似 Zero-ETL 这样的方案,将 TP 数据库数据以秒级的速度高效同步到数据仓库系统中,以供类似 Apache Doris 进行高效处理和分析。

飞轮科技与阿里云合作的面向 Apache Doris 的阿里云云原生服务产品(阿里云 SelectDB 版本),已经在 8 月 20 日进行邀测,预计在 9 月底进行公测,其中也包括类似于 Zero-ETL 的解决方案。用户使用阿里云的 MySQL 或者 PolarDB 来作为事务数据库后,只需进行适当配置,数据就可以立即同步到阿里云上的 SelectDB 中,从而实现 TP 和 AP 数据库之间更好的协同工作。

写在最后

在采访最后,马如悦强调:“很多人问大数据分析领域有没有更新的黑科技了,实际到现在,大数据分析这个领域不是产品太少,黑科技太少,而是太多太复杂了。Hadoop 逐渐被替代最主要的原因是组件过于复杂,而过去数据仓库领域也涌现出了太多的新概念,我们接下来更希望把产品做得更简单、统一。”在他看来,Apache Doris 能否在未来稳居大数据项目第一梯队,并不是依靠更多的组件更多的功能,而是要坚定的专注于实时分析、融合统一和云原生化,将产品做到极致,让数据分析快速简单。

“实时分析、融合统一以及云原生化”,是马如悦在采访过程中不断强调的三个关键词。我们也很乐于看到,未来在飞轮科技的持续引领下,Apache Doris 能够持续朝着以上三个目标迭代,不断降低企业使用数据系统的复杂度。

相关文章

KubeSphere 部署向量数据库 Milvus 实战指南
探索 Kubernetes 持久化存储之 Longhorn 初窥门径
征服 Docker 镜像访问限制!KubeSphere v3.4.1 成功部署全攻略
那些年在 Terraform 上吃到的糖和踩过的坑
无需 Kubernetes 测试 Kubernetes 网络实现
Kubernetes v1.31 中的移除和主要变更

发布评论