共计 4473 个字符,预计需要花费 12 分钟才能阅读完成。
作者: 李欣 诺亚财产数据总监,卢帅 诺亚财产高级数据开发
客户简介
诺亚控股有限公司以“诺亚财产”为品牌,源起于中国,是首家在港美两地上市的中国独立财产管理机构,首家创始了财产治理和资产治理的双轮驱动业务模式,同时也是国内首家取得规范普尔“投资级”评级的财产治理公司,公司业务涵盖财产治理、资产治理和其余业务。诺亚数据智能部门负责公司大数据体系框架建设,次要工作是撑持日常的 BI 剖析,数据看板,人群画像,自助剖析等场景。
在公司数字化转型的背景下,业务增长带来了数据量的激增,不同的数据需要衍生出各种数据服务,不同的数据服务抉择不同的数据库和数仓技术,比方 MySQL,Impala, Greenplum,ElasticSearch 等。为了最大化的升高运维老本,提供高性能的数据服务,做到真正的极速对立,从 2021 年上半年开始,诺亚数据智能部门开始上云,将自建 CDH 替换成阿里云对立大数据平台,同时正式引入 Hologres,替换外围的 Impala OLAP 剖析局部,晋升数据查问效率,全面打造金融数字化剖析平台。因而在本文中,咱们将会具体介绍诺亚从 CDH 迁徙阿里云大数据平台的前因后果,以帮忙更多的业务更加方便快捷的建设实时数仓。
业务挑战:自建 CDH 组件多运维难、交易指标多元查问慢
为了反对业务,诺亚原大数据架构采纳 Impala 和 CDH 构架构建,架构图如下:
在最后的架构中,咱们从 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 迁徙成阿里云大数据平台。迁徙后诺亚基于阿里云大数据平台架构图如下:
诺亚数据智能核心在 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 团队对咱们来说亦师亦友,陪伴咱们一路成长,也心愿未来可能一起打造金融大数据的最佳实际!