什么是数据平台——企业构建Data+AI的基础数据底座需要的决策参考

什么是数据平台

标准的解释是这样的

Wikipedia
A data platform usually refers to a software platform used for collecting and managing data, and acting as a data delivery point for application and reporting software.

数据平台是指将各类数据进行整合、存储、处理和分析的技术平台，旨在基于数据为业务提供各类服务、产生业务价值。数据平台可以从不同的数据源中获取数据，并将数据进行清洗、融合和转换，最终提供给分析师、决策者和应用开发者等各类用户使用。

大数据平台，是数据平台在大数据时代的概念衍生，其功能宽度和包含的要素要胜于传统的数据平台，是能处理海量数据存储、计算，支持离线批处理分析、交互式查询、流数据实时计算等多类负载场景的技术堆栈，通常包括数据采集、数据存储、数据计算、调度运维、数据治理和数据应用等主要核心功能。

非官方的解释，我有一个更简明的定义：

“数据平台是尽可能高效地利用存储和计算资源（用最少资源），处理和分析海量且多样数据的技术底座”

数据平台的价值

介绍数据平台价值的文字很多，通常会提到数据平台可以存储海量信息，处理、分析并转化这些数据为分析洞察等等。不过结合笔者在过去十几年的数据分析和使用平台的经验，还是讲三点有特别价值的点。

大数据平台是创新的孵化器

以智能汽车和工业互联网场景为例，据车百智库2024年的行业分析报告，一辆L4自动驾驶的智能网联汽车，每日通过车内外传感器采集的行驶数据、环境数据和行为数据等，已达到10TB的量级，是传统汽车的5-10倍。根据最新预计，在路上行驶的智能汽车每年上传到云端的数据超过70000PB。在20年前，也就是2000年前后，互联网最蓬勃发展时期全球互联网的数据总量是1000PB。也就是如今仅智能汽车机器产生的数据就是20年前整个互联网数据的70倍。如今进入大数据时代，我们越来越清晰的看到，数据规模的几何倍增长衍生产生的数据价值，以及需要更创新更智能分析数据的方式。

举3个过去10年已经成为现实的数据创新的例子：

城市交通管理：
许多城市利用数据平台来优化交通流量，通过分析来自交通信号、车辆传感器、公共交通系统的数据，数据平台能够预测交通拥堵并调整信号灯周期，甚至引导驾驶者选择最佳路线。这种智能交通系统的创新减少了拥堵，提高了城市交通运行效率
电商如亚马逊的动态定价策略：
亚马逊的数据平台能够实时分析市场需求、库存水平、竞争对手定价等信息，以此来调整产品价格。这种动态定价策略帮助亚马逊最大化利润，同时保持市场竞争力。数据平台在这里起到了创新策略的试验场和实施者的角色。
内容和电商平台的动态推荐系统：
数据平台收集了用户的观看历史、评分、搜索习惯等数据，并利用复杂的算法为用户推荐电影和电视剧。这种个性化体验不仅提高了用户满意度，也增加了用户粘性。抖音、小红书、电商如阿里、京东、海外如Netflix的平台都有类似的推荐设置。通过不断迭代更新，使得推荐系统越来越精准。

还有更多的案例，这里不再一一列举。简言之，笔者认为基于数据和智能AI的创新是帮助企业从激烈的竞争中走出差异化的道路的有效手段。

数据平台促进非技术团队的分析能力

通过提供易于使用的工具，数据分析不再是数据分析师和科学家的专属领域。非技术团队如市场、运营、财务甚至产品研发等，传统上依赖BI团队和数据开发运维团队支持，可自己上手用更直观的方式进行数据分析，这得益于数据平台的不断演进，包括采用如数据可视化的操作面板，元数据和数据资产管理平台，免运维的SQL运行环境，更安全的数据管理机制，也包括自然语言支持的数据分析能力逐步成熟。总的说，数据平台凝结了技术普惠的结晶，一整套提供给组织使用，大幅降低了门槛，提升组织的数据能力。

