关于大数据:FusionInsight怎么帮宇宙行建一个好的云数据平台

摘要： 基于数据湖架构，利用效率得以极大晋升。通过几年倒退，以后集群规模曾经达到 1000 多节点，数据量几十 PB，日均解决作业数大略是 10 万，赋能于 180 多个总行利用和境内外 41 家分行及子公司。

本文分享自华为云社区《FusionInsight 怎么帮「宇宙行」建一个好的「云数据平台」？》，作者：徐礼锋。

大数据技术的「演进趋势」

大数据从 2010 年开始到当初各种新技术层出不穷，最近围绕云基础设施又有十分多的翻新倒退。

很多企业晚期的数据分析系统次要构建在数据仓库之上，有的甚至连数据仓库都没有，应用 TP 类关系型数据库间接对接 BI 零碎实现。这类零碎个别以物理机状态的一体机部署，分布式能力比拟弱，随着数据规模微小增长，尤其是挪动互联网倒退，传统数据库难以撑持这种大体量的数据分析需要。

在这个背景下，Hadoop 技术应运而生并飞速发展，无效地解决了大数据量的剖析和解决需要。Hadoop 最开始的利用多用于日志类非关系型的数据处理，次要基于 MapReduce 编程模型，随着 SQL on Hadoop 的倒退，关系型数据的解决能力也越来越强。

晚期的 Hadoop 次要基于物理机部署，始终到当初依然是最成熟的部署模式。尽管 Hadoop 计算与存储之间是解耦的，然而绝大部分实际都还是会把计算与存储进行一体化部署，Hadoop 调度零碎会把计算调到数据所在位置上进行就近计算，就近计算大大提高了零碎的解决能力，前期 Spark、flink 等都继承了这种架构劣势。

自从亚马逊推出云 IT 基础设施以来，越来越多的企业都将本人的 IT 业务迁徙到云上，因而，在云上发展大数据业务牵强附会。基本上所有的云厂家也都提供云上大数据解决方案。

那么，在云上部署大数据与原来基于物理机的 on premise 部署形式又有哪些不同呢？

首先，尽量利用云的计算资源，包含云虚机、容器以满足资源的疾速发放，包含裸金属服务 BMS 以提供近似物理机的高性能解决计算资源。

其次，各云厂商都推出存算拆散的大数据架构，亚马逊是最早实现对象存储代替 HDFS，因为对象存储绝对 HDFS 三正本老本绝对较低。计算与存储拆散之后带来了很多益处，然而也面临着诸多挑战。这个方向始终在一直地欠缺，目前，云上大数据存算拆散曾经倒退的比拟成熟。

Lakehouse 是最近十分热的一个大数据概念。2020 年 1 月份 databricks 发表的一篇博客中首次提到 Lakehouse 这个概念。之后，在往年的 1 月份再次发表一篇论文，系统阐述如何构建 Lakehouse。

很多数据分析系统都构建在数据仓库、数据湖的根底上，有些将两者联合造成如图的两层架构，大型企业前面这种模式更多。这种数据湖、数据仓库的两层架构到底存在哪些问题呢？

能够看到，数据湖和数仓的很多数据是雷同的，这样就会导致以下三个问题：

第一，数据要存储两份，相应的存储老本翻倍。

第二，数据湖和数仓的数据存两份，就须要保护数据的一致性，这个过程次要通过 ETL 来保障，保护代价比拟高，而且往往很难保持一致，可靠性不是很高。

第三，数据的时效性。数据湖将大批量的数据集成起来并不容易。因为数据湖大多基于 Hive 来治理，而其底层 HDFS 存储并不反对批改，所以数据仅反对追加的模式来集成。而业务生产零碎的数据变动不是只有追加的数据，还有很多更新的操作，如果要对数据湖的数据进行更新，就须要按分区先合并后重写。这样就减少了数据合并解决的难度，更多的时候只能通过一天合并一次的 T + 1 的模式，T+ 1 的模式也就意味着大部分数据对后端利用的可见性差了一天，以后看到的数据实际上是昨天的，意味着数仓外面的数据始终并不陈腐。

LakeHouse 就是冀望解决数据湖与数仓的交融剖析的问题。LakeHouse 提出通过提供 ACID 的凋谢格局存储引擎来解决数据的时效性问题，凋谢格局另一个益处在于数据湖里的数据能够面向多种剖析引擎，如 Hive、Spark、Flink 等都能够对数据进行拜访剖析, 而且 AI 引擎也能够拜访 Lakehouse 数据做高级剖析。

