北京做网站商标的公司,个人做网站有什么条件,cloudflare wordpress,开封北京网站建设成都云览科技有限公司倾力打造了凤凰浏览器#xff0c;专注于为海外用户提供服务#xff0c;公司致力于构建一个全球性的数字内容连接入口#xff0c;为用户带来更为优质、高效、个性化的浏览体验。 作为数据驱动的高科技公司#xff0c;从数据中挖掘价值一直是公司核心任务… 成都云览科技有限公司倾力打造了凤凰浏览器专注于为海外用户提供服务公司致力于构建一个全球性的数字内容连接入口为用户带来更为优质、高效、个性化的浏览体验。 作为数据驱动的高科技公司从数据中挖掘价值一直是公司核心任务公司以前选用了众多组件来提升内部大数据分析效率如 Trino 作为即席查询的工具、用 ClickHouse 和 StarRocks 来加速报表业务查询但经过长期实践最终决定将所有内部数据分析平台统一至 StarRocks。 而且社区在 3.0.0 版本中发布了存算分离能力与公司内部大数据平台部门正在推动的降本增效理念非常契合部门也在第一时间测试验证确定评测各方面满足业务需求后已经开始逐步在线上业务中替换现有系统未来也会作为公司大数据平台部门统一数据架构的重点发展方向。 平台现状 作为公司内部大数据平台部门主要负责公司海量数据处理、数据质量保证及指标体系维护的工作服务公司四大业务场景用户画像、报表、实验系统以及业务服务。公司大数据平台经过上云及几次云平台迁移当前结合某云 EMR、对象存储建设存算分离的架构主要架构如下图所示 如图所示原始数据存储在 Kafka 中,通过 Flink 消费,写入到 OSS 中然后通过 Hive 和 Spark 进行数据进一步加工最后再将数据导入不同的 OLAP 组件中供业务查询。后期统一了计算引擎使用 Spark on K8s 的架构使用 Spark SQL 和自定义了 UDF/UDAF 对数据进行统一处理。 平台痛点 我们在发展过程中不断采用新技术来满足不同业务需求日积月累各种数据处理与分析组件越来越多面临着巨大的压力与挑战主要表现在以下几点 使用组件多维护成本高 公司的业务近几年飞速增长伴随着业务扩张带来了数据量指数式增长。我们的分析平台规模也相应增长使用的规模变大平台维护成本也成倍增长。例如仅 OLAP 我们就使用了 Trino、ClickHouse、StarRocks。其中Trino 给业务同学提供即席查询用途ClickHouse 负责应用与用户洞察、实验系统和报表StarRocks 对接业务报表。维护成本高体现在 学习成本高不同的系统实现不同语法兼容性不同对开发人员提出了很高要求。 定位问题复杂三种组件对应三套监控系统定位排查问题需要查看不同的监控系统搜索各自的日志排查链路很长。 链路冗长数据时效性难以保证 数据由客户端上报通过统一的转发服务进入到不同的 Kafka 实例中再经由 Flink 消费sink 到数仓的 ODS 层最后通过 tez 和 Spark SQL 对数据进行处理构建数仓分层。而这其中 ODS 层的数据统一处理整体时间就需要3小时左右偶尔中间任务数据产出有误需重跑整条链路数据延时会被进一步拉长。 服务稳定性不足 当并发量大、大查询多时Trino 很容易出现内存溢出稳定性不足目前统计线上查询失败的情况约有10%左右由内存溢出导致。ClickHouse 则无法处理高并发场景很容易因 cpu 打满导致服务重启。 StarRocks 存算分离调研 StarRocks 社区在 3.0.0 版本推出了存算分离版本与我们内部追求降本增效的目标不谋而合我们也第一时间进行了调研测评。 在调研时我们特别关注这几个方面: 查询效率相比存算一体用户不能感觉到较为明显的查询变慢 显著的成本降低这也是我们尝试存算分离新架构的初衷 能够无缝替换我们正在使用的各个组件为未来统一分析打好基础 运维简单减轻开发运维同学的日常工作复杂度 最后是需要社区比较活跃问题能得到及时的处理 以下是我们针对各个维度的一些调研结果。 性能对比 我们针对单表和多表 Join 两种真实线上场景进行了具体测试采用两个相同规模的集群对同一数据量的表进行相同的查询多次查询取平均值的方式进行对比。ClickHouse 集群规模单节点 96C * 384G , StarRocks 集群 6 * 16C * 64G。单表查询的数据量大小为 200G数据行数为1.3亿行对表进行 count 计数查询。Join 查询为表进行自 Join然后进行 count 计数查询。 StarRocks VS ClickHouse 测试表明在 ClickHouse 最拿手的单表查询场景中 StarRocks 存算分离性能可以保持一致在多表 Join 场景中StarRocks 能快3倍左右。 存储成本 在对比了性能后我们对比了存算一体和存算分离的成本情况。在存算一体中数据量 1T 的表通过 export 到 OSS再通过 Broker Load 到存算分离集群中由标准磁盘存储转换为对象存储后期还可以在对象存储内将数据进行冷热归档进一步节省成本。从云服务文档中了解到标准磁盘存储 1T 存储一天7 某 云 法 兰 克 福 区 磁 盘 计 费 转 为 对 象 存 储 存 储 一 天 (某云法兰克福 OSS 计费)存储费用降为原来的1/15。成本的详细计算可以看后文。 易用性 我们了解到 StarRocks 也推出了 Operator 支持 K8s 集群部署。利用 K8s 本身的容灾恢复机制以及强大的 StarRocks Operator 显著降低了集群部署运维复杂性。另外StarRocks 还提供了较为丰富的监控和诊断工具便于我们在第一时间观察系统运行情况。 StarRocks 存算分离实践 查询优化 物化视图 在一些实时查询的场景我们发现通过物化视图进行预聚合的方式能达到查询事半功倍的效果。例如我们的实时分析场景通过 Flink 直接将明细数据写入到 StarRocks最初直接对原始明细数据复杂查询耗时约30秒左右后来看社区力推物化视图我们也为该表创建异步物化视图对明细数据进行预聚合结果显示查询延迟降低为3秒左右带来了10倍性能提升。 物化视图的场景我们刚刚体验就取得了比较惊艳的效果未来我们将在更多场景中推广该能力进一步提升业务同学体验。 数据分桶 在初见 StarRocks 存算分离时我们简单认为数据存储在对象存储中建表时我们没有关注分桶数设置分桶数设置过多结果在使用时发现随着系统 Tablet 数量越来越多发现 FE 的内存被打满。后来在社区同学帮助下定位发现是由于 Tablet 过多导致 FE 节点一直在 GC。最后通过增加 FE 内存再按数据量合理分配不同表的分桶数便彻底解决了该问题。 根据我们实际使用的经验来看一般为每个分桶差不多容纳 1 ~ 3G 数据容量比较合理过多的数据分桶会产生大量的小文件且降低了 I/O 效率而分桶数不足则可能会影响查询的并发效果。 聚合查询模型 最初公司大部分报表都是参照 Kylin 模型使用 Hive、Spark 将数据预聚合处理再将处理结果数据导入到 StarRocks 中进行查询依靠 StarRocks 强大的查询能力降低查询延迟。 这种方式虽然提升了查询速度但会导致数仓中结果表的数据量膨胀且部分报表增加维度后会存在数据兼容性问题。后来我们将部分预聚合查询转换为 StarRocks 的聚合模型通过测试和提前预聚合的查询效率几乎相同同时也解决了数据膨胀和历史数据兼容问题。 Cache 上面我们提到调研测评时我们也详细评估了存算分离与其他系统的性能对比上面的测试都是在开启 Local Disk Data Cache 情况下达到因此我们对于线上所有的表在创建时都开启了 Data Cache。 目前我们线上计算节点规模为6个每个计算节点配置了 2 块 200G 容量大小的 SSD最好不要用 HDD通过该配置我们基本上能将业务访问的热点数据都缓存在 Local Disk 上。同时我们观察到目前线上磁盘使用到达一定量时存储空间会自动下降经过与社区沟通发现这是内部触发了自动 LRU 缓存淘汰这一点极大缓解了我们空间焦虑。 降本 使用 StarRocks 存算分离替换现有架构后能在以下三个方面给成本带来较大的降低 将 OLAP 组件换成 StarRocks首先是通过聚合模型替代在数仓中的结果表预聚合不必对所有维度进行排列组合计算各个组合的结果数据。省去这一步骤后存储对比之前减少了20%左右。 通过使用 StarRocks 存算分离数据被存储在对象存储通过将存算一体集群中 5T 左右的数据导入到对象存储中一个月能节省 1000$ 左右未来随着数据量的不断增长成本降低会愈发明显。 使用 K8s 部署方便部署的同时也省去了一笔不菲的云平台服务费。 通过以上几点综合测算相比原来使用 Spark 离线计算出结果再将结果导入ClickHouse 的方式使用 StarRocks 存算分离我们将成本降低了 46%。 运维监控 StarRocks 的监控可以无缝对接 Prometheus 和 Grafana使用 StarRocks 存算分离版本后我们根据建议首先配置了较为完善的监控StarRocks 存算分离在存算一体基础上增加了不少对于系统 I/O 等指标通过这些监控我们可以直观查看当前的各种指标。 FE、BE相关监控 StarRocks I/O 相关监控 另外我们使用过程中比较关注查询性能问题而也出现过由于版本太多导致了查询时读取文件数较多的问题在社区提醒下可以利用 SQL 监控当前集群 Compaction 情况 有了这种监控我们也能看出当前是否出现 Compaction 慢等情况并考虑是否资源不足需要扩容。 另外从使用来看相比于存算一体存算分离版本有一个极大的简化就是无需关注多副本数据一致性存算分离数据位于 OSS 之上本地缓存单副本再也无需关注副本的数据均衡迁移、数据修复等问题这是一个不小的解放。 最后社区的各种文档也比较丰富尤其是存算分离最近给我们提供了最佳实践、各种运维指导、参数优化等文档作为 StarRocks 新用户我们也能根据这些文档快速上手取得最佳效果。当然随着使用的深入我们还希望能更深入地了解 StarRocks 内部实现原理希望社区能在这方面提供更多指导。 我们使用存算分离集群上线初期遇到了一些 bug 导致集群运行不稳定但是在社区帮助下我们快速定位并修复后现在集群已经稳定运行了3月有余。 数据迁移 由于目前社区尚未提供一键式迁移工具将数据从存算一体集群迁移至存算分离集群咨询过社区后我们决定采用 export 到对象储存再使用 Broker Load 到新集群的方式进行数据迁移。 另外在进行 Broker Load 时导入任务和线上查询任务会对磁盘的 I/O 资源产生争用这可能会导致 K8s 将 BE 节点驱逐进而导致短时间 StarRocks 查询变慢对此我们也建议降低 Broker Load 并发度同样通过分批导入的方式来减少 I/O 争抢。 通过 Export Broker Load 配合我们提到的优化手段目前我们已经将线上 80% 的业务数据迁移到存算分离集群中并做到用户在使用上体验感更佳。后续会继续将所有业务迁移至集群最终完成统一大业。 另外我们也从社区获知社区已经在推进一键式迁移工具的开发如果不着急的小伙伴可以等等这个我们后续也会尝试使用这种新方式来提升数据迁移效率另外我们也很期待社区能推出从更多数据源的迁移方式便于我们可以更快速地将数据架构统一至 StarRocks。 未来规划 短期目标|数据湖 StarRocks 缩短计算链路 数据入仓后ODS 层的统一处理需要2-3个小时这对数据及时产出有不小的影响且计算成本较高。通过对数据湖的调研我们计划将 ODS 层的处理提前到 Flink 当中省去这几个小时的计算时间和计算资源将 Flink 处理的数据直接落入数据湖中。利用 StarRocks 和数据湖的结合实现对数据的实时查询解决离线数仓中的数据不方便实时查询的问题。 长期规划|使用 StarRocks 构建数据湖仓一体新架构 在文章的开头我们也提过公司现在使用了三种 OLAP 组件服务不同场景每种组件都需要将 Spark 加工好的数据导入至对应系统运维复杂难以保证数据时效性同时数据的多方存储也进一步提升了成本。我们也一直在思考能否做到 Spark 不参与计算加工只用 StarRocks 搭建数仓呢经过我们调研推导发现还是有可能实现这一步的。 具体来说Flink 消费 Kafka 的数据后直接入湖Hudi、Iceberg 等接下来我们利用 StarRocks 作为计算引擎直接查询湖上数据利用强大的湖查询能力这块尚未深入测试看社区其他用户有不少 Good Case可以直接进行查询对于某些查询效率较低的查询我们直接为其构建物化视图。 我们之前的测试表明利用物化视图能带来 10 倍以上的加速效果。构建数仓的过程中涉及到简单的 ETL 也能够通过逻辑视图结合物化视图的方式来完成。通过这样一套 Lakehouse 新架构我们理想中能够达到以下几点目的 去掉当前多套 OLAP 服务只保留 StarRocks 作为计算引擎节约大量计算资源 数据无需多处存储降低数据延迟时效性。同时使用存算分离架构数据单一存储能节约大量存储成本尤其原来存算一体架构下数据依靠云盘多副本存储云盘价格过于昂贵 利用 StarRocks 存算分离带来的弹性和数据共享能力我们可以做到 1). 为不同的业务实现资源硬隔离 2). 业务峰谷期间可以轻松实现快速弹性业务高峰期快速扩容以应对突发流量业务低峰期可以快速缩容以削减成本 架构简化也减轻了运维复杂度使得我们有更多时间可以考虑提升业务增效来达到公司降本增效的目的。 而且通过调研学习发现众多业内技术领先企业和我们的想法不谋而合。 本文由 mdnice 多平台发布
