写点什么

AI 信创与湖仓一体化,2024 年数据库 & 湖仓发展与展望

  • 2025-01-16
    北京
  • 本文字数:5418 字

    阅读完需:约 18 分钟

AI 信创与湖仓一体化,2024 年数据库&湖仓发展与展望

时光荏苒,转眼间 2025 年已然来临,这又是我从传统 OLTP 数据库领域转向云原生湖仓 Databend 的第三个年头,这段转变恰如一场快速的旅程,让我深感这一年如飞箭般迅速。展望未来,我意识到,尽管数据库行业正面临明显的瓶颈,湖仓领域却蕴藏着无尽的潜力,而 AI 的崛起将进一步提高从业门槛。以下,我将从四个方面与大家分享我对 2024 年数据库 & 湖仓的回顾与思考:1. 数据库的发展现状 2. 湖仓现状 3. 行业观察 4. 未来思考。


数据库的发展现状


数据库平台化趋势


在互联网行业,数据库的应用仍以 MySQL 为主。大部分公司已经实现了数据库的平台化或是云化,很多企业甚至已经拥有上万、10 万 + 级别的实例规模。在这种公司中,数据库技能已经完全平台化, 数据库大多处于一个微服务层的定位。他们早已完成数据库基础运维技术的积累,基于平台化运维实现了数据库自助上线、自动备份和半自动恢复,构建了数据零信任的完整体系。


早期,这类公司都有对应的数据库内核研发团队,从 2024 年起,对内部数据库内核团队减员增效成为一种趋势。


信创背景下的自主可控


国内高举“信创”这杆大旗,推动所有 IT 建设从追求“可用性,高性能”转向了“自主可控”。在此背景下,这个赛道上更多产品以 HTAP(Second Engine) 为主要方向,主攻超融合数据,专注替换 Oracle , SQL  Server, MySQL 等产品的存量市场,且各家产品都在协议兼容上重度投入。例如:


  • Oceanbase 兼容 Oracle, MySQL;

  • 达梦兼容 Oracle、SQL Server、MySQL、Teradata 等;

  • 金仓兼容  Oracle、MySQL、PostgreSQL;

  • TiDB 兼容 MySQL。


此外,一些后起之秀也在追赶中,一些产品基于 PG 或 MySQL 前端套了一个 Proxy 实现了 Oracle、SQL Server 协议的接入,也获得了用户的认可。这波国产化 + 信创从去年常听到的是“又不是不能用”,到今天“有些产品真的不好用”,市场的选择逐步显现,“当大潮退去,才知道谁在裸泳”。


从整体看,完全自研加上有互联网基因的数据库,在性能和好用方面都占优;偏传统的数据库在兼容性上有着绝对优势。目前,信创市场还是一个销售为王的时代,预计在 2025 年,信创数据库的“圈地运动”或将进入尾声。但中国的信创数据库少年们仍需加油,未来还有出海这片广阔天地。


AI 对数据库的赋能


目前,AI 在数据库行业的应用,尤其是在比较成熟的近似度搜索和知识库整合方面,原创数据库产品加此类功能比较容易。例如, PingCAP 的黄东旭在会议上分享 TiDB 在 2 周内完成了相关功能的实现,Databend 的  Bohu Tang 也在一周内增加了近似度搜索能力。这种只需少量时间投入,就能让数据库或湖仓产品拥有一个向量检索能力,可以让产品快速迭代出 AI 能力,是一种非常值得的尝试。


湖仓方向


Hadoop 的退场与湖仓一体化的崛起


Hadoop 时代正在快速退场,正如人们对“固定电话时代”的看法:虽然还能用,但如果坏了就不值得再修,有太多好用的产品可以替代它。随着 CloudOS 被越来越多人的接受,湖仓一体化时代已经到来。越来越多的产品宣称能够替代 Snowflake,其中以 Databricks、Databend 为代表的新兴产品,通过技术创新和高效的操作方式,正在重塑湖仓市场的格局。


2024 年,你可能会看到一个现象,任何一个湖仓产品都在宣称自己能够替换 Snowflake。然而,很多人对 Snowflake 仍停留在“听说过”的阶段 ,还不真正了解 Snowflake 。


互联网公司传统的湖仓平台已经从 Hadoop 转向了“Spark + Icberg(Hudi) + Painmon + Trino + kafka + Zookeeper + 元数据服务 + MySQL + 任务调度平台 … ”。大数据从业人员也分为:基础架构平台(Java)工程师、数据加载清洗准备工程师(Spark 任务, Data X 任务, Java, Python)、数据使用工程师。其中,大数据工程师汇报时的 PPT 最丰富,架构最丰富,但也是报警及故障最多的部门。


相比这套复杂的技术栈,基于 Snowflake 的湖仓平台只需“ Snowflake  + 数据使用工程师”, 就 OK 了。No Java, No Python,所有一切都基于 SQL 操作,方便快捷。