对于诸如 Hudi、Iceberg、DeltaLake 增量数据管理框架，因为其提供了 ACID 的能力，数据能够进行更新操作以及并发读写，因而对存储数据存储要求也更高，比方须要反对工夫旅行、零拷贝等能力，能力保证数据随时能够回溯。

Lakehouse 除了撑持传统的 BI 以及报表类的利用，还要反对高级的 AI 类的剖析，数据分析师、数据科学家能够间接在 Lakehouse 进行数据科学计算和机器学习。

另外，Lakehouse 的最佳实际是基于存算拆散架构来构建。存算拆散最大的问题在于网络，各云厂家以及大数据厂家，都摸索了很多的伎俩来解决云存储自身拜访的性能问题，如提供本地缓存性能来进步数据处理的效率。

Lakehouse 架构能够实现离线与实时的交融对立，数据通过 ACID 入湖。

如图所示是经典的大数据的 Lampda 架构，蓝色的解决流是批处理，红色的则是流解决，在应用层造成实时合并视图。这个架构存在的问题就是批处理和流解决是割裂的，数据管理之间的协同比拟麻烦，而且不同的开发工具对开发要求的能力不同，对系统维护工程师和数据开发人员都是较大的挑战。

针对这种的状况，Lakehouse 架构能够将批处理和流解决合并成一个 Lakehouse view，通过 CDC 把业务生产零碎数据实时抽取到数据湖，实时加工后送到后端 OLAP 的零碎中对外开放，这个过程能够做到端到端的分钟级时延。

Lakehouse 自身的概念比拟新，大家都还在做着各种各样的实际以进行欠缺。

FusionInsight 在工商银行实际的三大阶段

工行晚期次要以 Oracle、Teradata 构建其数据系统。数仓为 Teradata，数据集市是 Oracle Exadata。

2013 年开始，咱们在工行上线了银行业第一个大数据平台，过后的大数据平台以繁多的利用为主，例如一些日志剖析、TD 的新业务卸载和明细查问。

2015 年之后，对数据系统进行整合合并，包含通过 GaussDB 代替 Teradata 数仓，造成了交融数仓，在工行被称之为一湖两库，以 FusionInsight 构建数据湖底座以反对全量的数据加工，同时实时剖析、交互式剖析等业务也在其中得以发展。

2020 年初，开始构建云数据平台，将整个数据湖迁徙到云上以实现大数据的云化和服务化，同时构建存算拆散的架构。另外还引入 AI 技术。

工行的技术演进方向是从繁多走向多元、从集中式走向分布式、从孤立零碎走向交融、从传统 IT 走向云原生的过程。

第一代大数据平台更多的是依据利用需要按需建设，这个期间对 Hadoop 到底能解决什么问题并没有很深的认知。

首先想到的是解决业务翻新，以及在数仓里做不进去的业务，比方把大批量的数据合并作业卸载到 Hadoop 零碎里。

这个期间短少零碎布局，导致单集群规模小，集群数量一直增多，保护老本较高，资源利用率低。另外，很多数据是须要在多个业务间共享的，须要在集群间进行拷贝迁徙，大量冗余的数据减少了资源的耗费。同时，数据须要依据不同的场景存储在不同的技术组件中，利用不同的技术组件进行解决，也导致 ETL 链路较长、开发效率低，保护的代价高。因而，须要对整个大数据平台的架构进行优化。

第二阶段将多个大数据集群进行了合并，造成数据湖，其特点在于数据处理层统一规划，集中入湖、集中管理。使得整体的治理、保护、开发效率失去极大晋升。

将原始数据入湖之后，还会对数据进行一些加工解决以造成汇总数据和主题数据，并在数据湖里进行集中治理，数据加工解决后送到数仓或者数据集市，以及后端的其余零碎里。

基于这种架构，数据湖的利用效率得以极大晋升。通过几年倒退，以后集群规模曾经达到 1000 多节点，数据量几十 PB，日均解决作业数大略是 10 万，赋能于 180 多个总行利用和境内外 41 家分行及子公司。

然而，将所有数据存进一个集中的数据湖也带来了很多治理方面的难题。

数据湖撑持的业务和用户对 SLA 高下的要求不尽相同，如何给不同部门、不同业务线、以及不同用户的作业进行对立治理比拟要害，外围是多租户能力，Hadoop 社区 YARN 调度性能晚期并不是很强，上千个节点的治理能力较弱，尽管当初的新版本得以改良。

