大数据是不是凉了？
文/吴炳锡
近几年，"大数据要凉了"的声音似乎越来越多。有人说大数据热潮退却了，也有人感慨岗位越来越少、平台越来越重、业务越来越复杂。但这真的是大数据"凉"了吗？
我并不这么看。在我看来，真正"凉"的不是大数据本身，而是原来的"屠龙之术"已经无"龙"可杀，因为"龙"已经进化，而我们的武器却还停留在过去。技术需要进化，架构需要重构，能力也需要更新。
要理解大数据的现状和趋势，得先看看它是如何一步步发展演进的。我们可以将大数据的发展分成三个阶段：
阶段一： 传统 Hadoop ------第一代"烟囱式"大数据平台
最早的大数据平台基本是围绕 Hadoop 构建的，Lambda 架构（离线 + 实时）几乎是当时的行业标准。但在实际工作中，我深刻体会到这个阶段的大数据平台仍然极不易用，需要大量的人力和资源投入，所构建的系统难以真正商业化，只是一个个离线的组件。
当时，技术团队拿着各种 Hadoop + Hive + Spark 的架构图给老板讲未来、画愿景，靠着数据中台的"故事"扩张团队，组建起来五十人的大数据团队，雄心壮志地把平台堆了起来。
Lamda 架构的大数据，各处树烟囱
然而现实很快打脸：
- 数据总不一致，只能安慰老板说"海量数据差 1-2 条不影响使用， 这个系统和核心业务无关"；
- 发现数据写错了， 居然不能更新，只能把一个分区干掉重写；
- 成本居高不下， 因为数据往往要存储两份；
- 号称大数据平台多么牛， 老板想查个数直接把平台弄挂了， 只因查数据时没带分区键；
- 初期平台 1 个月 10 亿数据，分区还算合理；后期每天都到 20亿数据，系统开始严重卡顿；等量级上到万亿，前面那些人已经跑了，平台只能推倒重建；
- 平台组件多（至少 30 个以上），任一组件升级都足以导致平台整体崩溃；
- 架构"烟囱"林立，每"树"一个烟囱都会引入新的安全问题，都会把平台干翻；
- SQL 执行计划需要几分钟才能出来， 基本无法执行（因分区过多， 元数据顶不住）；
- 老板说"把数据去个重吧"，大家都想辞职。（某大平台当年只有 ODS 活着）；
- ... 类似的糟心例子数不胜数。
可以说，这个阶段的大数据平台让老板彻夜难眠。实践证明，该架构不仅无法支撑业务需求，反而可能将公司的大数据战略带入死胡同。大数据工程师大多数时间都在用 Spark 将数据加载到 Hadoop，完成清洗和治理，做好数据准备工作，为上层的数据开发利用人员使用。关键这个阶段数据开发利用的人员还不敢多说一句话，常常处于弱势地位。
阶段二： 数据湖+湖仓一体------ 组件"瘦身"，但架构复杂性仍高
第一代大数据平台的"惨痛经验"倒逼架构进行重塑。以 Apache Iceberg、Delta Lake 为代表的数据湖架构兴起，用于替代封闭的 Hadoop 体系，实现事务支持、统一元数据、统一存储的"湖仓一体"方案。
在这个阶段，技术团队开始尝试简化组件，减少部署复杂性。我们开始引入数据湖，把数据持久化为 Iceberg 格式 （ODS），支持 Spark、Flink 的统计读写，将原来复杂的30 + 组件缩减至 10个左右。大数据团队规模也从 50+ 人压缩到 10 人左右。 此时，大数据团队的工作主要包括：
- 学习 Spark 调度任务清理 Iceberg 的历史版本；
- 学习 Spark 调度任务实现 Iceberg 的 compact 操作；
- 学习 Spark 调度任务完成 Iceberg 的 Z-order 任务处理；
- 学习使用 Shuffle 服务调用；
- 各种开源组件拼合后的权限整理；
- 制作 SQL Gateway，根据 SQL 情况路由到后面的三个计算引擎；
- 给老板呈现一个"架构美观、功能强大"的平台。
这个阶段可以给老板画饼：
- 支持 ACID 事务；
- 实现统一元数据管理；
- 支持统一存储。
然而，老板常常提出疑问："不对啊，这个平台至少还要投入 10 个人，这 10 个人拉去做业务不香吗？"
现实中，大部分公司都以此为底座构建大数据平台。虽然平台瘦身了，人员规模从 50 人缩到 10 人，组件数量从 30 个缩到 10 个，但实质复杂度依然太高，大多数企业难以真正落地使用。
如果这个平台的数据量上到万亿级别还能顶住， 那实属幸运。 否则，就只能让大数据开发人员"祭天"了。作为这类平台下的大数据工程师，需要特别注意它的定位：单表数据最好不要超过百亿，全库控制在 1万个表以内。否则，Spark 任务再多就不好搞了，加班现象会非常严重。
阶段三：云原生新范式，颠覆"大数据工程师"（当前形态）
进入第三阶段，尤其是在游戏行业中，一些大的游戏公司每周都会上线新业务， 上线后各种数据分析就来了。这种时候，如果用阶段二的方案，你会发现每次都要搭建一个新平台，一旦出问题就要通宵加班。游戏行业每时每刻都意味着钱，每一个环节都关系到兄弟们的年终奖。 传统大数据方案已经无法解决业务需求：
- 数据需要秒级接入；
- 系统需要支持上万级的流式计算；
- 海量的数据挖掘需求。
此时，像 Snowflake 和 Databend 这类按需付费、支持流批一体、全 SQL 表达的云原生平台应运而生。
它们为大数据平台带来了巨大变化：基于标准 SQL 可以直接读取 S3 中 CSV,、NDJson、Parquet、ORC... 等文件类型；无需 Spark 团队预处理，ETL 工程师在半小时内即可完成原本需 2 天的数据接入流程。
如你再会点 Python ，还可以利用 Databend 这类支持外置 UDF 的产品， 实现表级增量捕获，替换原来的 Flink 任务。原先游戏行业里，打完一把游戏立刻输出本局对战详情的任务就可以这样搞定。原来几十台 Flink 集群才能跑的流计划任务，现在只要半天就能搞定，而且还能做到弹性伸缩。
这时候，我们会发现"数据准备工程师"角色消失了，传统意义上的"数仓平台搭建专家"也逐渐被边缘化。大数据进入了一个"轻平台 + 重表达 + 强业务理解"的新阶段。
目前，Snowflake、Databricks、Databend 等产品在这方面都有比较完美的实现。
总结与感想
如今大数据生态的工作依然比较多，涉及到的角色包括不限于：
- 大数据数据准备工程师 （ 曾经说的数据搬运工）( 平台化 & SaaS )；
- ETL工程师；
- BI 及 分析人员 ( 可能每天用 Excel 记录任务， 也会使用 Text2SQL 辅助 ）；
- 数据质量管理 & 血源治理工程师 （ 平台化 & SaaS )；
- 算法 & 机器学习工程师；
- 调度平台研发 （ SaaS )；
- 数据同步工具开发 （ SaaS, 变身称谓：Data pipeline )；
- 可视化相关的工作 ( 平台化 & SaaS )；
- 数据中台 （由一堆概念堆出来的一个大数据平台，当前都在转向 Data + AI ）；
- 专注于业务的数据分析师（ 那些花了 10万投放，如何用数据分析来指导投放）；
- 利用数据去变现的运营或决策。
其实大数据行业对人才需求还是依然旺盛的，只是需要更加专业的人了，原来定位大数据的数据搬运工的工作确实少了， 因为有更简单的方式去替代。
如果你想从事大数据工作，我认为还是大有可为。以下是我个人的一些建议，从入门到进阶的路径：
- ETL 工程师或是数据抓取工程师 （低代码 + SQL ）；
- 参与专项任务的开发工程师， 例如： 数据同步工具、调度平台、可视化等；
- 深入底层核心：存储、算法、SQL 编译器等，都是不是错的工作。
大数据没有"凉"，只是"基础建设时代"已经过去，进入了"智能运营时代" 。未来比拼的不再是谁组件堆得多，而是谁能用更低的成本更快地创造数据价值。
附： 数据分析 平台进化时间线
我本人是从 OLTP 转到大数据基础架构的， 目前是 Databend Labs 联合创始人兼生态负责人。今年是我进入这个领域的第四年，虽然仍是大数据领域的新兵，但已经深深感觉到这个行业的巨大变化与无限机会。
欢迎更多大数据从业者一起交流，共同成长。你经历过哪一代的大数据平台？你所在的公司现在处在哪个阶段？你又是怎么看待"数据搬运工"到"数据工程师"的转变？欢迎在评论区留言，聊聊你的真实感受和思考。
如果你对文中提到的 Databend 云原生湖仓方案感兴趣，也欢迎来试用体验。
关于 Databend
Databend 是一款开源、弹性、低成本，基于对象存储也可以做实时分析的新式湖仓。期待您的关注，一起探索云原生数仓解决方案，打造新一代开源 Data Cloud。
👨💻 Databend Cloud：databend.cn
📖 Databend 文档：docs.databend.cn
💻 Wechat：Databend
✨ GitHub：github.com/databendlab...
