淘客客怎么做自己的网站,常用的网站建设技术有什么,软件专业做学校网站论文怎么选题,网站开发过程文档作者#xff1a;StarRocks Active Contributer、微信 OLAP 内核研发工程师 微信作为国内活跃用户最多的社交软件#xff0c;其数据平台建设经历了从 Hadoop 到 ClickHouse 亚秒级实时数仓的阶段#xff0c;但仍旧面临着数据体验割裂、存储冗余的问题。通过 StarRocks 的湖仓… 作者StarRocks Active Contributer、微信 OLAP 内核研发工程师 微信作为国内活跃用户最多的社交软件其数据平台建设经历了从 Hadoop 到 ClickHouse 亚秒级实时数仓的阶段但仍旧面临着数据体验割裂、存储冗余的问题。通过 StarRocks 的湖仓一体方案以及和社区密切配合开发的实时增量物化视图微信解决了“实时、极速”背后的“统一”诉求。在直播业务场景中通过湖上建仓的方案改造使得数据开发同学需要运维的任务数减半同时存储成本降低65%以上离线任务产出时间缩短两小时。 当前基于 StarRocks 的湖仓一体方案已经在微信的多个业务场景中上线使用包括视频号直播、微信键盘、微信读书和公众号等集群规模达到数百台机器数据接入量近千亿向理想化的湖仓一体形态不断演进。 背景 从 Hadoop 到亚秒级实时数仓建设多年以前微信的数据分析架构还是完全基于 Hadoop 生态的其存在着较多的弊端首先查询非常慢数据延迟高业务同学进行数据开发也很慢其次在架构方面采用的是流批分离的架构整体架构非常臃肿。 随着微信业务的不断发展视频号等推荐系统对个性化体验的强烈诉求我们基于 ClickHouse 内核打造了亚秒级的 OLAP 实时数仓广泛用于 A/B 实验平台、BI 分析、实时指标计算等场景中。在基于 ClickHouse 的实时数仓中我们做到了亿行数据的亚秒级响应海量数据的低延迟、精确一次接入实现了流批一体架构。 “实时、极速”后的“统一”诉求一直以来数据分析技术栈从 MySQL 开始基本上是沿着两条路线不断往前演进的一条是实时的路线另一条是极速的路线。实时的路线经历了从 Lambda 架构到 Kappa 架构再演进到最近的 Data Lake形成流批一体而极速的路线经历了从 Hive 小时以上的分析时延然后演进到 SparkSQL再到 Presto/Druid/Kylin 达到分钟级的查询时延最终演进到了诸如 ClickHouse 这类的 OLAP 数据库达到亚秒级响应。从未来的趋势来看两者会形成统一这也是湖仓一体/Modern OLAP 所要达到的目标。 在微信的数据分析场景中主要面临三个方面的挑战 海量数据在我们的业务场景下数据规模很大单表日增万亿单次查询扫描数据量在10亿以上同时需要计算的指标和维度可能会非常多50维度100指标 极速微信业务场景对查询耗时要求极高查询耗时 TP 90 需要在5秒以内同时要求数据低时效秒/分钟 统一我们希望能够实现计算侧和存储侧的统一。 过去在基于 ClickHouse 的实时数仓中我们已经解决了海量数据和极速的挑战但还有一个统一的需求没有解决。 湖仓一体 湖仓一体要解决的是通用大数据计算引擎处理 OLAP 数仓体验割裂、存储多份的问题。过去无论是在湖上面还是仓上面都存在着相应的困境。 湖上面面临的主要问题是查询性能太慢如果需要对 Hadoop 中的数据进行即席查询则需要先将数据导出到 OLAP 数据库中再进行查询加工造成了资源的浪费工序繁琐而仓上面存在着通用大数据计算引擎处理 OLAP 实时数仓生态不够友好的问题例如Spark 无法直接分析 ClickHouse 中的数据如果要进行查询分析则需要先将数据从 ClickHouse 落回 Hive 中。总结来看过去的架构存在的问题就是 两份存储 口径不一致 额外的数据导入导出步骤 数据分析流程难以标准化 通过湖仓一体架构我们希望能够真正解决上述问题实现存储统一、接口统一、元数据统一亚秒级查询与分钟级查询统一等最终理想化的湖仓一体形态面向SQL用户不再需要感知底层架构。 技术路线一湖上建仓 实现湖仓一体的第一种技术路线是湖上建仓即在数据湖基础上实现数仓的功能代替传统数仓构建 Lakehouse在传统 Hadoop 系统中引入 Delta lake、Hudi、Iceberg 或 Hive 3.0 等更新技术引入 Presto、Impala 等 SQL on Hadoop 查询引擎引入 Hive Meta Store 进行统一元数据和权限管理引入对象存储作为底层存储等数仓特性形成湖仓一体业务比较有代表性的是 Databricks 提出的湖仓一体架构。 在微信内部湖上建仓的架构经历了从 PrestoHive 到 StarRocks Iceberg 的演变过程通过使用 StarRocks 替代 Presto数据的时效性从小时/天级提高到了分钟级同时查询效率从分钟级提高到了秒级/分钟级其中80%的大查询用 StarRocks解决秒级返回剩下的超大查询通过 Spark 来解决。 秒级 中大表秒级返回StarRocks 分钟级大表查询,分钟级Spark 与 Presto 相比StarRocks 直接查湖的性能提升 3-6 倍以上。 目前在我们的使用场景中湖上建仓的方案主要通过外挂调度的方式来实现。未来当 StarRocks 的外表物化视图功能更加成熟以后会采用更加简洁、方便、易于运维的外表物化视图来实现。 湖上建仓方案具有的优点是成本低实现简单同时 Hadoop 生态兼容性更好。但其存在的缺点是数据延迟较高需要5-10分钟左右另外ODS、DWD 层的查询会比较慢需要通过本地缓存等方式来进行加速。因此综合来看湖上建仓的方案主要还是湖为主更适合于离线分析为主的场景。 技术路线二仓湖融合 实现湖仓一体的第二种技术路线是仓湖融合通过在数仓中加入跨源融合联邦查询的功能打通内容存储从而不需要经过 ETL 能够直接分析数据湖。在该方案中我们采用冷存下沉的手段实现仓湖数据的统一。 在该方案中数据会先实时接入仓之后冷存经过转换下沉到湖通过 Meta Server 实现仓湖元数据的统一管理在查询时能够合并冷热数据读取同时通过 SparkLake API 提供对通用离线计算的支持。在该方案中由于数据是先落仓的因此数据的实时性会更高在秒级到2分钟以内同时 DWD 层的查询响应会更快。但其缺点是成本高热数据TTLHadoop 生态兼容性不如湖上建仓的方案。因此综合来看仓湖融合的方案主要还是考虑仓为主更适合于实时分析为主的场景。 当前仓湖融合、冷存下沉的湖仓一体方案已经在微信安全的业务场景中落地接入的大表每日数据量达数十亿超大表每日数据量千亿以上。小时分区降冷耗时分钟级天分区降冷耗时小时级在内存消耗方面单任务最大消耗 5GB 左右对集群无明显影响。 同时通过 BE/FE 参数调优 compaction 线程数比例调整、flush 线程数调整、并发事务数调整消除了大表并发时的数据挤压全天稳定运行 上线前 上线后 湖仓一体架构 从前面的分析中可以看到湖上建仓和仓湖融合两种方案各有优缺点分别适用于湖为主和仓为主的业务场景而在微信的业务场景中两种路线都有需求。 因此在我们的湖仓一体方案中采用的是湖上建仓和仓下沉湖的融合方案。 在该方案中我们同时支持实时接入和准实时接入用户可以根据自身对成本、性能和数据时效性的要求来选择通过哪种方式进行接入并且是可切换的。例如刚开始时用户对性能、数据时效性要求不是特别高那么可以选择通过湖接入的方式这样成本较低当后续该用户对性能和数据时效性要求变高了那么他可以切换到仓接入的方式这样就可以满足需求。因此在我们的湖仓一体架构中既能够支持极速 BI 分析的场景也能够满足通用离线计算的需求。 实时增量物化视图 过去在 StarRocks 中主要有两种不同类型的物化视图异步物化视图和同步物化视图。 异步物化视图会根据基表的数据变化定时触发刷新或手动刷新物化视图更新数据变化在进行刷新时需要对整个表或整个分区进行一次完整的 INSERT OVERWRITE如下图所示。在查询基础表时优化器会根据物化视图定义自动进行查询改写从而利用物化视图的预计算结果来对查询进行加速同时也可以直接查询物化视图表的数据。 然而由于需要不断进行分区级的 INSERT OVERWRITE 刷新当基础表的数据量比较大时这一刷新的过程开销会非常大容易影响集群整体负载和稳定性同时物化视图是通过异步刷新来更新数据的更适合于离线数仓场景而不适用于实时数仓场景。 同步物化视图能够在数据写入基础表的时候同步刷新物化视图。与异步物化视图不同的是同步物化视图的结果是作为一个 Index 和基础表绑定在一起的物化视图本身对用户不可见不能直接查询。在查询基础表数据时能够基于基础表中存在的同步物化视图进行透明加速 然而 StarRocks 的同步物化视图具有一些限制 不支持复杂表达式仅能够对基础表中的列进行简单的聚合操作无论是维度列还是指标列中都不能包含复杂表达式 不支持输出列别名 基础表中的列不能在物化视图中被多次引用 仅支持少量聚合函数不支持通用聚合函数 物化视图数据与基础表强绑定无法直接查询物化视图数据。 在湖仓一体场景下对于实时性、性能要求高的场景我们需要通过实时增量物化视图来进行加速。微信的实时物化视图具有如下一些特点 大规模单表数据量大因此物化视图只能增量更新不能全量刷新 实时性要求高需要同步刷新不能异步刷新 多表指标拼接多个基础表的物化视图计算指标拼接到同一个物化视图目标表中 在物化视图写入时进行高性能维表关联 ... 针对这些特点和要求我们基于 StarRocks 的物化视图功能与社区共同在过去的同步物化视图基础上进行了新的探索以适应这类更加复杂的分析 物化视图增强技术路线 多流同步物化视图 - 全局字典关联 - streaming 物化视图(doing) - 湖上增量同步物化视图 目前实现到第二阶段已经可以实现多数 ClickHouse 增量同步物化视图的能力下边详细介绍 多流同步物化视图 在新的实时增量物化视图设计中我们将基础表与存储物化视图结果的目标表进行了解耦物化视图本身仅用来表达计算逻辑如下图所示。这样做有多个方面的原因 在数仓体系中基础表通常属于 ODS 层需要保留37天而存储物化视图结果的目标表属于 DWS 层通常需要保留半年到一年将这两者解耦之后我们才能够分别为其定义不同的存储周期。 将物化视图的计算逻辑和计算结果完全解耦业务不需要关心具体的计算逻辑直接查询物化视图目标表中存储的指标结果即可能够极大提高易用性同时能够将上下游业务逻辑解耦上游计算逻辑发生变化不会影响下游使用。 最后只有将两者解耦我们才能够实现多个基础表的协议关联通过让多个基础表的物化视图计算结果写同一个目标表从而完成指标拼接。 基于全局字典的维表关联 在我们的物化视图场景中另一个比较关联的需求是基于全局字典的维表关联。维表关联是在 BI 场景、流式计算中一个非常通用的问题。在过去我们需要依赖于 Flink 任务在上游先完成维表关联的工作得到中间表然后再将中间表写入物化视图进行查询加速。而基于高性能的全局字典功能我们能够在数据写入时通过查询字典表直接在 OLAP 数据库的内部完成维度表的关联从而不再需要依赖于繁重的 Flink 任务同时字典表也可以用于优化 BI 查询的 JOIN 性能。 未来 当前我们已经支持多流同步物化视图同时社区全局字典功能也基本可用。但是目前的多流同步物化视图仍然存在较多限制例如不支持 JOIN不支持通用聚合函数等。未来我们希望新的 Stream MV 能够消除上述限制进一步满足更多的业务场景更进一步Stream MV 结合外表物化视图达到湖上实时增量物化视图成为更好的湖上建仓方案。 总结与展望 当前基于 StarRocks 的湖仓一体方案已经在微信的多个业务场景中上线使用包括视频号直播、微信键盘、微信读书和公众号等集群规模达到数百台机器数据接入量近千亿。 在收益方面我们以一个具体的业务来举例在直播业务场景中通过湖上建仓的方案改造使得数据开发同学需要运维的任务数减半同时存储成本降低 65% 以上离线任务产出时间缩短两小时。 未来我们希望不断探索和完善现有的湖仓一体架构最终能够达到理想中的湖仓一体 面向 SQL用户不再感知底层架构 接入/查询体验统一存储统一 秒级/分钟级延迟架构体验统一亚秒/分钟级分析统一 单个/百 QPS 体验统一 SQL 交互标准统一。 致谢感谢“腾讯大数据团队”提供稳定内部集群和各类技术支持帮助业务落地感谢 StarRocks 社区在功能开发问题定位解决上的诸多帮忙祝愿社区发展的越来越好 本文由 mdnice 多平台发布
