大数据是不是凉了？

文/吴炳锡

近几年，“大数据要凉了”的声音似乎越来越多。有人说大数据热潮退却了，也有人感慨岗位越来越少、平台越来越重、业务越来越复杂。但这真的是大数据“凉”了吗？

我并不这么看。在我看来，真正“凉”的不是大数据本身，而是原来的“屠龙之术”已经无“龙”可杀，因为“龙”已经进化，而我们的武器却还停留在过去。技术需要进化，架构需要重构，能力也需要更新。

要理解大数据的现状和趋势，得先看看它是如何一步步发展演进的。我们可以将大数据的发展分成三个阶段：

阶段一： 传统 Hadoop ——第一代“烟囱式”大数据平台

最早的大数据平台基本是围绕 Hadoop 构建的，Lambda 架构（离线 + 实时）几乎是当时的行业标准。但在实际工作中，我深刻体会到这个阶段的大数据平台仍然极不易用，需要大量的人力和资源投入，所构建的系统难以真正商业化，只是一个个离线的组件。

当时，技术团队拿着各种 Hadoop + Hive + Spark 的架构图给老板讲未来、画愿景，靠着数据中台的“故事”扩张团队，组建起来五十人的大数据团队，雄心壮志地把平台堆了起来。

Lamda 架构的大数据，各处树烟囱

然而现实很快打脸：

1. 数据总不一致，只能安慰老板说“海量数据差 1-2 条不影响使用， 这个系统和核心业务无关”；
2. 发现数据写错了， 居然不能更新，只能把一个分区干掉重写；
3. 成本居高不下， 因为数据往往要存储两份；
4. 号称大数据平台多么牛， 老板想查个数直接把平台弄挂了， 只因查数据时没带分区键；
5. 初期平台 1 个月 10 亿数据，分区还算合理；后期每天都到 20亿数据，系统开始严重卡顿；等量级上到万亿，前面那些人已经跑了，平台只能推倒重建；
6. 平台组件多（至少 30 个以上），任一组件升级都足以导致平台整体崩溃；
7. 架构“烟囱”林立，每“树”一个烟囱都会引入新的安全问题，都会把平台干翻；
8. SQL 执行计划需要几分钟才能出来， 基本无法执行（因分区过多， 元数据顶不住）；
9. 老板说“把数据去个重吧”，大家都想辞职。（某大平台当年只有 ODS 活着）；
10. ... 类似的糟心例子数不胜数。

可以说，这个阶段的大数据平台让老板彻夜难眠。实践证明，该架构不仅无法支撑业务需求，反而可能将公司的大数据战略带入死胡同。大数据工程师大多数时间都在用 Spark 将数据加载到 Hadoop，完成清洗和治理，做好数据准备工作，为上层的数据开发利用人员使用。关键这个阶段数据开发利用的人员还不敢多说一句话，常常处于弱势地位。

阶段二： 数据湖+湖仓一体—— 组件“瘦身”，但架构复杂性仍高

第一代大数据平台的“惨痛经验”倒逼架构进行重塑。以 Apache Iceberg、Delta Lake 为代表的数据湖架构兴起，用于替代封闭的 Hadoop 体系，实现事务支持、统一元数据、统一存储的“湖仓一体”方案。

在这个阶段，技术团队开始尝试简化组件，减少部署复杂性。我们开始引入数据湖，把数据持久化为 Iceberg 格式 （ODS），支持 Spark、Flink 的统计读写，将原来复杂的30 + 组件缩减至 10个左右。大数据团队规模也从 50+ 人压缩到 10 人左右。 此时，大数据团队的工作主要包括：

1. 学习 Spark 调度任务清理 Iceberg 的历史版本；
2. 学习 Spark 调度任务实现 Iceberg 的 compact 操作；
3. 学习 Spark 调度任务完成 Iceberg 的 Z-order 任务处理；
4. 学习使用 Shuffle 服务调用；
5. 各种开源组件拼合后的权限整理；
6. 制作 SQL Gateway，根据 SQL 情况路由到后面的三个计算引擎；
7. 给老板呈现一个“架构美观、功能强大”的平台。

这个阶段可以给老板画饼：

1. 支持 ACID 事务；
2. 实现统一元数据管理；
3. 支持统一存储。

然而，老板常常提出疑问：“不对啊，这个平台至少还要投入 10 个人，这 10 个人拉去做业务不香吗？”

现实中，大部分公司都以此为底座构建大数据平台。虽然平台瘦身了，人员规模从 50 人缩到 10 人，组件数量从 30 个缩到 10 个，但实质复杂度依然太高，大多数企业难以真正落地使用。

