导读：
大数据技术的倒退历程中，继数据仓库、数据湖之后，大数据平台的又一变革技术——湖仓一体近年来开始引起业内关注。市场倒退催生的数据管理需要始终是数据技术革新的能源。比方数据仓库如何存储不同构造的数据？数据湖又如何防止因为不足治理导致的数据芜杂景象？明天的文章想跟大家具体聊聊咱们的数栈如何解决这些问题。
你能看到👇👇👇
▫ 湖仓一体概念简述
▫ 数栈的湖仓建设过程中有哪些痛点
▫ 湖仓一体如何针对性解决这些问题
背景
随着进入 21 世纪第三个十年，大数据技术也从探索期、发展期逐步迈向了遍及期。现如今，越来越多的企业开始应用大数据技术辅助决策分析。数据仓库自 1990 年数据仓库之父比尔·恩门（Bill Inmon）提出以来，曾经倒退了三十余年，各大云厂商也纷纷推出如 AWS Redshift、Google BigQuery、Snowflake 等数据仓库。
但随着企业的现代化，各式各样的数据结构、越来越高的实时性、疾速变动的数据模型等现实情况导致数据仓库曾经不能满足日益增长的企业需要，以 Iceberg、Hudi 为代表的数据湖便应运而生。凋谢的文件存储、凋谢的文件格式、凋谢的元数据服务以及实时读取与写入等特点使它们受到大家的热烈追捧，各大云厂商也随之纷纷提出本人的数据湖解决方案，因而有人说，数据湖是下一代大数据平台。
新的事物总有两面性，一方面数据仓库无奈包容不同格局的数据，另一方面，数据湖不足构造和治理，会迅速沦为“数据沼泽”，两种技术均面临重大的局限性。在此背景下，交融了数据仓库与数据湖长处的新的架构模式”湖仓一体“被提了进去。
什么是湖仓一体
一言蔽之，“湖仓一体”是一种新的架构模式，它将数据仓库与数据湖的劣势充沛联合，其数据存储在数据湖低成本的存储架构之上，领有数据湖数据格式的灵活性，又继承了数据仓库数据的治理能力。
数栈在湖仓一体上的演进
随着客户业务的一直倒退，数栈作为一套数据中台也遇到了越来越多的挑战。在克服这些挑战的同时，咱们也深感本身还有很多有余的中央。
数栈离线数仓
如图所示，用户业务数据通过 FlinkX 导入 Hive 数仓，通过 Spark 引擎解决业务逻辑，最终通过 FlinkX 再写回用户数据源。
数栈实时数仓
如图所示，实时数仓有两条链路: 一条是实时链路，采集到的 CDC 数据写往音讯队列，通过 FlinkStreamSQL 实时计算，最终写到 Kudu、HBase 等高效读写的数据源；另一条是准实时链路，采集到的 CDC 数据写往 Hive 表，通过 Spark SQL 计算。
引入数据湖
因为数栈流计算引擎应用的是 Flink，在调研 Iceberg、Hudi 两款开源数据湖我的项目之后，Iceberg 相比于 Hudi 来说，与 Flink 集成更便捷，生态上也更敌对，因而咱们决定采纳 Iceberg 作为咱们的第一款数据湖产品，后续将一一反对 Hudi 等其余数据湖。对于 Iceberg 的一些特点这里就不过多赘述了，上面是引入数据湖后的数仓链路：
结构化、半结构化及非结构化的数据通过 FlinkX 做 ETL 解决后写入 Iceberg 数据湖或者写回音讯队列。接着数据在音讯队列和数据湖中通过 Flink 和 Spark 引擎一直流转与计算，最终写到 Kudu、HBase 等高效读写的数据源。
数栈在湖仓建设中的痛点
批流拆散，运维费钱费劲
目前离线数仓的做法是先应用 FlinkX 将数据采集到 Hive 表中，而后再通过 Hive SQL 或者 Spark SQL 计算，最初写回 Hive；实时数仓的做法是数据从源表的 Kafka 中读取，通过 FlinkStreamSQL 计算，最初写到 kudu 或 HBase。
在这两条链路中，开发人员首先不得不保护两套自研的框架：FlinkX 和 FlinkStreamSQL；运维人员不得不对 Hive SQL、Spark SQL 和 Flink SQL 工作有肯定的理解；数据开发也不得不相熟 Hive SQL、Spark SQL 和 Flink SQL 的语法及参数配置。这样的一整套数仓开发、应用、运维起来，老本不堪称不微小。
代码反复，采算资源节约
FlinkX 和 FlinkStreamSQL 在创立之初，一个面向同步，一个面向计算。但随着业务的一直倒退，这两个其实越来越类似了。FlinkX 在同步时也须要做肯定水平的计算，将数据荡涤后写入指标表。而 FlinkStreamSQL 如果不进行计算只是单纯的写库，那么就是同步性能。
因而后续在新增数据源类型的时候，FlinkX 和 FlinkStreamSQL 须要各减少一个相似的 connector，而这个 connector 中 80% 的代码都是类似的。在面对数据源相干的 bug 时，FlinkX 和 FlinkStreamSQL 都须要进行修复。两套框架所带来的是两倍的人力老本。
不足治理，湖仓变成沼泽
在引入 Iceberg 数据湖后，绝大部分数据都未经解决就写入进去了。因为不足 catalog 级别的元数据管理，想要从大量原始数据中找到想要的业务数据如同沙中淘金。不同的业务人员在应用完各自的数据后不知如何整顿，就导致了数据杂乱不堪，并衍生出了大量的小文件。大量的小文件重大连累了 Hadoop 集群的效率，使数据湖沦为了数据沼泽。
数栈迈向湖仓一体
痛点的解决方案
为了解决以上痛点，数栈做了以下改变：
1、启用 Flink 做主计算引擎
Flink 在 1.12 版本实现了 Source&Sink API 的流批一体，并且社区也在一直向着流批一体的方向倒退，因而咱们选用 Flink 作为次要的计算引擎。至此，无论是离线、实时数仓还是数据湖，只须要一套 Flink SQL 工作即可实现业务的解决。得益于 Flink 在数据处理上的行业领先水平，咱们能够基于 Flink 流批一体，应用 Flink 作为湖仓的次要计算引擎，一举解决运维老本高，操作难度大的问题。
2、交融代码反复的两套插件
如上文提到的，FlinkX 与 FlinkStreamSQL 在插件层 80% 的代码是反复的，因而咱们不须要保护两套反复的插件。咱们将两套框架的长处相结合，写出了全新的 FlinkX。交融后的 FlinkX 继承了原 JSON 的数据同步性能，并且也能应用弱小的 SQL 语言。无论数据是离线的还是实时的，数据无论是入仓、入湖还是计算，借助全新的 FlinkX 均能轻易解决。
3、对立湖仓数据源核心
引入数据源核心对立治理中台中应用到的数据源，能够不便中台管理员治理数据源，控制数据源的应用权限。同时将散列在各我的项目中的元数据模块对立到数据源核心中，能够不便使用者查看某数据源的应用状况。针对 Iceberg 数据湖数据源设置更细粒度的 catalog 治理，避免沦为数据沼泽。对于底层存储在 HDFS 上的数据源，如 Hive、Iceberg 等，减少小文件合并性能，手动的或主动的定时合并小文件，彻底解决小文件问题。
数栈湖仓一体架构
基于上述所说，让咱们一起来看看，咱们通过 Flinkx 将数据入湖 (Iceberg)、入仓（hive）之后，数栈上湖仓一体的构造是如何实现的：
在引入 Iceberg 之后咱们不仅能够对立对接各种格局的数据存储，包含结构化半结构化数据，并且底层存储上反对对 OSS,S3,HDFS 等存储系统，而利用 Iceberg 的个性也能够提供对 ACID、表构造变更，基于 Snapshot 读取历史数据等性能的反对，同时数栈在上一层对立了元数据中心，应用对立的元数据存储，不仅仅能够治理数据湖的存储，而且能够做到对原有的数据仓库进行对立治理，在表结构层做到对立入口，在下层计算的时候能够看到全局的表信息，而不是孤立的多个源的表信息。
在对立元数据之后，咱们须要一个能基于曾经构建的元数据之上对数据湖，数据仓库进行计算的工具，在 Hadoop 生态上，相似的计算工具有很多，包含 Trino,Flink,Spark 等。以后这个构造上，咱们能够依据客户的业务场景进行抉择，如果客户曾经有数据仓库，并且想借助数据湖来进行下层的业务构建的话，能反对跨源的 Flink,Trino 用来查问就是一个适合的抉择，同时客户对查问交互性能有要求的话，那么 Trino 的 MPP 架构提供的横向扩大的个性就会是一个不错的抉择。
数栈对于将来的瞻望
数栈以后通过引入 Iceberg 和革新 FlinkX，对立了实时和离线的数据集成和计算和存储能力，能够在数栈上实现根本的湖仓库一体。将来咱们心愿数栈具备跨源能力，不只是在繁多的 Hadoop 生态外面构建湖仓一体，而且能够基于企业已有的传统数据存储比方 MySQL、Oracle 仓库（不须要将数据从 MySQL、Oracle 等仓库抽到对立的数据中心），通过对立的元数据中心注册不同的 catalog 进行隔离，加上新建设的数据湖，在下层的 Flink 计算引擎做到湖仓一体的能力。
在存储层，咱们心愿能够做到对以后 HDFS 和 S3 的反对，同时也能够反对本地和云端存储；并且在存储层面咱们要做到主动进行数据管理，包含对小文件进行定期合并，对近程文件数据进行减速, 并对数据构建索引，对立的元数据管理等等；咱们的指标是实现存储层的 Data warehouse as a servrice。
要做到下面的布局，咱们还有很多性能要去优化和整合，将来咱们会实时关注和参加 Iceberg、Hudi、Flink 社区，关注社区的布局和倒退，联合咱们以后已有的对立的数据开发平台进行一直的迭代，达到 DasS 的能力，让企业和用户能在湖仓一体的架构下晋升数据价值。