晚上正能量网站大全,西安给大学做网站公司,哪些行业做网站最重要,哪些公司做外贸网站好作者#xff1a;bilibili 大数据高级开发工程师 杨洋 B站大数据元仓是一款用来观测大数据引擎运行情况、推动大作业治理的系统诊断产品。经过调研和性能测试#xff0c;大数据元仓最终以 StarRocks 为技术底座#xff0c;从实际的应用效果来看#xff0c;大部分查询都能在几… 作者bilibili 大数据高级开发工程师 杨洋 B站大数据元仓是一款用来观测大数据引擎运行情况、推动大作业治理的系统诊断产品。经过调研和性能测试大数据元仓最终以 StarRocks 为技术底座从实际的应用效果来看大部分查询都能在几百毫秒内返回结果。 B站大数据元仓是一款用来观测大数据引擎运行情况、推动大作业治理的系统诊断产品。经过调研和性能测试大数据元仓最终以 StarRocks 为技术底座从实际的应用效果来看大部分查询都能在几百毫秒内返回结果。 随着B站业务的高速发展数据量已达到 EB 级为了适应数据服务需求B站大数据平台引入了 Presto、Spark、ClickHouse 等多种大数据引擎。 在大数据引擎运行过程中由于缺乏一些运行时的切面数据我们难以实时观测引擎的运行情况另外由于缺乏作业维度的统计信息我们也难以推动用户对大作业进行治理。为了满足这些需求B站构建了大数据元仓系统。 大数据元仓涉及的大数据组件包括 Yarn、Presto、Spark 等以 Presto 元仓为例系统主要从集群、队列、query 等三个维度进行分析。 其中集群维度可以细分为包括 CPU、内存、扫描数据量等在内的节点资源汇总信息和包括各种 query 状态统计的集群 query 汇总信息队列维度主要包括队列的资源、水位信息query 维度则是对集群 query 汇总信息的一个补充可以获取更详细的信息比如可以具体了解导致查询失败的异常情况。 技术选型 需求特点 目前我们的内部监控架构基于 Prometheus 搭建Prometheus 存储数据量有限通常仅为一两个月的数据不适合存储长时间的历史数据。此外Prometheus 是基于度量的系统更多地用于展示趋势性数据例如集群的 CPU 和内存情况等但对于像元仓这样需要下钻到具体明细数据的需求Prometheus 则难以满足。 基于以上问题我们打算设计一个新的架构来构建大数据元仓。我们的大数据元仓应该满足以下特点 实时观测能够实时观测到集群的指标数据并在多维分析场景中实现秒级或亚秒级的查询返回。 复杂逻辑计算支持复杂的逻辑计算不需要将数据落库后打成大宽表的形式。有较高的灵活性以便后期满足不同的需求并在现有逻辑的基础上进行处理和分析。 存储及回放能够存储半年甚至更久的数据并支持数据的回放。 数据湖 or 数仓 基于以上需求我们对当前比较热门的数据湖、数仓组件进行了调研。其中数据湖组件主要包括 Iceberg、Hudi 和 Delta Lake数仓组件则重点调研了 ClickHouse 和 StarRocks。 最终由于以下原因我们选择了数仓技术作为大数据元仓的技术底座 传统的数据湖技术在实时性方面普遍存在不足Hudi、Iceberg 虽然可以达到分钟级的实时性但要实现秒级的实时性可能仍然存在一些困难 数据湖的远程 I/O 成本可能会较高而数仓技术更多地采用本地 I/O可以更有效地减少远程 I/O 的开销。 在数仓技术中有一些成熟的加速手段例如通过物化视图和索引等方式来提高查询性能。相对于数据湖技术数仓技术在这方面更加成熟。 组件选型 在数据湖与数仓之间作出选择后关于采用 StarRocks 还是 ClickHouse我们从6个维度进行了比较。 标准 SQLStarRocks 支持标准 SQL并兼容 MySQL 协议这对于应用程序迁移来说是一个优点。而 ClickHouse 在标准 SQL 方面并不完全支持 性能StarRocks 的读写性能都较好而 ClickHouse 在单机性能方面可能更强大 StarRocks 可以很便利地通过多机多核的方式提高并发能力而 ClickHouse 的并发能力相对较弱默认的 QPS 大约为100 JOIN 能力StarRocks 的支持较好可以建立星型或者雪花模型应对维度数据的变更而 ClickHouse 的 JOIN 能力相对较弱通常需要将数据处理成宽表进行查询 运维StarRocks 不依赖第三方组件如果出现资源不足的情况可以很容易地对 FE 和 BE 进行横向扩展。而 ClickHouse 依赖于第三方组件如 Zookeeper 来构建集群运维成本更高 StarRocks 社区在国内活跃度相对较高在我们对 StarRocks 进行调研和测试时如果遇到问题社区往往能够快速给出建议和回复 根据以上分析我们更倾向于选择 StarRocks 作为大数据元仓技术的底座。 性能测试 为了进一步了解 StarRocks 在性能方面的表现我们对 StarRocks 内外表与内部 Presto 集群的性能进行了比较使用了 TPCH 数据集并随机选择了一些 SQL 进行性能测试。 图中橙色线表示 StarRocks 外表的查询灰色线表示 Presto 的查询。可以看出相对于 PrestoStarRocks 具有更强大的查询性能外表查询时间相缩短了大约70%至80%。如果采用内表查询查询时间则会进一步缩短。 除了查询性能我们还关注计算引擎的资源消耗因此还比较了 StarRocks 和 Presto 的查询资源消耗。 这里特别说明一下考虑到我们的元仓场景更倾向于使用内表进行查询因此采用内表进行了资源、内存和 CPU 方面的比较。总体而言相对于 PrestoStarRocks 的资源消耗更小。 架构方案 在元仓架构方面我们最终确定 StarRocks 作为元仓的技术底座提供存储和查询能力。此外还构建了一个采集模块主要功能是收集各个集群的指标并将其推送到 Kafka。为了实现这一功能我们在内部实现了一个代理agent该代理封装了从采集器collector将数据推送到 Kafka 的逻辑。 StarRocks 有两种方式从 Kafka 导入数据Routine Load 和 Flink。其中Routine Load 是 StarRocks 自带的一种导入作业方式可以消费 Kafka 数据并将其写入 StarRocks。 采用 Routine Load 方式比较简单用户只需要创建一个 Routine Load 作业并指定列和 Kafka 主题以及一些分区信息即可进行数据消费和写入 StarRocks。在线上环境中对于新业务来说Routine Load 是比较容易推广的因为我们可以与用户规范数据格式使其以规范的格式写入 Kafka。 对于存量数据用户可能已经在 Kafka 端采集了一些度量指标此时让用户按照之前定义的规范重新将数据写入 Kafka 可能并不合适。对于一些特殊的业务逻辑Routine Load 可能无法满足需求这时就需要用到 Flink 来处理。 相比 Routine LoadFlink 通过编码的方式更加灵活特别适用于处理复杂的多表关联查询。然而由于 Flink 即使是对于简单的表也需要进行编码这对于一些不常开发代码的用户来说可能会增加上手成本。因此在内部我们会将 Routine Load 与 Flink 结合使用。 应用效果 根据最终的应用情况StarRocks 整体的性能表现非常好在99分位延迟方面表现出色大部分查询都能在几百毫秒内返回结果。 从元仓的角度来看大数据元仓以 Presto 元仓为例带来的一个效果是对 CPU 使用情况的监控和分析。通过监控 Presto worker 的 CPU 指标如可用处理器数量和 CPU 负载等可以根据用户选择的时间范围如3000分钟和粒度分钟、小时或天对 CPU 使用情况进行分组和聚合以获取整体 CPU 使用情况的统计数据。这样可以帮助用户了解 CPU 的利用率情况。 上图展示了B站内部 Presto 集群作业的概况。有时用户会反馈 Presto 作业运行较慢或失败较多。在遇到这些问题时我们可以通过这张图进行量化分析以确定是否存在排队查询或失败等情况。 图中排队查询量、正在执行的作业成功量以及失败的作业数量等数据主要来源于 Presto Coordinator 的查询信息。通过这些信息我们可以更加清楚地了解 Presto 作业的排队情况、执行成功率以及失败数量以便更好地监控和管理 Presto 集群的性能和稳定性。 未来规划 目前我们已经在内部完成了 StarRocks 的初步落地将其应用于公司的元仓场景并构建了一个大数据元仓系统为用户提供实时的资源观测能力。此外还通过诊断系统推动用户治理异常作业。 未来会在如下一些方向开展工作 由于 StarRocks 在大数据元仓场景中表现非常出色我们希望将其接入更多的业务场景例如 BI 和 DQC 等。 解决权限、UDF 等问题比如接入 Hive UDF使 StarRocks 与其它引擎对齐。 目前的架构主要是以仓为中心未来我们计划将半年或者更长时间的数据回流到数据湖中从而实现湖仓一体化的架构。 开启 StarRocks 的一些加速功能例如物化视图索引以提升现有元仓查询的速度。 我们希望能够接入更多的组件例如将 HDFS、Kyuubi 的大数据元信息纳入元仓体系中。 诊断系统方面目前主要以 Spark 诊断为主。未来我们希望能够支持更多类型的作业诊断如 Presto 和 Flink 作业的智能诊断。此外我们还希望将诊断系统与公司内部其他平台打通为用户提供更专业的诊断建议。 本文由 mdnice 多平台发布
