从数据库软件诞生之日起，财务领域就是数据库最为重要的场景。从关注财务的数据一致性、安全性开始，数据库技术不断进化；现在，人们又越来越关心如何从纷繁复杂的财务数据更深度的挖掘价值，数据库技术在财务领域进化的技术焦点，转向了海量、高速、实时、精细、多维。

要满足财务领域的新要求，无论是财务软件厂商还是数据库厂商，都意识到这绝不是简单的性能问题，对于数据库，更需要功能、架构上的创新。

从“望远镜”到“全息投影” - 财务分析精细化

过去几年，我们的合作伙伴作为财务领域的领军企业，不断进行创新，致力于通过提升财务分析的精细程度，帮助企业从数据中不断挖掘价值，提升企业的经营效率。

过去，财务分析如同使用望远镜，只能观测宏观数据——事业部的整体利润、季度的营收增长、产品线的毛利率水平。这些汇总后的数字虽然能反映经营概况，却掩盖了细节中的关键信号。

如今，随着企业对数据驱动决策的需求升级，财务分析正经历一场“显微镜式”的精细化变革。从“整体”到“局部”，从“汇总”到“分解”，从“滞后”到“实时”，财务数据的颗粒度被不断细化：

这一趋势的背后，是数据技术的进步与管理思维的进化 - 企业不再满足于“发生了什么”，而是需要知道“为何发生”以及“如何优化”。财务分析的精细化，正在让数据从“后视镜”变成“导航仪”，从“总结工具”升级为“决策引擎”。

1. 传统会计：做“财务素描”

只记录“结果”（收入100万/费用50万）

像用黑白相机拍静物照

案例：超市月末报表显示"促销费用30万"

2. 事项会计：拍“全息视频”

记录"业务事件+多维属性"

像用VR摄像机记录全过程

案例：记录"9月16日10:00门店A鸡蛋促销→吸引62岁王女士购买→连带销售食用油和纸巾"

当业务提问从"上季度整体毛利多少"变成"昨天A店面的一款新品此刻的真实盈利"，传统财务系统就像用望远镜观察细菌。

过去，一笔交易会被汇总到各个不同的维度、口径，而这个汇集的过程，在数据层面，是信息量衰减 - 在汇聚之后，可能你只能看见一个部门统计、一个月的统计、一款产品的统计，而不能自由的看到更为精细的粒度：一次促销，一批产品，一场直播的数据。

相较传统的财务分析方式，现在这种更为精细的分析需求，要求我们把同一笔交易能同时映射到多维度、多口径、多时态的分析视角，打个形象的比方，我们要对数据进行“全息投影” - 将一条数据，映射到越来越多的维度上。

手脚并用跑高速 - 数据库面对的挑战

当我们用SQL查询实现这类分析时，往往会遭遇：

• 维度爆炸：数百个分析维度组合导致查询复杂度呈指数级增长

• 性能悬崖：多表JOIN操作让响应时间从秒级恶化到小时级

• 资源黑洞：一个复杂查询就可能耗尽整个数据库集群资源

-- 简单查询：0.01秒
SELECT SUM(amount) FROM sales;

-- 精细查询：47分钟（然后超时）
SELECT 城市,渠道,产品类型... 
FROM 销售表 JOIN 库存表 JOIN 用户表...
WHERE 活动ID='618' 
GROUP BY 城市,渠道,产品类型...（还有20个维度）

无论 SQL 的功能多么强大，数据库的性能总是有限的。所以这种“全息投影”式的需求，在现实世界中，是无法仅仅依靠复杂 SQL 查询实现的。这是数据库需要根据使用场景进行建模、设计的事实基础。

为了让这种多维的，复杂分析得以真正具备可用性，交易数据本身，就需要用投影的方式进行建模。通过在使用前，提前对各个维度的账簿，统计口径进行统计计算，保存在数据库中，用空间换时间，从而提供使用时能够满足日常需求的分析体验。

虽然我们可以通过这种建模方式，实现多维度、多口径、多时态的分析视角，然而在这种现代的先进财务产品的实际构建过程中，从数据基础设施层面，很多高难度的挑战难以避免：

挑战1： 数据量

过去，财务数据随着越来越接近最终呈现出的报表，数据量会不断减少；而现在，由于维度变多，实际一条数据进入下一维度，数据量反而会增加数倍。我们在一个全国有数千家门店的零售业客户的实际案例中，清晰的看到由于分析粒度的提升，带来的数据量的指数级放大。

数据量的放大，意味着整个数据加工的过程对数据库性能、处理大数据的能力的更高要求。一般的数仓系统中，在晚上非交易时段内必须要完成当日所有数据的导入与加工。一旦性能不达标导致数据库不能在固定时段处理完所有数据，就会导致次日分析结果不可用。而更大运算量，也对数据库的稳定性提出了更高的要求，一旦查询中断，可能会导致大量任务重跑。

某国内领先零售企业数据量

挑战2： 复杂度