图1：提升企业内数据使用员工比例

优化资源分配与成本控制

在成本控制方面，讲究的是数据新鲜度和成本平衡。例如处理高新鲜度的流式数据，通过flink和kafka的组合，由于流数据要保持常驻的计算节点，通常会有比较高的成本，而且如果考虑后续的分析加工链路也需要实时，整体方案的成本会比较高。如何无极调节数据新鲜度和成本的平衡，是一个数据平台需要具备的能力。

新的解法有包括更统一的引擎架构，例如下一代数据平台数据引擎可以用增量计算技术实现数据的微批处理和增量存储。此外更智能的引擎也可以通过AI识别和学习适合合并数据和计算任务，进行增量而非全量处理流程、或通过优化数据存储方案，减少重复冗余的数据存储降低成本。具有AI加持的数据平台可以通过多种自动化方式减少手动处理需求，从而降低成本并提高效率。

图2：无极调速的数据平台大幅提升运行效率概念图

定义数据平台功能的组成，分别解决什么问题

通常一个数据平台有如下功能模块（熟悉这个领域的朋友可以略过）包括：

1.数据集成同步

将来自不同数据源的数据整合到一起形成一个统一的数据集的过程，涉及数据收集、清洗、转换、重构和整合，以便在统一的数据仓库或数据湖中进行存储和管理，包括离线同步和实时同步。

图3：典型数据集成

2.数据的批处理

数据的批处理是数据最通常的处理方式，将数据集合按照上下游关系安排任务顺序，分批次进行处理，以处理海量数据，是一种最大化处理数据规模，最大化节省资源的数据处理方式。

3.流数据的处理

是实时处理和分析连续生成的数据流的过程。流数据的处理通过跟踪和存储有状态算子的中间计算结果，支持有状态的计算和容错性，具有低延迟和高吞吐量的特点，适用于实时数据处理场景，如网络监控、推荐系统和物联网数据分析等场景。

4.交互式分析

数据分析师使用例如SQL/Python/R等数据分析语言，或通过可视化工具对数据进行实时的查询，聚类，汇总等分析，得出分析结果并支持企业或组织采取决策或行动。交互式分析有低延迟高并发的特点，以更好支持分析师对实时性及临时性（ad-hoc）和交互性的使用体验。

5.任务开发调度和运维监控

通过数据开发界面，使用类似SQL等通用的描述性数据分析语言，对数据进行抽取(Extract)、转换(Transform)和装入(Load)的步骤，或进行ML/数据科学研究，进行数据分析的模块。

通过对系统内所有数据库资源进行统一管理和监控，采集监控数据，并根据预警规则进行判定，以及采取相应的预警或自动化处理措施，确保系统的稳定性和性能。

图4：数据目录监控数据血缘

6.数据资产管理

狭义上是对数据本身的创建、存储、加工和控制的一整套流程，旨在帮助用户快速理解数据的上下游关系及其含义，精准定位所需数据，减少数据研究时间成本，提高效率。进一步，现代的数据资产管理，旨在提供企业对数据资产进行规划、控制和供给数据的方式。例如确保数据的安全前提下的跨组织共享；例如有严格权限管控的数据报表，确保核心数据保密；例如同一个报表，不同人看有不同的报表层级——区域只能看到区域的数据，总部能纵览全局，等数据权限控制机制。

把组件组装在一起，就可以了么？

一个建设大数据平台的最朴素的想法就是把上述的组件组合在一起，构成企业能用的平台。MDS（Modern Data Stack）就是这样的数据架构理念，它强调组件之间的解耦与模块化，组合实现不同工具和服务的集成。

MDS理念和反思

Tristan Handy，dbt的CEO，最先在2020年下半年的Future Data会议上提出了“Modern Data Stack”（MDS）这一概念，既由众多模块化功能组合而成的数据技术栈，并在dbt Labs的博客上发表了相关文章。

