诺亚财富 X Hologres : 统一OLAP分析引擎,全面打造金融数字化分析平台

本文涉及的产品
实时数仓Hologres,5000CU*H 100GB 3个月
简介: 本文将会介绍诺亚财富从自建CDH迁移上阿里云,统一OLAP分析引擎,打造金融数字化分析平台的最佳实践

作者:李欣 诺亚财富数据总监, 卢帅  诺亚财富高级数据开发

客户简介

诺亚控股有限公司以“诺亚财富”为品牌,源起于中国,是首家在港美两地上市的中国独立财富管理机构,首家开创了财富管理和资产管理的双轮驱动业务模式,同时也是国内首家获得标准普尔“投资级”评级的财富管理公司,公司业务涵盖财富管理、资产管理和其他业务。诺亚数据智能部门负责公司大数据体系框架建设,主要工作是支撑日常的BI分析,数据看板,人群画像,自助分析等场景。

在公司数字化转型的背景下,业务增长带来了数据量的激增,不同的数据需求衍生出各种数据服务,不同的数据服务选择不同的数据库和数仓技术,比如MySQL,Impala, Greenplum,ElasticSearch等。为了最大化的降低运维成本,提供高性能的数据服务,做到真正的极速统一,从2021年上半年开始,诺亚数据智能部门开始上云,将自建CDH替换成阿里云统一大数据平台,同时正式引入Hologres,替换核心的Impala OLAP分析部分,提升数据查询效率,全面打造金融数字化分析平台。因此在本文中,我们将会详细介绍诺亚从CDH迁移阿里云大数据平台的前因后果,以帮助更多的业务更加方便快捷的建设实时数仓。

业务挑战:自建CDH组件多运维难、交易指标多元查询慢

为了支持业务,诺亚原大数据架构采用Impala和CDH构架构建,架构图如下:

诺亚00.png

在最初的架构中,我们从Cloudera购买了License 基于CDH 搭建了一套数据服务平台:上游的源数据库主要是 MySQL,Oracle,Mongo等 ,业务相关的数据和部分日志数据都记录在里面。我们通过 DataX 和 Sqoop 将数据库中的数据导入到 HDFS,通过 Hive的元数据映射生成 Schema,并接入 Impala 实现数据的即席查询。数据仓库的分层和建模全部都在 Hive 中完成,借助 LDAP 和 Sentry 进行用户权限管理,分析师在HUE中进行查询。

对于实时指标,我们通过Debezium 采集 MySQL 的 Binlog 日志,解析到Flink中对数据进行处理建模,并关联Kafka中的埋点日志数据,生成实时指标写入到 MySQL 中。该流程适用于大部分的报表需求,但是由于 MySQL 对于OLAP 的任务执行效率较低,在单日报表超过50万记录的情况下,一些多维分析结果可能需要8+秒以上才能返回,非常影响报表查看体验。同时我们也提供了相应的数据服务,分析师通过 JDBC 的连接方式对数仓数据进行查询,数仓数据通过数据API直接应用于一线业务,相应的 BI 报表展示也基于 Impala 计算实现。


随着业务的增长,此架构面临如下挑战:

1、业务方面:

  • 数据分析性能不足:因为我们的用户可能多年的存量和交易指标特别多,数据需要复杂关联查询才能得到数据指标,还有高并发查询时间周期比较长的数据,返回时间太长,业务方体验很差。
  • 实时分析场景不足:历史的数据架构导致数据延迟频繁,无法满足业务方及时做出决策。
  • 查询引擎不统一 :系统可能有多种查询引擎组成,每一种查询引擎都有自己的DSL,增加了用户的学习成本,同时需要跨多数据源查询也是一种不方便的的事,异构查询引擎也容易形成数据孤岛。
  • 用数据难 :由于数据分布在各个系统中,用户无法在一个系统满足所有的数据需求。特别是一线的运营和分析同学,需要通过各个系统导出大量的excel表格的方式做数据分析,费时费力,同时也存在一定的数据隐患。

