简介:本期咱们将揭秘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零碎提供自定义API,SQL接口无疑更加的简略易用。
- 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(点查的物理Plan),Fixed Planner十分轻,无需通过任何的等价变换、逻辑优化、物理优化等步骤,仅仅是基于AST树进行了一些简略的剖析并构建出对应的Fixed Plan,从而尽量躲避掉优化器的开销。
Prepared Statement
只管Query Optimizer对点查Query进行了short cut,然而Query进入到FrontEnd后的解析开销仍然存在、Query Optimizer的开销也没有完全避免。
Hologres兼容Postgres,Postgres的前、后端通信协议有extended协定与simple协定两种:
- simple协定:是一次性交互的协定,Client每次会间接发送待执行的SQL给Server,Server收到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,次要有以下几个劣势:
1)Reactor模型、全程无锁的异步操作
BHClient工作形式相似reactor模型,每个指标shard对应一个eventloop,以“死循环”的形式解决该shard上的申请。因为HOS对调度执行单元的形象,即便是shard很多的状况下,这种工作形式的根底耗费也足够低。
2)高效的数据交换协定binary row
通过自定义一套外部的数据通信协定binary row来缩小整个交互链路上的内存的调配与拷贝。
3)反压与凑批
BHClient能够感知后端的压力,进行自适应的反压与凑批,在不影响原有Latency的状况下晋升零碎吞吐。
稳固牢靠的后端存储
1)LSM(Log Structured Merge Tree)
Hologres的行存表采取LSM进行存储,相比于传统的B+树,LSM可能提供更高的写吞吐,因为它不会呈现任何的随机写,Append Only的操作保障了其只会程序的写盘。
- 一个行存tablet上会存在一个memtable,和多个immutable memtable。
- 数据更新都会写入到memtable中,当memtable写满后会转变为immtable memtable,immutable memtable会Flush成Key有序的SST(Sorted String Table)文件,SST文件一旦生成则不能批改,因而不会产生随机写的操作。
- SST文件在文件系统外面按层组织,除了level 0上的SST文件间无序,且存在overlap外,其它level上的SST文件间有序,且无overlap。因而查问的时候,对于level 0上的文件须要一一遍历,而其它level的文件能够二分查找。底层的SST文件通过Compaction成新的SST文件去到更高层,因而低层的数据要比高层的新,所以一旦在某层上找到了满足条件的key则无需往更高层去查问。
2)基于C++纯异步的开发
采纳LSM对数据进行组织存储的零碎并不仅仅只有Hologres,LSM在谷歌的"BigTable"论文中被提出后,很多的零碎都对其进行了借鉴采纳,例如HBase。Hologres采纳C++进行开发,相较于Java,native语言使得咱们可能谋求到更极致的性能。同时基于HOS(Hologres Operation System)提供的异步接口进行纯异步开发,HOS通过形象ExecutionContext来自我治理CPU的调度执行,可能最大化的利用硬件资源、达到吞吐最大化。
3)IO优化与丰盛的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研发工作。
后续咱们将会陆续推出无关Hologres的技术底层原理揭秘系列,具体布局如下,敬请继续关注!
- Hologres揭秘:首次公开!阿里巴巴云原生实时数仓核心技术揭秘
- Hologres揭秘:首次揭秘云原生Hologres存储引擎
- Hologres揭秘:深度解析高效率分布式查问引擎
- Hologres揭秘:高性能原生减速MaxCompute外围原理
- Hologres揭秘:优化COPY,批量导入性能晋升5倍+
- Hologres揭秘:如何反对超高QPS在线服务(点查)场景
- Hologres揭秘:如何反对高吞吐Upsert
- Hologres揭秘:__如何反对高并发查问
- Hologres揭秘:__如何反对高可用架构
- Hologres揭秘:__如何反对资源隔离,反对多种负载
- Hologres揭秘:__向量检索引擎Proxima原理与应用实际
- Hologres揭秘:__读懂执行打算,查问性能翻十倍
- Hologres揭秘:__分布式系统如何设计Shard与Table Group
- Hologres揭秘:__如何反对更多Postgres生态扩大包
- Hologres揭秘:高吞吐写入Hologres的N种姿态
- ......
感谢您的浏览,也欢送应用体验Hologres,能够参考使用手册。
版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。