1 、前言
2020年，Lakehouse 架构被首先提出，区别于传统数据仓库，Lakehouse 同时吸收了数据仓库和数据湖的优势，试图去融合数仓和数据湖这两者的优势，通过将数仓构建在数据湖上，使得存储变得更为廉价和弹性，同时 Lakehouse 能够有效地提升数据质量，减小数据冗余，使数据分析师和数据科学家可以在同一个存储中对数据进行操作，同时也能为数据平台进行数据治理带来更多的便利性。
TBDS 在过去几年很好的支撑了各行业客户业务在湖仓架构下的落地，在数据的时效性、数据审计、数据降冷、数据查询速度、数据存储查询成本等维度得到了全面的提升，然而随着用户对湖仓的使用场景越来越多样化和规模化，数据湖底层文件治理成本也随之增高，一方面是用户在湖仓架构上使用的便利与高效，另一方面是湖仓架构下万亿级文件治理带来的运维成本，目前业界在数据湖存储治理方面开源且易用的方案并不多，我们基于项目中的实战经验，分享腾讯云 TBDS 在湖仓存储自动化治理的解决方案，希望能对大家有所启发和帮助。
2、湖仓治理实践背景
当前，数据驱动业务决策已经成为各行业客户业务发展的共识，尤其是在互联网、金融、新媒体等行业，数据新鲜度成为数据质量的重要衡量指标，越来越多的客户开始将数据链路从传统数仓T+1更新转化为更加实时的数据架构，这里我们从某头部金融客户的湖仓架构展开，其整体数据加工链路如下:
在客户的数据处理链路中，Iceberg / Hudi 作为统一湖格式支撑着整个数据链路中各个环节数据的入湖出湖，承担着重要的角色，取代了传统的 Hive 驱动着整个数据链路。
随着数据湖使用规模的扩大，客户在使用过程中也遇到了数据湖带来的多个问题，过多的小文件会给 Hadoop HDFS 的 NameNode 可用性上带来严重的问题，同时也会在计算引擎侧带来大量的 IO 和查询速度的降低，同时数据湖ACID 特性和高频入湖也会导致数据湖元数据的膨胀，以及数据湖下表的生命周期管理等问题，这些都会影响湖仓在客户侧的落地，因此数据湖存储优化模块是湖仓架构下必不可少的模块，也是湖仓生产落地过程中关键的部分。
基于客户在湖仓架构下的生产使用现状，秉承开源优先的原则，我们率先在 TBDS 中集成了开源数据湖优化组件 Amoro。得益于 TBDS 底座强大易用的 Open API，我们也在 Amoro 的集成上进行了开箱即用的增强来减少用户使用的成本，同时保证内核和社区对齐。与此同时为了将湖仓存储优化能力更好的落地客户生产业务，我们也对 Amoro 的内核进行了大量的功能性和易用的改造，该部分会在下个章节的 Luoshu 相关优化方案中展开。
3、新一代的数据湖存储治理解决方案
数据湖存储优化方案的一个核心在于：为上层用数应用提供一个合理的数据组织结构，为下层存储基座提供一个精简的数据存储结构，同时为运维人员提供一个功能完备的数据管理系统。这一切都是为来简化 Lakehouse 架构在落地过程中开发和运维的复杂性，提供一个统一的数据处理层，同时支持离线批量处理和实时增量处理，满足用户对数据一致性的要求。
3.1 传统业务实践痛点
● 学习门槛高
在客户的生产环境中，我们发现传统的开源数据湖存储优化方案在客户侧能很好的解决不同时效性的表的存储优化，特别是在小文件治理方面表现出色，同时能很好的进行优化资源的配置和隔离，但是实现这一过程需要对组件内核和运行机制比较熟悉，同时由于传统的开源方案内部引入了“资源组”等领域概念，并且内部优化资源服务于该资源组下面的所有表，在优化过程中需要用户控制每个表的资源使用配额，包对资源组资源实例的调整等。
因此，数据湖存储优化方案中，在提供功能强大的优化能力的同时，客户对于优化系统的易用性和高效的运维也存在比较迫切的需求。
● 资源运维成本高
传统的开源方案内部主要使用 Spark , Flink任务来作为优化资源重写数据湖表来达到对表进行优化的目的，通常情况下用户在为表配合好逻辑优化资源队列后，用户需要从业务角度出发为该优化队列配置足够的资源，同时确保队列下的计算资源稳定运行来确保业务表的优化正常稳定执行，但是由于缺少优化资源队列下表的统计信息无法对计算资源进行正确的评估，以及生产环境中优化任务的稳定性问题，通常保证队列下表优化的正常需要比较高的运维成本，难以达到理想的优化状态。
因此，业界对一个能够在统一解决数据湖存储优化的同时降低运营维护成本的数据湖优化解决方案的需求日益迫切，在这种方案架构下，用户可以上层无感的进行使用，同时底层优化组件具备良好的自适应优化和完备的资源自愈能力来满足用户落地数据湖过程中对高效运营的需求。
3.2 湖仓治理定位及特性分析
构建一个具备对数据湖文件中数据生命周期管理，数据文件治理，数据组织优化的核心功能外，我们也需要在整体的数据湖优化过程中具备对系统资源的整体管控，以及底层的优化资源管控，和底层优化资源的自适应运维能力，来帮助用户尽可能地降低在使用过程中的运维成本。
3.3 湖仓治理核心优化方向
从用户使用角度出发，我们除了需要为用户提供完善的数据湖核心优化能力之外，我们重点完善了整个方案中的运维成本较高的模块，包括进行了Serverless化部署适配，同时将逻辑资源优化组直接对接系统的资源管理模块，自动化同步优化资源组模块，对于用户在使用中复杂程度较高的优化资源实例扩展，我们实现了根据用户配置规则进行自动化拉起释放机制，让用户摆脱了使用中的需要人工介入运维的过程。
基于腾讯云TBDS 在客户侧丰富的实践经验，我们开始在 Amoro 的基础上通过改造，赋能 TBDS 上一个功能全面易用的数据湖优化组件，简单描述我们的预期为：
用户只需要在工作台编辑配置表的属性配置，即可无感将该表托管给 TBDS 的数据管理优化系统，TBDS 会根据预置策略全自动的托管该表的生命周期管理和优化。
3.4 新架构服务Luoshu的核心能力
下面是TBDS增强版数据湖优化管理服务Luoshu的整体架构，包含OptimizerMaintainer, ClusterManager, CommandCenter等核心新增模块:
由于自动化数据优化核心在于表的生命周期全优化托管，用户只需关心业务相关语义，无需关心优化组和优化器具体的生命周期，因此，为了实现整个流程表优化的自动化我们主要改造点为：
● Serverless化。由于该组件服务于管控下的所有 Hadoop集群，因此需要进行 Serverless 化来支持后期性能扩展，同时配合 TBDS 管控来实现 Hadoop集群生命周期初始化过程中自动化的将 Catalog 相关信息注册到 Luoshu，实现为多集群提供存储优化服务。
● 资源统一管控。TBDS管控下所有用户的资源队列信息自动化同步到 Luoshu 中为用户提供统一资源组视图，对齐用户在传统 Hadoop/K8s 下的使用方式，同时支持优化任务多集群提交，需要针对不同集群的湖文件，在进行优化时将优化资源提交到指定的计算集群，实现 Luoshu 的资源管控与传统大数据使用同一套资源管控
● 优化资源自适应。Luoshu 自动感知优化队列是否有表需要优化，并根据用户的资源模版自动拉起优化任务，并在没有表需要优化时主动释放资源
3.4.1 Serverless化部署
不同于社区的云原生方案，TBDS版本中我们进行进行了定制化的落地改造，主要基于以下出发点：
● TBDS目前提供面向云原生的计算集群，但是考虑到大量的客户主要计算资源依旧为yarn, 所以云原生场景下依旧需要完整的支持 Yarn 作为主要的计算资源。
● 由于 TBDS 全栈支持 IPv4/IPv6 协议，在云原生场景下涉及多个外部接口, 我们需要通过 TBDS 管控平台获取该 Pod 的专有 IPv4与IPv6 地址。
● TBDS 可以同时纳管多套 Hadoop集群以及上面的计算引擎，同时各个集群自由支持 IPv4, IPv6, 双栈等网络协议栈，TBDS需要根据不同的 Hadoop集群协议栈使用不同的通信协议。
● 为提升优化任务性能，我们也将 TBDS 内部优化版本 Flink, Spark进行预置。
同时 TBDS 目前提供了完备的 Open API ，TBDS管控侧的监听机制可以在 Hadoop 集群创建的初期自动化的将以上所有的配置文件自动化的注册到 Luoshu 组件上，实现 Catalog 的自动化接入注册，实现 Hadoop 创建过程中及联化接入。
3.4.2 资源统一管控
通常情况下，对于开源数据湖存储优化组件，用户需要配置优化队列，并在后期拉起优化器过程中使用该优化队列来聚合优化资源，提供统一的资源视图，但是实际使用过程中我们也发现部分问题：
● 该优化资源队列不同于 yarn 或 k8s 队列，为内部领域概念，在用户使用过程中增加了理解成本
● 对于优化资源队列的创建需要单独进行规划设计，增加了额外的成本，在多集群的架构下运维变得困难
TBDS 提供了统一的资源管理模块，我们希望将优化队列概念对齐统一资源视图中资源队列的概念，减少用户使用时的学习使用成本。因此我们也自动化的将 TBDS 的资源相关信息自动化的同步到了 Luoshu侧。同时为了进行不同集群的资源隔离，我们在 Luoshu 的优化组侧对资源相关信息进行重新格式化为 queue@cluster-id 的形式，用于在后期进行调起任务的过程中去解析集群与资源组的信息。
TBDS 统一资源管理视图
TBDS 统一资源管理编辑界面
由于在实际客户使用场景中，大数据的集群计算资源主要以 Yarn 资源为主，同时从客户使用稳定性角度出发，我们优先支持了 Yarn 资源来进行优化，但同时也面临一个问题，在一个 Pod 中如何根据指定的优化器启动命令完成向不同的集群提交优化任务，同时保证该任务可以正常的优化并和传统Hadoop 的 AZ部署时具备相同的优化性能。为此我们对接 TBDS OpenAPI 实现了在单一POD 可以根据指定资源组自动化的将优化任务提交到指定的 Yarn 集群中，具体多集群远程提交示意图如下：
其中主要需要实现了以下几个关键功能:
● 自动化感知纳管集群配置信息并同步至 POD 中。
● 支持异构网络协议栈下提交 Flink/Spark 优化任务。
● 支持自动化识别生成优化器提交命令上下文并提交至远程指定 Yarn 集群中。
通过以上的改造我们可用将用户指定优化队列下的优化任务提交到指定的远程 Yarn 集群，同时保证优化任务可以正确的建立心跳以及后续优化任务拉取等流程。实现湖文件优化的计算本地化。
3.4.3 优化资源自适应
传统的对数据湖表进行优化需要用户手动拉起优化计算资源，并在表无需优化时进行手动释放，在实际的业务使用中，用户需要频繁的进行运维操作，同时优化任务失败时无法及时感知拉起会导致整个湖表的优化状态不符合预期，为此我们在 Luoshu 上实现了优化任务的自动拉起释放机制来确保用户无需人工介入，全流程自动化感知操作。
● 优化任务自适应拉起
通常情况下用户需要在指定的优化队列下手动拉起指定的优化任务，并在后续根据优化时根据具体情况手动 Kill 掉优化任务来释放资源等，为了减少用户的使用成本，我们也将该过程进行自动化。由于在 Luoshu 内部，表的优化信息通常会聚合在指定的优化队列下，同时保持连接的优化器也会聚合在指定的优化队列下，我们通过检测各个优化队列下的表信息以及优化器信息来决定是否需要进行拉起优化器。
● 优化任务自适应释放
优化任务自动释放，主要在两个场景下需要处理：
-
优化任务与 Luoshu 由于网络隔离导致失联，同时 Luoshu 的自动拉起优化器逻辑无法感知网络隔离会导致频繁拉起，该场景下需要使断联的优化器主动自杀来避免耗尽所有机器队列资源。
-
优化任务在指定队列无优化表的情况下默认会持续持有资源等待新的优化任务生成，该场景下存在一定情况下的资源浪费，该情况下进行优化任务的主动释放时必要的，我们也在该场景下实现了优化任务的主动释放，其中部分代码逻辑如下：
//主动释放资源异常类型
public static final int PLUGIN_STOP_ERROR_CODE = 2007;
public class LuoshuStopException extends LuoshuRuntimeException {
public LuoshuStopException(String message) {
super(message);
}
}
//在Luoshu指定优化队列无表需要进行优化的情况下进行资源释放
@Override
public void touch(String authToken) {
if (schedulingPolicy.isEmpty()) {
throw new LuoshuStopException(
"SchedulingPolicy is empty, will indicate the optimizer should be stopped");
}
OptimizerInstance optimizer = getAuthenticatedOptimizer(authToken).touch();
LOG.debug("Optimizer {} touch time: {}", optimizer.getToken(), optimizer.getTouchTime());
doAs(OptimizerMapper.class, mapper -> mapper.updateTouchTime(optimizer.getToken()));
}
//在网络断联情况下对于连接失败指定次数后进行主动释放资源
private boolean shouldStop(Throwable t) {
String tName = t.getClass().getName();
if (t instanceof ConnectionFailException) {
if (throwableMeta.getOrDefault(tName, 0) >= CONNECTION_FAIL_TIMES) {
return true;
}
throwableMeta.put(tName, throwableMeta.getOrDefault(tName, 0) + 1);
}
// Call Luoshu again when got an unexpected error
return false;
}
4、总结与展望
4.1 业务使用效果
目前我们已经在腾讯云TBDS 上线自动化数据湖优化组件 Luoshu，用户只需为指定表配置使用的资源队列，即可将该表全托管给 TBDS 优化，为用户提供更加易用的数据湖优化体验，减少用户数据湖落地过程中使用运维成本。如下图所示，用户只需为表配置优化资源队列既可托管该表，由 Luoshu 负责该表的优化以及生命周期管理。
性能层面，目前在客户的使用场景中，使用 Luoshu 单实例治理的 Iceberg 表数量稳定在 1W 左右，Iceberg 单表存储最大 50G 左右，单表文件数最大多达17W，可确保整个数据湖使用达到平稳状态，同时使用 Luoshu 进行自动化治理后，上层计算引擎在计算阶段平均节省资源 15% 左右，大大减少了因为小文件过多导致的计算查询无法完成的异常情况。
使用体验层面，使用 Luoshu 作为公共数据湖优化组件，可以为同时为多套 Hadoop 集群上湖仓数据提供优化服务，用户在使用过程中也无需进行除了表配置外的其他操作，即可无感知的对表进行优化，无需在进行专职运维人员进行运维操作，极大的优化了业务开发人员的使用体验。
4.2 未来优化方向
在后续 Luoshu 的演进方向上，我们结合客户的使用场景也会继续进行一系列功能的增强和性能的优化，主要包括:
● 优化资源方面将自动化根据线上表优化任务执行统计信息自动化扩缩容优化资源。
● 优化计划生成方面将自动化识别巨量表，自动拉起单实例优化任务，来减小对其他表优化的影响。
● 功能层面将会结合 TBDS 统一元数据服务将 Index, Clustering 等功能集成进入 Luoshu 实现湖仓智能加速，进一步提升上层计算引擎的查询速度。
后续我们也将继续加强 TBDS Luoshu 在数据湖治理方面的能力，同时也将积极将这些功能回馈社区，继续推进湖仓一体架构在更多的客户业务中落地。
腾讯云大数据始终致力于为各行业客户提供轻快、易用，智能的大数据平台。
关注腾讯云大数据公众号
邀您探索数据的无限可能
