揭秘大数据时代秒级查询响应引擎的架构设计

文章目录

基于 IOTA 架构的秒算引擎如何设计?
数据处理性能提升 200% 秒算引擎 2.0 如何优化?
开放技术，拥抱开源

声明：本文来自于微信公众号 Analysys易观（ID：enfodesk），作者：黄显东，授权转载发布。

近年来，大数据技术发展迅速，从过去的 hive、Spark，到现在的 Flink、Clickhouse、Iceberg 等，各种大数据技术推陈出新，不断演进大数据存储和引擎系统的架构，来适应大数据时代的海量数据处理需求。

大数据

而随着技术的更迭，每次架构演进都需开发人员重构一次业务代码，既耗费了开发人员的精力，又会影响数据处理的效率。另外，在 PB 级数据体量下，开发人员还面临数据秒级处理与数据准确兼顾的挑战。

为此，易观基于 IOTA 架构思想设计出秒算引擎架构，以解决开发人员在数据处理上遇到的难题，并提升数据处理效率与质量。那可以秒级查询响应的秒算引擎是如何设计的呢?易观 CTO 郭炜与易观架构师高俊，给出了详细的分析和解读。

基于 IOTA 架构的秒算引擎如何设计?

秒算引擎是一个用户行为分析的数据解决方案，包含数据接收、数据实时处理、数据冷热存储和 OLAP 分布式 SQL 查询引擎，基于下一代 IOTA 架构设计，可针对各种业务场景进行快速分析查询。

基于IOTA架构，支持引擎快速升级

整体架构上，通过 SDK 在设备端将采集的数据转化成统一的数据模型，然后传送到秒算引擎中。秒算引擎分为临时存储、历史存储和查询引擎，由查询引擎将临时数据和历史数据合并，并提供统一的查询接口供用户查询。

架构以统一的数据模型贯穿始终，秒算引擎内部模块支持热插拔，可以保持前端查询引擎不变的情况下，将存储引擎个性化更换。

数据模型采用高度抽象的主谓宾数据模型，既能规范各端数据格式，又具有通用性和扩展性，解决了传统非结构化数据在结构化存储时带来的数据质量问题。秒算引擎还可实时处理用户上报的数据并入库，并立即和历史数据一起被分析计算。

除此之外，秒算引擎中数据表的表结构是由收到的真实数据动态生成，用户可以随时上报自己感兴趣的数据和字段，解决了过去分析系统 Schema 维护难的问题。还具有热数据自动 Dump 到磁盘、磁盘上的小文件自动 Merge、支持多种数据源的数据统一查询分析等特点。

数据处理性能提升 200% 秒算引擎 2.0 如何优化?

一、实时数据缓冲层架构升级

秒算引擎中，历史数据都保存在 hive 中，不过 hDFS 文件对追加写的支持不友好，需要将最近一段时间内上报的数据暂时存储在支持高吞吐、低延迟写入更新的数据库中。当数据量达到一定的阀值时，由秒算的后台线程将数据 Dump 到 hive 中。整个过程，通过 Presto 的视图来保证 hive 中的数据和实时缓冲层的数据同时参与分析计算。

Kudu引擎“透明”替换，数据处理性能数倍提升

由于单一的技术方案无法应对越来越差异化的需求场景，在秒算引擎 2.0 中抽象了 Buffer 层，以实现快速的切换新的缓冲层数据库，同时也让秒算引擎拥有更好的扩展性。秒算 2.0 通过采用 Kudu 替换 hbase，数据处理的消费性能和持久化性能分别分别提升 200% 和 300%。

二、智能虚拟分桶

秒算引擎 1.0 中用户上报的事件在 hive 中是以用户 id 和事件发生时间排序后保存的，保证同一个用户的行为数据在磁盘上是连续的，可以减小查询时的磁盘寻址时间。同一个用户的行为数据按事件发生的时间做好排序，这样在漏斗等分析场景下可以优化排序的时间，提升查询性能。

不过，大部分产品在版本的迭代中会产生很多的事件，有些事件是核心事件，经常需要参与分析查询。还有些事件日常的分析场景使用不多，但会产生大量的事件数据，比如热图事件，如果把这类事件的数据和核心事件的数据放到一起，会影响到核心事件的查询性能。

核心数据和行为数据隔离，提升数据分析查询性能

因此，秒算引擎 2.0 中新增了智能虚拟分桶这一特性，通过智能虚拟分桶，可以将核心数据和行为数据隔离。借助这一特性，可以将核心事件放到同一个桶中，非核心的事件放到其它桶中，这样便可以提升数据分析查询的性能。

智能虚拟分桶主要分为以下一个步骤：首先是智能生成分桶策略。其次根据分桶策略，在数据从 Buffer 层 Dump 到 hDFS 时，将对应的事件数据放到该事件的分桶文件中。最后是查询引擎根据查询涉及的事件读取该事件对应的 hDFS 文件。

三、优化查询计划

秒算引擎的一部分最新数据保存在 Buffer 中，历史数据保存在 hive 中，通过使用了 Presto 的视图功能来同时查询 Buffer 和 hive 中的数据，在视图里 Union all 不同存储库里的表，来提供统一的查询能力。

但在使用过程中，Union all 的两个子查询可能有不同的过滤条件，会导致 Presto 在处理 Union all 时的执行计划和查询单表的执行计划不一样。所以 Presto 查询引擎针对 Union all 的场景需要先将 Union all 两边的数据都读出来，之后再在上层做 Where 条件的过滤。

修改Presto执行计划，提升秒算查询性能

不过，如果 Union all 两边子查询的过滤条件本身一样，或者没有过滤条件，那就可以将这个视图的查询当成查询单表来处理的，即直接将 Where 条件下推到执行计划的 Source 阶段。

基于此认知，秒算引擎 2.0 修改了 Presto 的执行计划，专门针对这一点做了优化，提升了秒算的查询性能。同时针对 Presto 的优化，也已经反馈给 Presto 社区，通过社区为更多的人提供支持和帮助。

基于通用性、可二次开发的底层架构，秒算 2.0 引入了分池(Pool)查询。分池查询支持复杂长查询和短查询分开运行，保证在高并发访问与查询数据量大时，普通查询不会被一个复杂长查询阻塞。

引入分池(Pool)查询，解决大查询困扰

开放技术，拥抱开源

在易观多年的技术开发过程中，开源是基本的技术价值观。在 2019 年 8 月，易观自主研发的分布式任务调度引擎 DolphinScheduler 通过了 Apache 软件基金会的投票决议，正式成为 Apache 孵化器项目。

DolphinScheduler 是一个分布式、去中心化、易扩展的可视化 DAG 工作流任务调度系统，致力于解决数据处理流程中错综复杂的依赖关系，使调度系统在数据处理流程中开箱即用。易观希望通过开源的方式，让更多的人参与到大数据的生态建设中来。

目前，秒算引擎也计划逐步开源，通过开源将秒算的能力开放给更多需要的人，为更多的企业和开发者提供简单易用的服务。同时，也为技术社区的发展添砖加瓦，履行易观数据能力平民化的使命。