晚期的集群到几百个节点后，调度管理系统就难以撑持。因而咱们开发了 Superior 的调度器加以欠缺。工行的 1000 节点集群在银行业算是比拟大的数量级。咱们在华为外部构建了从 500 到几千直到 10000 节点的一个集群，这个过程曾经对大集群的治理能力提前进行铺垫，在工行的利用就绝对比较顺利。

如图所示，咱们把整个的资源管理依照部门多级资源池进行治理，通过 superior 调度器，依照不同的策略进行调度以撑持不同的 SLA。整体成果而言，资源利用率得以成倍晋升。

还有一些其它组件，尤其是像 HBase 的 region server 是基于 JAVA 的 JVM 来治理内存，能利用的内存很无限，物理机资源根本用不满，资源不能充分利用。

为了解决这个问题，咱们实现在一个物理机上能够部署多实例，尽量将一个物理机的资源充分利用，ES 也是依照这种形式来解决。

集群变大之后，其可用性和可靠性也存在着很大的问题。大集群一旦呈现问题导致全面瘫痪，对业务影响十分大。所以，银行业必须全面具备两地三核心的可靠性。

首先是跨 AZ 部署的能力，AZ 理论是属于云上的一个概念，传统的 ICT 机房里更多的是跨 DC 数据中心的概念，跨 AZ 部署意味着一个集群能够跨两个 AZ 或者三个 AZ 进行部署。

Hadoop 自身具备多正本机制，以多正本机制为根底，能够将多个正本搁置在不同的机房里。然而以上条件并非开源能力能够撑持，须要补充一些正本搁置和调度的策略，在调度时要感知数据到底搁置在哪个 AZ，任务调度到相应的 AZ 保证数据就近解决，尽量避免 AZ 之间因为数据传输带来的网络 IO。

另外，容灾能力还能够通过异地主备来实现，跨 AZ 能力要求机房之间的网络时延达到毫秒级，时延太高可能无奈保障很多业务的发展。异地的容灾备份，即一个主集群和一个备集群。平时，备集群并不承当业务，仅主集群承载业务，一旦主集群产生故障，备集群随之进行接管，然而相应的代价也会较大，比方有 1000 个节点的主集群，就要构建 1000 个节点的备集群，所以少数状况下，主备容灾更多的是仅构建要害数据要害业务的备份，并非将其全副做成主备容载。

大数据集群须要一直扩容，随着工夫的推移，硬件会升级换代，升级换代之后必然呈现两种状况，其中之一就是新洽购机器的 CPU 和内存能力，以及磁盘的容量，都比原来增大或者升高了，须要思考如何在不同的跨代硬件上实现数据平衡。

换盘的操作也会导致磁盘的不平衡，如何解决数据平衡是一个很重要的课题。

咱们专门开发了依照可用空间搁置数据的能力，保障了数据是依照磁盘以及节点的可用空间进行搁置。同时，对跨代节点按规格进行资源池划分，对于晚期比拟老旧且性能绝对差一些的设施，能够组成一个逻辑资源池用于跑 Hive 作业，而内存多的新设施组成另一个资源池则用来跑 spark，资源池通过资源标签进行辨别隔离，别离调度。

集群变大之后，任何变更导致业务中断的影响都十分大。所以，降级操作、补丁操作都须要思考如何保障业务不会中断。

比方对 1000 个节点集成进行一次版本升级。如果整体停机降级，整个过程至多须要破费 12 个小时。

滚动降级的策略可实现集群节点一个一个滚动分时降级，逐渐将所有节点全副升级成最新的版本。然而开源的社区跨大版本并不保障接口的兼容性，会导致新老版本无奈降级。因而咱们研发了很多的能力以保障所有版本之间都能滚动降级。从最早的 Hadoop 版本始终到 Hadoop3，所有的组件咱们都能保障滚动降级。这也是大集群的必备能力。

数据湖的构建解决了工行的数据管理的难题，但同时也面临着很多新的挑战和问题。

一般而言，很多大企业的硬件都是集中洽购，并没有思考到大数据不同场景对资源诉求的不一，而且计算与存储的配比并未达到很好的平衡，存在较大的节约。

其次，不同批次的硬件之间也存在差别，有些可能还会应用不同的操作系统版本，导致了一个集群内有不同的硬件、不同的操作系统版本。尽管能够用技术手段解决硬件异构、OS 异构的问题，然而继续保护的代价相当高。

