如何制作私人网站,wordpress笑话主题模板,wordpress模板原理,wordpress怎么调用音频简介#xff1a; 本期我们将揭秘Hologres如何支持超高QPS在线服务#xff08;点查#xff09;场景。
Hologres#xff08;中文名交互式分析#xff09;是阿里云自研的一站式实时数仓#xff0c;这个云原生系统融合了实时服务和分析大数据的场景#xff0c;全面兼容Post…简介 本期我们将揭秘Hologres如何支持超高QPS在线服务点查场景。
Hologres中文名交互式分析是阿里云自研的一站式实时数仓这个云原生系统融合了实时服务和分析大数据的场景全面兼容PostgreSQL协议并与大数据生态无缝打通能用同一套数据架构同时支持实时写入实时查询以及实时离线联邦分析。它的出现简化了业务的架构为业务提供实时决策的能力让大数据发挥出更大的商业价值。从阿里集团诞生到云上商业化随着业务的发展和技术的演进Hologres也在持续不断优化核心技术竞争力为了让大家更加了解Hologres我们计划持续推出Hologres底层技术原理揭秘系列从高性能存储引擎到高效率查询引擎高吞吐写入到高QPS查询等全方位解读Hologres请大家持续关注
往期精彩内容
2020年VLDB的论文《Alibaba Hologres: A cloud-Native Service for Hybrid Serving/Analytical Processing》Hologres揭秘首次公开阿里巴巴云原生实时数仓核心技术揭秘Hologres揭秘首次揭秘云原生Hologres存储引擎Hologres揭秘Hologres高效率分布式查询引擎Hologres揭秘高性能原生加速MaxCompute核心原理Hologres揭秘优化COPY批量导入性能提升5倍
本期我们将揭秘Hologres如何支持超高QPS点查。
传统的 OLAP 系统在业务中往往扮演着比较静态的角色以通过分析海量的数据得到业务的洞察比如说预计算好的视图、模型等从这些海量数据分析到的结果再通过另外一个系统提供在线数据服务比如HBase、Redis、MySQL等。这里的服务Serving和分析Analytical是个割裂的过程。与此不同的是实际的业务决策过程往往是一个持续优化的在线过程。服务的过程会产生大量的新数据我们需要对这些新数据进行复杂的分析。分析产生的洞察实时反馈到服务让业务的决策更实时从而创造更大的商业价值。
Hologres定位是一站式实时数仓融合分析能力Analytical与在线服务(Serving)为一体减少数据的割裂和移动。本文的内容将会针对Hologres的服务能力核心为点查能力介绍Hologres到底具备哪些服务能力以及背后的实现原理。
通常我们所说的点查场景是指Key/Value查询的场景广泛用于在线服务。由于点查场景的广泛需求市场上存在多种KV数据库定位于支持高吞吐、低延时的点查场景例如被大家广而熟知的HBase它通过自定义的一套API来提供点查的能力在许多业务场景都能够获得较好的效果。但是HBase在实际使用中也会存在一定的缺点这也使得很多业务从HBase迁移至Hologres主要有以下几点
当数据规模大到一定程度的时候HBase在性能方面将会有所下降无法满足大规模的点查计算同时在稳定性上也变得不如人意需要有经验的运维支持HBase提供的是自定义API上手有一定的成本。Hologres直接通过SQL提供高吞吐、低延时的点查服务。相比于其它KV系统提供自定义APISQL接口无疑更加的简单易用。HBase采用Schema Free设计没有数据类型对于检查数据质量修正数据质量也带来了复杂度查错难修正难。Hologres具备与Postgres兼容的几乎所有主流数据类型可以通过Insert/Select/Update/Delete标准SQL语句对数据进行查看、更新。在Hologres中的点查场景是指行存表基于主键PK的查询。
--建行存表
BEGIN;
CREATE TABLE public.holotest (a text NOT NULL,b text NOT NULL,c text NOT NULL,d text NOT NULL,e text NOT NULL,
PRIMARY KEY (a,b)
);
CALL SET_TABLE_PROPERTY(public.holotest, orientation, row);
CALL SET_TABLE_PROPERTY(public.holotest, time_to_live_in_seconds, 3153600000);
COMMIT;-- Hologres通过SQL进行点查
select * from table where pk ?; -- 一次查询单个点
select * from table where pk in (?, ?, ?, ?, ?); -- 一次查询多个点点查场景技术实现难点
正常情况下一条SQL语句的执行需要经过SQL Parser进行解析成AST抽象语法树再由Query Optimizer处理生成Plan可执行计划最终通过执行Plan拿到计算结果。而要想通过SQL做到高吞吐、低延时、稳定的点查服务则必须要克服如下困难
在不破坏PostgreSQL生态的情况下SQL接口如何做到高QPS
如何做低甚至避免SQL解析与优化器的开销
一套高效的Client SDK如何与后端存储进行交互
如何在低消耗的情况下做到高并发的交互如何减少消息传递过程中的开销如何感知后端的压力、配合做到最好的吞吐与延迟
后端存储如何在高性能的情况下更加稳定如何最大化利用cpu资源如何减少各种内存的分配与拷贝、避免热点key等问题对系统带来的不稳定性如何减少冷数据IO的影响
在克服上述3大类困难后整体的工作方式就可以非常的简洁在接入层(FrontEnd)上直接通过Client SDK与后端存储通信。 下面将会介绍Hologres是如何克服以上3大困难从而实现高吞吐低延时的点查。
降低、避免SQL解析与优化器的开销
Query Optimizer进行Short Cut
由于点查的Query足够简单Hologres的Query Optimizer进行了相应的short cut点查Query并不会进入Opimizer的完整流程。Query进入FrontEnd后它会交由Fixed Planner进行处理并由其生成对于的Fixed Plan点查的物理PlanFixed Planner非常轻无需经过任何的等价变换、逻辑优化、物理优化等步骤仅仅是基于AST树进行了一些简单的分析并构建出对应的Fixed Plan从而尽量规避掉优化器的开销。
Prepared Statement
尽管Query Optimizer对点查Query进行了short cut但是Query进入到FrontEnd后的解析开销依然存在、Query Optimizer的开销也没有完全避免。
Hologres兼容PostgresPostgres的前、后端通信协议有extended协议与simple协议两种
simple协议是一次性交互的协议Client每次会直接发送待执行的SQL给ServerServer收到SQL后直接进行解析、执行并将结果返回给Client。simple协议里Server无可避免的至少需要对收到的SQL进行解析才能理解其语义。extended协议Client与Server的交互分多阶段完成整体大致可以分成两大阶段。第一阶段Client在Server端定义了一个带名字的Statement并且生成了该Statement所对应的generic plan(不与特定的参数绑定的通用plan)。第二阶段用户通过发送具体的参数来执行第一阶段中定义的Statement。第二阶段可以重复执行多次每次通过带上第一阶段中所定义的Statement名字以及执行所需要的参数使用第一阶段生成的generic plan进行执行。由于第二阶段可以通过Statement名字和附带的参数来反复执行第一个阶段所准备好的generic plan因此第二个段在Frontend的开销几乎等同于0。
为此Hologres基于Postgres的extended协议支持了Prepared Statement做到了点查Query在Frontend上的开销接近于0。
高性能的内部通信
BHClient是Hologres实现的一套用于与后端存储直接通信的高效Private Client SDK主要有以下几个优势
1Reactor模型、全程无锁的异步操作
BHClient工作方式类似reactor模型每个目标shard对应一个eventloop以“死循环”的方式处理该shard上的请求。由于HOS对调度执行单元的抽象即使是shard很多的情况下这种工作方式的基础消耗也足够低。
2高效的数据交换协议binary row
通过自定义一套内部的数据通信协议binary row来减少整个交互链路上的内存的分配与拷贝。
3反压与凑批
BHClient可以感知后端的压力进行自适应的反压与凑批在不影响原有Latency的情况下提升系统吞吐。
稳定可靠的后端存储
1LSM(Log Structured Merge Tree)
Hologres的行存表采取LSM进行存储相比于传统的B树LSM能够提供更高的写吞吐因为它不会出现任何的随机写Append Only的操作保证了其只会顺序的写盘。
一个行存tablet上会存在一个memtable和多个immutable memtable。数据更新都会写入到memtable中当memtable写满后会转变为immtable memtableimmutable memtable会Flush成Key有序的SSTSorted String Table文件SST文件一旦生成则不能修改因此不会发生随机写的操作。SST文件在文件系统里面按层组织除了level 0上的SST文件间无序且存在overlap外其它level上的SST文件间有序且无overlap。因此查询的时候对于level 0上的文件需要逐个遍历而其它level的文件可以二分查找。底层的SST文件通过Compaction成新的SST文件去到更高层因此低层的数据要比高层的新所以一旦在某层上找到了满足条件的key则无需往更高层去查询。
2基于C纯异步的开发
采用LSM对数据进行组织存储的系统并不仅仅只有HologresLSM在谷歌的BigTable论文中被提出后很多的系统都对其进行了借鉴采用例如HBase。Hologres采用C进行开发相较于Javanative语言使得我们能够追求到更极致的性能。同时基于HOSHologres Operation System提供的异步接口进行纯异步开发HOS通过抽象ExecutionContext来自我管理CPU的调度执行能够最大化的利用硬件资源、达到吞吐最大化。
3IO优化与丰富的Cache机制
Hologres实现了非常丰富的Cache机制row cache、block cache、iterator cache、meta cache等来加速热数据的查找、减少IO访问、避免新内存分配。当无可避免的需要发生IO时Hologres会对并发IO进行合并、通过wait/notice机制确保只访问一次IO减少IO处理量。通过生成文件级别的词典及压缩减少文件物理存储成本及IO访问。
总结
Hologres致力于一站式实时数仓除了具备处理复杂OLAP分析场景的能力之外还支持超高QPS在线点查服务通过使用标准的Postgres SDK接口就能通过SQL获得低延时、高吞吐的在线服务能力简化学习成本提升开发效率。
作者周思华花名思召阿里巴巴技术专家现从事交互式分析引擎Hologres研发工作。
原文链接
本文为阿里云原创内容未经允许不得转载。
