作者 | 刘旭晖

审校 | 罗燕珊

2022 年 12 月，国务院发文关于发挥数据要素作用的指导意见（俗称数据 20 条）。2023 年 10 月，国家大数据管理局正式挂牌，同年各地数据要素交易市场纷纷建立。2024 年 1 月 1 日“数据资产入表”正式生效。毋庸置疑，数据在企业数智化运营的大环境趋势下，作为核心生产要素和资产的价值，越来越突显。

但大数据团队是成本中心还是价值中心，近几年来，众多走在降本增效的路上的大数据团队，如何为自己正名？从数据入表的财务角度来看，怎样才能“赚钱”？本文将结合云器科技过往的行业经验和大数据领域的最新趋势理念，尝试做一些分析和讨论。

原本以为，《天下无贼》里黎叔的这句话，说的是二十一世纪，人才，能赚很多的钱。

深以为然的我，思前想后，在数智化的时代，什么样的人才能挣最多的钱呢？那必须得包括肩负着水电煤一般存在的使命的大数据团队啊，作为大数据团队的人才，也一定是值钱得不能更值钱了。

后来，经过多年的社会毒打，渐渐发觉，是我天真了。

贵，就简单的是“贵”这个字表面的意思，并没有太多的解读空间。而大数据团队，历来在公司老板们的心目中，就是个成本中心，和“值钱”并没有一毛钱的关系。

疫情之后，接触过业内各式各样公司的大数据团队，降本，几乎是所有有一定规模的大数据团队，都逃不过的命题作业。甚至有些团队的负责人直言不讳地说，维稳省钱，就是领导对他们今年唯一的核心 KPI 指标要求。

这也难怪，谁叫你最贵呢。贵的意思不就是成本高，降的就是你们。连带着各大公有云厂商，大数据方案提供商们，近几年的日子也不太好过，地主家，也没有余粮了。

但，这好像有哪里不对。不是说好了，二十一世纪是数字化、智能化的时代吗?

那大数据团队到底是成本中心还是盈利部门呢，数据到底是资产还是负债呢？

这种大事，还是得国家权威机构说了算。这不，国家财政部在今年 8 月发文了 《企业数据资源相关会计处理暂行规定》，说人话，也就是俗称的“资产入表”，2024 年 1 月 1 日起正式执行。

延展阅读：《企业数据将作为资产被纳入会计报表》

简单来说，就是数据，作为数字化时代企业的核心生产要素之一，可以、也应该作为“无形资产”，计入上市企业的资产负债表中进行披露。

这么一说，大数据团队不就要咸鱼翻身了嘛。

严谨的同学又要问了，数据资产值多少钱咋评估呢？是不是像有的同学总结的那样，把故事说好了就可以了呢。你看，獐子岛的扇贝都可以成为玄学，何况这看不见摸不着的 “无形资产”？

同样是数据，为什么比如阿里巴巴的生意参谋里的数据就是金凤凰，很多功能都号称普惠了，每年还能卖个十亿八亿的，自己家那几 P 的数据，就都是压箱底的石头疙瘩，既费神还烧钱呢。

其实， “无形资产”也是有严肃的定义的，这还得搬出财政部的官方文档——《企业会计准则第 6 号——无形资产》。

详情可查阅：
https://kjs.mof.gov.cn/zt/kjzzss/kuaijizhunzeshishi/200806/t20080618_46242.htm

这里面很关键的一点是，数据能作为无形资产的前提是能够为企业带来经济利益。

此外，准则中还有这么几条：

简单来说，就是你折腾各种开源组件，研究他们的最佳组合、跟进版本，研究特性，趟坑踩坑花的那些钱，在你心目中，是改进架构、是提升团队能力，但在财务眼里，那都是纯粹的成本支出。只有最终后续的业务开发中，对生产有实质价值应用的研发投入，才能转化为无形资产的组成部分，并且还有个前提是，你得证明其有用性。

看到这里，也不难理解为什么大数据团队总是被看做“成本中心”了，门槛高，前期投入高，建设周期长，集群和团队维护的成本一目了然。**而这些产生了多少经济利益，通常确实很难量化度量。**领导看不见数据的价值，只看见维护团队的代价，一旦企业进入到精打细算的阶段，那不妥妥的让你降本吗，降低集群成本不算什么，没有开“猿”节流就算客气了。

