【Alluxio&大型银行】科技赋能金融，兴业银行按下“大数据处理加速键”

关于银保监会对银行业，包括保险业在金融科技方面提出的一些要求。我们后续会有几方面的重点建设方向：

第一个就是大力推进云化转型，包括云原生的转型和大数据云等一系列云化的转型，对于我们的要求也是越来越高。

第二也是比较重要的，持续优化科技与业务融合，用数字化支持企业数字化转型，通过为业务赋能为业务展开提供重要的科技基础。

第三就是夯实技术基础，加大数据治理和资产管理体系的建设。

第四是深化敏捷转型

第五就是强化人才和文化的保障，这块也是非常的重要。

现在对银行的科技，包括银行的基础设施要求非常的高，很多传统基础设施的建设，已经没有办法满足我们现在面临的快速扩展数据要求的场景，所以需要对原先的整体网络和系统架构需要做一些调整。

我们需要重新审视我们的整体网络架构的设计，推进网络架构重整，主要有几个方面的挑战：

一方面是我们在数据文件的集成过程中，因为我们这边的数据交换基本上还是以数据文件的方式，就是我们会有标准的数据文件卸载，卸载完之后会通过一个类似于HDFS或GPFS这种分布式文件系统来进行共享，但是随着数据量的增大，随着加工次数、加工任务的增加，数据集成的任务的增加，导致GPFS或者HDFS文件系统在性能上和网络带宽上的压力非常的大，现在为了满足这些性能要求，GPFS跟HDFS的存储全部是全场存储，才能保证基本生产和 I/O存储量的要求。网络带宽的话，在本机房的网络基本能满足，但是一旦跨机房并发量就非常的高。

第二点是跨机房的数据加载的场景，我们之前的方案是用 Spark 直接跨机房把数据拉过来，但是对整个网络的开销非常的大。我们Spark的数据拉取作业一旦提起来的时候，基本上把我们两个同城机房的网络带宽全部打满了，就是万兆网全部打满，会影响到其他更加重要的交易业务的开展，所以对我们的挑战非常大。我们作为软件和系统设计者很少去考虑网络对我们带来的消耗，但是现在我们不得不面对这些给我们系统带来的压力。

另外一点就是信创这方面的压力也是非常大的，我们之前主要选择的是GPFS，它是IBM 的软件产品，在信创方面是不符合国家要求的，所以我们现在也是在逐步地换成国产的符合生产信创要求的文件存储系统。但因为文件存储系统对我们整个交换体系是非常关键核心模块，所以我们也不敢轻易更换，我们希望通过Alluxio来做一个缓存，来屏蔽我们下面不同的文件系统，通过这种方式来达到平稳过渡切换文件系统的目的，这就是我们机构为什么选择Alluxio的考虑。

讲一下跟Alluxio应用接触的历程，其实我们很早就开始关注Alluxio这个产品，但是那个时候可能还没有那么迫切的需要，我们只是作为一个前沿技术去研究，但是到了2019年出现了网络带宽那个问题之后，我们觉得可以通过Alluxio来解决我们跨机房网络加载的问题，所以我们在那个时间点开始测试Alluxio，然后逐步地在2020年的时候开始小规模地试用。

到了2021年的时候，因为我们当时计划重构我们的大数据平台，所以在大数据平台上全面推广Alluxio的使用，包括支撑整个大数据的Spark，Impala等组件的运行，在访问HDFS之前都先用Alluxio做一层缓存，包括所有的数据的入湖、归档这些操作之前，都会用Alluxio进行缓存，后面我们也会更多地去使用Alluxio。

现在介绍我们这边当前的Alluxio应用的具体的情况，我们这边分成两个机房，DC-A 机房跟DC-B 机房， DC-A机房是我们核心的交换域，交换域就是作为文件交换、数据加载的技术平台。现在这个域上部署的是Alluxio，用Alluxio进行缓存和远程拉取，我们的数据交换、数据入湖，包括数据计算、查询都是在Alluxio平台上运行的，所以我们其实已经在核心领域引入了Alluxio，作为们的重点文件系统做支撑，后面我们可能希望Alluxio平台能够通过两个不同的路径进行迭代演化。

我们现在一个场景一个场景地来介绍一下，首先介绍最开始使用Alluxio进行缓存的一个场景，我们原先在GPFS上把数据进行集成，数据集成之后要分发给不同的子公司或者分行，原先的做法就是直接在 GPFS上解压，解压之后往外发给分行，但是因为GPFS跟Spark之间没有原生的接口，所以我们的做法就是在 GPFS跟Spark之间加了Alluxio，先把GPFS上的压缩文件解压到Alluxio上，利用Alluxio跟Spark的集成能力。现在使用了Alluxio之后可以做到一次解压，把解压后的文件缓存到 Alluxio上，再用Spark从Alluxio拉取数据。解压的过程能够从原来的多次解压减少成一次解压。通过Alluxio的内存，我们又能够加快 Spark的数据的基层处理的速度。

另外一块是打算介绍缓存的分层，我们现在刚刚做，包括分层以及存算分离的一些做法，想通过Alluxio把我们的数据按照冷热关系进行分解，对于内存、SSD包括远程的HDFS，我们都想根据不同的需要进行分解，根据每天的实际运行情况，动态地往Alluxio上预先加载一些我们比较关心的热数据，加大查询引擎的性能。我们现在的查询引擎主要是用到Spark和Impala，Spark主要面向离线计算和处理的场景，对于大数据的查询产品，一般还是选择Impala来做，通过Alluxio预加载或者内存缓存，对一些关键的对时效性要求非常高的应用进行加速，从而保障这些关键应用在时效上能满足我们的要求，比如很多银行开门前的需求，或者一些快速查询和热点查询的需求，我们可以根据需要定制化数据存放位置来实现冷热数据的交互。这个功能很好用也能解决我们的问题，因为毕竟不可能所有数据都占SSD和内存，这样的话成本实在不太经济。

