揭秘大数据时代秒级查询响应引擎的架构设计
文章目录 基于 IOTA 架构的秒算引擎如何设计? 数据处理性能提升 200% 秒算引擎 2.0 如何优化? 开放技术,拥抱开源
近年来,大数据技术发展迅速,从过去的 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 工作流任务调度系统,致力于解决数据处理流程中错综复杂的依赖关系,使调度系统在数据处理流程中开箱即用。易观希望通过开源的方式,让更多的人参与到大数据的生态建设中来。
目前,秒算引擎也计划逐步开源,通过开源将秒算的能力开放给更多需要的人,为更多的企业和开发者提供简单易用的服务。同时,也为技术社区的发展添砖加瓦,履行易观数据能力平民化的使命。
标题名称:揭秘大数据时代秒级查询响应引擎的架构设计
网站路径:http://scyanting.com/article/cpdsch.html