如果这个平台的数据量上到万亿级别还能顶住， 那实属幸运。 否则，就只能让大数据开发人员“祭天”了。作为这类平台下的大数据工程师，需要特别注意它的定位：单表数据最好不要超过百亿，全库控制在 1万个表以内。否则，Spark 任务再多就不好搞了，加班现象会非常严重。

阶段三：云原生新范式，颠覆“大数据工程师”（当前形态）

进入第三阶段，尤其是在游戏行业中，一些大的游戏公司每周都会上线新业务， 上线后各种数据分析就来了。这种时候，如果用阶段二的方案，你会发现每次都要搭建一个新平台，一旦出问题就要通宵加班。游戏行业每时每刻都意味着钱，每一个环节都关系到兄弟们的年终奖。 传统大数据方案已经无法解决业务需求：

1. 数据需要秒级接入；
2. 系统需要支持上万级的流式计算；
3. 海量的数据挖掘需求。

此时，像 Snowflake 和 Databend 这类按需付费、支持流批一体、全 SQL 表达的云原生平台应运而生。

它们为大数据平台带来了巨大变化：基于标准 SQL 可以直接读取 S3 中 CSV,、NDJson、Parquet、ORC... 等文件类型；无需 Spark 团队预处理，ETL 工程师在半小时内即可完成原本需 2 天的数据接入流程。

如你再会点 Python ，还可以利用 Databend 这类支持外置 UDF 的产品， 实现表级增量捕获，替换原来的 Flink 任务。原先游戏行业里，打完一把游戏立刻输出本局对战详情的任务就可以这样搞定。原来几十台 Flink 集群才能跑的流计划任务，现在只要半天就能搞定，而且还能做到弹性伸缩。

这时候，我们会发现“数据准备工程师”角色消失了，传统意义上的“数仓平台搭建专家”也逐渐被边缘化。大数据进入了一个“轻平台 + 重表达 + 强业务理解”的新阶段。

目前，Snowflake、Databricks、Databend 等产品在这方面都有比较完美的实现。

总结与感想

如今大数据生态的工作依然比较多，涉及到的角色包括不限于：

1. 大数据数据准备工程师 （ 曾经说的数据搬运工）( 平台化 & SaaS )；
2. ETL工程师；
3. BI 及 分析人员 ( 可能每天用 Excel 记录任务， 也会使用 Text2SQL 辅助 ）；
4. 数据质量管理 & 血源治理工程师 （ 平台化 & SaaS )；
5. 算法 & 机器学习工程师；
6. 调度平台研发 （ SaaS )；
7. 数据同步工具开发 （ SaaS, 变身称谓：Data pipeline )；
8. 可视化相关的工作 ( 平台化 & SaaS )；
9. 数据中台 （由一堆概念堆出来的一个大数据平台，当前都在转向 Data + AI ）；
10. 专注于业务的数据分析师（ 那些花了 10万投放，如何用数据分析来指导投放）；
11. 利用数据去变现的运营或决策。

其实大数据行业对人才需求还是依然旺盛的，只是需要更加专业的人了，原来定位大数据的数据搬运工的工作确实少了， 因为有更简单的方式去替代。

如果你想从事大数据工作，我认为还是大有可为。以下是我个人的一些建议，从入门到进阶的路径：

1. ETL 工程师或是数据抓取工程师 （低代码 + SQL ）；
2. 参与专项任务的开发工程师， 例如： 数据同步工具、调度平台、可视化等；
3. 深入底层核心：存储、算法、SQL 编译器等，都是不是错的工作。

大数据没有“凉”，只是“基础建设时代”已经过去，进入了“智能运营时代” 。未来比拼的不再是谁组件堆得多，而是谁能用更低的成本更快地创造数据价值。

附： 数据分析 平台进化时间线

我本人是从 OLTP 转到大数据基础架构的， 目前是 Databend Labs 联合创始人兼生态负责人。今年是我进入这个领域的第四年，虽然仍是大数据领域的新兵，但已经深深感觉到这个行业的巨大变化与无限机会。

欢迎更多大数据从业者一起交流，共同成长。你经历过哪一代的大数据平台？你所在的公司现在处在哪个阶段？你又是怎么看待“数据搬运工”到“数据工程师”的转变？欢迎在评论区留言，聊聊你的真实感受和思考。

如果你对文中提到的 Databend 云原生湖仓方案感兴趣，也欢迎来试用体验。

关于 Databend

Databend 是一款开源、弹性、低成本，基于对象存储也可以做实时分析的新式湖仓。期待您的关注，一起探索云原生数仓解决方案，打造新一代开源 Data Cloud。

👨‍💻‍ Databend Cloud：databend.cn

📖 Databend 文档：docs.databend.cn

💻 Wechat：Databend

✨ GitHub：github.com/databendlab...