金融行业数据平台极速、统一升级实践,镜舟科技出席帆软2023智数大会并作分享
实践案例1:
湖仓融合统一,极致优化证券业务实时性
在金融行业,随着金融交易业务场景日益增多,对于数据可用性要求、数据分析时效性要求也越来越重要。以某证券企业为例,其在业务中遇到了实时性与成本双重挑战,亟待数据分析平台升级,破局效率难题。
证券公司典型的数据分析逻辑是,将日常交易、融资融券、贵金属、期货交易等数据作为数据源,集中到数据中心后进行数据分层,通过数据开发做 ETL 得到实际的报表数据,随后通过网关为指标平台提供数据。
然而,传统方案会存在一定弊端,数据在进入数据中心后,为了方便业务人员在不同的维度对数据进行分析和价值洞察,会在数据仓库里面形成维表跟事实表的关联,将每个事实表与对应的维度属性建立联系,多个维度数据的冗余会导致数据量指数级膨胀。
在数据处理过程中,往往需要对相应的指标进行变更、新增等操作,因为指标已经完成聚合,会形成细节忽略的特性,接下来的开发工作很有可能涉及对源头数据进行处理,导致仓库的复杂性不断地增加,数据冗余也会不断地增多。
举个例子,A 用户早上 8 点钟在广州,下午 5 点钟又来到了深圳。业务人员在指标分析平台上按城市、时间 2 个维度进行指标 UV 的分析时,发现增加城市后 UV 数据不一致,这是因为一天内算了两次 UV(广州、深圳各算一次)。
传统的数据架构解决上面问题的方法是存储明细数据,通过对明细的聚合操作得到不同维度的结果,但数据流水特别大的情况下明细数据的存储需要大量存储成本,并造成计算成本的极大浪费。
针对这些问题,有没有更优秀的解决方案?
镜舟科技给出了实时性更高、成本更低的数据分析解决方案——基于 StarRocks 的湖仓一体联邦分析架构。从而帮助客户搭建新指标分析平台。
StarRocks 优势在于可以通过Flink、Spark、Routing Load 、Broker Load等多种方式实现数据的实时导入,并且通过外表的方式访问如HDFS、Hudi、Iceberg等数据湖的数据,实现了Single Source of Truth。StarRocks 内部提供的丰富的 BitMap 的函数,业务人员可以采用 Roaring BitMap 按位计算对数据进行交、并、差等操作,实现不同维度下的指标统计分析。
同时,由于通过 BitMap 对用户 ID 明细进行了保存,所以在统计过程中不会形成由于指标更改导致的统计错误,实现按照不同的维度进行指标的上卷下钻,统计结果永远是准确的。在测试过程中发现,StarRocks 可以将 1000 万的数据压缩到 15 万,极大地减少了数据重复存储问题。
镜舟数据库是底层分析引擎,具有高效、稳定、易用的特点,可以提升金融行业数据分析的时效性。StarRocks 通过 Data Cache 能力,让外表查询的性能接近本地表的查询性能,让实时联邦查询分析成果落地,实现了如 Hive 跟 Iceberg 等外表的关联分析,保证数据源的统一,不会出现由于数据多份、多地存储造成口径不一致,结果不一致的问题。
实践案例2:
3-5 倍性能提升,实时营销分析升级保障精准投放决策另一方面,金融行业有大量直接面向 C 端消费者的业务场景,构建精准的 C 端用户广告投放画像将极大提高机构的营销效率,降低营销成本。以某保险公司为例,在与镜舟数据库合作优化营销投放分析平台后,整体数据查询和分析性能提升了 3-5 倍,同时将平台响应时间降到了 3 秒以内,大幅提升了市场人员在营销决策上的效率。
在营销活动中,该保险公司的市场人员经常要在多渠道投放新产品的广告以获取足量曝光,同时会通过实时报表随时核算对应渠道的投放成本,并根据渠道的表现以及实时的运营支出及时调整投放策略,降低营销流程中的获客单价,来达到比较好的 ROI。
投放分析遇卡点:大体量数据的实时性与性能支撑双需求
在广告投放的用户行为分析的场景下,随着业务的发展,市场人员对数据实效性有了更高的需求。
首先,市场人员需要对用户活跃分析数据进行实时分析,比如要根据注册、活跃以及留存数据进行营销活动设计。然而,该类数据总量过于庞大,比如 TB 级别的数据场景下用 10 秒钟返回结果,对分析系统的性能提出了很大挑战。
另外,在整个投放环节,市场人员需要根据投放效果决定是否要调整投放动作,以实时保单数据或收益数量去关联投放策略。例如,8 点生成的保单在 15 点退保后,需要实时修正 8 点的数据。而因为数据量十分庞大,实时修订之前的数据让传统架构难以招架,一旦修正失败,运营支出的统计错误,会导致后续的整体投放策略受影响。
该公司过去使用 ClickHouse 作为底层的实时更新模型只能支持千万级数据量,且更新与查询常常超时,严重影响市场投放效果。而且数据渠道的数据一旦加载时间过长、导入性能差或者响应的指标计算延时太高,很有可能造成公司大量的金额损失。
如何在支持数据更新、回撤的同时,保证查询的性能?
过去的解决方案是通过 Flink 往 ClickHouse 导入数据, 在 ClickHouse 实现数据分层,会导致分析作业查询慢的问题,响应往往都需要 10 秒以上。同时,ClickHouse 中 MergeTree 引擎的数据读取是读合并操作,在高频读取的场景下,性能比较差。
同时,在数据写入时,为了保证数据的一致性需要单独搭建一套 ZooKeeper 的组件,生产过程中需要维护 CK 和 ZK 等多个产品,导致出现运维难度加大以及数据多份冗余的情况。
StarRocks 的解决方案提出 Flink + StarRocks 主键模型,该方案支持批量的数据更新和删除,且开发成本相对较低,不需要依赖于 ZK 组件就可以实现数据的一致性,这也从侧面印证了 StarRocks 在分布式数据库产品中极速统一的特性。
该企业数据分析平台在集成了 StarRocks 以后,以前需要 10 秒钟的看板加载,现在 3 秒钟就可以完成加载,以前只能支持千万级别的数据量,在使用 StarRocks 后,可支持亿级别的数据量级。在实际的运营过程中,StarRocks 为业务的发展提供了高 SLA 保证。
在分享过程中,石强强调了数智化管理在金融领域中的重要性,也指出数智化管理需要企业具备完整的体系。镜舟数据库作为企业数智化升级的核心数据底座,可以为企业提供一站式的数据分析服务,助力企业全面数字化经营。
未来,镜舟科技将持续致力于为客户提供高效、稳定、安全的大数据服务,帮助企业实现数字化转型。