图5：Modern Data Stack（MDS）

业界对MDS的讨论

Modern Data Stack(MDS)概念的提出者 Tristan Handy在2024年2月的文章中也表达了他最新的思考，文章的标题就是“Is the 'Modern Data Stack' still a useful idea?"。当一个概念的提出者都发出这样的疑问，我们就应该引起重视了。感兴趣的朋友可以参看这篇文章：《Is the "Modern Data Stack" Still a Useful Idea?》

Tristan Handy

Finally, as a result of all of this pressure on data spend, buyers developed a strong preference to buy integrated solutions rather than to buy many tools to construct a stack. Buyer willingness to construct a stack from 8-12 vendors has declined significantly. Companies are much more likely today to expect to buy 2-4 products as the core of their analytics infrastructure.

Handy的观察是“（随着经济大环境的改变），来自成本的压力逐级传导到数据团队和架构选择上，客户越来越倾向于购买整合一体的产品。而组合8-12个厂商的技术栈方案，已不太受买家青睐，采用的意愿度大幅下降...”

此外，Ternary Data的创始人兼CEO，畅销书《数据工程基础》的联合作者Joe Reis，与Matt Housley共同讨论了Modern Data Stack的未来，并在他们的线上书中提到了“现代数据栈”MDS这一概念的消亡。文章的标题甚至更直接“Everything Ends - My Journey with modern data stack” ，直译文章标题《一切都结束了——我的MDS历程》：Everything Ends - My Journey With the Modern Data Stack

文中的观点也是对现代数据技术栈的反思，讲到由于多种数据工具的大量产生使得人们的关注点不再是基础和原理，而是简单的实践，重视工具的使用技巧而不是工具背后的原理。导致数据技术栈的发展缺乏创新。

Joe Reis也很不留情面的讲出，“MDS组件确为客户提供了‘丰富’的工具，让企业的数据团队有了成吨的‘问题’要解决——然而对企业本身无实际附加价值。”

Joe Reis

I feel like the MDS made it easy for the data industry to go backward, allowing data teams to have a ton of convenient tooling while adding questionable value to their organization.

大部分使用开源工具的企业或者组织，买台机器并下载开源数据工具使用，并不会对代码和项目做定制化开发和长期的投入，仅仅是使用基础能力。这样的方式既没有发挥出开源软件的工具的100%潜力，也没有真正的降低成本。

笔者的观察是，一方面数据架构过于复杂，如果并非对极致的场景的特殊组件有强要求，可以考虑更一体化的整套商业化产品。这一点Joe Reis说的情况看来是在国内海外差异不大，毕竟改造开源代码做企业的本地化适配，是只有少数几个大厂才投得起的事。要看企业规模来决定是不是采用大量开源组装的方案。有能力使用开源并基于开源做定制开发以更好的做到数据创新，才是开源组件的正确打开方式。然而这种级别的投入，也只有少数几个大厂能够想想，在如今的创业环境中这样的投入不一定经济。

数据架构的演进

参考A16Z-Andreessen Horowitz在2023年更新总结现代数据架构全景图，包括离线、实时以及数据湖，数据仓库，ML/AI等多个领域统一数据架构。图中每一个灰色框代表一个专门的领域模块，通常有多个类似的产品提供相似的功能。

图6：A16Z 2023 现代数据架构全景图

在具体的场景中选择适合的产品，例如我们可以在Spark/Trino/Impala/Doris等产品中做选择，如果看中多样性可能选择Spark对接Hive，如果对高并发和时效性有要求会选择Trino/Impala等。在不同的场景中选择各有优势的产品，还包括用Yarn统一管理资源等等。

