诺亚财富金融数字化转型中OLAP的探索和实践 演讲人:李欣诺亚财富数仓总监 Contents 目录 诺亚财富挑战和选型业务案例最佳实践 01诺亚财富 •诺亚控股有限公司以“诺亚财富”为品牌,源起于中国,是首家在港美两地上市的中国独立财富管理机构,开创了财富管理和资产管理的双轮驱动业务模式,同时也是国内首家获得标准普尔“投资级”评级的财富管理公司,公司业务涵盖财富管理、资产管理和其他业务。 •诺亚数据管理部门负责公司整体大数据体系框架建设,主要工作是支撑日常的BI分析,数据看板,人群画像,自助分析等场景。 •数据量不大但是业务场景复杂、业务域数据域范围广: •公募 •私募 •股权 •证券 •保险 •代销 •直销 •… 02数字化挑战和选型 业务方面: •数据分析性能不足:因为我们的用户可能多年的存量和交易指标特别多,数据需要复杂关联查询才能得到数据指标,还有高并发查询时间周期比较长的数据,返回时间太长,业务方体验很差。 •实时分析场景不足:历史的数据架构导致数据延迟频繁,无法满足业务方及时做�决策。 •查询引擎不统一:系统可能有多种查询引擎组成,每一种查询引擎都有自己的DSL,增加了用户的学习成本,同时需要跨多数据源查询也是一种不方便的的事,异构查询引擎也容易形成数据孤岛。 •用数据难:由于数据分布在各个系统中,用户无法在一个系统满足所有的数据需求。特别是一线的运营和分析同学,需要通过各个系统导�大量的excel表格的方式做数据分析,费时费力,同时也存在一定的数据隐患 早期架构 技术方面: •使用的组件过多:实现不同的需求需要不同的组件,例如批处理采用的Hive,即席查询使用的 Greenplum和Impala,这对于数仓内部的管理提�了较高的要求,对于分析师和报表同学不够友好。 •运维难度大:CDH虽然是商业软件平台,提供了界面化操作,但是大多数组件依然需要自己去探索维护,并且官方文档严重缺失。由于CDH已经不在中国市场提供更新,暴露�来的漏洞也越来越多,并且未来的不确定性也在增加,缺乏稳定性。 •大数据量查询较慢:我们使用Impala进行加速查询,但是数据文件没有有效的索引,对于数据量的扫描过大的查询,有时候需要几十秒才能返回结果。并且自身的SQL优化器比较粗糙,SQL稍微写的不够 规范,就会产生不必要的资源开销,导致查询卡死。 •Impala的自身的缺陷:在表数据或者表结构更新的情况下,需要手动的刷新元数据才能查询到最新的数据,极其不方便。 •成本高:业务发展快,产生数据快速膨胀,Impala的线性扩容成本比较高。 早期架构 2021年开始,我们对架构进行升级,整个架构进行了上云。大大降低了运维成本。同时,在寻求解决方案的过程中,OLAP分析和应用是我们非常看重的一个部分,也是数据的最终�口和利用的关键一环,直接影响了整个数据部门的关键考核指标。因此我们根据诺亚的复杂业务场景和需求,从四个维度考察选型了主流OLAP 诺亚数据中台依托于DataWorks,离线部分在MaxCompute中进行,通过DataWorks的数据同步模块把离线部分同步到MaxCompute和实时部分同步到Hologres,然后利用Flink的把神策埋点的Kafka数据清洗同步到Hologres中,同时也通过Hologres的外表把MaxCompute的数据迁移到Hologres中,实现一站式的OLAP分析引擎实施部署。 03业务案例 •客户资产分析报告系统 •客户资产分析报告系统 •客户资产分析报告系统:OLAP中表结构设计,大表关联 自助取数系统DataATM 以Hologres作为业务部门访问数据仓库的入口和核心,完善交互式查询体验。 自助取数系统DataATM 以Hologres作为业务部门访问数据仓库的入口和核心,完善交互式查询体验。 自助取数系统DataATM Maxcompute表直接作为外表映射到Hologres中,加速查询 一键生成API应用和数据服务 作为数据部门提供OneSevice的数据服务平台的底座,稳定性和高性能的支撑业务系统,提高了客户的体验感。 一键生成API应用和数据服务 完善的日志监控体系、省心的运维服务 04最佳实践和展望 最佳实践:一站式的全面支持 报表场景: Hologres支持使用创建外部表的方式,实现MaxCompute加速查询,在底层与MaxCompute无缝连接;且可以联邦分析实时数据和离线数据,无需预计算 分析取数场景: 在Hologres中支持行存、列存和行列共存三种存储格式,行列并存可以支持大数据量的分析同时满足单个客户数据的点查场景;且可以快速生成API服务 实时场景: 支持FlinkCDC实时写入、实时更新;支持了金融领域的实时风控、实时效果分析等实时场景 —THANKS—