2021年底，大数据领域最“吸睛”的事件莫过于Databricks和Snowflake关于TPC-DS测试结果的“恩怨情仇”了。

2021年11月，Databricks发布了《Databricks Sets Official Data Warehousing Performance Record》一文，在体现Databricks数仓高性能的同时，矛头直指云数仓“当红炸子鸡”Snowflake，双方随即在就TPC-DS测试结果展开争论，数据湖与数据仓库在跑分竞赛中狭路相逢。

事实上，作为大数据分析赛道的代表性厂商，不论是具备数据仓库功能的数据湖工具Databricks，还是借鉴数据湖范式的可扩展数据仓库Snowflakes，其发展路线都说明“湖仓一体化”已成为了目前市场主流的技术发展方向。

从一笔银行转账谈起

如果单单提到“湖仓一体化”，对大数据分析技术不那么了解的读者来说感受可能并不真切。那么我们就从最贴近生活的银行转账场景谈起。

在用户通过银行向某个特点商家完成线上交易转账的背后，银行在数据层面需要经过怎样的流程呢？

首先，几乎在用户转账行为的同时，为了更好保障用户转账资金的安全性，银行需要将本次用户转账的时间、金额、位置等数据进行加工，形成衍生特征提供给反欺诈应用系统并迅速完成对交易性质的判断，若转账存在欺诈风险则需要及时完成预警与交易阻断。在这个流程中，就需要银行对数据进行实时流处理。当大量用户转账行为同时发生时，伴随着大量数据的同时涌入，如何分配计算和存储资源以保障流处理的及时性是考验数据分析体系的关键。

在用户转账行为完成的短时间内，交易双方均可能产生对特定时间段内转账信息的查询需求，如商家会查询近10分钟内新增的大额交易的合计金额。在数据处理层面，这就要求银行能够立即将本次用户的转账数据反映到实时的报表和统计分析中。而由于实时报表和统计分析的需求千变万化，需要的数据维度、数据时间范围各有差异，流处理系统难以满足，因此需要银行构建起实时按需分析的能力。

最后，在用户转账行为完成的较长时间内，该笔转账的数据将会被银行通过报表统计、数据挖掘等技术用于银行业务流水分析、用户消费行为画像等场景中，以支持银行的业务决策，这即是银行最为传统的离线分析需求。这种离线分析对数据的实时性要求不高，围绕银行特定的决策支持场景展开，对银行的日常运营具有重要意义。

而面对从实时流处理，到实时按需分析、再到离线分析的复杂需求，单一的靠数据仓库还是数据湖都难以流畅的实现支持。

大数据分析的三大场景

一方面，数据仓库作为银行进行传统离线分析的数据工具，应用已经相对成熟，但是数据仓库需要严格定义schema，选取哪些数据维度、如何构建分析表单，需要进行审慎的数据建模，这个过长往往涉及对银行诸多部门的需求分析与验证，还需要进行跨部门协作，因此数据建模路径长、时间久，难以满足实时性的数据分析需求。

另一方面，数据湖是在大数据时代中成长起来的数据工具，在多种数据类型、海量数据的存储，及数据的取用规则上具有更强的灵活性，因此能够更好支持对数据的实时分析。但是其在性能、事务、管理运维效率等方面均无法与核心数仓相比。

事实上，随着移动互联网、5G等技术的不断进步，不仅仅是银行的交易转账，在企业营销、智能制造、智慧交通等多个应用场景下，均同时存在以上三种数据分析需求。结合数据仓库和数据湖各自的优势，实现二者融合协作已成为多个行业大数据应用的共识。只有湖仓一体化，才能帮助企业撬动更大的数据潜能，助力企业数智化转型。

重塑湖仓一体化标准，1+1如何>2

而对湖仓一体化趋势的统一认知并不必然导向正确的技术实现路径。

在企业进行湖仓一体化探索时，可能对原有的IT系统和平台产生路径依赖，从而选择采用湖仓分体的技术模式，即湖是湖，仓是仓，而这个各自独立部署，数据通过ETL的方式打通，即业内常常提到的Hadoop+MPP模式。

这种方式尽管在逻辑上可以为用户提供统一的数据管理能力，但在物理层面数据湖和数据仓库仍然是分离的，同一份数据可能分别存在于多个存储集群中，从而不可避免的形成数据孤岛。

同时，随着数据分析和应用场景的复杂化，并发查询的需求凸显。而面对动辄数百TB的数据查询，不论是基于Hadoop构建的数据湖，还是基于MPP数据库构建的数据仓库都无法支撑，从而影响整个系统的性能。为了满足高并发场景需求，企业往往会把数据更细化分割到更多的集群中，从而造成更严重的数据孤岛效应，不利于企业对数据的统一管理。

而在企业克服湖仓分体模式带来的种种弊端的过程中，又可能进一步催生ETL逻辑复杂、数据变更困难、数据不一致等一系列实施与运维问题，最终不仅无法最大化湖仓性能，还极大增加了管理运维成本。