2、技术方面:

  • 使用的组件过多:实现不同的需求需要不同的组件,例如批处理采用的Hive , 即席查询使用的Greenplum和 Impala ,这对于数仓内部的管理提出了较高的要求,对于分析师和报表同学不够友好。
  • 运维难度大:CDH 虽然是商业软件平台,提供了界面化操作,但是大多数组件依然需要自己去探索维护,并且官方文档严重缺失。由于CDH已经不在中国市场提供更新,暴露出来的漏洞也越来越多,并且未来的不确定性也在增加,缺乏稳定性。
  • 大数据量查询较慢:我们使用Impala进行加速查询,但是数据文件没有有效的索引,对于数据量的扫描过大的查询,有时候需要几十秒才能返回结果。并且自身的SQL优化器比较粗糙,SQL稍微写的不够规范,就会产生不必要的资源开销,导致查询卡死。
  • Impala的自身的缺陷:在表数据或者表结构更新的情况下,需要手动的刷新元数据才能查询到最新的数据,极其不方便。
  • 成本高:业务发展快,产生数据快速膨胀,Impala的线性扩容成本比较高。

技术选项多维对比

为了解决上面的痛点,我们想要对架构进行升级,在寻求解决方案的过程中,OLAP分析是我们非常看重的一个部分,因此我们根据业务需求评估了四个维度:

功能

Hologres

Starrocks

Clickhouse

标准SQL

支持

支持,兼容Mysql协议

不完全支持

高并发查询

端到端的全异步处理框架,可以避免高并发系统的瓶颈,充分利用资源,并且最大可能地避免存储计算分离系统带来的读数据延迟的影响。

有限支持

不支持高并发,官方建议QPS 为 100

运维

完善的dashboard,包括查询日志,慢SQL等都可以查询

社区版不提供dashboard,需要自己实现自动化部署

依赖zookeeper,运维成本高

性能

Hologres支持行存储、列存储和行列共存多种存储模式, 可以根据业务场景选择合适的存储类型

大宽表和多表join性能比ck更好

单机性能强悍,但是单表查询效率快。

社区(技术支持)

响应时间较快,版本迭代快。

较快

较慢,社区活跃度较低

解决方案:自建CDH迁移上云,Hologres助力统一OLAP分析

经过4个维度的充分考虑和论证,我们决定将自建CDH迁移成阿里云大数据平台。迁移后诺亚基于阿里云大数据平台架构图如下:

诺亚00.png

诺亚数据智能中心在2021年进行了上云的计划,全面实现数据中台的云原生,抛弃掉原来的CDH那套数据架构,我们花了一年的时间进行了整个数据中台的改造和迁移,原来的数仓基于impala的表大概有1w+ 张,烟囱式开发,老架构的数仓是DL层 + DH 层,没有对于数据进行分层和沉淀 ,导致数据冗余严重,任务之间互相依赖严重,没有很好的进行对于业务模块的划分。


整个数据中台依托于DataWorks,离线部分在MaxCompute中进行,通过DataWorks的数据同步模块把离线部分同步到MaxCompute和实时部分同步到Hologres,然后利用Flink的把神策埋点的Kafka数据清洗同步到Hologres中,同时也通过Hologres的外表把MaxCompute的数据迁移到Hologres中,保证统一OLAP分析引擎。


在迁移的过程中,我们是两套中台并行,新的业务我们直接依赖阿里云进行开发,老的任务,我们根据业务线对于数仓进行了重构和分层,ODS , CDM (DIM,DWD,DWS) ,ADS 层,对于表进行了梳理和整合,计算资源和任务减少了一半,任务之间的依赖关系通过DAG图清晰明了,不要再为了改一个脚本,进行俄罗斯套娃式的改造脚本,大大节省了人力成本。


业务价值:更简的架构,更快的查询,更低的成本,全面金融数字化分析

