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

2021年底 , 大数据领域最“吸睛”的事件莫过于Databricks和Snowflake关于TPC-DS测试结果的“恩怨情仇”了 。
2021年11月 , Databricks发布了《DatabricksSetsOfficialDataWarehousingPerformanceRecord》一文 , 在体现Databricks数仓高性能的同时 , 矛头直指云数仓“当红炸子鸡”Snowflake , 双方随即在就TPC-DS测试结果展开争论 , 数据湖与数据仓库在跑分竞赛中狭路相逢 。
事实上 , 作为大数据分析赛道的代表性厂商 , 不论是具备数据仓库功能的数据湖工具Databricks , 还是借鉴数据湖范式的可扩展数据仓库Snowflakes , 其发展路线都说明“湖仓一体化”已成为了目前市场主流的技术发展方向 。
从一笔银行转账谈起
如果单单提到“湖仓一体化” , 对大数据分析技术不那么了解的读者来说感受可能并不真切 。 那么我们就从最贴近生活的银行转账场景谈起 。
在用户通过银行向某个特点商家完成线上交易转账的背后 , 银行在数据层面需要经过怎样的流程呢?
首先 , 几乎在用户转账行为的同时 , 为了更好保障用户转账资金的安全性 , 银行需要将本次用户转账的时间、金额、位置等数据进行加工 , 形成衍生特征提供给反欺诈应用系统并迅速完成对交易性质的判断 , 若转账存在欺诈风险则需要及时完成预警与交易阻断 。 在这个流程中 , 就需要银行对数据进行实时流处理 。 当大量用户转账行为同时发生时 , 伴随着大量数据的同时涌入 , 如何分配计算和存储资源以保障流处理的及时性是考验数据分析体系的关键 。
在用户转账行为完成的短时间内 , 交易双方均可能产生对特定时间段内转账信息的查询需求 , 如商家会查询近10分钟内新增的大额交易的合计金额 。 在数据处理层面 , 这就要求银行能够立即将本次用户的转账数据反映到实时的报表和统计分析中 。 而由于实时报表和统计分析的需求千变万化 , 需要的数据维度、数据时间范围各有差异 , 流处理系统难以满足 , 因此需要银行构建起实时按需分析的能力 。
最后 , 在用户转账行为完成的较长时间内 , 该笔转账的数据将会被银行通过报表统计、数据挖掘等技术用于银行业务流水分析、用户消费行为画像等场景中 , 以支持银行的业务决策 , 这即是银行最为传统的离线分析需求 。 这种离线分析对数据的实时性要求不高 , 围绕银行特定的决策支持场景展开 , 对银行的日常运营具有重要意义 。
而面对从实时流处理 , 到实时按需分析、再到离线分析的复杂需求 , 单一的靠数据仓库还是数据湖都难以流畅的实现支持 。
重新定义湖仓一体化:偶数科技崭露国产数据库领导力
文章图片
一方面 , 数据仓库作为银行进行传统离线分析的数据工具 , 应用已经相对成熟 , 但是数据仓库需要严格定义schema , 选取哪些数据维度、如何构建分析表单 , 需要进行审慎的数据建模 , 这个过长往往涉及对银行诸多部门的需求分析与验证 , 还需要进行跨部门协作 , 因此数据建模路径长、时间久 , 难以满足实时性的数据分析需求 。
另一方面 , 数据湖是在大数据时代中成长起来的数据工具 , 在多种数据类型、海量数据的存储 , 及数据的取用规则上具有更强的灵活性 , 因此能够更好支持对数据的实时分析 。 但是其在性能、事务、管理运维效率等方面均无法与核心数仓相比 。
事实上 , 随着移动互联网、5G等技术的不断进步 , 不仅仅是银行的交易转账 , 在企业营销、智能制造、智慧交通等多个应用场景下 , 均同时存在以上三种数据分析需求 。 结合数据仓库和数据湖各自的优势 , 实现二者融合协作已成为多个行业大数据应用的共识 。 只有湖仓一体化 , 才能帮助企业撬动更大的数据潜能 , 助力企业数智化转型 。