浅谈G行数据湖平台建设

随着移动互联网的飞速发展，对于短时间内产生的大规模、多种类数据的存储和分析要求越来越高。数据湖是一种支持结构化、半结构化、非结构化等大规模数据存储和计算的系统架构，能够高效地对原始数据进行存储和取用，解决了传统数据仓库需要预先定义数据结构、海量数据加载慢的问题。目前，G行基于“湖仓一体”的建设思路实现了对行内海量数据的高效存储和处理，本文主要介绍了G行数据湖平台的建设实践。

G行数据湖平台建设实践

近年来，G行大数据平台项目建设取得了一定的成果。在大数据应用开发平台的建设基础上，数据湖平台采用了采集层、平台层、应用层的三层架构建设方案，如图1所示。

图1 数据湖平台系统架构

采集层实现了对G行原始数据的统一采集管理。目前原始数据主要以数据文件的形式推送入湖，在对文件格式、文件大小、数据内容等进行基本校验后，将数据存储到HDFS或Hive中。对于具备网络条件的源系统，通过HDFS直连方式进行数据推送，对数据进行校验、压缩等处理后完成入湖。对于部分准实时数据则通过Kafka实现采集传输，并由Flink消费后存储入湖。为了更好地实现数据计算共享，下游数仓及应用加工处理后的数据也会回流到数据湖进行统一汇聚和共享。

平台层主要完成对入湖数据的存储管理、授权管理、元数据管理、任务管理等功能。根据应用对数据的需求，数据湖共设计了四种入湖模型，包括当日全量数据存储、当日增量数据存储、上日全量数据与当日更新增量数据合并存储、拉链表存储。平台的授权管理基于Ranger实现，让不同系统可通过数据湖进行数据共享。目前，平台已经实现了G行将近200个系统1万多张表的原始数据采集，并为约100个下游应用提供数据授权和调用。元数据管理模块可以轻松实现对数据入湖、数据存储方式以及数据下线的管理。任务管理模块实现了对数据入湖加载任务的状态查询、延迟查询、任务重调、时长统计等功能。

图2 数据湖平台任务管理大屏

应用层主要基于G行的数据运营、营销拓展、个性化推荐等业务场景，利用Oozie、Spark等组件实现对数据批量任务的调度和加工计算。同时，结合高斯数仓强大的MPP计算能力，对数据进行进一步的加工和处理，业务人员可以借助Presto、openLooKeng等查询分析引擎实现数据的实时查询或多源分析。

实时数据湖建设

目前，G行数据湖中主要是T-1日的离线数据。随着数字化转型的不断深入和业务场景的不断丰富，对于数据分析的时效性要求越来越高。因此，G行建设了数据湖平台实时数据湖子系统，完成了实时数据的统一接入、统一管理和统一服务，同时实现了对T-1离线数据的比对修正，保证了数据一致性。实时数据湖子系统设计架构如图3所示。

图3 实时数据湖子系统架构

根据G行数据平台建设的现状和需求，实时数据湖选择了基于Hudi的技术方案。作为目前数据湖的热门实现技术，Hudi可以高效处理大规模数据集，支持HDFS、S3等多种数据存储方式，支持Spark、Flink计算引擎实时消费Kafka、Pulsar等消息队列的数据后入湖，支持Hive、Presto、Impala等引擎进行数据查询分析，并且通过索引构建，提升了计算引擎的查询性能。

为了便于实现对实时数据湖的管理，G行从作业管理、元数据管理、任务监控方面进行了实时数据湖平台的建设。

作业管理：支持批量初始化、实时数据入湖的配置化开发以及数据比对作业提交，最低开发成本保证实时数据入湖与查询。

元数据管理：为了实现与批式数据湖元数据的统一，采用了基于Hive Metastore的元数据存储，通过Thrift接口协议，Flink在实时消费数据的同时将元数据写入到Hive Metastore中，实现元数据的统一管理。

任务监控：为加强平台运维管理，提供了数据湖流式作业以及服务运行状态和性能的监控，并且接入了G行分布式监控系统提供实时故障告警，方便运维人员及时掌握生产运行情况。

总结与展望

目前，G行数据湖项目的建设取得了一定的成果，基本实现了全行数据的统一存储和管理，支持了越来越多的基于数据共享和多维分析的业务场景，也助力数仓实现了数据的进一步加工和提取，使得业务应用的集市化建设更加便捷。但是，在实际生产中也存在一些亟需关注和解决的问题。

一、目前实时数据湖只是作为离线数据湖的补充和完善，批流数据入湖仍是分别基于Hive和Hudi两套数据格式的实现方案。Hive数据更新只能通过全量数据覆写的方式实现，占用资源较高且比较耗时。而Hudi提供多种内置索引机制和高效的数据更新能力，既支持批量入湖，也支持流式数据，并且通过Clustering机制避免了小文件问题造成的集群压力。因此，建设统一的基于Hudi的数据湖，不但可以高效地处理数据，也符合统一数据管理的要求。

二、数据链路治理也是需要关注和加强的地方，数据链路治理的目标是保障数据的准确性、可用性和及时性。由于上游任务异常或集群故障问题，推送到数据湖的数据可能出现延迟，从而影响下游数据调用及批量任务。另外，如果上游入湖数据出现异常，会导致下游批量错误，修正数据则需要下游所有相关批量任务的重新运行，代价很大。因此，完善的延迟监控、数据异常监测及批量任务熔断机制是后续需要重点加强的方面。

数据湖平台在统一数据管理、数据链路治理等方面将日趋完善和健壮，持续助力数据价值的挖掘，不断赋能G行业务的发展。