一、 大数据平台底座信创规划

1.背景

在数字化转型的趋势下，大数据平台已不再是单纯的批处理平台，更是建设数字银行的核心基础平台，需要建立全面、开放的生态平台，以满足业务敏捷、自助的用数需求。大数据平台信创建设，对银行而言，不仅是完成信创底座的更替保障及自主可控，更是为大数据平台架构全方位升级提供了一个契机。新一代大数据平台技术演进路线已逐渐明朗，流批一体向湖仓一体演进，大数据技术发展呈生态融合、数据融合两个态势。生态融合方面，由大数据&AI融合向大数据云化演进。数据分离、计算资源池化、流批一体等技术特性的新一代存储计算平台，已逐步成为业内共识的演进方向。在大数据平台信创规划时，我们不仅要关注到眼下的各软硬件信创底座替换，还要兼顾到长远需求。大数据平台数据量已经达到PB级，未来还会继续增长，在海量数据的情况下，如何实现更好的数据治理、数据挖掘、容灾建设等，在规划阶段都需要系统性考虑。

2.信创大数据平台集群整体规划

基于大数据组件特性，实现架构分层，大幅提升离线计算和实时计算供给能力，同时满足需求侧数据查询能力。
（1）在线区，包括交易管道、采集管道、其他管道
（2）离线区，包括数据湖、交易处理集群，交易处理集群承接交易/联机型批处理场景，并建设灾备；
（3）近线区，包括A/A 类集群、B/C类集群，公共集群承载应用可视应用业务场景进行独立集群拆分。

3.灾备建设：建设多机房的数据及应用容灾机制

（1）分等级集群隔离：A、A+面向客户，涉及账务处理，时效性、稳定性要求高，服务中断影响程度高，故采用独立部署模式，与分析型应用物理隔离，避免交叉影响。
（2）多机房部署：在集群拆分的基础上，补齐灾备能力，满足RTO、RPO要求。

4.关于兼容性适配

（1）大数据组件兼容性考虑：管理面源码开放，或支持组件插件式打包集成，在厂商产品停止迭代后，行方能继续迭代，尽可能延长产品生命周期，避免底层平台重建带来的海量数据迁移和大量应用适配风险。

（2）大数据平台相关工具链系统的兼容性：对于大数据平台调度系统、文件传输管道等系统，均是java应用，因此具备良好的兼容性

（3）硬件兼容性:要求产品同时支持x86和ARM芯片服务器混合部署，满足信创，对上层应用透明，实现底层服务器平滑替换。

5. 大数据平台底座信创平滑替换和迁移规则与策略

根据大数据平台的战略方向、转型要求、技术演进等规划，结合OneData数据服务理念，对现有基础数据平台布局进行分层、整合、升级，解决当前的系统平台多样化、不满足信创要求、安全要求等问题。在迁移完成后实现建设数据全、算力足、时效快、服务稳的基础数据底座，并全面满足信创要求。基于此定位本项目进行实时与离线数据平台迁移工作。

（1） 迁移原则:本次迁移遵循分层架构体系不变、上下游接口不变、脚本加工逻辑不变的基本原则。具体原则如下:

• 平滑迁移原则:程序代码以不改变业务处理逻辑的原则进行迁移，减少数据核对工作量。需要修改逻辑的代码按照新增需求处理，不做数据核对工作;
• 研发成本最小化原则:程序代码迁移和数据核对以自动化工具为主、人工为辅方式进行
• 风险最小化原则:减少对业务连续性影响，新平台上线后，采用并行策略，逐步完成新老平台切换;

（2） 迁移策略:领域集市迁移策略分为一次迁移和多批次迁移两种。不依赖其他集市模块采用一次迁移的方式;依赖其他集市的相关集市采用多次迁移。

（3） 迁移先后顺序为:依赖标准明细层核验通过后，进行共性模型集市微服务作业迁移，不依赖共性模型集市只依赖标准明细层作业可同步与共性模型集市同步迁移。

在新老平台并行期间，团队需要同时对两套环境进行需求受理、模型和脚本开发。新增需求可选如下两种策略：

• 领域集市管理系统于老平台进行开发测试，并通过迁移工具转换成新平台（信创大数据平台）脚本，新老平台同时上线。

• 领域集市管理系统于新老平台双开发领域集市管理系统优先使用新老平台双开发方式，尽快熟悉新平台（信创大数据平台）开发的语法要求及新平台（信创大数据平台）调优的技巧，保证开发过程的平稳过渡到新平台（信创大数据平台）上来。

二、大数据平台存储技术路线选择

在当今大数据时代，数据量呈爆炸式增长，企业和组织对于数据的处理和存储提出了更高的要求。不同的业务场景需要不同类型的集群来满足其特定的需求，而存储架构的选择直接关系到数据的存储效率、访问性能以及系统的可靠性和可扩展性。目前大数据平台存储层主要有两大技术路线，基于服务器本地盘或专业分布式存储。深入研究不同集群类型的存储需求特点和探索不同技术路线的适用性具有重要的现实意义。

1. 不同业务场景存储需求特点