但你说这也不对呀，广告营销运营部门也花那么多钱买流量啊，况且这一点技术含量都没有，咋不让他们也降本呢。我们贵有我们的理由，毕竟难度高。

但那些部门也有个“高端”的名称，叫用户增长部门。所以，关键不在于你贵不贵，关键在于你增不增收。降本增效，降本是基本动作，增效只是个数字计算结果，如果只能增效，那降本还不得降得没边了，毕竟这么计算的话，成本越低，效率越高嘛。而且效率高了，没准还能向社会输送更多更贵的人才呢。合情合理不是。这也怪不得老板们这么想，一众人工智能新贵也琢磨着这事，跃跃欲试，想要为老板们服务呢。

所以，降本增收，才是更有前途的路径，只要投入产出的 ROI 大于 1，降本增收分分钟变成“固本增收”，“扩本增收”。这才是你说的，贵，有贵的理由，只是这个理由从来都和难度无关，只和价值有关。商业社会的逻辑，就是这么简单枯燥。

数据的价值，首先当然取决于它所在行业的内在业务价值属性。比如对于电商行业来说，消费者的行为偏好数据，显然就比集群机器的日常运行负载日志数据更有价值一些，后者可能更接近于成本开销而非资产（当然，如果你的业务就是专门给企业做运维优化的除外）。

毕竟，哪怕“无形资产”的价值评估，一定程度上得靠讲故事，但也得有合情合理的事实作为依托，这个故事才能讲得圆满和持久，而数据的业务价值属性很大程度上就是故事的起点。

在一个特定的行业领域中，你很难改变数据本身的业务价值属性，但是你可以改变数据的加工流转和应用形式，从而放大、复用，甚至挖掘之前尚未充分应用的资产价值，提升投入产出的性价比 ROI。

一个企业是否具备这样的能力，在很大程度上需要依托其大数据平台的体系建设好坏。

工欲善其事必先利其器，一个能最大化数据资产价值的数据平台，应该具备什么样的能力或者说特点呢？

按提高 ROI 投入产出的角度来简单归纳，我们可以总结枚举如下：

• 多 ： 一份投入多份产出（用更少的投入赚更多的钱）

￮ 可能包括：引擎能力能复用，数据价值能复用，链路流程能复用，人力资源能复用......

• 快 ： 今天投入明天见效（更快的赚钱）

￮ 可能包括：建设周期短，启动门槛低，数据加工流转快，业务需求响应快......

• 好 ： 干别人干不了的事（赚更有壁垒的钱）

￮ 可能包括：支持更复杂的业务场景，提供更极致的性能，处理更大规模的数据，支撑更新的应用模式......

￮ 此外，壁垒越高，数据资产的价值越高，也就衍生出对数据的安全、合规、分享、交易等方面的能力需求。

• 省 ： 省心省力省钱，减少不必要的投入（不该花的钱，坚决不花）￮ 可能包括：免运维，提高集群负载和效率，减少无效数据存储，计算成本，降低重复工作，降低试错成本，按需使用，动态扩缩容......

那么如何做到这几点呢，对于各家大数据或 BI 团队来说，公司所面对的问题和客观条件各不同，方式方法和侧重点自然也不尽相同。但我们还是可以结合业内的先进实践和产品技术理念的发展趋势，做一些普适性的探讨：

经典的大数据业务场景，通常包括：离线批处理、实时流计算、交互式 OLAP 查询等几种场景，如果进一步和在线业务 Serving 相关联，甚至可能还包括部分高并发点查询的场景。

如何实现这些场景下的各种计算、存储、人力资源和链路流程复用，一直是近几年大数据领域发展和探索的重点方向之一。

最为大家熟悉的，可能就是 Flink 主推的流批一体能力。希望通过一套计算引擎同时支持批处理和流计算两种语义（其实作为资本家，老板更希望是用同一批数据开发同学，支持两种业务场景），当然由于其实现难度也很高（不光是技术层面，也包括业务逻辑层面、计算成本层面等各方面因素），所以即使作为相关概念的主要倡导者，阿里巴巴数据中台，在其内部数据业务中，也只是在局部链路中实现了相关目标。

除流批一体之外，其实还有很多类似的探索：

