【摘要】
随着业务线上化、移动化和场景化比例越来越高，数据仓库数据面临数据规模爆发式增长和数据类型多样性等问题，单一的数据仓库技术已无法完全应对。为此银行启动了融合数据湖建设。本文对数据仓库和数据湖的技术路线进行了分析对比，简述了“湖仓一体”架构的必要性；同时从银行数据湖存储技术路线评估与选型经验，到基于专业分布式存储存算分离架构的建设过程，以及融合数据湖项目所取得的成效做了详细分享。
【作者】dragon1220
，
就职于某银行金融科技部，存储工程师。主要负责存储实施方案设计及存储设备管理。擅长集中式存储和分布式存储整体架构的方案制定以及存储容灾建设等方面工作。
一、背景介绍
随着银行业数字化转型进程的加快，以及数据驱动战略在银行的落地实践，2019年我行围绕分布式数据仓库和大数据技术，构建了一套满足一站式数据集成、存储、整合、计算与开发的数据技术中台，解决了海量数据存储与分析的问题，支撑了行内商业决策与各类应用规模化交付。
随着行内业务的发展，业务线上化、移动化和场景化比例越来越高，相应地也带来了数据规模爆发式增长和数据类型多样性等问题。尤其是在数据规模方面，数据仓库作为行内主要的基础设施，我们围绕数据仓库建设的数据整合平台承接了行内大量的贴源、明细数据。3年间其存储的数据总量增加了2倍多，基于数据仓库架构的应用数量增长到60多个，数据仓库扩容已趋于常态化，数据存储成本占全行信息科技预算的比例也越来越高，需要进行架构优化以实现整体TCO更优。同时，以RPA、人机交互、知识图谱等为主的人工智能技术对半结构、非结构数据的存储、特征提取以及数据加工提出了新的要求，单一的数据仓库技术已无法完全应对上述需求。
二、业务需求分析及融合数据湖建设思路
为解决数据爆发式增长问题，在满足后续业务系统发展需求的前提下尽可能降低商务采购成本，经过调研，数据湖技术进入了我们的视线。通过对比，我们发现数据湖和数据仓库作为大数据体系架构下两条不同的技术演进路线，具有各自的优势和局限性。具体表现在以下三个方面。
1）数据湖支持结构化、半结构化、非结构化数据的存储与加工。而数据仓库基本上只支持结构化数据。
2）数据湖按照原样存储数据，无需事先对数据进行结构化处理，这也造成数据湖缺乏像数据仓库的数据管理能力，数据质量较差。而数据仓库在处理数据之前要先进行数据梳理、定义数据结构后才可以进行入库操作。
3）数据湖在灵活性上具备天然优势，开源大数据引擎只需遵循相对宽松的兼容协议就能够读写数据湖中的数据。而数据仓库只对特定引擎开放，并作了深度定制优化，进而换取更高的存储与计算性能。
经过对比，数据湖与数据仓库两者虽然能力互补，但通过过论证，从技术层面却很难将两者合并成一套系统。通过对业内主流技术的调研，发现借助逻辑数据仓库的架构理念，采用湖仓协同工作的方式，将数据湖、数据仓库与数据类服务连接成为一个整体，数据在其间按需自由移动，以逻辑统一的方式为用户提供服务。而数据仓库作为数据库技术在大数据时代的一种产品形态，其安全稳定、高效易用和完善而精细的数据管理能力满足了金融行业对海量数据的分析需求。因此在金融行业依然对数据仓库依赖较重的前提下，如何更好地兼容企业数据技术中台建设的历史现状，同时将数据湖的灵活性与数据仓库的企业级能力有机结合，成了我们数据技术中台下一步建设的重点。
通过对“湖仓一体”架构方案的深入研究与学习，我们也逐步明确了我行融合数据湖的建设思路：
1）在数据仓库已经建设完善的前提下，数据湖可以作为数据仓库的补充，用于存放数据仓库温冷数据，例如卸载数据仓库的部分重载，历史数据的存储与查询。
2）数据湖可扩展其他场景下的数据探索与AI分析能力，原有数据仓库对外服务保持不变，依然以整合层、集市层、应用层批处理任务加工和报表查询等应用场景为主。
3）是在逻辑层面，采用湖仓任务一体化开发、元数据统一管理以及联邦查询等技术将数据湖、数据仓库与数据类服务连接成为一个整体，满足用户的一体化使用需求。
三、数据湖存储技术路线评估与选型
经过对上述场景业务需求的分析，我们计划新建一套数据湖来对现有数据仓库进行容量和功能性的补充。在数据湖整体建设方案中，其中重要部分就是如何构建一个具备弹性扩展能力，建设成本较低，且能兼容现有大数据平台各类功能组件的存储资源池。
在存储选型时，我们根据数据湖实际的应用场景，其对存储的需求主要如下：
1）IO读写稳定，并发流量大；
2）建设成本相对低廉，易于扩展；
3）适用于保存海量非结构化数据
4）数据量级超过PB级；
5）数据接口类型丰富，兼容性强；
经过对存储需求的分析，我们评估下来，由于数据量太大，采用服务器本地盘进行数据存储成本太高，服务器集群规模过大机房占用空间大、维护难度大、扩容也不方便，最后计划采用基于商用分布式存储的存算分离技术路线来构建数据湖的存储底座。
为了论证方案有效性和可落地性，我们对业内主流分布式存储厂商设备进行了现场POC测试。测试内容主要包括存储设备的功能性、稳定性、可扩展性、集群硬件兼容性、存储性能、大数据接口兼容性等场景。
经过对现场POC测试，商用分布式存储的架构可满足本次的建设需求，其中，华为OceanStor Pacific分布式存储在比较关注的几个测试项中，测试结果为最优，主要为如下几个方面。
1）大数据组件支持能力测试。
支持标准完整的Hadoop文件系统语义。支持Zookeeper、Yarn、Spark、Flink，Hive、Hudi等各类大数据组件。在测试中，华为存储在各测试项均测试通过，可无损接入现有的CDH集群，数据类型和存储方式无需进行转换。
2）存储集群性能测试。
在性能测试中，华为OceanStor Pacific整体的性能结果为最优。尤其是在小文件混合（64KB及以下场景）读写测试中，华为存储的优势尤为明显。
3）易扩展性，集群内CPU异构兼容性。
华为分布式存储同一集群可支持不同型号和类型的芯片混合部署，方便后续进行的设备扩容。
4）集群可靠性测试。
高可用性测试中，在硬盘故障、存储节点故障、交换机故障、单条网络链路等故障场景中，华为存储整体的测试结果为最优。尤其是在存储集群进行存储节点扩容时，单个存储节点发生故障的场景，在故障发生时，华为分布式存储集群的IO读写虽短时间内出现了抖动，但并未中断，随即恢复正常，后续并未出现性能下降的情况。
基于POC测试结果及实际业务需求，我们最终选定了使用华为OceanStor Pacific分布式存储来搭建数据湖的数据底座。
四、数据湖存储建设及维护经验
2021年，我们在生产中心搭建了一套21节点X86架构的分布式存储集群，EC纠删码等级为18+3，启用存储协议为HDFS。在分布式存储集群正式启用后，为数据湖提供了PB级容量的存储空间，而数据湖、数据仓库与数据类服务通过湖仓任务一体化开发、元数据统一管理等技术方式，从逻辑上连接成为了一个整体，实现数据在其间按需高效流转与统一管理，满足全行不同业务条线的个性化多维度的数据统计分析需求，达到了我行融合数据湖的建设目标。
数据湖存储自2021年投产至今，运行稳定，性能表现情况良好。经过近年对存储设备日常的维护管理，我有如下几点经验总结如下，仅供各位同行参考。
1、存储建设规划
首先是数据保护方式的选择。经过实际性能测试发现，在HDFS场景下，存储使用的副本及EC纠删码两种数据保护方式。在满足数据湖性能要求的前提下，为降低建设成本，我们本次计划使用EC纠删码数据保护方式，与服务器本地盘副本方式对比，在可用容量一致的情况下，可减少近一倍的硬件采购成本。
其次，由于数据湖所需要的存储容量较大，其后端对应的存储节点也会相对较多。建议提前对分布式存储做好建设规划。例如这套存储集群的预期规模大小，机柜的物理位置及电力，网络交换机的接口余量，新老设备的兼容能力，等等。这些因素都在某种程度上影响了集群整体的扩容能力及规模大小。个人认为，如果分布式架构存储选择使用纠删码的数据冗余模式，+3是绝大部分厂商推荐配置的最大冗余配比，所以从设备冗余配置来考虑，建议单个分布式存储的集群规模要控制一下，不超过3至4个机柜为宜，这样交换机接口使用率、机柜使用空间比例、分布式集群整体性能等都可以达到一个较为理想的状态。
2、存储节点配置选型
存储节点的配置选型，第一要考虑的便是2U存储节点和4U存储节点间的选择。我个人建议是用于重要业务系统场景的尽量选择2U存储节点，用于备份归档场景业务系统场景的则可选择高密度的4U存储节点。本次数据湖使用的分布式存储集群我们选用的是2U的存储节点。首先，同等容量和数据盘配置的情况下，需要配置更多的2U存储节点，这样会得到一个更高的存储集群性能。其次，EC纠删码的可靠性是基于硬盘和节点两方面的，对于重要业务系统场景，如想达到+2或者更高的冗余级别，若配置4U存储节点有可能会出现节点数过多从而导致容量过剩的情况。
第二要考虑的就是硬盘类型和大小的选择。存储的硬盘故障在我们日常存储故障统计中，占比是稳超90%的，所以存储硬盘的选择也很重要。从数据盘大小角度来说，由于我们本次建设的存储集群主要用于冷数据保存，对IO时延等并没有特别高的要求，故我们本次选择的是大容量的HDD盘。如果对存储集群性能要求有一定要求，可选用SSD盘。分布式存储一般配置的HDD盘都比较大，6TB、8TB至16TB、18TB等。本次数据湖使用的分布式存储集群我们选用的是6TB大小的HDD存储硬盘。从数据保护方式来说，虽然无论是副本或者EC纠删码均可容忍多块硬盘同时发生故障，但从新换硬盘数据重构时间来说，实际情况是更换使用率达到60%的单块6TB HDD盘时，数据重构大概需要24个小时，并且在平台较为繁忙的时段，这一时间甚至会拉长到2-3天，这其实也一定程度上增加了存储集群运行的风险。因此我个人建议是用于重要业务系统场景的尽量选择小容量HDD盘，用于备份归档场景业务系统场景的则可选择大容量HDD盘。而且从性能的角度来说，在总容量需求相同的情况下，HDD盘的大小越小，配置硬盘的数量也越多，可提供的整体集群性能也就更好一些。同时，也要加强对存储集群的日常巡检和监控，对风险盘、问题盘提前处理，以防出现多块HDD存储硬盘故障的场景。
3、存储实施部署
分布式存储从设备实施的角度来看，就是多台多硬盘服务器所构建成的一个软件定义存储资源池。与服务器不同的是，分布式存储集群需要的功能性网段会更复杂一些。例如我们在实际的实施中，要为存储分别分配BMC网络、管理网络、业务网络、存储集群网络以及双中心复制网络。建议在实施时，参照设备原厂的规划建议，提前对网络进行规划，并为未来可能进行扩展的存储集群，预留足够的地址数量，以及存储集群内部交换机端口。
在实施时，建议要根据自己内部的网络架构，提前确认业务数据的具体流向及负载大小。例如我们在实施前，对我行现有的数据仓库、数据湖与分布式存储集群间的业务访问方式进行了确认，了解到分布式存储集群间到数据仓库、数据湖有很大的网络流量，到外围系统的业务流量相对较小。经过评估，为提升整体架构的访问效率，降低网络跨区域间防火墙的压力，在存储集群实施部署前，我们提前对现有的数据仓库、数据湖业务网络架构进行了调整，在其业务网络交换机前端增加了一组汇聚交换机。汇聚交换机添加完成后，我们将这套分布式存储集群的业务网络作为一个大数据业务集群进行规划，将存储集群的业务接入交换机连接在了大数据业务网汇聚交换机上，从而有效降低了对网络跨区域间防火墙的压力。后经我们实际观察，数据仓库、数据湖访问存储集群的流量峰值流量会达到15GB/s，日常流量也经常维持在GB/s级别。
最后是存储集群对外提供服务的方式。建议使用域名方式对外服务，这样不仅可以充分利用存储集群内部自身的负载均衡算法策略，也可以规避掉存储集群集群由于扩容或者故障处理引起的节点地址变化，减少客户端存储访问配置的修改。
4、存储集群扩容
我们对数据湖使用的分布式存储集群进行了2次扩容。在数据湖存储建设初期，搭配国产芯片的分布式存储并未在金融行业大规模使用，我们在选型时还是优先选择了X86架构。但我们在当初选型时，考虑到了国产分布式存储产品是否支持CPU异构和融合部署，是否能实现业务系统底层数据在不同存储池之间进行数据迁移迁移。在进行存储集群规划设计时，也已经提前为未来硬件架构的更迭及新老替换做了准备，即业务数据由非信创存储节点向信创存储节点逐步实现数据迁移做了准备。
2022年，我们对现有存储集群扩容了5个存储节点。这5个存储节点HDD硬盘配置为6TB，和现有存储节点配置一致。CPU类型为X86，但型号略高于现有存储节点。我们将新增节点在线加入了已有的硬盘池中，整个扩容操作业务层无感知。
2023年，我们对现有存储集群扩容了21个存储节点。这21个存储节点HDD硬盘配置为6TB，和现有存储节点配置一致。CPU类型为鲲鹏，为ARM架构，和现有存储节点配置不同。在实施过程中，我们将新增的21个ARM节点新建了一个独立的硬盘池，和原有26个X86节点的硬盘池并列，同时让这两个硬盘池属于同一个存储池，业务数据可通过存储集群自身的负载均衡能力，可将X86硬盘池中的数据，在后台自动逐渐平均分布在两个硬盘池中。这样的话，存储集群整体对外仍是一个统一接口，数据仓库及数据湖无需进行业务端的接口改造。
5、未来规划的思考
当前数据湖存储节点数已达47个，运行时间3年左右，对于这套存储集群后续扩容、新老设备替换、硬件架构更迭，我有如下一些想法。
我行数据湖存储中数据已保存近3年，可以使用存储自身的数据分层技术，通过各种限制条件，如文件生成时间、文件访问时间、文件名等，将现有的一部分历史数据或者访问频次较低的数据，存放在相对廉价的存储集群上，对数据湖存储进行“瘦身”，这样就变相实现了存储集群扩容，可有效降低后续采购成本，并且存储集群整体对外仍是一个统一接口，现有的数据仓库及数据湖无需进行业务端的接口改造。
负责基础设施的同事，应该都经历过存储设备新老替换的事情。同样，这种数据分层的思路，也可以为我们的存储设备新老替换提供另一种解决方案。我们之前实施过多次新老设备的替换，在实际实施中一个难点便是历史数据导入时间和业务停机窗口时间的冲突。如果参考上面的方法，我们可以将新部署的存储节点做为一个新的存储池加入存储集群，通过文件保留策略，将绝大部数据均转移入新的存储池中，再在域名解析的配置中，逐步替换老旧节点的业务地址为新增节点地址，这样在不需要客户端做大量配置修改的前提下即可较为快速的实现新老设备的切换。
如上内容目前均是我个人的一些想法，仅供大家参考。我们近期也在准备这方面的测试，如可行将会成为我们数据湖存储扩容及后续建设的一个备选方案。
五、融合数据湖建设效果
我行融合数据湖方案从2021年开始建设到最终落地，历时1年左右时间。整体方案已在行内应用，并取得一定效果。
成本节约：
融合数据湖方案支持多类型数据管理，PB级海量数据存储，数据湖分析与计算服务。硬件架构上采用基于华为OceanStor Pacific分布式存储的存算分离方案，业务逻辑架构上采用湖仓一体的数据智能分层存储策略，有效降低行内数据单位存储成本20%以上。
效率提升：
通过Openlookeng提供的湖仓协同分析能力，在保持现有数仓业务模型和数据分析人员使用习惯的前提下，减少50%以上的数据搬迁，同时基于算子下推、元数据缓存、数据缓存等技术，支持数据湖存储数据的秒级查询。同时也与行内模型管理平台、反欺诈平台完成对接，支撑了各类平台对图片数据的存储与使用需求。
开发管理：
通过构建湖仓与数据类服务的一体化方案，实现数据高效自由流转与统一管理，支持湖仓任务的协同开发与调度，为全行60多个项目组提供稳定高效的数据开发服务。
课题协作：
金海波 某银行 技术专家
董生 某银行 数据库架构师
张乔光 某银行 基础架构负责人
滕召森 某银行 大数据负责人
课题审核：
姜旭 某银行 系统架构师
欢迎点击文末
阅读原文
到社区原文下留言交流
觉得本文有用，
请转发、点赞
或点击
“在看”
，让更多同行看到