这个思路就是我们常说的Lambda架构，Lambda架构是一种用于处理大数据的架构模式，通常至少是将数据处理分为两个明确的层次：批处理层（Batch Layer）和流处理层（Speed Layer）。Lambda架构的目的是同时兼顾数据处理的准确性和实时性，通过这两个层次的结合，能够有效处理和分析大规模数据集。同理，组合结构化数据所需的数据仓库和非结构化数据的数据湖，等等组装的方式来实现一个基础的数据平台。有过统计，如果需要完成基本的数据平台，会需要至少10余个组件拼装完成。这是一个比较复杂且有挑战的过程。

Lambda架构

实践上，以下是几个不同场景不同用户的数据架构实例，可以作为参考理解数据平台的典型架构：

图7：目前典型的大数据系统架构案例

Lambda架构受诟病的原因，还在于数据处理需要分为两个路径：一个是批处理路径，用于处理大量历史数据；另一个是流处理路径，用于处理实时数据。

图8：Lambda架构数据处理流程

这两个路径在处理逻辑上往往有所重叠，但是需要分别维护，这就增加了系统的复杂性和开发成本。此外数据湖和仓难统一，也有格式不开放，冗余数据的诸多问题。

Kappa架构是什么

Kappa架构的设计理念是简化实时大数据系统的复杂性。

与Lambda架构不同，Kappa架构提出了一个更为简洁的解决方案。在Kappa架构中，所有数据——无论是实时的还是历史的——都被同一套处理引擎进行处理，无论是实时分析还是批量处理，都使用相同的处理逻辑，从而简化了系统设计，减少了冗余，并使得系统维护和扩展变得更加容易。

简单来说，如果把Lambda架构比作一家餐厅里分开运作的快餐窗口（流处理）和正餐区（批处理），那么Kappa架构就像是一个将所有顾客都通过同一个窗口服务的快餐店。这样做的好处是，餐厅的工作人员只需要掌握一套服务流程，无论是面对想要快速吃完走人的顾客，还是想要慢慢享用的顾客，服务的效率和质量都能得到保证。

一体化架构有统一的引擎，支持实时、离线和交互分析，避免了数据冗余、多条链路等问题。下图是举例一个典型的在Kappa架构的数据分析架构，支持多种不同的任务负载，共享资源池，可弹性伸缩并有统一存储等特点。

图9：一体化架构使用示意图

总结数据平台必备的组件和要素

总结一下现在的数据平台——不再只是单一功能的大数据库，有处理批和流以及实时分析等多种负载的引擎能力，有整体的支持非结构化数据和结构化数据的管理机制，有更多有机组合的管控能力。数据平台也不再是几个组件的简单集合。

数据平台应该具备如下六个关键要素：

稳定：数据平台需稳定运行，直接支撑业务运营。保证数据处理及时准确，遵循“可监控，可灰度，可回滚”原则。关键在于可观测性，确保任务运行、版本控制、监控、告警、运维等功能齐全。
经济：存储和计算的高效对于成本的节约至关重要。存储格式，压缩率、文件的读写性能，单位算力处理数据的性能，一直是基础平台层持续优化追求的目标。在性能上的比拼，是数据平台在稳定性之外的主要考量要素。
多样：数据平台需要能够支持多样的数据处理模式，比如离线批处理、交互式查询分析、流计算和实时处理等。传统的方式通过组装不同的计算引擎来满足，但业界也开始出现基于Single Engine来满足不同作业负载的新的趋势。
安全：数据平台需要能提供体系化的安全管控能力，诸如统一的数据权限管理、存储加密、数据脱敏、风险识别，以及满足安全合规要求等
开放：数据平台可以与其他产品进行对接，尤其是存储、计算引擎的开放性；数据平台自身也要易于扩展增加新的组件。
易用：数据平台在操作层面的易用性容易被忽视、但对数据平台的成功应用至关重要。数据平台需要综合考量不同的用户群体，比如数仓ELT工程师、数据分析师、业务运营人员等，在专业技能和使用习惯上的差异性，用户使用体验。从平台建设视角看，仅面向技术同学、单纯以技术视角来构建数据平台产品是大忌，会严重影响平台的推广使用。数据平台效率为本、业务价值优先。