• 统一开发语言，比如：SQL for every thing（Streaming，BI，AI，OPS），各种 SQL 语法糖，翻译或代理层项目，希望在接口语义层封装不同引擎，简化开发难度；
• 统一流程和数据，比如：尝试用 Kappa 架构替代 Lambda 架构，降低多链路存储计算成本；
• 统一元数据管理，比如：类似 Databricks 的 unity catalog，增强跨源数据处理能力，适应 Data and AI 融合应用；
• 各种联邦查询，外表支持，比如：通过外部数据源，外表，volume 等能力，使用同一计算引擎对接查询多种外部存储计算引擎，支持湖仓一体能力等等；
• OLAP 引擎和批处理引擎双向奔赴：OLAP 引擎引入更多的批处理特性或加强，批处理引擎也逐步增强其 OLAP 能力；
• 多场景融合引擎：除了 Flink 的流批一体，也包括最近业内开始流行的增量计算模式，用于实现离线，实时，和交互式查询的不同场景下，性能，成本和数据新鲜度之间的灵活调配。总体而言，在过去十几年，大数据各类组件层出不穷，百花齐放的同时，减少大数据平台组件数量、简化技术栈、Single Engine for ALL、一专多能等需求，也是企业在面对日趋复杂的平台体系架构，数据加工流程和高昂的运维成本代价时，必然的趋势选择。

天下武功唯快不破，赚钱也是一个讲究资本周转周期的事项。毕竟时间就是金钱，尤其是在当下高速发展的商业环境中。

一方面，从大数据引擎的角度来说，各种存储、计算速度的快固然是很重要的因素（这也是为什么会有那么多层出不穷的计算引擎，各自针对不同业务场景的原因）。

另一方面，从数据平台整体宏观能力构建的角度来看，其建设和迭代周期短，启动和维护门槛低，业务需求响应快，业务开发成本低，业务方能快速参与到数据业务的应用中来，有时候可能更为重要。

这是因为一个完善的大数据平台，除了面对各式各样的存储，计算引擎，为了更快更好更稳定地支撑业务的需求，往往还需要建设一整套完整的开发环境和数据应用管理链路，构建包括：数据集成、数据开发、任务调度、运维、数据地图、数据质量、监控告警、安全管控、数据可视化和 BI 报表分析等在内的能力。

由于其技术和业务的复杂性，同时对系统的稳定性和数据安全等各方面都有较高的要求，所以大数据平台历来都是一个前期投入高、技术门槛高、建设周期长、迭代更新成本高的系统。

国外的企业（特别是美国企业），往往依托各式各样商业公司的产品，组装串联加二次开发，混合应用来支撑业务。AWS、Azure、GCP 等公有云，也倾向于提供各类独立的组件，让客户自己组装。而国内则更多的倾向于要么完全基于开源自研，要么服务商提供完整的端到端解决方案。

一方面，是因为欧美国家 IT 发展历史更长，人才市场上，有更多成熟的软件类人才储备，企业自身通常都有比较强的产品组装能力；另一方面，也是因为同样的原因，大大小小的 SaaS 类产品更加丰富，相互之间开放合作互通的氛围也更强。

但即便是在欧美市场客户动手能力相对更强的环境下，类似 Snowflake、Databricks 这样的产品，也越来越多的开始构建生态，以便为客户提供完整的一站式产品能力体验。而其它专注于大数据完整链路上具体某个环节组件或服务的厂商，也更倾向于尽可能的对主流云平台产品的链路进行预置适配，实现开箱即用的能力，实现这类能力的厂商，往往也更容易在商业市场上取得成功。

归根到底，分工合作、尽可能采用成熟的解决方案来快速启动业务，让企业自身聚焦在数据创新开发，而非产品集成适配的踩坑与学习之中，已经成为大家的共识。

而作为大数据平台相关从业者，也需要思考自己创造的增量价值应该是以什么样的方式呈现，在不同的企业环境下，是借助成熟产品，做差异化的数据业务应用类创新更能体现价值？还是自力更生，做更好的基础平台能力重要。（这个问题当然没有绝对，就好比上云还是下云，在大趋势上云的节奏下，也有不少体量很大的公司，选择“逆潮流”下云，前提是如果能力、时间和经济效率都能搞得定的话。）

从大数据平台的角度来说，就是要将数据的价值赋能业务使用方，能别人所不能，赚别人不好赚，或者赚不到的钱。

一方面，这包括了提供更极致的处理性能，例如：向量化执行引擎、物化视图、智能缓存加速、位图计算、执行计划剪枝、下推优化、增量计算等等各类技术。

