共计 4442 个字符，预计需要花费 12 分钟才能阅读完成。
对于银保监会对银行业，包含保险业在金融科技方面提出的一些要求。咱们后续会有几方面的重点建设方向：
第一个就是鼎力推动云化转型，包含云原生的转型和大数据云等一系列云化的转型，对于咱们的要求也是越来越高。
第二也是比拟重要的，继续优化科技与业务交融，用数字化反对企业数字化转型，通过为业务赋能为业务开展提供重要的科技根底。
第三就是夯实技术根底，加大数据治理和资产管理体系的建设。
第四是深入麻利转型
第五就是强化人才和文化的保障，这块也是十分的重要。
当初对银行的科技，包含银行的基础设施要求十分的高，很多传统基础设施的建设，曾经没有方法满足咱们当初面临的疾速扩大数据要求的场景，所以须要对原先的整体网络和零碎架构须要做一些调整。
咱们须要从新扫视咱们的整体网络架构的设计，推动网络架构重整，次要有几个方面的挑战：
一方面是咱们在数据文件的集成过程中，因为咱们这边的数据交换基本上还是以数据文件的形式，就是咱们会有规范的数据文件卸载，卸载完之后会通过一个相似于 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 来实现数据的共享，在不物理搬移的状况下，通过内存的形式实现数据共享，谢谢大家。