Databend 产品基于 Rust 开发,从 0 到 1,以 Snowflake 为蓝本实现了一个开源的 Snowflake 替代方案,目前也是唯一个可以私有化部署的 Snowflake 替代产品。2024 年,该产品已经在海外金融和保险行业实现商用私有化部署。


湖仓一体化未来思路


目前来看,湖仓一体化在未来的整体思路是:


  1. 实现数据秒级接入可见,拥有强大的吞吐能力,支持每秒 500 万行 /S 以上的数据加载及卸载能力;

  2. 基于 SQL 操作;

  3. 强调 NoETL 特性;

  4. 支持离线计算和实时挖掘, 平台稳定性越来越重要;

  5. 数据少搬家或是不搬家,提供数据集市功能;

  6. 支持事务性操作,确保数据完整性和一致性;

  7. 支持结构化、半结构、非结构化、空间类数据融合;

  8. 易管理,易运维;

  9. 低成本,支持云上按需付费;

  10. 提供多 IDC 容灾能力。


湖仓创业方向众多,例如:


  • 引擎方向: Paimon

  • 元数据方向: Gravitino, 成名公司: Illumex

  • 数据统一访问层: OpenDAL


湖仓方向需求非常复杂, 这个方向机会也很多,需要考虑清楚立足点是云上或是云下,这两个产品方向区别比较大。因为我个人也在湖仓方向创业,就不对同行的产品进行过多评价。


行业观察


技术会议的转型


2024 年,DTCC 会议中纯数据库技术分享的吸引力逐渐下降,已经无法吸引到太多听众。但观众对信创、AI 和数据应用、数据治理、湖仓方向的热情还是非常高的。


我的感觉是大学生现在专业度也提高了,很多知识在学校里就完成了积累,行业内的数据库会议如果再讲开发规范及基本架构已经无法满足需求。


国内如 QCon 等技术会议也都开始往  AI 方向转变。这也给了会议主办方带来一个新的思考:技术会议究竟能为参与者提供什么价值?


AI 与数据的交汇


AI 方向有着绝对的诱惑,文生图、文生视频、语音模仿都有着非常成熟的应用;其实反观:大模型就是一个强大的数据库,有着海量的数据和内容可供查询。 如果想在 AI 和数据方向搞创业,参考 Illumex 专心给大模型提供数据,应该还是一个不错的方向。


此外,AI 的成熟也让启发式 SQL 更快融入工作中, 对于数据库和分析型湖仓产品也有了更高的要求。


“插管吸血”的云厂家


大家也许总会讨论为什么原来有那么多优秀的开源产品,但现在感觉却越来越少了。其实并也不少,可能是大家宣传方面低调了很多。因为原来的高调宣传反而都给云厂家做了嫁衣。例如:当年 Hadoop 火的时候 AWS 推荐 EMR, 基于 Presto 的 Athena 以及今年的 S3 Table ,  阿里云的 MySQL RDS 基本每个产品都可以做到上亿,甚至更多的收入,但这些产品对开源社区可以说基本没有任何帮助,修正的 bug 和优化的性能往往也不会反馈到社区,但看到开源社区好的性能往往会较快速度合并过来。很多优秀的开源产品快被这些云厂商“吸干”,估计后面也只能慢慢自行搞了。


优秀的开源产品现在比较难吸引贡献者,但很容易吸引云厂商的同行来 fork 或是抄你一个产品。如何与云厂商差异共存,通常成为创业者第一时间要想好的事。


未来的思考


基础架构的变化


基础架构的变化往往蕴藏着无限商机和工作机会,尤其在当前技术快速发展的背景下,这一趋势愈发明显:


  • 信创需求驱动的复杂性提升


随着信创要求的深入,大量信创服务和操作系统融入私有化环境,导致企业内部引入“赛马机制”,带来了大量的异构机型及操作系统共存,将 IT 建设带入了一个新的难度。这些企业往往是更偏统业务模型的数据库或是湖仓产品的天下,未来必然面临下一步的平台化或是私有云的进一步转型。同样的,传统信创数据库也要面临从“能用到好用”的挑战。


  • 云端轻资源化的崛起


另一类企业则通过云基础架构将创业轻资源化。在云上, K8s 已经成为新的操作系统, 对象存储就替代了文件存储,在这一基础架构的变革中, Databend 捐赠给 Apache 的 OpenDAL 项目已经被多家数据公司使用。如果你是一个面向云端的架构,或是你将来想要把数据及湖仓产品部署在云上和云厂家分一杯羹,就不要犹豫,需要认真思考如何把数据库跑在 K8s + 对象存储之上。以下是一些成功的产品:


  • OLTP

  • Neon

  • TiDB Cloud Servless

  • 湖仓产品:

  • Snowflake (闭源产品)

  • Spark + Iceberg

  • Databend

  • 通信协议的更新