由于存在多级、多维度的数据“投影”，也就意味这投影过程必将带来大量的数据加工过程。通常来说，传统的数仓架构会选择 T+1 的方式，在晚间，业务低谷时执行主要的加工过程。更高的复杂度，意味整个加工过程的不可控性，大大增加。一个任务卡住了，慢了，都会影响下一层加工任务的执行，各个环节组合下来，整个加工过程的可靠性，可预测性，相比简单的数据加工过程，都会大打折扣。要准确、合理、高效的进行调度，本身对财务软件的设计研发，也是巨大的挑战。

挑战3： 实时性

在传统的 T+1 数仓的架构下，实时性是无法保证的。为了实现"实时"分析的能力，业内一般会引入Spark, Flink等工具构建实时处理的链路。在晚上 T+1 的数据加工结果的基础上，白天业务发生一笔，这条数据会进入Flink这样的实时处理链路，完成对数仓内存储的各个维度当日统计数据的实时更新，从而实现“实时分析”。虽然，这种架构能够大大提升整个系统的实时性，然而却使得整个系统的复杂度大大增加。原来 T+1 处理的逻辑，需要在 Flink 为核心的实时链路中重新维护一套，复杂度增加超过一倍,而整个系统稳定性、可维护性的降低，可就不止100%了。实时虽好，但是是否值得，如何在实时性和整个架构的可靠性中取得平衡，成为一个难题。

挑战4：UPDATE/DELTE 刺客

作为财务系统，不可避免的需要解决账目出错的问题。一笔开销，可能因为种种原因写错了需要修正，都是无避免的。看似正常的需求，却对我们所谈到的“全息投影”式的财务系统，带来了巨大的挑战。一个账目的修改，删除，意味着他对应的所有账簿都需要进行相应的调整，而基于这些账簿的统计口径，也需要进行调整。如果我们再叠加上上面所说的实时链路，复杂度何止翻倍！我们的合作伙伴，曾经因为类似的问题，在程序中开发了数百个数据库的触发器，就是为了处理这些"刺客"逻辑。

新技术，新架构 - 基于 Domino 流计算引擎的流批一体架构

面对这种全新的财务分析模式，在过去1年多时间中，我们与合作伙伴的进行了深度合作。除了传统的性能、稳定性方面的基础能力，更基于财务分析精细化、实时化的要求，开发了关键特性 - Domino库内流计算引擎，最终实现了数据库内真正的流批一天架构，实现了实时财务数据加工全流程不出库。

Domino 流计算引擎允许用户定义一个流表，实现上游数据写入，下游自动刷新，从而实现“实时流”的功能；同时，流表也像一般的表一样，能够使用 SQL 进行各类查询，没有任何限制。

原本从一笔交易，到多个账簿、统计口径的映射是通过 T+1 的数据加工和 Flink 主导的库外实时加工链路构成的，现在，全部简化成了用 SQL 定义的流表。

1. 实时：上游交易发生，在数据产生之后，数据库会自动触发下游账簿更新，账簿更新又触发下一层统计报表的实时更新，实现了整个加工过程的"实时化"。

2. 增量：而这个加工的过程，完全是增量的。传统的数据加工过程中，经常一条数据的更新意味着需要重算。以简单的按月统计总销售额为例，今天新的交易数据插入，那么今晚统计时，就要把这个月的所有交易再重新累加一次。这本身意味着大量的运算被重复进行，如果晚上要执行的加工任务多，复杂度高，就以为着这些重算会浪费大量计算资源。而我们 Domino 流引擎，实现的是“增量”计算，一条新交易发生后，报表中保存的总销售额实时多加了一笔，无需再把涉及的数据重算，这就大大提升了运算效率。

3. 简洁：由于整个加工过程完全基于数据实现，原来 Flink 主导的库外流链路也就不再需要了，开发、维护都只需关注数据库内唯一的链路，整个系统的复杂度大大降低，从而提升的系统的稳定性，可维护性，也降低的软硬件成本

4. 智能：用我们的 Domino 流引擎定义的流表，不但支持INSERT这样最普通的操作，对与UPDATE,DELETE 也同样支持。一个账目的修改，对应的账簿，统计报表也会自动更新，而这些操作，都是由数据库实时、增量、自动的执行的。在产品实际使用过程中，仅触发器一项，我们的合作伙伴就删除了300多个。

写在最后

这场从"望远镜"到"电子显微镜"的进化，是在重财务的价值重新定义，也是一场财务分析的革命。要驱动这场革命，让他从理念变成被各种企业广泛使用的产品，不但需要重构财务产品，也需要数据库产品的助力。

过去一年多时间中，我们与合作伙伴一起，针对财务场景进行了联合研发。我们的伙伴为我们提供了大量真实的财务应用场景，使得我们作为一家专注于数据库的企业对财务这一关键领域，有了相较其他友商更为深刻的理解。这也使得我们基于对行业趋势判与长期技术积累创新研发的 Domino 流计算引擎，从诞生之日起，就找到了特别适用的真实场景。经过一年多的联合研发和打磨，我们和伙伴一起，已经将 Domino 流计算引擎与伙伴领先的财务产品深度融合，落地多家行业龙头企业，而我们联合方案的产品的功能先进性、架构先进性、性能先进性也得到了客户的广泛认可。

当产品已经开上高速公路，底层的数据库不能再骑自行车追赶。YMatrix 提供的 Domino 流计算引擎，就是我们让数据库赶上财务产品变革的“秘密武器”。