跨机房数据加载解决了我们一个非常大的问题，之前没有用Alluxio时，直接Spark远程拉取GPFS上的数据，我们两个计算机房之间的网络是万兆的带宽，基本上一拉取的时候，整个网络带宽打满，影响了其他交易系统的运行系统，导致经常被数据中心报故障，只能先暂停加载，后来通过引入Alluxio远程地把数据先拉到Alluxio上。通过Alluxio，我们可以把有需要的数据逐个从GPFS上拉到Alluxio，通过Alluxio跟Spark的原生结合能力，就能够支持非常高并发的峰值读写，这样在性能包括网络带宽还有并发性方面都能满足我们的要求。在Alluxio上我们也通过一些 TTL、Pin的策略实现了数据的自动式清理，所以也不需要去考虑太多的数据清理的工作。这点也是我们选择一个专用的系统来做这件事情的原因，大家都知道，这件事情可以通过手工或应用上的控制去做，但是如果我们有一个分布式文件系统能够直接把这个文件都清理和过滤掉，对我们来讲非常有帮助，节省了我们的很多工作量。

统一的数据生命周期的管理，今年开始想做的一个事情就是说把Alluxio作为我们底层多个文件系统之间的统一的接口，比如说我们现在的GPFS，包括我们很有可能引入的信创文件系统，包括 HDFS以及现在比较火热的一些对象存储，我们都想通过Alluxio统一的接口来进行接入，上端提供不同的访问接口，给各种计算，比如说数据采集、数据加工、报表，包括数据服务，数据科学等一系列的应用场景提供统一的文件访问入口。这个访问入口又能够提供一些数据，根据我们的编排规则能够对一些关键数据进行加速的处理。这个对于我们整体的规划是一个非常有意义的事情，既能做到统一又能做到各种层次的不同的逐项的选择，可以根据不同的发展情况，选择不同的存储系统，也可以选择不同的计算引擎来做不同的事情。但是文件管理包括元数据管理，包括我们看到的文件都能够通过同一个接口，我觉得对于我们所有做这种数据体系的人来讲都是一个非常幸福的事情，有这方面经验同学应该有同感。

今年在技术领域上，包括银行的技术领域上，对于存算分离架构的研究非常火热，因为虽然一般情况下，我们金融行业的技术热上会比互联网和社区要晚一些，但是现在已经传导到我们这边了，加速了我们在存算分离这种新的大数据架构上的研究，预言或者试用，这块对我们来讲也是很好的。因为我们现在的计算资源，包括计算资源的管理，包括租户的弹性的管理，都可以通过存算分离这种方式来实现，然后通过Alluxio进行租户存储资源的管理，这对我们来讲是很重要的，因为以前对于计算资源的弹性管理、租户管理其实是很简单的，都有很成熟的做法，但是对于存储这一块的资源隔离，包括资源的动态分配，都比较难做到，我觉得有可能通过Alluxio的权限控制，比如租户之间的数据访问的隔离，通过统一的存储能够实现不同数据、不同租户的数据按需存储，这对于我们进行大数据平台的租户管理来讲是一个很有帮助的方向。

我们来看一些测试，包括一些实际使用情况下的对比，对我们平台带来的读写能力的提升。数据访问模式这边的话，我们以HDFS进行对比，访问都是一次写入多次读取，根据我们的测试与实际生产环境的一些数据的验证，Alluxio缓存命中的情况下，相比HDFS效率能提高一倍，就是能够缩短50%的等待访问时效，相当于降低了HDFS的NameNode的压力，但是如果没有预加载就直接冷读，效率可能要比HDFS再延后一点，但是命中的情况下，有预加载的情况下提升是很大的，这点还是非常的有效果。

另外一点就是网络带宽压力，以刚才跨机房网络加载的情况为例，没用Alluxio的时候，我们的网络峰值会达到30GB/s，峰值非常的高，通过Alluxio的话，我们基本上能够把峰值降低到2GB/s，也就是占用1/5的万兆光纤的带宽，远程加载了之后，峰值非常明显降低，对我们的帮助也非常大。

1、我们后面可能需要Alluxio社区对我们实际企业应用在一些功能上提供帮助，或者在未来把一些功能集成到开源社区版本里面去，一个是Cache缓存的优化以及监控，最主要是监控这一块，因为对企业应用来讲，Cache的技能是怎么样的，监控哪些数据，正在产生哪些数据，这些东西我们都是很关心的，一旦系统出现故障，我们需要马上能够解决问题，所以监控这块非常重要。

2、第二点的话就是数据中台在存算分离架构的演进和技术的方案，希望能够把这种方案更多地共享出来，或者在社区内进行分享，做好租户隔离或者SLA控制，权限管理这块能够更加的优化一些。然后就是 Alluxio对计算引擎的深度优化，我知道Alluxio对Presto系统有很多的深度研究跟优化，因为我们这边用Impala，我们希望社区包括Alluxio这边能够对Impala引擎进行深度的优化，包括与Kubernetes的集成这一块。

3、另外一方面是我们自己的考虑，兴业银行这边总行和分行之间，我们希望能够通过Alluxio来做一个数据共享的方案，比如说有中心节点和分部的分中心节点这种企业架构，怎么能够通过Alluxio来实现数据的共享，在不物理搬移的情况下，通过内存的方式实现数据共享，谢谢大家。