TCP/IP 协议在数据库和湖仓产品中已经被视为效率的桎梏,特别是随着 AI 的融入,对更快的通信有着迫切的需求。以太网 25GB 已成为新一代设备的标配, RDMA 通信在数据库和湖仓产品中大量使用,多家云厂商对外宣传在做新的通信协议。预计 2025 年,我们将看到更多关于新通信协议的技术探索与实践。


在 CloudOS 背景下,未来需要更多高性能、低成本且能充分利用 CloudOS 资源和便利的数据库和湖仓。


数据库与湖仓产品未来的变化


  • 专业化的内核开发与用户融合


随着大量更加专业的内核开发人员,及数据使用者进入, 数据库和湖仓产品进入更加专业的阶段。中国大量的开源项目也已成为全球行业认可的项目。这些变化吸引了大批专业人士融入,将进一步推动数据库和湖仓产品的快速发展。


  • “快”不再是唯一标准


从产品体验上看,“快”已经不再是数据库和湖仓产品唯一的选择标准。因为总是有比你更快的,随着硬件发展这个现象将越来越普遍。 从用户侧看,在产品性能可以达到用户要求后,用户会更在意产品的使用和运维体验,包括是否能更加简单使用,更容易运维或是无需运维。


  • 稳定性仍是最大挑战


2025 年,产品稳定还是数据库和湖仓产品最大的挑战。在功能飞速迭代的同时,过于复杂的“瑞士军刀”模式,可能会带来产品的高故障率。例如一个崩溃需要半个小时才能恢复,甚至停电后无人能把服务启动起来。此类问题亟需通过产品简化来真正解决。在这一方面,Rust 语言有着天然优势,将在未来的数据库和湖仓开发中扮演重要角色。


数据工作者的职业转型


信创自主可控和国际化融合进程加速了数据工作者的角色变化:


  • 职业路径的多样化


一类是越来越多的 DBA 进入数据库公司或乙方担任技术专家;另一类是投身于国内业务 / 产品的快速出海。有一些华人甚至在海外创业,国内招聘技术人员。国内的技术人员专业能力都不错,DBA 出海也成为了热门。在新加坡等地区,一些海外公司也会在国内招聘人员。


  • 潜在危机:云端 RDS 的挑战


云产品的普及让 DBA 曾经担忧失业,虽然云厂商初期对此否认,但现状表明,RDS 产品确实对 DBA 岗位产生了冲击。RDS 整合了内核和 DB 运维团队的力量,个人专业技术难以匹敌团队协作的效能。


我个人从 OLTP 的 DBA 切换到湖仓方向,这几年也在专注分析和学习 Snowflake,以及从 Databend 和 Snowflake 的真实用户里看,给大数据工作者提供一些建议参考。


  • 大数据与湖仓领域的三类职业


目前来看,大数据及湖仓领域的工作者可以为分以下三类:


  1. 基础架构开发工程师: 主要从事 HDFS、Spark 、EMR 开发类的工程师。这类工程师的黄金时代应该是阿里 2010 年左右大力搞开源的时代,后续这波人有很多出国或是去了其它公司做了技术负责人。这波人目前也比较危险,就如同互联网公司养的数据库内核团队对公司产出的价值有限。而且在一个企业内很容易出现对于开源产品 Follow 不够全面造成大的故障。这类人专业度很高,最好的出路还是需要早日融入专业的产品中。

  2. 数据搬运工: 负责利用 Spark , DataX, ETL 工具把数据搬来搬去,每天面对上万或是 10 万 + 的任务运行。数据核对,数据重新生成占了最大量的工作。这类工作现在已经有很多专业的产品取代,参考上面提到的 RDS 干掉 DBA。你的同行有专家团队时会干得更加专业。而且在 Snowflake 和 Databend 中更加强调 ELT 或 NoETL 的方式,也降低了这一岗位的需求。

  3. 数据分析工程师: 贴近业务的高价值岗位,工作内容的上下限较高,短期内难以完全被替代。但 AI 的发展对这类岗位提出了更高的要求,数据分析工程师需要尽快拥抱 AI,提升竞争力。


总结


2024 年,数据库与湖仓领域面临着巨大机遇与挑战。信创自主可控已成基调,2025 年将会加速这个市场的格局演变;AI 的势不可挡则蕴含了未来无限可能,要求从业者结合行业需求,最大化发挥 AI 的价值;湖仓一体时代已经到来,使高性能、易用性、稳定性和低成本的产品成为未来发展的关键词;此外,出海正成为国产创业公司生存和发展的必经之路。