开篇曾谈到数据平台的定义，“数据平台是指用最少资源，处理和分析海量且多样数据的技术平台”。我认为这个定义足够简洁抽象地概括了数据平台的核心价值——通过整合和统一为企业和组织提升数据分析效率。

此外关于数据平台的发展趋势，如果您想深入了解演进过程和发展趋势，我重磅推荐这篇文章《AI风暴来袭：2024年数据平台的演进、挑战与机遇》，对数据平台的演进过程和方向做了很好的梳理。

如何选择数据平台

1.明确企业或组织对数据平台的需求

并非所有企业的数据需求都是相同的。根据企业的成熟度、业务目标和技术能力，我们可以将企业对数据平台的需求分为五个级别，从基础的数据收集和存储到高级的数据智能和预测性分析，每一级别都代表了企业在数据应用深度和复杂度上的逐级上升。

图10：数据分析5级智能分层模型

如图所示的企业数据智能化的5级分层模型，代表企业对数据的分析能力和智能化能力，从L1到L5逐步升级向上，层级越高智能化能力越强，也需要更完备的数据平台能力支撑。这里建议重点关注两个关键跨越——分别出现在向L2级和L4级的跨越上。

第一个关键跨越是由第1级台阶迈向第2级台阶的过程，为什么这一个跨越很重要，因为这是真正进入大数据分析的分水岭——考虑到数据量的快速增加，CTO必须要考虑数据平台的成本和效率问题。相对的，第一级台阶基于对小量数据，依靠内存计算和MPP高并发低延迟的计算已经逐渐成为数据分析的统一标准，很容易给用户带来“甜区”效应。问题就在于当数据量快速扩大时，组织往往会发现很难一边对接更多的多个组件，保证数据分析规模平滑扩展，一边控制成本：总系统复杂度和维护成本陡然上升。

第二个关键跨越是由第3级迈向第4级的过程中，为什么它重要，有两个原因，其一是外部环境的剧变，AI时代下应该考虑数据资产如何能够更好地和AI结合，结合数据和AI的能力。其二是数据生态的内耗阻力让CTO重新思考寻找开放的数据格式和数据湖仓方案。传统的方案数据格式在多种负载中不统一，在数据传统的数据湖不具备状态存储，而实时链路又需要带状态的存储。挑战在于此时企业已经有了非常大的数据规模，方案的调整和迁移成本都会相对更高。所以这级跨越也对组织来说非常具有挑战，需要提前规划长效的升级方案。

2.选择“云上”或“云下On-Premise”

图11：云下 vs 云上

近期“下云”话题炒得火热，特别是在马斯克推动Twitter全力“下云”之后，这一讨论达到了高潮。所谓“下云”，指的是企业从依赖云计算服务商提供的云服务，转而采用自建数据中心或其他本地解决方案来处理和存储数据。据评估这个决策可以为Twitter节省60%的成本。对头部巨型企业而言，这个成本节省是非常有吸引力的。有一个数据可以参考，据评估苹果公司每月在亚马逊云计算上的支出就超过了3000万美元。

安全考虑，对于对数据安全性和隐私有严格要求的企业来说，On-Premise部署提供了让数据管理者放下顾虑的方式。企业可以直接控制物理服务器和网络环境，实施自定义的安全策略，减少数据泄露和未经授权访问的风险。

自建服务器部署的另一个考虑是企业想实现“可控”。企业将拥有对数据库系统的完全控制权，包括硬件选择、配置设置、数据管理和安全性控制。此外，企业会拒绝接受云厂商提供的一系列服务，不想被锁定了软件生态，不想被“绑定”。

优点
- 安全因素
- 自主可控，不会被云厂商绑定
缺点
- 需要庞大的专业的技术团队
- 数据规模和计算规模缺乏弹性

On-Premise部署的缺点也是很明显，首先需要庞大的专业的技术团队，这就决定了必须要有足够大规模的计算集群，这样做才值得。其次，选择OP部署相当于放弃了云的弹性能力，扩缩容将变得复杂，需要一系列流程和操作。