通过将将技术架构从自建CDH全面上云后,对我们以及业务来说,都带来了非常多的好处,主要有以下几点:

  • 原来的IDC的CDH ,每年花费在机房的费用也很高,现在上云也满足了公司降本增效的整体方针,自动上云之后,我们在大数据运维层面的投入变少,让一些基础设施基础服务交给阿里云去做 ,更多的时间专注于业务,缩短了需求的交付时间,同时也保证了交付的质量 ;其次,阿里云的云原生的拓展性,弹性计算,可以随时的扩容缩容,能够满足业务膨胀带来的紧急需求,高效稳定。阿里云的平台能力很强,对于开发,分析师都很友好,上手能力很快,操作简单便捷,学习成本较低。
  • 实时的广告投放多维分析,帮助市场部门及时提供数据支撑,及时调整投放策略,提高投资回报率。原来的神策埋点数据是通过Kafka直接进入到HBase,然后通过挂载hive的外表的方式来做各种维度的聚合,指标类的计算,然后再借助Impala的加速查询,这样的方式整个数据链路太长,经常出现数据丢失的情况,无法满足业务方的真正的实时数据需求,后续我们把kafka的数据直接sink到Hologres中,借助于Hologres+ Flink的实时数仓的能力,满足业务部门的实时需求。
  • 作为用户指标的载体,完成用户画像等的精细化分析需求,为公司数字化赋能。精确的数据去重,Hologres兼容PostgreSQL生态,原生支持Roaring Bitmap函数。通过对标签表构建索引,将用户ID编码后以Bitmap格式保存,将关系运算转化Bitmap的交并差运算,进而加速实时计算性能。在超大规模用户属性洞察分析的场景中,使用RoaringBitmap组件能够实现亚秒级的查询响应。
  • 以Hologres作为业务部门访问数据仓库的入口和核心,完善交互式查询体验。使用Hologres,在性能上明显明显,之前千万级的表的查询在5s+ , 当前在查询在 300ms左右,查询平均性能提升 90%以上,目前整体已经迁移了全部的报表800张+。 Hologres可以根据业务场景做行列存储的优化,既减少了运维压力,又对于查询性能提升明显。
  • 作为数据部门提供OneSevice的数据服务平台的底座,稳定性和高性能的支撑业务系统,提高了客户的体验感。原来提供的API是查询MySQL,但是面临一个问题就是数据量大和并发数大时,接口相应速度很慢,影响到客户的体验,后面我们借助于DataWorks的数据服务模块,把这块的接口的底层查询引擎全部切换到Hologres,接口又原来的平均800+ms缩减到 300+ms ,同时也减少了数同步,借助于Hologres和MaxCompute的生态完整性,直接刷成Hologres的外表,加速查询。



写在最后

孙甜 诺亚财富数据智能中心总经理 寄语 :


阿里云Hologress团队和技术支持团队真正做到了以客户为中心,不以销售额为导向,而是一路陪伴客户成长,并主动帮助我们实现降本增效。诺亚面向高净值客户提供复杂资产配置服务,高端金融服务的业务属性天然带有“行少列多”的数据特点。大多数数据厂商偏爱服务数据量大且结构化程度高的互联网客户--算力消耗大且场景较为标准化;而高端金融服务的“行少列多”则是数据服务的深水区,算力消耗有限但客户需求又极为复杂,如果不是抱着用数据改变行业的决心和过硬的技术,是很难服务好金融行业客户的。Hologres支持同学不仅亲自来诺亚为我们提供了高水平的数据培训,还不厌其烦地在钉钉群里解答我们的各类问题。甚至我们深夜提问,也会有Hologres的伙伴迅速响应并积极解决。更让我感动的是,我们上云以来在Hologres团队的支持下做了大量计算优化,在提高了数据计算速度的同时也降低了一半以上的成本。Hologres团队从来没有因为我们消费降低而抱怨,把我们当做战友一样全力支持。Holo团队对我们来说亦师亦友,陪伴我们一路成长,也希望将来能够一同打造金融大数据的最佳实践!



了解Hologres:

https://www.aliyun.com/product/bigdata/hologram

合集.png