另一方面，也包括提供更大规模的数据处理能力，或更新的数据应用模式的支持，比如：能无缝线性水平扩容的能力，存算分离独立伸缩的架构，和 AI 相关能力的集成，BI/AI 数据业务链路的融合应用等等。和 Serverless 函数式计算服务对接的能力，也能极大拓展传统 BI 数据分析和在线服务，大语言模型等应用的无缝融合。

这些都是为了让原本无法在合理的成本或时间代价下完成的业务变成可能。

而**一旦数据具备了更好的业务价值，**构建起其资产属性，也就有了更多的面向内部或外部用户的开放、分享乃至交易的需求。

所以，业界领先的湖仓一体架构体系，都开始强调开放的 Open Lakehouse 设计理念。

从企业内部使用的角度来说，开放的 Open Lakehouse 湖仓架构，能够兼容主流开放的数据存储格式，支持多种外部引擎访问。降低企业数据被特定 vendor 绑定的风险的同时，减少了重复开发的工作量，避免数据孤岛的问题，提高数据生态系统的整体效率和一致性。

从价值复用，数据分享和交易的角度来说，基于开放的体系架构和统一的 Catalog 管理能力，也能更好的支持 Data Sharing 等低成本的数据分享，交易售卖体系。

比如，Snowflake 的 data sharing 技术，能够在其自身生态环境内，帮助他的用户构建起安全可控的数据交易的能力，使得数据要素的交换流通成为可能。

而 Databricks 更是期望基于 unity catalog 和 delta sharing 这样一套元数据管理和开放标准的数据分享体系，构建起一个开放的非单一 Vendor 厂商生态绑定的数据分享和交易市场。

虽然说到投入产出比，产出作为企业商业的驱动目标是关键，但投入毕竟是分母，当然也是能省则省。

这里面，既包括各种物理资源成本也包括人力成本和时间成本。既包括未来需要支付的成本，也包括过往已经投入的资产沉淀的保护。（毕竟，你不会希望自己的无形资产，一夜之间统统折旧蒸发了）。

所以，多云、混合云等能力也往往成为企业追求自身数据安全可控，避免云环境锁定、灵活按需复用多云环境资源、保护企业既有资产的诉求之一。

此外，在云环境大数据服务 Saas 化的语境之下，计算和存储引擎提供按量计费的模式，能够帮助企业减少不必要的资源浪费。配合资源秒级动态伸缩的能力，也有利于减少业务早期的成本投入，随时按照业务发展动态调整资源投入，降低前期业务启动成本。

这也是一个合格的存算分离体系结构的大数据引擎应该具备的能力和目标收益，所以这一两年来，各种传统的基于存储一体的数据库，也纷纷开始推进存算分离的架构改造。

再有，自 2023 年年初以来，越来越为大家所接受的物化视图增量计算解决方案，也是为了进一步在业务场景和数据量都不变的前提下，挖掘降本空间。在保证业务语义正确性的同时，以更低的成本，加快海量数据的实时更新和汇总计算。避免全量数据计算给系统带来了的负载压力，减少数据更新时对全量数据进行扫描带来的额外计算时间和成本。

总的来说，数据是资产负债表中的资产，还是只是现金流量表中的成本支出，大数据团队是降本增效的对象，还是增值创收的驱动引擎，这些说到底都取决于你是否把业务价值摆在了第一位，是否花最少的钱干最多的事，还能干得又快又好。数据资产入表与否只是一个结果，观察行业趋势，用正确的路径、聪明的方式，多快好省地创造价值，才是大数据团队在公司内部能挺直腰杆的底气所在。

关于作者

刘旭晖，《大数据平台基础架构指南》和《Spark 大数据处理技术》作者，现任云器科技数据平台研发负责人。在消费电子、大数据引擎、大数据开发平台，以及电商、风控、营销等行业有近二十年的数据产品从业经验。曾任阿里巴巴、51 信用卡、蘑菇街等互联网公司大数据平台和数据中台团队负责人；更早期曾就职于 Intel 开源技术中心，期间是国内 Spark、Hadoop、HBase、Flink、Alluxio 等开源项目最早的一批贡献者之一。

原文链接：数据资产入表，“降本增笑”的大数据团队怎样才能赚钱？_多云/混合云_刘旭晖_InfoQ精选文章