笔者认为现在已经有越来越多的PaaS层产品/开源生态方案，支持在多云环境部署，也是一种解除软件生态绑定的方式。另外On-Premise要考虑数据备份问题，异地灾备也并不简单。对于大中型企业，数据安全的担忧永远是相对于成本和性能做综合考虑，根据企业自身情况安排适合的方式。举个例子，您会选择把钱放在家里的保险箱，还是存在银行？数据的上云或下云也是类似的选择。

相应的在云环境搭建数据平台是有它的优势，首先是计算资源和存储资源的弹性伸缩能力，云资源池提供了近乎无限的可能性，而企业不用关心如何采购服务器的和软件运行环境，运维扩缩容等问题。云计算契合增长型企业对数据平台的诉求：全面、灵活且易扩展。

3.选择“全托管”的数据平台，或自建

自建企业数据平台允许企业根据目前的需求定制其数据处理、存储和分析的组件，例如目前不需要流数据的处理那就可以先不考虑流计算，如果暂时没有大规模数据要求，例如可以用2台机器先运行起来开源软件做分析。这种方法为企业提供了灵活性和控制权，使企业能够调整数据架构以优化性能和效率。然而灵活和控制权的代价是显著的初期投资，包括硬件、软件许可以及招募和培养专业人员的成本。开源数据平台的运行离不开持续的维护和升级成本，如前文所述，组装本身有系统复杂和冗余链路的诸多问题。

优点
- 灵活和可扩展性的控制权
- 如果选择开源自建则软件本身是“免费”的
- 如果能参与开源社区，或在此基础上做定制开发，可以在特定场景专项优化
缺点
- 初始成本和维护成本难控制
- 技术复杂度，系统复杂度有挑战
- 维护成本高

全托管的一体化数据平台为企业提供了一个无需担心硬件和软件维护的解决方案，使得企业能够更加专注于其核心业务。这些平台通常易于部署和使用，能够快速适应企业需求的变化。由于成本大多是基于订阅的，企业可以更容易地预测和管理其数据管理成本。然而，选择全托管的SaaS解决方案也意味着企业可能会面临一定程度的功能限制，以及对供应商的依赖增加。

优点
- 快速部署和易于使用，一体化综合性能优异
- 直接获得成熟的大数据infra架构
- 成本可预测，线性可控，免运维减轻内部负担
- 多云环境的数据平台也兼具灵活
缺点
- 平台有一整套组件，有一定的适应使用和学习门槛

在考虑是否自建企业数据平台或选择全托管的SaaS模式数据平台时，关键在于评估您的企业情况。自建数据平台提供了高度的定制性和对数据控制的优势，适合那些对数据安全有着严格要求，且愿意投入初期成本和资源进行长期投资的企业。企业选择开源自建如果不能做到深度参与开源，或基于开源框架做一些定制改造，实际上与使用整套方案无异。采用整套一体化方案适合专注在业务创新的企业，希望减轻管理负担，快速启动，并优先考虑成本效益。这种全托管的SaaS模式的数据平台可能是这类企业更合适的选择。

决策建议

评估业务需求和目标：明确您的数据处理需求、安全标准以及长短期业务目标。

考虑资源和能力：评估您的内部资源和技术能力，确定是否有能力自行建设和维护数据平台。
成本效益分析：进行详细的成本效益分析，包括初期投资、长期维护成本以及潜在的业务价值。
最后，无论选择哪种路径，都应保持灵活性，随着企业发展和市场变化调整数据战略。技术的迅速发展意味着今天的最佳选择可能需要在未来重新评估。持续的技术评估和战略调整将是企业成功利用数据的关键。

通过深入分析和适时的决策，企业可以选择最适合其特定需求和目标的数据平台解决方案，最大化数据的潜在价值，从而在竞争中保持优势。

几个关键问题：