（1） 联机查询场景
联机查询场景主要用于快速响应用户的查询请求，对数据的实时性和查询性能要求较高。其特点包括：

• 高并发访问：需要能够同时处理大量用户的查询请求，因此对系统的并发处理能力要求较高。例如，在电商平台的商品搜索功能中，可能会有大量用户同时进行查询，这就需要联机查询集群能够快速响应这些请求。
• 低延迟：用户对于查询结果的返回时间有较高的期望，所以系统需要尽可能地降低查询延迟，以提供快速的响应。比如在金融交易系统中，交易员需要实时查询市场行情和交易数据，延迟过高可能会导致交易决策失误。
• 数据一致性：保证查询结果的准确性和一致性是联机查询集群的重要要求，尤其是在涉及到金融、电商等对数据准确性要求较高的领域。如果查询结果不一致，可能会给用户带来错误的信息，影响用户的决策。

（2） 批处理场景
批处理场景主要用于处理大规模的批量数据处理任务，对数据的处理效率和吞吐量要求较高。其特点包括：

• 数据量大：批处理任务通常需要处理大量的数据，数据规模可能达到 TB 级甚至 PB 级。例如，在大数据分析场景中，需要对海量的日志数据、用户行为数据等进行分析处理，以挖掘有价值的信息。
• 任务周期性：批处理任务通常是周期性执行的，例如每天、每周或每月执行一次，以处理积累的数据。比如企业的财务报表生成、数据仓库的 ETL（Extract, Transform, Load）过程等都是批处理任务。
• 资源利用率高：批处理集群可以充分利用集群中的计算资源，并行处理大规模的数据，提高数据处理效率。通过合理的任务调度和资源分配，可以在较短的时间内完成大量数据的处理。

（3）准实时场景
准实时场景介于联机查询场景和批处理场景之间，既需要满足一定的实时性要求，又需要处理较大规模的数据。其特点包括：

• 实时性要求适中：相比于联机查询集群，准实时集群对数据的实时性要求相对较低，但仍然需要在较短的时间内处理数据，以满足业务的需求。例如，在物流跟踪系统中，需要实时更新货物的位置信息，但对于查询结果的返回时间可以稍微放宽一些。
• 数据处理规模较大：准实时集群需要处理的数据量通常比联机查询集群大，但比批处理集群小，数据处理的复杂性也介于两者之间。比如在社交媒体的数据分析中，需要对实时产生的用户数据进行分析，但数据量相对批处理任务要小一些。
• 灵活性高：准实时集群可以根据业务需求进行灵活的配置和调整，以适应不同的实时性和数据处理规模要求。例如，可以根据业务的繁忙程度动态调整集群的规模和资源分配，以提高系统的性能和效率。

2.存储技术路线选择的考虑因素

（1）数据特点
数据类型：不同类型的数据对存储架构的要求不同。例如，结构化数据适合采用关系型数据库存储，而半结构化和非结构化数据则更适合采用分布式文件系统或 NoSQL 数据库存储。结构化数据具有明确的结构和格式，如关系型数据库中的表格数据；半结构化数据具有一定的结构，但格式相对灵活，如 JSON、XML 等格式的数据；非结构化数据没有固定的结构和格式，如图片、音频、视频等。

数据量：数据量的大小是存储架构选型的重要考虑因素。对于小规模的数据，可以采用传统的集中式存储；而对于大规模的数据，分布式存储架构则更为合适。随着数据量的增长，集中式存储可能会面临存储容量不足、性能瓶颈等问题，而分布式存储可以通过增加存储节点来扩展存储容量和提高性能。

数据热度：数据的热度分布也会影响存储架构的选型。热数据需要快速的访问和处理，因此适合存储在高速存储介质中；而冷数据则可以存储在低成本的存储介质中，以降低存储成本。例如，可以将热数据存储在固态硬盘（SSD）中，将冷数据存储在机械硬盘（HDD）或磁带库中。

（2）性能需求
查询性能：对于联机查询集群，查询性能是存储架构选型的关键因素。需要选择能够提供快速查询响应的存储架构，例如采用索引、缓存等技术来提高查询性能。索引可以加快数据的检索速度，缓存可以将经常访问的数据存储在内存中，以减少磁盘 I/O 操作，提高查询性能。

写入性能：对于批处理集群和准实时集群，写入性能也非常重要。需要选择能够支持高吞吐量写入的存储架构，例如采用分布式文件系统或分布式数据库等。分布式文件系统可以将数据分散存储在多个存储节点上，并行写入数据，提高写入性能；分布式数据库å可以通过数据分区和复制等技术来提高写入性能和数据的可靠性。

数据传输性能：在分布式存储架构中，数据的传输性能也会影响系统的整体性能。需要选择具有高带宽、低延迟的数据传输网络，以提高数据的传输效率。例如，可以采用高速以太网、InfiniBand 等网络技术来提高数据传输性能。

（3）可靠性和可用性
数据冗余：存储架构需要具备一定的数据冗余机制，以保证数据的可靠性和可用性。例如，采用副本机制或纠删码技术来保证数据的冗余存储。副本机制是将数据复制多份存储在不同的存储节点上，当某个存储节点出现故障时，可以从其他副本中恢复数据；纠删码技术是通过对数据进行编码，生成一定数量的校验数据，当部分数据丢失时，可以通过校验数据恢复丢失的数据。

