实时数据正当红，解析偶数科技实时数仓 OushuDB 核心特性
近年来，在大数据技术高速发展和国家政策的双重推动下，金融机构数字化转型持续加速。其中，金融行业对数据分析与应用的需求不断上升，特别是对实时数据更加重视，这是因为实时数据能够充分体现业务“事中”的情况，有效利用实时数据的价值，将大大提升金融机构处理各类业务的决策效率。
例如在银行业务场景中的交易转账，银行后台通过大数据实时计算分析，对交易行为实时监控。单笔交易的时间、金额、位置等信息要素都会经过加工，最后反映到实时报表与统计分析中。对于传统的数据仓库来说，这些实时性需求和数据流转特性是无法实现的，因为传统离线数仓的数据时效性是 T+1（甚至更久），调度频率一般以天为单位，无法进行实时数据分析。另外在某些场景中，数据的价值会随着时间推移而逐渐损失，企业将错失提升竞争力的重要契机。
数据越来越重要，国内外的数据库系统都在积极实践，并推出新型的实时数仓产品，CSDN 旗下《新程序员》杂志在数据库系列专题报道中提到，数据库系统的发展将迎来一个新的时代，其中实时数仓则是数据库系统发展的一个重要趋势。
营销、风控，实时数据正在进入金融各类创新与重要业务场景
以金融实时数据为例，金融行业是关注实时数据的典型行业，实时数据可应用在用户行为分析、实时营销、个性化推荐、实时风控、实时反欺诈等多个场景中，其中既有创新的金融业务场景，也有如风控这样重要的金融业务场景，实时数据的重要性不言而喻。
对于金融个人消费者而言，除了对金融账户各类数据的实时需求，更重要的，是流式计算系统通过分析海量用户的实时行为数据，可以实时阻断交易欺诈，降低个人账户风险。例如银行转账中，当一次转账交易发生时，银行将开启交易反欺诈检测，此时实时流处理系统会将实时交易信息进行加工，然后将实时数据与用既定规则计算出的风险指标进行分析比较，并与风险模型进行匹配，第一时间判断交易的风险等级并作出相应的风险控制措施（如自动告警通知转账者，或更改业务流程），进而降低欺诈性交易的风险，保护个人消费者的财产安全。
对于金融机构而言，实时数据的应用则可以让金融企业提升服务质量并提高运营效率。采用实时数仓接收实时数据，数据将会以更快的速度进入仓库，即实时到达。例如银行可以获取 ATM 机内现金存款的实时数据，当出现现金不足或机器故障时可以第一时间将故障信息传送给后台。此外，由于实时数据具有“到达即可查”的特性，因此工作人员对于新到达的数据无需进行处理、压缩或聚合，可以按需即席查询，大大提高了查询速度，通过数据赋能助力业务发展；同时，运营人员如果需要校正和更新数据，也可以很快完成，即数据更改效率高。
对于金融监管层而言，监管时效性在未来也会逐步提升。目前，银保监对银行三个重要的监管报送模块包括：非现场监管报表（1104）、监管数据标准化（EAST）、客户风险数据报送，几乎覆盖了金融机构全部数据。金融监管通过实时数仓技术可以提高报表提交的时效性，监管方、金融机构等角色可以近实时的看到监测数据，将大大提升监管效率，进一步保障了金融系统稳定运行。
实时数据背后，来看 OushuDB 的硬实力
一、Omega 全实时架构 VS Lambda、Kappa 架构
目前，数据的实时处理有两种典型的架构：Lambda 和 Kappa 架构，其中 Lambda 架构由于不同视图多份存储，难保障数据的一致性，Kappa 依赖 Kafka 等消息队列来保存所有历史，难以实现更新、纠错，故障和升级周期长，并且不具备即席查询数据，架构实际落地困难。同时两个架构又都很难处理可变更数据（如关系数据库中不停变化的实时数据），即便引入流处理引擎实现了部分固定模式的实时分析，仍无达到 T+0 全实时水平。因此，我们需要一种新的架构满足企业实时分析的全部需求，这就是基于偶数科技自主研发的云原生数据仓库 OushuDB 的 Omega 全实时架构。
Omega 架构由流数据处理系统和实时数仓构成。相比 Lambda 和 Kappa，Omega 架构新引入了实时数仓和快照视图 (Snapshot View) 的概念，快照视图是归集了可变更数据源和不可变更数据源后形成的 T+0 实时快照，可以理解为所有数据源在实时数仓中的镜像和历史，随着源库的变化实时变化。
因此，实时查询可以通过存储于实时数仓的快照视图得以实现。实时快照提供的场景可以分为两大类：一类是多个源库汇集后的跨库查询，比如一个保险用户的权益视图；另一类是任意时间粒度的分析查询，比如最近 5 分钟的交易量、最近 10 分钟的信用卡开卡量等等。
另外，任意时间点的历史数据都可以通过 T+0 快照得到（为了节省存储，T+0 快照可以拉链形式存储在实时数仓 ODS 中，所以快照视图可以理解为实时拉链），这样离线查询可以在实时数仓中完成，离线查询结果可以包含最新的实时数据，完全不再需要通过 MPP+Hadoop 组合来处理离线跑批及分析查询。
Omega 架构逻辑图
偶数流处理系统 WASP 既可以实现实时连续的流处理，也可以实现 Kappa 架构中的批流一体，但与 Kappa 架构不同的是，OushuDB 实时数仓存储来自 Kafka 的全部历史数据，而在 Kappa 架构中源端采集后通常存储在 Kafka 中。
因此，当需要流处理版本变更的时候，流处理引擎不再需要访问 Kafka，而是访问实时数仓 OushuDB 获得所有历史数据，规避了 Kafka 难以实现数据更新和纠错的问题，大幅提高效率。此外，整个服务层可以在实时数仓中实现，而无需额外引入 MySQL、HBase 等组件，极大简化了数据架构。
在 Omega 全实时架构的加持下，偶数率先实现了具备实时能力的湖仓一体，即实时湖仓。实时湖仓统一了湖仓市（数据湖、数仓、集市），避免数据孤岛的同时，极大提升了企业实时数据分析能力，让企业在快速更迭的商业环境中立于不败之地。
Lambda、Kappa 与 Omega 架构比较
二、OushuDB 性能有多强
随着 Hadoop 生态发展，许多企业已经搭建了基于 Hadoop 的大数据平台，并且尝试更加丰富的应用。作为 Hadoop 分析组件，Spark 扮演了重要角色，其 3.0 版本通过自适应查询执行（AQE）框架提升了部分场景性能。
测试数据显示：凭借 SIMD 新执行器优势，OushuDB 性能全面超过 Spark，性能相差 8 倍以上，最大相差 55 倍。该测试采用国际通用的测试标准 TPC-H，包括 22 个查询 (Q1~Q22)，主要评价指标是各查询的响应时间，即从提交查询到结果返回所需时间。通过检测比较，得到如下结果：
OushuDB 4.0 与 Spark 3.0 查询响应时间对比
注：测试采用单节点，并使用 Scale 为 100 的数据集（约 100GB）
三、金融案例实践：OushuDB 实现高性能、高效金融智能营销
回到实时数据在金融行业的应用，以某跨国保险公司财险业务使用 OushuDB 的实践为例，偶数实时湖仓数据平台从算力支持、统计分析、机器学习三个方面为该保险公司提升业务智能水平。在算力支持方面，OushuDB 保证高性能数据处理能力，在兼顾“实时”数据需求的同时，通过流计算算子实现高效智能营销；在统计分析方面，利用偶数科技自动化机器学习平台 Littleboy分析模式建立模型，对代理人、保单、用户多维度分析，实现更精准的客户画像；在机器学习方面，结合专家经验将数据结构化和标准化，通过模型调优调参，训练符合场景需求的机器学习模型。
机器学习结合OushuDB 算力上万个分类模型找出最优参数组合（模型的召回率预计可以达到 90%以上，AUC 曲线的面积可以达到 0.9 以上），实现了高潜续保客户推荐，帮助个人代理精准触达续保客户，节省 80%的时间；此外，OushuDB 及同步工具还完成了“静流结合”的数据分析，实现高性能、全面、精准的预测，提升业务线条整体续保水平。
据了解，目前 OushuDB 已在金融、政府、运营商等更多企业级 IT 的重要行业中进行实践，与腾讯云、阿里云、亚马逊、微软等企业建立合作关系。
大数据经过几年发展之后，数据的价值愈加重要。实时数据系统满足了新场景对数据的新需求，因此广受技术界的关注和追捧。不过在金融、运营商等这些行业中，实时数据系统发展仍处于早期阶段。从偶数科技 OushuDB 的核心技术架构、思路，以及实际应用，我们可以看到，凭借过硬的技术与性能，偶数科技正在为核心行业的新数据应用和业务场景提供稳定技术支撑，并为行业带来更多实践与参考。CSDN 也将继续持续关注国内优秀的数据系统厂商发展与进程。
来源：CSDN
