数据仓库原生 vs. 应用原生的收入工具

在每一次收入工具选型决策中，都存在一个几乎从未在评估过程中被明确点出的分岔口，但它却会在此后多年里持续影响所有权归属、成本结构和灵活性。这个工具是运行在你已经拥有的数据仓库之上，基于你自己拥有和控制的数据进行计算？还是运行在供应商的环境内部，把你的数据副本拉进一个你完全看不见内部情况的系统？这就是"数据仓库原生"与"应用原生"之争，也是现代收入平台参考架构中最具影响力的抉择之一。

没有哪个答案永远正确。但其中的取舍是可以预见的，理解这些取舍的评估者，往往比那些被一场演示打动的人做出更好的长期决策。

两种架构

应用原生型工具维护自己的数据存储。你连接好数据源，供应商把一份数据副本导入自己的基础设施，所有计算都在那里完成。它是一个自成一体的应用程序，拥有自己的数据库、计算能力和用户界面。大多数较老的收入工具都是这样构建的，因为这对供应商来说搭建和运维都更简单。

数据仓库原生型工具运行在你已经拥有的云数据仓库之上：Snowflake、BigQuery、Databricks、Redshift。它不是把数据复制出去，而是把逻辑推送进来，在数据本身所在的地方直接执行模型。你也会听到它被称为"data-app"或"warehouse-first"。这种模式的出现，是因为越来越多的公司已经把数据仓库作为分析层面的重心，而把数据复制出仓库之外，恰恰重新制造了数据仓库本应解决的孤岛问题。

这并非表面文章。它决定了谁掌握原始数据、谁为计算资源付费，以及你能在供应商所提供的功能之外，把系统扩展到多远。

这种取舍取决于什么

主要取决于五件事。

数据所有权。 数据仓库原生方案在你的环境中保留唯一的权威副本。应用原生方案则在供应商系统中制造出第二份副本，这份副本需要不断同步，且必然会产生偏差，这恰恰重新引入了共享数据层本应防止的数据分歧问题。

可扩展性。 采用数据仓库原生方案时，供应商输出的结果就是数据表，你可以对它们进行联表查询、扩展，用 SQL 在此基础上构建自己的模型。而应用原生方案的输出则被封闭在供应商的用户界面和 API 背后，你只能得到他们对外开放的部分，别无其他。

计算成本与掌控力。 数据仓库原生方案运行在你自己的仓库计算资源上，你可以查看、计量并调优，成本透明，且完全归你所有。应用原生方案则把计算资源打包进订阅费用中，这更简单，但也更不透明。

治理。 数据仓库原生方案继承了你在数据仓库中已经建立起来的访问控制、行级安全和审计能力。这一点的重要性远超表面听起来的程度，治理与访问控制对此有详细阐述。而应用原生方案则意味着你需要配置并维护第二套治理边界，还要设法让它与第一套保持一致。

价值实现速度。 应用原生方案通常上线更快，甚至完全不需要数据仓库。对于数据基础设施尚不成熟的团队来说，这是一个实实在在的优势。数据仓库原生方案则默认你已经在能力上熟练运营着一个数据仓库，如果并非如此，它只是把你原本无法承受的复杂性转移了位置而已。

因此，数据仓库原生方案是用便利性换取掌控力和可扩展性；应用原生方案则是用掌控力换取简单性和速度。

什么情况下该选哪一种

以下情况适合应用原生方案：你没有成熟的数据仓库或运维团队；你希望快速实现价值，并且能接受供应商在这个用例上掌控数据层；或者这个用例本身是自成一体的，你并不打算在这个工具的输出结果上做进一步开发。

以下情况适合数据仓库原生方案：数据仓库已经是你的唯一可信数据源，你希望收入工具强化这一点，而不是使其进一步分裂；可扩展性很重要，因为你希望把输出结果与其他数据联接起来，或者把它们输入到你自己的模型中；数据驻留、治理或安全方面的要求，使得把数据复制到供应商的云端成本高昂甚至根本不被允许；以及你从长远角度考虑，希望避免在数据层被供应商锁定。

我们常用的经验法则是：数据仓库在公司整体运营中越是处于核心地位，选择数据仓库原生方案的理由就越充分。把数据从一个你已经投入大量资源的仓库中复制出去，无论工具的演示看起来多么亮眼，都是一种倒退。

大多数真实架构其实是混合型的

在实际场景中，这条界限往往是模糊的，最好的架构设置常常两者兼顾。一个平台可能会把繁重的建模工作以数据仓库原生的方式完成——在数据所在之处直接计算归因和评分，同时提供一个应用层来处理工作流、激活，以及负责把结果路由回人们日常工作系统中的写回层。这样一来，你在数据密集型部分获得了数据仓库原生的所有权和可扩展性，又在工作流部分获得了类应用的易用性。

无论供应商的营销话术怎么说，都要追问三个问题。我的原始数据究竟物理存放和计算在哪里？如果诚实的答案是"我们云端的一份副本"，那么无论宣传册怎么写，你实际上用的都是应用原生方案。我能否把你的输出结果作为我可控的数据获取，还是只能通过你的用户界面和 API？以及是谁的治理边界在负责执行这些数据的访问控制？

直截了当的答案会揭示真实的架构。在此基础上，最终的选择取决于你的数据成熟度、你需要在多大程度上扩展这个系统，以及你有多看重掌握数据层。这些同样的答案，也决定了一个API 优先的平台能否真正有效地扩展你所购买的产品。

关键要点

• 应用原生方案把你的数据复制到供应商的环境中并在那里计算；数据仓库原生方案则在你已经拥有的数据仓库上直接计算。
• 这种取舍一端是掌控力和可扩展性，另一端是简单性和速度。
• 没有成熟的数据仓库，或者用例本身自成一体？选应用原生。数据仓库是你的唯一可信数据源，或者治理很重要？选数据仓库原生。
• 最强大的架构设置通常是混合型的：数据仓库原生的建模能力，搭配用于工作流和写回的应用层。
• 三个问题足以看穿营销话术：数据存放在哪里，我能否把输出结果作为数据获取，以及适用的是谁的治理规则。

了解这个分岔口，能让你从架构而非演示效果的角度去评判收入工具，Revnewo 这样的平台也理应接受同样这三个问题的检验。如果你的数据仓库已经处于核心地位，那就仔细权衡任何新工具是尊重这项投资，还是会使其进一步分裂。