展望未来,竞争的核心不仅仅依赖于技术的速度和性能,更在于如何为用户提供更便捷、更稳定的解决方案。我们应以开放的心态,迎接 AI 和信创带来的新变革,努力开辟更广阔的市场空间。让我们共同携手,迎接未来的挑战,以创新和合作驱动行业的进步与繁荣。


作者简介


吴炳锡,Databend  Labs 联合创始人兼生态负责人,资深 MySQL 与数据专家,也是 3306π 社区联合创始人,知数堂联合创始人, 腾讯 TVP 鲲鹏会、TGO 成员,担任多年 DTCC,SACC, Oracle 技术嘉年华顾问及出品人。


今日好文推荐


刚刚过去的一年 GitHub 刷星大爆发?!450 万假 Star,项目风光仅撑 2 个月!


C++用了11年,仅17位贡献者代码提交超过10次,迁移到Rust后,再也不想回去了


软件架构50年:大模型是否开启新的抽象层次?ACM 院士、UML创始人谈软件架构演变


微软全新原生 Copilot 应用被指是 Edge 套壳:从 PWA 转向“原生”,内存占用却飙升至 1GB


活动推荐


随着进入 Data + AI 驱动的新时代,企业对实时数据分析的需求不断增加,对半结构化和非结构化数据的处理也愈显重要,如何高效整合多种数据源,实现实时分析与智能决策,已成为业界面临的重大挑战。这一过程也促使 Lakehouse 架构正在迎来新一轮的架构演进。2025 年 4 月 10 - 12 日,QCon 全球软件开发大会(北京站)策划了「Lakehouse 架构演进」专题,直击行业痛点,解锁可复制的经验与模式。现在报名可以享受 8 折优惠,单张门票立省 1360 元,详情可联系票务经理 18514549229 咨询。



2025-01-16 18:4210452

评论 1 条评论

发布
用户头像
推荐一下专业数据集成开源工具 - Apache SeaTunnel,比 DataX 优秀很多,比如:
- 识别表元数据,字段类型
- 多表读取
- 心跳延迟检测
- 源中心数据源开发
- 模型推演,以及批流一体等,性能也比 DataX 强劲
2025-01-22 21:26 · 北京
回复
没有更多了

ARTS打卡 week 2

猫吃小怪兽

ARTS 打卡计划

食堂就餐卡系统设计

飞雪

不可不知的 7 个 JDK 命令

武培轩

Java 程序员 jdk 后端 JVM

每周学习总结-架构师培训一期

Damon

LeetCode 769. Max Chunks To Make Sorted

liu_liu

LeetCode

Element-UI实战系列:Tree组件的几种使用场景

AR7

vue.js 大前端 Elemen

食堂就餐卡系统设计

饶军

食堂就餐卡系统设计

刘志刚

架构方法学习总结

飞雪

程序员的晚餐 | 6 月 7 日 豆腐年糕

清远

美食

【ARTS打卡】Week02

Rex

Flink源码分析之FlinkConsumer是如何保证一个partition对应一个thread的

shengjk1

flink flink 消费 kafka 实时计算 flink源码分析

人人都是产品经理

二鱼先生

产品经理 个人品牌 职场成长 产品思维

架构师训练营第一周作业

芒夏

极客大学架构师训练营

dnsmasq-域名访问及解析缓存

一周思进

架构师训练营第一周作业

小树林

架构师训练营-命题作业1

水边

极客大学架构师训练营

Flink源码分析之Flink startupMode是如何起作用的

shengjk1

flink flink 消费 kafak 实时计算 flink源码 flink源码分析

ARTS-WEEK2

一周思进

ARTS 打卡计划

程序员陪娃系列——数学启蒙趣事

孙苏勇

程序员 陪伴

架构师训练营-每周学习总结1

水边

极客大学架构师训练营

Flink源码分析之Flink是如何kafka读取数据的

shengjk1

flink flink 消费 kafka flink源码分析 flink消费kafka源码解析

Flink源码分析之-如何保存 offset

shengjk1

食堂就餐卡管理系统

孙志平

SpringBatch系列之并发并行能力

稻草鸟人

Spring Boot SpringBatch 批量

愚蠢写作术(3):如何把读者带入迷宫深处

史方远

学习 读书笔记 个人成长 写作

SpringBoot基本特性以及自动化配置-SPI机制

攀岩飞鱼

Java 微服务 Spring Boot SpringCloud

因为 MongoDB 没入门,我丢了一份实习工作

沉默王二

mongodb

极客时间-架构师培训-1期作业

Damon

Flink源码分析之Flink 自定义source、sink 是如何起作用的

shengjk1

flink flink源码 flink源码分析 flink自定义source flink自定义sink

架构师训练营第一周学习总结

刘志刚

AI 信创与湖仓一体化,2024 年数据库&湖仓发展与展望_数据湖仓_吴炳锡_InfoQ精选文章