【数据湖加速篇】 —— 数据湖结构化数据优化与查询加速方案

简介： 近几年，数据湖架构的概念逐渐兴起，很多企业都在尝试构建数据湖。相比较大数据平台，数据湖在数据治理方面提出了更高的要求。对于数据湖场景所提出的新需求，“传统”的大数据工具在很多方面都面临着新的挑战。JindoTable 正是专为解决数据湖管理结构化数据甚至是半结构化数据的痛点而设计的，包括数据治理功能和查询加速功能。

概述

近几年，数据湖架构的概念逐渐兴起，很多企业都在尝试构建数据湖。相比较大数据平台，数据湖在数据治理方面提出了更高的要求。对于数据湖场景所提出的新需求，“传统”的大数据工具在很多方面都面临着新的挑战。JindoTable 正是专为解决数据湖管理结构化数据甚至是半结构化数据的痛点而设计的，包括数据治理功能和查询加速功能。

数据优化

数据湖需要存储来自各种数据源的数据。对于 HDFS 集群，小文件问题让很多用户倍感烦恼。在存储计算分离的数据湖中，小文件同样会产生很多问题：过多的文件数会导致目录list时间显著变长，小文件也会影响很多计算引擎的并发度。此外，由于对象存储一般以对象为单位，小文件也会导致请求数量的上升，会明显影响元数据操作的性能，更会增加企业需要支付的费用。而如果数据文件过大，如果数据又使用了不可分割的压缩格式，后续计算的并发度会过低，导致无法充分发挥集群的计算能力。因此，即使是数据湖架构中，对数据文件进行治理和优化也是非常必要的。

基于数据湖所管理的元数据信息，JindoTable 为客户提供了一键式的优化功能，用户只要在资源较为空闲时触发优化指令，JindoTable 可以自动为用户优化数据，规整文件大小，进行适当的排序、预计算，生成适当的索引信息和统计信息，结合计算引擎的修改，可以为这些数据生成更加高效的执行计划，大幅减少用户查询的执行时间。数据优化对用户透明，优化前后不会出现读取的数据不一致的情况。这也是数据湖的数据治理所不可或缺的功能。

查询加速

JindoTable 还有一项重磅功能，就是查询加速功能。在数仓中，数据分析总是越快越好。尤其是 Ad-Hoc 场景，对查询延迟非常敏感。现在“湖仓一体”的概念也很火，对于数据湖这种普遍使用存储计算分离场景的架构，如何尽可能减少 IO 开销，对于缩短查询时间是非常关键的。

之前介绍的 JindoTable 数据优化功能，是在存储端减少额外开销，并且通过提前的计算，为运行时优化打好基础。JindoTable 的查询加速功能则是在查询执行时，通过把计算推向存储，减少计算时整体的 IO 压力，同时利用存储端空闲的计算资源提供高效的计算，缩短整体查询时间。JindoTable 的加速服务结合修改后的各种计算引擎，可以把尽可能多的算子下推到缓存端，并且利用高效的 native 计算能力过滤大量原始数据，再把数据高效地传输给计算引擎。这样，计算引擎所需处理的数据大大减少，甚至一些计算也可以直接略过，后续的计算所需的时间自然也就大为减少。

分层存储

数据湖所存储的数据量通常增长迅速。对于传统的 Hadoop 集群，如果数据量急剧增长，所需的存储资源也要相应增加，这样会导致集群规模迅速扩大，计算资源也会变得过剩。抛开集群规模增长导致的其他问题不谈，光是运营集群的成本问题就足够让人头疼。好在公有云平台提供了对象存储的服务，我们可以按存储的数据量来付费，这在节约成本的同时，用户也不用担心 HDFS 在集群资源和数据量快速增长情况下的稳定性问题。但数据量快速增长还是会等比例的增加整体开销。

阿里云的对象存储服务 OSS，为用户提供了低频存储和归档存储，对于访问不是那么频繁的数据，如果能够转为低频或归档模式来存储，可以尽量节约成本。而一部分数据如果有频繁的访问需求，放在远离计算资源的对象存储上，又会导致计算时的 IO 出现瓶颈。JindoTable 对接数据湖中各种计算引擎，以表或分区为最小单位，统计数据的访问频次。根据用户设定的规则，JindoTable 可以告诉用户哪些表或者分区的访问频次较高，让用户可以通过 JindoTable 命令，借助 JindoFS 提供的底层支持，把这些表或者分区对应的数据缓存到计算集群内，加速查询的执行。同时，对于访问频次较低的表或者分区，用户也可以使用 JindoTable 把对应的数据转为低频或者归档存储类型，或是设置生命周期。在需要对归档数据操作的时候，可以直接用 JindoTable 对归档数据进行解冻。JindoTable 还为用户提供了元数据管理，方便用户检视表或者分区当前的存储状态。JindoTable 让用户能尽可能高效地管理自己的数据，节约成本的同时，不牺牲计算性能。