那么，究竟怎样的湖仓一体化才能更好发挥数据仓库和数据湖在功能上的互补性，以真正实现对丰富的用户数据分析场景的支持呢？

面对用户对数据分析实时性和并发度的要求，以及湖仓分体模式集群规模受限、非结构化数据无法整合、数据一致性弱、性能瓶颈突出等问题，作为国内湖仓一体化领域最早的探索者和实践者，偶数科技提出了ANCHOR标准，即All Data Types（支持多类型数据）、Native on Cloud（云原生）、Consistency（数据一致性）、High Concurrency （超高并发）、One Copy of Data（一份数据）、Real-Time（实时 T+0）。

而正是在技术上的不断突破与创新使偶数科技有底气提出ANCHOR标准、满足ANCHOR标准。

偶数科技湖仓一体化解决方案

偶数科技研发的全球最快的云数据库OushuDB创新性的采用了存算分离的云原生架构，突破了传统MPP和Hadoop的局限，将计算和存储部署在不同的物理集群中，使得计算和存储资源可以独立的弹性伸缩；通过构建虚拟计算集群，OushuDB可以在数十万节点的超大规模集群上满足高并发需求，形成了统一的数据体系，不仅使得湖仓更适应云环境，还降低了用户的成本；通过支持分布式表存储Magma，OushuDB的计算引擎便于实现快照视图，能够高效实现实时查询需求，从而在性能和事务方面的支持更加完善。

为了同时满足实时流处理、实时按需分析和离线分析需求，偶数科技独创性的探索出了Omega全实时数据处理架构。Omega架构通过流处理系统WASP实现实时连续的流处理或批流一提处理，并通过存储于实时数仓的快照视图完成实时查询，从而解决了传统Kappa架构落地困难、Lambda架构难以保证数据一致性的问题，并极大简化了数据架构。

满足用户“既要也要”的要求，偶数科技的突破性技术和前瞻性观点并非空中楼阁，而是以多年的行业实践和用户洞察为基础支点形成的经验沉淀。偶数科技正在赋能用户的过程中不断完成自我迭代，探索最佳实践。

探索最佳实践路径，偶数科技“方法论”落地

银行业是所有行业中对应用的自主可控、高可用、高可靠性的要求最高的领域之一，偶数科技解决方案在银行业的落地正是其技术实力和对用户痛点理解力的明证。

作为企业数字化转型的先锋行业，银行业自80-90年代起就已经开始了信息化探索，在自手工统计到信息化再到数智化的较长技术发展过程中，大多数的银行形成了较为复杂的技术体系。

在数据分析场景下，银行早已采用甲骨文、Db2等厂商的OLTP数据库构建了成熟数据仓库以满足对标准化数据的离线分析需求。随着近年来活动营销、交易风险监控等实时性数据应用场景的出现，因而又引入了数据湖。

因此在银行的IT体系中，往往数据仓库与数据湖并存，二者各自服务于不同应用负载，并未形成“合力”，也因此银行在数据层面并没有形成一体化的视角。同时，不同的技术接入必然带来系统架构的复杂性，从而使得银行整体的研发成本和运维难度增大。

偶数科技率先洞察到了银行面对大数据时代的湖仓一体化需求，早在2020年就与建设银行成立了高性能大数据联合实验室，共同探索湖仓一体化的实施路径。

经过持续的技术探讨与应用验证，二者合作开发的基于云原生数据库技术的全实时湖仓一体方案，采用了一套技术栈、统一存储进行湖仓双重能力建设，已具备极速性能、弹性伸缩、计算资源按需分配、全量数据单一存储、无须频繁导数、混合负载等相关能力，能够充分建设银行及其客户的实时应用场景，帮助建行提升了实时需求响应性能、增强了系统弹性，同时节约运维成本。

除了银行业以外，截至目前，偶数科技的产品和解决方案已在非银金融、电信、政府、能源、制造和互联网等行业中被广泛的部署和应用。同时，其商业模式的可行性与成长性也得到了资本的认可，连续获得了国内顶级投资机构红杉中国、腾讯、红点中国与金山云的四轮投资。

2022年，偶数科技正式入选国家级专精特新（专业化、精细化、特色化、新颖化）“小巨人”企业名单。作为助力国家突破关键技术领域“卡脖子”难题的创新企业，偶数科技在国产数据库领域的硬实力和影响力再次得到国家的肯定。

而随着未来物联网、工业互联网的逐步建立，大数据领域将面临越来越广的数据来源、越来越大的数据量、越来越多的非结构化数据、越来越丰富的应用场景和越来越复杂的技术栈，大数据处理和分析的难度将进一步提升。偶数科技作为湖仓一体化领域的领导者，也将持续优化技术，为用户带来更高性能、更稳健的解决方案，支撑更多行业用户将数据转化为生产力。