再次，大数据手工部署效率低。往往发展一个新业务的时候，从硬件的洽购到网络配置、再到操作系统装置，整个零碎交付周期至多须要一个月。

最初，资源弹性有余，如果上新业务时面临资源有余，就须要扩容。申请洽购机器和资源导致上线的周期较长，咱们有时给客户部署一个新业务，往往大多工夫是在等到资源到位。另外，不同资源池之间的资源无奈共享，也存在着肯定的节约。

所以工行要引入云的架构。

FusionInsight 很早就上了华为云，即华为云上的 MRS 服务。

当下工行和其余很多银行都在部署云平台，将大数据部署到云平台上。但大规模的大数据集群部署到云上还存在着一些挑战，基于云原生的存算拆散架构来部署大数据业务有很多劣势。

首先，将硬件资源池化，资源池化之后对下层就是比拟规范的计算资源，计算和存储能够灵便的扩大，利用率绝对较高。

其次，基于云平台的大数据环境搭建，全副自动化，从硬件资源筹备到软件装置，仅用一小时实现。

再次，在申请集群扩容资源弹性时，无需筹备，能够很快的在大资源池进行对立调配。一般而言，云上只有预留了资源，空间资源能够很快退出到大数据的资源池里，新业务上线也会变得十分麻利。

再说存算拆散，存储次要是以对象存储为主，用低成本的对象存储代替原来 HDFS 的三正本的能力，对象存储个别提供兼容 HDFS 的接口，在此基础上，对象存储能够给大数据、AI 等提供一个对立的存储，升高存储老本，运维的效率得以进步。

然而，对象存储的性能不是很好，须要围绕大数据的业务特点解决以下问题。

第一个，就是元数据，因为大数据是个重载计算，在计算的过程中读 IO 很高。读取数据的过程中。对象存储的元数据性能是个很大的瓶颈，因而须要晋升元数据的读写能力。

第二个，网络带宽，存储与计算之间的网络 IO 对网络带宽的需要比拟高。

第三个，网络时延，大数据计算是就近计算，数据在哪里相应的计算就会在哪里，存储数据是优先读本地盘，之后是读网络。时延存在肯定的敏感性。

咱们次要是从缓存、局部计算下推上做一些优化，整体上而言，存算拆散架构的性能跟一体化相比，除了个别用例有差距，整体性能都更高，尤其是写场景，因为写对象存储是写 EC，而不必写三正本，写 1.2 个正本就能够了。

最初，整体的 TCO 大略失去 30%~60% 的降落。整体的性能与周边其余产品比照还是具备很大的劣势。

大数据部署到云上，对于大集群而言，虚机并没有太大劣势，因为数据池子够大，虚机还会带来性能的损耗，而且其性能与物理机有肯定差距。而且，基于 SLA 隔离要求，大数据资源池在公有云部署，很多时候还是须要独占，其资源无奈和别的业务共享。

而裸金属服务实际上能够很好的解决这些问题，它的性能靠近物理机，而且能够分钟级实现裸金属服务器的发放，包含整个网络配置，OS 装置。

网络局部有专门的擎天网络加速卡，对裸机网络进行治理，而且网络性能比原来的物理网卡的性能更高，在裸金属服务器上发展大规模大数据业务是云上的最佳部署计划。

将来瞻望：湖仓一体

工行和咱们也在摸索湖仓一体的解决方案。

华为云湖仓一体在存算拆散的根底上，将数据管理层独立进去，其中蕴含了几个局部，第一个是数据集成，数据从各种各样的内部零碎入湖。第二个是元数据集成，因为 Hadoop 数据湖上的元数据通过 Hive 治理，咱们提供一个兼容 Hive Metastore 的独立元数据服务。第三个是数据的受权以及脱敏这些安全策略，咱们要将其在 Lake Formation 这一层进行对立闭环。

数据的底座构建好之后，数据分析服务如大数据的服务、数仓的服务、图计算、AI 计算都是在同样的一个数据视图上进行计算解决。数仓 DWS 的服务实质是本地存储，数仓也能够通过它的一个引擎拜访 Lakehouse 中的数据。这样数仓本人在本地有一个减速的数据层，同时也能够拜访 Lakehouse。

在此基础上咱们通过一个架构来实现这三种湖，继续演进。

蓝色数据流是离线数据流，实现离线数据湖能力，数据通过批量集成，存储到 Hudi，再通过 Spark 进行加工。