相关实践学习
基于Hologres轻松玩转一站式实时仓库
本场景介绍如何利用阿里云MaxCompute、实时计算Flink和交互式分析服务Hologres开发离线、实时数据融合分析的数据大屏应用。
相关文章
|
14天前
|
DataWorks 数据挖掘 大数据
方案实践测评 | DataWorks集成Hologres构建一站式高性能的OLAP数据分析
DataWorks在任务开发便捷性、任务运行速度、产品使用门槛等方面都表现出色。在数据处理场景方面仍有改进和扩展的空间,通过引入更多的智能技术、扩展数据源支持、优化任务调度和可视化功能以及提升团队协作效率,DataWorks将能够为企业提供更全面、更高效的数据处理解决方案。
|
1月前
|
SQL 流计算 关系型数据库
基于OpenLake的Flink+Paimon+EMR StarRocks流式湖仓分析
阿里云OpenLake解决方案建立在开放可控的OpenLake湖仓之上,提供大数据搜索与AI一体化服务。通过元数据管理平台DLF管理结构化、半结构化和非结构化数据,提供湖仓数据表和文件的安全访问及IO加速,并支持大数据、搜索和AI多引擎对接。本文为您介绍以Flink作为Openlake方案的核心计算引擎,通过流式数据湖仓Paimon(使用DLF 2.0存储)和EMR StarRocks搭建流式湖仓。
407 4
基于OpenLake的Flink+Paimon+EMR StarRocks流式湖仓分析
|
1月前
|
SQL 存储 数据挖掘
快速入门:利用AnalyticDB构建实时数据分析平台
【10月更文挑战第22天】在大数据时代,实时数据分析成为了企业和开发者们关注的焦点。传统的数据仓库和分析工具往往无法满足实时性要求,而AnalyticDB(ADB)作为阿里巴巴推出的一款实时数据仓库服务,凭借其强大的实时处理能力和易用性,成为了众多企业的首选。作为一名数据分析师,我将在本文中分享如何快速入门AnalyticDB,帮助初学者在短时间内掌握使用AnalyticDB进行简单数据分析的能力。
54 2
|
2月前
|
SQL 分布式计算 Serverless
EMR Serverless Spark:一站式全托管湖仓分析利器
本文根据2024云栖大会阿里云 EMR 团队负责人李钰(绝顶) 演讲实录整理而成
179 2
|
2月前
|
存储 SQL 分布式计算
湖仓一体架构深度解析:构建企业级数据管理与分析的新基石
【10月更文挑战第7天】湖仓一体架构深度解析:构建企业级数据管理与分析的新基石
150 1
|
2月前
|
人工智能 自然语言处理 关系型数据库
阿里云云原生数据仓库 AnalyticDB PostgreSQL 版已完成和开源LLMOps平台Dify官方集成
近日,阿里云云原生数据仓库 AnalyticDB PostgreSQL 版已完成和开源LLMOps平台Dify官方集成。
|
2月前
|
OLAP
解决方案|基于hologres搭建轻量OLAP分析平台获奖名单公布!
解决方案|基于hologres搭建轻量OLAP分析平台获奖名单公布!
|
2月前
|
DataWorks 数据挖掘 关系型数据库
基于hologres搭建轻量OLAP分析平台解决方案评测
一文带你详细了解基于hologres搭建轻量OLAP分析平台解决方案的优与劣
460 9
|
1月前
|
数据采集 分布式计算 OLAP
最佳实践:AnalyticDB在企业级大数据分析中的应用案例
【10月更文挑战第22天】在数字化转型的大潮中,企业对数据的依赖程度越来越高。如何高效地处理和分析海量数据,从中提取有价值的洞察,成为企业竞争力的关键。作为阿里云推出的一款实时OLAP数据库服务,AnalyticDB(ADB)凭借其强大的数据处理能力和亚秒级的查询响应时间,已经在多个行业和业务场景中得到了广泛应用。本文将从个人的角度出发,分享多个成功案例,展示AnalyticDB如何助力企业在广告投放效果分析、用户行为追踪、财务报表生成等领域实现高效的数据处理与洞察发现。
68 0
|
2月前
|
存储 缓存 数据处理
深度解析:Hologres分布式存储引擎设计原理及其优化策略
【10月更文挑战第9天】在大数据时代,数据的规模和复杂性不断增加,这对数据库系统提出了更高的要求。传统的单机数据库难以应对海量数据处理的需求,而分布式数据库通过水平扩展提供了更好的解决方案。阿里云推出的Hologres是一个实时交互式分析服务,它结合了OLAP(在线分析处理)与OLTP(在线事务处理)的优势,能够在大规模数据集上提供低延迟的数据查询能力。本文将深入探讨Hologres分布式存储引擎的设计原理,并介绍一些关键的优化策略。
149 0

热门文章

最新文章

相关产品

  • 实时数仓 Hologres