故障恢复：当存储系统出现故障时，需要能够快速地进行故障恢复，以减少系统的停机时间。因此，存储架构需要具备快速的故障检测和恢复机制。例如，可以采用分布式存储系统中的自动故障检测和恢复机制，当存储节点出现故障时，系统可以自动检测到故障，并将故障节点上的数据迁移到其他正常的存储节点上，以保证数据的可用性。

高可用性：对于一些对可用性要求较高的业务场景，需要选择具有高可用性的存储架构，例如采用分布式存储架构或冗余存储架构等。分布式存储架构可以将数据分散存储在多个存储节点上，避免了单点故障，提高了系统的可用性；冗余存储架构可以通过增加存储设备或存储节点的方式来提高系统的可靠性和可用性。

（4） 成本效益
硬件成本：存储架构的硬件成本包括存储设备、服务器、网络设备等。需要根据业务需求和预算选择合适的硬件设备，以降低硬件成本。例如，可以选择性价比高的存储设备和服务器，或者采用云计算等方式来降低硬件成本。

运维成本：存储架构的运维成本包括设备的维护、管理、升级等。需要选择易于维护和管理的存储架构，以降低运维成本。例如，可以选择具有自动化管理功能的存储系统，或者采用云存储服务等方式来降低运维成本。

扩展性成本：随着业务的发展，数据量和业务需求可能会不断增加，因此存储架构需要具备良好的扩展性。需要选择具有良好扩展性的存储架构，以降低扩展性成本。例如，可以选择分布式存储架构，通过增加存储节点和计算节点的方式来扩展系统的存储容量和处理能力，而不需要对整个系统进行大规模的升级和改造。

3. 在PB级数据量大数据离线集群场景专业分布式存储技术路线应用探索

在PB级数据量大数据离线集群场景，专业分布式存储技术路线有如下特点与场景需求匹配：

（1）大存储容量：外置专业分布式存储技术可以提供 PB 级甚至更大规模的存储容量，能够满足大规模数据的存储需求。对于温冷数据，由于其访问频率较低，可以将其存储在分布式存储系统中，以降低存储成本。例如，企业的历史数据、备份数据等温冷数据可以存储在分布式存储系统中，以便在需要时进行查询和分析。

(2)数据分层存储：分布式存储系统可以支持数据的分层存储，将热数据存储在高速存储介质中，将冷数据存储在低成本的存储介质中，以提高存储系统的性能和成本效益。例如，可以将热数据存储在固态硬盘（SSD）中，将冷数据存储在机械硬盘（HDD）或磁带库中，根据数据的访问频率自动进行数据的迁移和存储。

（3）企业级数据管理和治理：外置专业分布式存储技术通常提供丰富的数据管理和治理功能，例如数据备份、恢复、归档、压缩等，以及容灾方案，可以有效地管理和治理大规模的数据。例如，可以定期对数据进行备份和归档，以保证数据的安全性和可恢复性；可以对数据进行压缩，以减少存储占用空间，降低存储成本。

过去，离线集群采用服务器本地盘架构，面临如下几个挑战：

（1） 现网对象存储采用3副本存储数据，占用空间资源多，存储资源利用率低，仅33.3%左右。
（2） 缺乏完善的跨AZ域容灾机制，数据中心故障，有数据可靠性风险。
（3） 升级扩容不方便，需要搭建新集群，拷贝数据。

我们行实施了针对上游系统数据库的数据瘦身，将交易类系统、分行系统的冷数据入湖进行归档，由归档系统提供对外的统一查询接口，实现对归档数据的单SQL查询，方便了业务工单、司法查询等场景的数据提取。随着归档数据规模的增加，通过OceanStor Pacific 9520替换服务器本地盘存储和非信创分布式存储，在性能不下降的前提下，实现了综合成本的降低、完成了归档系统的信创改造。实现了如下效果：

（1） 将存储资源利用率从33.3%提升到80%+
（2） 节约TCO：扩容1PB+存储容量为例，原有存算一体需扩容30+台服务器，使用存算分离解决方案，需扩容21台OceanStor Pacific 9520存储。
（3） 存储层100%符合信创要求，实现基础设施自主可控。

三、结语

借助大数据平台信创契机实现大数据平台架构优化升级是银行在大数据平台项目中真正的课题，需要充分梳理行内大数据采存算管用的业务需求，秉承长期主义原则进行系统而长远的建设规划。存储作为大数据平台底座的核心组件，不同业务场景类型的存储架构选型需要综合考虑数据特点、性能需求、可靠性和可用性以及成本效益等因素。在实际应用中，需要根据具体的业务场景和需求，选择合适的存储架构和技术路线，以满足业务的发展需求。从笔者从事的金融行业来看，分布式存储是未来兼容各类业务场景的主流趋势，我们将持续跟进分布式存储的发展动态，为提升金融行业大数据平台基础设施建设水平而努力。

本文转载来源为twt社区