重新定义湖仓一体化:偶数科技崭露国产数据库领导力( 二 )


重塑湖仓一体化标准 , 1+1如何>2
而对湖仓一体化趋势的统一认知并不必然导向正确的技术实现路径 。
在企业进行湖仓一体化探索时 , 可能对原有的IT系统和平台产生路径依赖 , 从而选择采用湖仓分体的技术模式 , 即湖是湖 , 仓是仓 , 而这个各自独立部署 , 数据通过ETL的方式打通 , 即业内常常提到的Hadoop+MPP模式 。
这种方式尽管在逻辑上可以为用户提供统一的数据管理能力 , 但在物理层面数据湖和数据仓库仍然是分离的 , 同一份数据可能分别存在于多个存储集群中 , 从而不可避免的形成数据孤岛 。
同时 , 随着数据分析和应用场景的复杂化 , 并发查询的需求凸显 。 而面对动辄数百TB的数据查询 , 不论是基于Hadoop构建的数据湖 , 还是基于MPP数据库构建的数据仓库都无法支撑 , 从而影响整个系统的性能 。 为了满足高并发场景需求 , 企业往往会把数据更细化分割到更多的集群中 , 从而造成更严重的数据孤岛效应 , 不利于企业对数据的统一管理 。
而在企业克服湖仓分体模式带来的种种弊端的过程中 , 又可能进一步催生ETL逻辑复杂、数据变更困难、数据不一致等一系列实施与运维问题 , 最终不仅无法最大化湖仓性能 , 还极大增加了管理运维成本 。
那么 , 究竟怎样的湖仓一体化才能更好发挥数据仓库和数据湖在功能上的互补性 , 以真正实现对丰富的用户数据分析场景的支持呢?
面对用户对数据分析实时性和并发度的要求 , 以及湖仓分体模式集群规模受限、非结构化数据无法整合、数据一致性弱、性能瓶颈突出等问题 , 作为国内湖仓一体化领域最早的探索者和实践者 , 偶数科技提出了ANCHOR标准 , 即AllDataTypes(支持多类型数据)、NativeonCloud(云原生)、Consistency(数据一致性)、HighConcurrency(超高并发)、OneCopyofData(一份数据)、Real-Time(实时T+0) 。
而正是在技术上的不断突破与创新使偶数科技有底气提出ANCHOR标准、满足ANCHOR标准 。
重新定义湖仓一体化:偶数科技崭露国产数据库领导力
文章图片
偶数科技研发的全球最快的云数据库OushuDB创新性的采用了存算分离的云原生架构 , 突破了传统MPP和Hadoop的局限 , 将计算和存储部署在不同的物理集群中 , 使得计算和存储资源可以独立的弹性伸缩;通过构建虚拟计算集群 , OushuDB可以在数十万节点的超大规模集群上满足高并发需求 , 形成了统一的数据体系 , 不仅使得湖仓更适应云环境 , 还降低了用户的成本;通过支持分布式表存储Magma , OushuDB的计算引擎便于实现快照视图 , 能够高效实现实时查询需求 , 从而在性能和事务方面的支持更加完善 。
为了同时满足实时流处理、实时按需分析和离线分析需求 , 偶数科技独创性的探索出了Omega全实时数据处理架构 。 Omega架构通过流处理系统WASP实现实时连续的流处理或批流一提处理 , 并通过存储于实时数仓的快照视图完成实时查询 , 从而解决了传统Kappa架构落地困难、Lambda架构难以保证数据一致性的问题 , 并极大简化了数据架构 。
重新定义湖仓一体化:偶数科技崭露国产数据库领导力
文章图片
满足用户“既要也要”的要求 , 偶数科技的突破性技术和前瞻性观点并非空中楼阁 , 而是以多年的行业实践和用户洞察为基础支点形成的经验沉淀 。 偶数科技正在赋能用户的过程中不断完成自我迭代 , 探索最佳实践 。
探索最佳实践路径 , 偶数科技“方法论”落地
银行业是所有行业中对应用的自主可控、高可用、高可靠性的要求最高的领域之一 , 偶数科技解决方案在银行业的落地正是其技术实力和对用户痛点理解力的明证 。