江西网站备案,门户网站做pos机,蛋糕店网站模板,wordpress 无限下拉云布道师
本文根据 2023 云栖大会演讲实录整理而成#xff0c;演讲信息如下#xff1a;
演讲人#xff1a;姜伟华 | 阿里云计算平台事业部资深技术专家、阿里云实时数仓 Hologres 研发负责人
演讲主题#xff1a;Hologres Serverless 之路——揭秘弹性计算组
实时化成为…云布道师
本文根据 2023 云栖大会演讲实录整理而成演讲信息如下
演讲人姜伟华 | 阿里云计算平台事业部资深技术专家、阿里云实时数仓 Hologres 研发负责人
演讲主题Hologres Serverless 之路——揭秘弹性计算组
实时化成为了大数据平台的核心演进趋势而其中 Serverless 技术可以让企业在实时场景取的性能、成本、高可用之间的平衡。2023 年云栖大会上阿里云实时数仓Hologres 研发负责人姜伟华介绍了一站式实时数仓 Hologres 在 6 年研发期间的Serverless 演进之路让客户实时数仓成本降低 70%-120%开发效率提升 100%性能提升 100-200%。
一站式实时数仓 Hologres
首先向大家简单介绍下 Hologres。Hologres 是阿里云自研一站式实时数仓以分析服务一体化架构统一数据平台架构实现一份数据同时支持支持多维分析、在线服务、湖仓一体、向量计算多个场景其中包含了
多维分析实现同 CK、Doris 等查询场景 数据高性能实时写入、更新与查询实现写入即可查支持列存、内置索引加速在线服务实现同 Hbase、Redis 等点查场景 超高 QPS 下 KV 与 SQL 点查、非主键点查支持行存、具备高可用能力湖仓分析实现同 Presto 等交互式分析场景 无需数据搬迁对 MaxCompute、数据湖中的表进行秒级交互式查询元数据自动发现向量计算实现同 Faiss 等向量查询场景 内置达摩院 Proxima 向量引擎QPS
Serverless 实时数仓的挑战与关键技术
在一个 All in one 的一站式实时数仓架构下像我们刚才提到的希望一份数据同时能支持以上四种场景那各个业务部门、各种业务需求便随之而来例如
稳定性需求 在进行资源的扩缩容、启停时候如何不影响实时在线的业务 如何保证业务/任务之间的隔离例如读写隔离、写写隔离、读隔离、任务隔离。并且是比起资源组或者资源队列来说更加干净的隔离。 如何有效利用资源例如水平的扩展实现 QPS 的简单增加从 500 QPS 到扩展1000 QPS 只需要简单加一倍资源即可让资源管理更加简单。成本优化需求 如何降低开发成本例如上线新业务基于同一份数据但是使用新的计算资源。 如何降低资源资源例如基于定时和负载做弹性应对洪峰、日夜变化用完即销毁Endpoint 保持不变。 如何降低学习成本例如开发接口是否通用是否能对接主流的BI产品。 于是实时数仓在接收了这么多需求后自然而然将 Severless 定义为平台核心演进方向Hologres 在 年的 Serverless 演进过程中总结下来了 4 项 Serverless 实时数仓关键技术挑战
存算分离 不管是 Hologres, 还是说其他的大数据产品经常讲一个词叫存算分离。为什么要做存算分离因为存算分离是实现 Serverless 化的一个前置条件Serverless 核心关注是计算资源的弹性这就要求存储和计算必须分离。Hologres 从产品第一天开始就是一个存算分离的架构。
如果不做存算分离的话有什么问题呢传统上像 Greenplum数据是存在本地磁盘的而本地磁盘有一个容量限制存满了就会有搬迁代价很大。第二个问题是数据的访问Serverless 本质上来说希望计算资源随时可以拉起然后就可以去访问数据任何计算资源都能访问到这个数据。但如果你要存在本地的话就不能够让任何一个计算资源访问只有本地盘能访问。
所以在 Serverless 的情况下一般来说数据肯定是存在一个分布式的文件系统上的。通过分布式文件系统首先第一个是解除了容量限制第二个任何的计算资源都可以去访问到这份数据计算资源和存储资源都能池化。如果是一个离线数仓的话这个问题就解决了因为数据都在分布式文件系统上任何计算资源都能访问到这个数据。
对于实时数仓来说有一个挑战在于数据是不是足够实时。实时数仓我们强调一个实时性就要求写进去的数据马上就能访问到所以在这件事情上不同的产品可能会有他的各自的取舍。
如果我们能容忍一个五分钟或者十分钟的查询延迟所有的数据客户端攒 5-10 分钟后发送过来直接写到分布式文件系统上别的计算资源就能访问到了。但是这个对用户体验其实是很差的。因为等于说数据写了那边查不出来延迟 5-10 分钟。Hologres 采用的是一个对用户比较友好的方案写入即可查。
写入即可查是有经典方案的就是 Mem Table LSM Tree。比方说像 Hbase 或者其他一些产品都是采用这样一个架构这个架构本质就是有一部分持久化的数据这些数据是存在分布式文件系统上的别人也能看到。但是最新的数据是在 mem Table 中的这部分数据只有本机能看到。
同时 Hologres 支持高频的 CRUD, 就是高频的更新与删除。因为有很多应用希望基于主键做非常高频的更新或者删除就要求一定要有一个主键索引。而这个主键索引一定要在内存里否则的话就是性能跟不上。并且这个主键索引还在不停的被更新。 Shard Replica Hologres 将实时写入高频 CRUD 这两点结合让实时数仓保持高频的实时更新或删除且写入即可见这样在使用体验上会非常像一个数据库对用户非常友好。但是同时它也带来了一个新的问题就是最新的几分钟数据是在内存里。刚才说Serverless 的场景下我们希望任何拉起的计算资源都能访问到这些数据。但是那些数据是在内存里的所以这是一个很特别的挑战。Hologres 解这个问题的方法我们称之为叫做 Shard ReplicaShard副本。
简单来说就是每个 Shard Replica 在实现机制上很像数据库里面的物理复制。数据库的物理复制是有一个从实例通过同步了主实例的 write ahead log然后重放这些 log然后构建 B tree把数据刷下去。在数据库的实现中主从两个实例的数据也是各自存各的。Hologres 在这个地方有一个创新Shard Replica 做了物理复制但仅在内存中构建了自己的 MEM Table, 这样子 Shard 副本就能看到最新的数据。但是 Shard 副本是不会去 flush 数据到文件系统的。这样分布式文件系统上的数据就只有一份。这样 Replica 通过自己的 MEM Table 与主 Shard 的存算分离的落盘数据就可以完整的访问所有数据了实现了实时的可见性。
副本的维护代价大概是主的 1/4 或者 1/8 的样子。
Shard Replica 能力是 Hologres 实现存算分离、高可用、容灾、高 QPS 等等的基础。 隔离与弹性 有了这个存算分离能力以后下面怎么样做刚才说到有了存算分离那可以任意地拉起计算资源并访问所以这个时候就可以做强的资源隔离并且自然可以弹性的伸缩也能够自适应的去响应负载。 高可用 在高可用上实时数仓跟一般的离线数仓做 Serverless 上有一些差异。因为一般离线数仓更关注的是资源能不能用满但实时数仓要求有很高的 SLA 保证。比方说延迟或抖动这种都是不允许有的。我们如何能保证在强隔离的情况下还能做到各种自由的弹性伸缩与高可用性。 离线数仓不是基于连接的每次提交一条 SQL执行完给出结果然后再来一条。但是实时数仓是基于连接的有点像数据库在资源的变化的过程中各种变更、扩缩容等如何做到自动的路由负载均衡。在计算资源弹性时连接与现有查询不受影响在后台计算资源改变时原有连接资源可自动路由到新的计算资源上保证连接不断。这些能力对于 Serverless 实时数仓来说非常有挑战性。
Hologres 的 Serverless 演进之路
刚才说到的这些难题与挑战Hologres 也不是一下子解决的接下来我们向大家介绍下 Hologres 在 6 年的发展中在 Serverless 是如何逐步演进的希望能和大家有一些交流。 2018 年 Hologres 在阿里内部立项。2019 年产品化并在阿里集团内部大规模使用。到 2020 年我们在阿里云上正式商业化并且在业界第一个提出了分析服务一体化。到了 2021 年我们主要增强一些企业级的能力。2022 年 Hologres 重点发布了主从实例。主从实例是我们 Serverless 演进过程中的一个关键步骤有非常多的客户在生产环境中用上了我们的主从实例实现了一份数据多种计算。跟传统数据库的主从不一样它的数据只有一份因为大数据场景下数据量很大对用户来说一份数据可以极大地节约存储成本。同时存算分离下的主从实例允许大家为不同的业务快速的拉起一个从实例干不同的工作如果不需要的话也可以快速地把它给销毁掉没有任何数据搬迁的过程。到了 2023 年我们正式发布计算组实例。是Hologres 面向完全的 Serverless 化的基本产品形态。 阶段一独享实例 独享实例是 Hologres 常用的形态基于之前我们提到的存算分离架构底下是阿里盘古文件系统上面是计算实例用户想要扩容、缩容都非常方便不需要做数据搬迁。但是唯一的问题是用户必须要小心翼翼地控制规格大小比方 QPS 压力太大了那你就要扩容不能做到资源按需使用按需付费。 阶段二共享集群 Hologres 在 2020 年就推出了一个完全 Serverless 化的湖仓共享集群它是不带存储只会按量收取计算费用。首先 Hologres 与离线数仓 MaxCompute 做了一体化的融合如果想要更快地查询 MaxCompute 中的离线数据不需要将数据导出也不需要预留任何资源运行一条 SQL 直接查询就可以最终只按照 SQL 查询量收费用户在不使用的时候不会收任何的费用也不需要任何的启停操作。这是我们做的非常彻底 Serverless 的产品不仅仅是 MaxCompute 中的数据还可以查询 OSS 中数据湖的数据。
共享集群仅适用离线数仓与数据湖加速查询的场景没有很好的 SLA 的保证。 阶段三主从实例 为了实现资源的强隔离同时支持一份数据、多种计算的愿景Hologres 推出了主从实例实现一份数据多种计算计算之间完全隔离。
一个典型的场景首先有一个读写的独享主实例负责数据的写入然后按需创建多个只读的从实例。这个创建过程非常快没有任何数据搬迁。比方说现在线上业务在跑着突然发现线上业务数据不太对。那怎么办呢用户可以临时拉起一个从实例然后在上面做数据分析找出问题在哪里这对用户来说是一个非常易用的一种体验。
这种场景我们做了非常强的隔离存储层面依托盘古强大的分布式文件系统的能力基本可以保证 IO 之间没有竞争。计算层面我们通过 K8S 实现隔离做到了计算之间也没有竞争。存储与计算都没有竞争让用户实现了很干净的强隔离体验也非常好。我们见过最多的一个客户是一主九从挂了非常多的从实例干各种各样的事情比如分配一个从实例给经常做分析的同事或者分配一个从实例给某个特定部门。
但是这种主从实例也有它的问题由于每一个都是一个独立的实例每个都有一个入口用户如果要用新的从实例必须要去改他的代码把代码指向这个新的实例才能用起来这样用户体验就不够好不够灵活所以今年我们正式推出了计算组实例。 阶段四计算组实例 计算组实例内部有多个计算组计算组之间还是强隔离但是它是一个实例有一个统一的路由于是在计算组内部各种强隔离、弹性自动路由等等都可以做了。
计算组上面有一个 gateway, 这是一个网关用户所有的请求都会通过这个网关打过来。下面的计算组跟刚才的从实例很像。每个计算组都是一组独立的计算资源。计算组和计算组之间是强隔离的由网关来进行这个任务的路由。这样对用户来说永远看到的是同一个网关。所有的弹性扩缩容等操作都是管理员做的事情对用户来说是无感的也解决了我们在主从实例中留下的不够灵活的问题。 举几个典型应用场景
计算组实例应用动态扩容
一般我们分 2 个计算组包括默认计算组和查询计算组其中默认计算组只承担写入ETL 等流程查询计算组负责对外查询实现读写隔离。当实时数仓使用人更多服务更多部门时读写隔离不能完全满足需求写入与写入之间会有资源争抢查询之间也有资源争抢。我们就可以需要提供扩容多种计算组比如离线写入计算组、实时写入计算组、OLAP 查询计算组、在线服务计算组实现不同场景/业务之间的完全隔离。
计算组实例应用弹性伸缩
在大促或者某些场景下我们经常遇到资源不足的情况当流量洪峰来临时根据业务需求对单个计算组扩容低峰期对计算组进行缩容同时系统支持热扩缩容方式将业务影响降到最低并且防止资源的浪费。
计算组实例应用自动路由
某一个计算组出了问题或者压力太大发生 Failover 后影响业务需要快速止血时我们希望给它减少流量或者完全停掉。原来是解不了这个问题用户只能改应用程序。现在管理员只需要通过 SQL 命令实现自动路由机制无需改动应用接口快速将 Failover 计算组的负载路由至默认/指定计算组实现业务快速恢复。
客户案例 某客户Serverless实时数仓升级之路
刚才我们是从 Hologres 自身的视角来看待实时数仓的发展与演进最后我们来看一个我们长期的资深用户是如何一步一步基于 Hologres 来做自己业务实时数仓的升级与 Serverless 化的。 这是一个物流的客户他们业务主要做仓储的管理有好几类业务第一类业务叫实时播报需要一个快速开发的高保障的一个业务。第二个业务就是仓库的各种实时作业指导仓库这种货放到哪里去等等需要一个作业调度系统要求高性能并且要持续服务高 SLA 的保证。第三类像传统的大屏或者说类似指标中心的自助分析要求更强的灵活性。整体业务规模上大概有 350 个左右的实时任务消耗 1 万 CU量非常大。同时 P2 级以上的重点任务占了 70%对 SLA 的要求也非常高。从性能要求上日均大概是每秒钟写入 2000 万条记录峰值能达到每秒 6000 万条然后每秒输出大概 50 万条记录整体的实时吞吐性能非常高。 可以看到这是一个业务复杂对性能、SLA、成本等都有非常多要求的客户场景。 实时数仓 1.0-Hologres 替换传统数仓 最早的时候实时数仓 1.0底下实时数据从 DWD 到 DWS 到 ADS, 这个加工层是通过消息队列 Kafka 加上 Flink 来做的。他们会把结果数据同时写两个地方一个是 Lindorm类似于 Hbase因为刚才我们提到的物流库存作业是一个高稳定性保障业务所以他用这个来对外提供点查的能力。同时将数据写入 Hologres提供交互式分析与 OLAP 查询等服务。
实时数仓 2.0-Hologres 升级主从实例高可用部署 2022 年随着 Hologres 推出了主从实例他们做了一次架构的变更。首先从实时数据加工链路上本来 FlinkKafka 实现的 DWD、DWS、ADS 层加工现在改成用 HologresFlink 来做把 DWD 层写到 Hologres 里面去同时 Flink 订阅Hologres 的 Binlog。这样任何一张表的变更Flink 都能感知到。Flink 加工得到的 DWS 层再写到 Hologres 里面去。然后再通过 Flink 订阅 Binlog, 加工 ADS 层写到 Hologres 里面去。这时候大家可能觉得这个场景有点奇怪为什么要这么搞来搞去。其实这个架构最大的好处是每一层数据都是可查可对外服务的。原来架构中数据在 Kafka 中只能给 Flink 用。如果数据有问题要去查一下问题都很困难。而在这个架构中每一层的数据都是 Hologres 对外提供服务的。不需要数据冗余同一份数据既可以给 Flink 应用也可以对外提供服务。
同时为了支持隔离与高可用他们建了好几个从实例来给不同的业务用。需要的时候就再创建一个。实现了读写分离和同城容灾故障从 6 次降为 0 次存储下降几百 T开发效率提升 100%。
实时数仓 3.0ing-Hologres 计算组实例弹性和隔离 2023 年随着我们推出了计算组实例后他们把整个主从实例替换成了计算组实例。通过拉起不同的计算组统一对外提供服务。整个实时数仓的架构更加 Serverless化拉起一个新的计算组不再需要去改应用每个计算组又能提供很好的隔离。 最后讲一下我们对未来趋势的一些看法虽然 Hologres 推出了计算组实例坦率地说这只是我们 Serverless 化的开始。作为一个云产品我们希望让客户通过 Serverless使用起来更简单成本更低。因此我们在未来主要有两个目标第一个是 Down To Zero简单来说当用户不用任何计算的时候不问用户收取任何计算的费用。并且在这种情况下如果有请求进来计算资源能秒级恢复并响应并不是说停掉了以后请求来了就断掉了。第二个目标我们希望能够把独享实例和共享实例统一在一起变成一个统一的对外的形态实现自助资源切换。最终用户在没有计算的时候可以不花一分钱请求来了能及时响应业务变化又能灵活满足多种资源需求这是我们希望给用户提供的终极形态。
除了 SeverlessHologres 在本次云栖大会还将物化视图升级 DynamicTable 进行升级与 Flink 结合构建流批一体的数仓分层架构用户只需描述数据的应用场景、产生逻辑、实时性要求、分层依赖DynamicTable 负责高效的一体化工程实现保持数据高性能的实时写入、实时更新、实时查询解决离线实时重复开发、数据不一致学习成本搞运维复杂等难题。
在淘天集团直播数据决策分析产品中Dynamic Table 数仓分层架构让实时数仓整体性能提升 200%延迟下降 85%在淘天集团营销活动分析场景中Dynamic Table 数仓分层架构让实时性能提升 30%离线性能提升 800%这个功能在不久之后也会在公共云开放给客户使用。
可以看到无论是 Serverless 还是物化视图的升级Hologres 在演进过程中始终紧紧围绕实时场景不断提高实时数仓的性能、可用性、用户体验。Hologres 希望替换企业纷繁芜杂的数仓架构通过一站式的理念让实时数仓更加干净、友好、高效并帮助企业不断降低成本加速数字化转型升级。
