摘要：基于数据湖架构，应用效率得以极大提升。经过几年发展，当前集群规模已经达到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生态云峰会》演讲内容改编。

 

点击关注，第一时间了解华为云新鲜技术~