红色数据流是实时流，数据通过 CDC 实时捕捉，通过 Flink 实时写入 Hudi；通过 Redis 做变量缓存，以实现实时数据加工解决，之后送到诸如 Clickhouse、Redis、Hbase 等专题集市里对外提供服务。

同时，咱们还开发了 HetuEngine 数据虚拟化引擎，将数据湖外面的数据以及其余专题集市里的数据进行多数据源关联剖析，造成逻辑数据湖。

尽管 HetuEngine 能够连贯不同的数据源，但并不意味着所有利用只能通过 HetuEngine 来拜访数据，利用还是能够通过各数据源原生接口进行拜访。仅须要不同专题数据之间进行联结剖析时，才须要通过 HetuEngine 对立拜访。

如下是具体的施行打算：

第一个，引入 Hudi，构建一个数据湖的数据管理，每年大略能够节俭几百万。

第二个，引入 HetuEngine，实现数据湖内的数据免搬迁的查问剖析。防止一些不必要的 ETL 过程。

第三个，引入 ClickHouse，ClickHouse 在 OLAP 畛域有着十分好的解决性能和很多劣势，因而思考将其在工行落地。

数据湖以 Hive 作为存储，采纳一天一次批量集成、批量合并的计划，即 T + 1 的数据处理模式。这种模式存在几个比拟大的业务痛点：

第一，数据延时比拟高，后端服务看到的数据并不是最新的。

第二，跑批作业在夜里进行，而白天资源利用率较低，但集群资源是依照高峰期需要来构建，造成很大的资源节约。

第三，Hive 不反对更新，数据合并须要开发较多代码实现，如把新数据长期表与原 Hive 表进行左右关联后笼罩原来整表或者局部分区表，开发成本比拟高，业务逻辑简单。

引入 Hudi 就能够在很大水平上解决这些问题。数据通过 CDC 入湖，通过 Spark 或者 Flink 写入 Hudi，反对实时更新，端到端能够做到分钟级的时延。数据以十分小的微批模式合并到数据湖，扩散跑批使得资源白天和早晨都能失去充分利用，数据湖集群 TCO 预计能够降落 20%。此外，数据集成脚本开发能够利用 Hudi 的 Update 能力，原来 Hive 要写几百行的代码，只需一行脚本即可实现，开发效率晋升很大。

工行数据湖应用 Hive 来承载灵便查问业务，如 SAS 应用 Hive SQL 来拜访数据湖，拜访效率比拟低，响应工夫长，并发能力也有余。

另外数据湖与数仓的两层架构导致了大量的反复数据，有较多关联剖析需要，关联解决必然波及到湖仓之间大量 ETL。比方为了撑持 BI 工具的剖析诉求，须要数据湖和数仓数据关联解决加工，并将加工之后的数据导入 OLAP 引擎。整体数据链路比拟长，剖析效率和开发效率都很低。

通过 HetuEngine 数据虚拟化实现湖仓协同剖析，一方面代替 Hive SQL 拜访 Hive 的数据，只需 1 / 5 的资源即可撑持大略原来 5 倍并发，同时拜访时延降到秒级。另一方面可同时拜访 Hive 和 DWS 提供秒级的关联查问，能够缩小 80% 的零碎间的数据搬迁，大量的缩小 ETL 的过程。

传统的 OLAP 计划个别用 MySQL、Oracle 或者其余的 OLAP 引擎，这些引擎因其解决能力无限，数据个别依照专题或者主题进行组织后与 BI 工具对接，导致 BI 用户和提供数据的数据工程师脱节。比方 BI 用户有一个新的需要，所需的数据没有在专题集市中，须要将需要给到数据工程师，以便开发相应的 ETL 工作，这个过程往往须要部门间协调，工夫周期比拟长。

当初能够将所有明细数据以大宽表的模式加载 Clickhouse，BI 用户能够基于 Clickhouse 大宽表进行自助剖析，对数据工程师供数要求就会少很多，甚至大部分状况下的新需要都不须要从新供数，开发效率和 BI 报表上线率都会失去极大晋升。

这套方法论在咱们外部实际成果十分好，原来咱们基于传统 OLAP 引擎建模，受限于开发效率，几年才上线了几十个报表。然而切到 Clickhouse 后，几个月之内就上了大略上百个报表，报表开发效率极大晋升。

注：本篇博客依据雷锋网举办的《银行业 AI 生态云峰会》演讲内容改编。

点击关注，第一工夫理解华为云陈腐技术~