论数据湖技术及其应用
摘要
2020年6月，我所在的公司中标某银行数据湖平台搭建项目1.0，该项目周期为2年，总投资为5000万人民币，通过该项目，搭建该银行数据湖建设项目，实现该银行所有业务数据以及用户行为日志入湖，为银行在投资理财、金融、贷款等方面提供精准营销，为挖掘潜在客户等提供业务支撑，帮助银行实现快速的业务增长。我有幸作为此次项目的负责人以及架构师参与了项目的搭建以及开发过程。该项目时间紧任务重、涉及人员组织多，直接相关银行内部40个部门 600 余人，外部配合协作 20 多个厂商团队 300 余人。该项目于 2022年 5月完成系统上线， 2022年 6 月通过最终验收，得到了用户的一致肯定，顺利达成了项目既定目标。本文重点结合实际经验，以该项目为例，论述一下项目建设过程中数据湖技术及其应用。
正文
2020年6月，我作为项目负责人以及架构师，主持某银行数据湖平台建设项目，该项目周期为2年，总投资为5000万人民币。该项目时间紧任务重，具有相当大的挑战性。一是需要配合的改造部门多，将近有40个部门60个应用配合数据湖平台的搭建，需要跟这60个应用配合，定义好统一的数据入湖格式，接入统一的数据湖接口。二是数据湖架构的选择。怎样选择一种高可用、可存储的数据湖架构成为该项目的一个技术难点。因为数据湖需要存储大量的数据，所需要存储的空间以及内存都要相当大，并且方便后续伸缩和可扩展。
调研得知，数据湖跟数据仓库明显不同。数据仓库是一个优化的数据库，用于分析来自事务系统和业务线应用程序的关系数据。数据仓库技术需要事先定义数据结构和数据模式（Schema）以优化快速SQL查询，其中结果通常用于操作报告和分析。数据经过了清理、丰富和转换，因此可以充当用户可信任的“单一信息源”。而数据湖能够同时存储来自业务线应用程序的关系数据，以及来自移动应用程序、物联网设备和社交媒体的非关系数据。在进行数据捕获时，无须定义数据结构或数据模式（Schema）。数据湖支持用户对数据使用不同类型的分析（如SQL查询、大数据分析、全文检索、实时分析和机器学习等），为企业智能决策提供支持。
下面从主要数据来源、数据模式转换时机、数据存储成本、数据质量、面对用户和主要支撑应用类型等六个方面对数据湖和数据仓库技术进行比较：
- 主要数据来源。数据湖主要数据来源为物联网设备、互联网、移动应用程序、社交媒体和企业应用程序的结构化、半结构化和非结构化数据。数据仓库主要数据来源为事务系统、运营数据库和业务线应用程序的结构化数据。
- 数据模式转换时间。数据进入数据湖时不进行模式转换，在进行实际数据分析时猜进行模式转换。数据在进行数据仓库时一般需要提前设计数据仓库的Schema。
- 数据存储成本。数据湖通常基于非关系型数据湖，数据存储成本相对较低。数据仓库通常基于关系型数据库，数据存储成本高。
- 数据质量。数据湖是原始的、未经处理的数据。数据仓库可作为重要事实依据的高质量数据。
- 面对用户。数据湖一般面向业务分析师、应用开发人员和数据科学家。数据仓库一般面向业务分析师。
- 主要支撑应用类型。数据湖主要支撑应用类型为机器学习、预测分析、数据发现和分析。数据仓库主要支撑应用类型为批处理报告、商务智能和数据可视化。
了解了数据湖和数据仓库技术的差异，现在就需要为数据湖寻找一种合适的架构。数据仓库实现的技术手段一般有hadoop、flink、hive等技术，这些原则上在进入数据仓库之前都需要将数据进行清洗、过滤等，而数据湖的数据在入湖时，不需要提前对数据进行处理，只有真正使用到数据湖里面的数据的时候，才对数据进行清洗、过滤等，并进行可视化展示。最后，经过行里面的高级架构师以及我们公司的高级架构师多方调研以及评估，一致认为应该采用hudi这种架构接入数据湖。这时候，将所有的应用程序的原始数据一共分为两部分入湖，第一部分数据就是业务数据，这部分数据我们通过flinkCDC传入，写入到ods层（hudi表格中）。第二部分数据就是用户行为日志，这部分数据我们通过flume+kafka，然后通过flinkSQL映射，写入到ods层（hudi表格中）。具体实现是，将ods层里面部分相关数据转换到dim层(维度层),将多张业务表进行维度化展示,写入到hudi表格中。将ods层里面部分相关数据转换到dwd层(明细层)，将多张业务表进行多组聚合（比如订单表、订单明细表），写入到hudi表格中。将dwd明细层数据进行聚合计算（需要使用flink的相关聚合函数sum等），同时对维度信息进行维度关联。最后，我们将所有业务需要查询的一些订单数据、营销数据、用户行为日志等，只要是用户想查询的数据，都将结果映射到集群架构的mysql中，并通过superset进行可视化展示。
该项目于2022年6月顺利通过验收。项目运行至今，一直表现良好，从未出现过重大生产问题。银行的数据湖搭建平台项目1.0取得巨大成功，不仅将每年业务原始数据入湖，并且给用户提供了可视化需要展示的界面，使用户对现有营销数据、经营生产数据有了一个清晰的掌握，并提供给业务人员，用户进行数据分析，对于精准营销有一定的实际指导意义，提高了银行的资源利用率。业务的原始数据入湖也为银行应对银监会的监管提供了一定的数据保护。
不足之处有两个方面，第一在架构设计的过程中我们忽略了系统的可用性，在系统测试阶段中，发现单个的hudi架构有的时候由于机房断掉，导致整个数据湖架构都不可用，为此我们采用了冗余和心跳检测机制，并实现hudi架构分南北机房部署，当一台服务器不可用时，由另外一台服务器接管，提高了系统的可用性。第二就是将数据映射到mysql中的时候，由于有的时候数据太大，映射在单台的mysql中，数据查询相当慢，针对这种情况，我们采用了mysql集群架构部署，部署了多个主从节点，并实现mysql的分库分表，以及采用读写分离的方式，成功的解决了数据查询慢的原因。
总之，在这个项目中，学到了很多很多。在以后的工作中，我将用自己的专业知识，争取为国家、为社会的发展贡献自己的一份绵薄之力。