湖南省住房建设厅网站,wordpress author 404,做一个同城便民信息网站怎么做,网站建设中销售人员会问客户的问题引言
大家好#xff0c;我叫张琦#xff0c;来自每日互动#xff0c;担任大数据平台架构师。今天我将分享我们团队在基于Apache DolphinScheduler实现ClickHouse零压入库过程中的实践经验。 这个实践项目涉及到两个关键组件#xff1a;Apache DolphinScheduler和ClickHous…引言
大家好我叫张琦来自每日互动担任大数据平台架构师。今天我将分享我们团队在基于Apache DolphinScheduler实现ClickHouse零压入库过程中的实践经验。 这个实践项目涉及到两个关键组件Apache DolphinScheduler和ClickHouse主要是我们在实际工作中遇到挑战后的解决方案。通过调研开源组件、验证官方建议和在线方法我们最终找到了一种较为理想的实现方式并将其落地。
分享内容概述
本次分享将主要分为以下三个部分
面临的技术挑战零压入库的实现方式生产应用效果及思考
整个分享的内容设计较为简洁我们会围绕实际遇到的问题和解决方案展开讨论并分享在开源和非开源技术中的探索和应用经验。
最后我们会讲述生产应用中的效果以便大家能够从中获得启发在未来的类似场景中取得更好的体验和成果。
什么是零压入库
首先我们先来解释一下“零压入库”的概念。可能很多人听过“零压大床房”这个词它指的是让人感受到舒缓、无压力的睡眠体验。
而在我们的技术场景中“零压入库” 指的是如何让 ClickHouse 在数据入库时不产生明显的系统压力从而保证服务的稳定性和高性能。
换句话说我们希望通过优化让 ClickHouse 在数据入库时能做到“无感知”地处理这些操作从而保证系统性能不受影响。这就是我们称之为“零压入库”的原因。
面临的挑战
ClickHouse的优势与劣势
在实现ClickHouse的零压入库实践中我们首先需要深入了解其优势和不足以便于在实际应用中扬长避短。
ClickHouse的优势和不足可以从以下几方面来分析
ClickHouse的优势 高性能的存储与查询 ClickHouse的列式存储结构让其在数据压缩和查询速度方面表现优异。支持多种数据压缩算法如LZ4和ZSTD用户可以根据服务器配置选择合适的压缩算法在磁盘空间与CPU消耗之间进行平衡。在测试中ClickHouse单机即可在毫秒级处理十亿级别的数据社区也在不断更新百亿级数据下性能表现出色。 灵活的SQL支持 ClickHouse兼容标准SQL支持复杂查询包括窗口函数、自定义函数等适用于大规模数据分析场景。其中对于bitmap的支持非常优秀。 此外ClickHouse还支持多源数据联合查询能够满足多源跨表分析的需求。 单机百亿级别性能 在64C CPU和256GB内存的配置下ClickHouse单机可以轻松处理百亿级别的数据实现高效查询和写入。
ClickHouse的劣势 硬件敏感性高 ClickHouse对硬件配置的要求较高尤其对磁盘的性能非常敏感。不同于对CPU和内存的相对宽容ClickHouse在机械硬盘和固态硬盘的使用体验上有显著差异这也直接影响了数据的写入性能。 写入并发受限 ClickHouse的高查询性能是以牺牲写入性能为代价的尤其在高并发写入场景中易出现瓶颈。其推荐单机QPS/TPS不超过20最好不超过100。高并发写入会加重IO负担直接影响查询和服务器性能。 内存消耗高 ClickHouse在写入数据和执行查询时都对内存有较大需求尤其是在执行关联查询时需要大量的内存空间来缓存和处理数据。对于内存配置不高的服务器写入和查询的内存需求可能会影响其他任务的正常执行。
合并性能低
ClickHouse的数据合并性能较差数据入库后可能需要花费数小时甚至更长时间进行文件合并。文件合并过程中会大量占用IO、CPU和内存资源影响整体性能。
海量数据入库的挑战
在海量数据入库过程中ClickHouse的弱点逐渐暴露尤其是在日入库量达到TB级别、数十TB级别甚至更高的情况下。
我们遇到的主要挑战包括
数据时效性受影响 在高并发写入的场景中服务器的负载快速上升写入和查询都会受到影响导致数据时效性下降。 业务查询的影响 在数据入库期间服务器水位高企业务查询的性能会受到较大影响甚至可能出现查询失败的情况。 集群资源有限 如何平衡业务查询和数据入库的资源分配是一个重要的课题特别是当集群资源紧张时往往难以保证两者的性能。 数据堆积和补数问题 在数据量大、数据入库性能受限的情况下数据堆积和补数难度增加。数据堆积可能导致集群性能下降而补数时大批量写入又容易引发性能瓶颈。 补数和依赖管理困难 在补数的过程中批量部署和上下游依赖的处理较为复杂入库、告警等功能目前多依赖人工维护缺乏自动化支持。
现有调度平台的局限性
之前我们主要采用的是Azakaban调度平台。它在早期大数据加工调度和日常数据运维中表现尚可但在面向现代化的DataOps或Data AI场景下表现出了一些不足。
例如对于需要快速迭代的数据研发场景Azakaban缺乏灵活性且在自动化告警和维护方面较为薄弱所以我们需重新选型一款调度产品来替代现有的技术栈。
总之我们在ClickHouse零压入库实践中必须解决ClickHouse的硬件敏感性、写入瓶颈和内存需求等方面的挑战同时探索新的调度平台和方法来提升整体的运行效率。
零压入库的实现
为什么选择 DolphinScheduler 选择 DolphinScheduler 作为调度引擎的主要原因包括以下几点
强大的调度能力
DolphinScheduler 已成为 Apache 顶级项目具备了稳定的调度能力支持复杂的任务流程管理社区活跃度高更新迅速。
这让我们能够高效实现各类复杂的数据调度需求同时支持多种作业流程管理需求。
可视化模板作业流
DolphinScheduler 的可视化模板大大简化了任务配置流程。数据开发人员可以通过模板快速创建作业流支持直接在可视化平台上完成配置。
这样核心开发人员只需设计模板其他用户即可复用大幅减少开发和配置时间。
丰富的重跑和补数机制
在 3.2.0 及后续版本中DolphinScheduler 支持依赖数据节点的补数机制即当上游节点出现异常时可以一键启动依赖链路中的所有节点自动补数。
此功能配合数据血缘图使用能有效降低数据维护难度使数据问题排查和修复更加迅速。
多环境支持
DolphinScheduler 支持开发、测试、生产环境的无缝切换允许用户在开发环境完成调试后将配置导入测试环境最终同步至生产环境极大地提升了数据上线效率。
环境配置的灵活管理使得多环境切换在保障数据安全的同时还能加速数据任务的上线流程。
零压入口平台架构
我们的数据零压入库平台架构分为几层 调度引擎与 BI 引擎DolphinScheduler 为调度底层引导 ClickHouse 和 Nebula 的 Worker 执行节点的操作提供调度稳定性保障。中心服务层中心服务集成了 DolphinScheduler 的调度和数据管理功能负责任务配置、日志管理以及一键补数等关键功能。数据质量模块基于 DolphinScheduler 的监控功能加入数据质量模块用于监控数据入库趋势、链路检查、大小与耗时分析等。告警模块提供多种告警方式包括 HTTP、邮件、企业微信和钉钉等。业务使用层通过模板化开发将 ClickHouse 和 Nebula 的入库任务标准化提升数据处理流程的易用性。公共工具如表合并工具、入库检查工具等进一步增强平台的灵活性和实用性。
流程设计
零压入库的核心技术原则为“算力转移”即将 ClickHouse 入库时的 CPU、内存和磁盘资源消耗尽可能转移至大数据平台 Yarn 中从而减少对 ClickHouse 资源的占用。
流程设计如下 技术参考 https://www.bilibili.com/read/cv16473965/ https://www.slidestalk.com/DolphinScheduler/SeaTunnelwithDolphinScheduler43829?embed https://www.slidestalk.com/SeaTunnel/23020 https://seatunnel.incubator.apache.org/zh-CN/docs/2.3.3/connector-v2/sink/ClickhouseFile https://clickhouse.com/docs/en/sql-reference/statements/attach https://juejin.cn/post/7162441097514319909 https://clickhouse.com/docs/zh/operations/utilities/clickhouse-local 核心算子的执行流程
在 Spark 中执行 ClickHouse 本地生成工具 ClickHouse Local以预先生成符合 ClickHouse 分区要求的文件。 执行步骤如下
待入库数据不需要排序 Spark在Driver中连接ClickHouse获取到表结构按照表分区规则进行Spark sql重分区计算 Executor中
下载ClickHouse-local程序读取HDFS上重分区后的数据加载用户自定义函数动态生成执行语句。执行命令生成表分区包含索引、数据文件等完整的分区目录结构基于配置化的参数可以自行调整大小这两个参数可以调整sql语句插入ck表时insert ck表时 单个最小切分分区目录大小的参数 min_insert_block_size_rows10000000,min_insert_block_size_bytes1073741824
压缩分区数据上传到HDFS
通过设计 Spark Executor 进行分区内数据处理减少 ClickHouse 资源的消耗并实现零压入库。与传统 Insert Into 方法相比这种方式降低了 ClickHouse 资源的占用同时提升了数据合并的效率。
总结来看通过零压入库方案我们实现了 ClickHouse 数据导入的高效、低压并且大大减少了内存和 CPU 的消耗确保数据入库稳定高效极大提升了 ClickHouse 在大数据场景下的数据处理性能。
生产应用效果
在我们的生产应用中基于海豚的技术方案取得了一些显著效果具体包括以下几个方面 可视化任务管理
开发人员可以创建任务模板并将这些模板开放给其他数据研发人员使用。目前主要通过复制或点击引用的方式进行使用。
支持重跑和失败重跑
实现了任务的重跑和失败重跑功能利用社区现有的功能来降低人力和成本提高数据研发效率。
监控告警
完善了监控告警机制利用组件的丰富性建立了有效的告警机制。
数据质量检查
入驻库的数据质量检查通过提供数据质量相关的算子若不够用用户仍可自定义编写Spark或SQL任务进行检查。
内存监控与管理
Worker监控机器服务器资源支持脚本监控整个CK服务器资源。提供多环境支持及导入导出的发布功能。
方案特点 我们的方案特点是“削峰不填谷”通过提前完成CK文件计算仅在入库时进行短时磁盘写入降低了CPU的负担。
我们目前验证的一些效果显示整体提升的效果基本上都在一倍或者一倍以上。具体而言8小时的合并时间可以缩短至4小时4小时缩短至2小时2小时再缩短至1小时。
这些改进还可以根据不同用户自行设定参数系统提供了项目参数功能可以直接引用全局参数来使用从而减少内存占用并降低CPU使用率。
入库过程优化
在入库过程中系统只需将数据从一个目录搬到另一个目录就可以完成数据的入库。得益于数据分块更大下载和解压过程的CPU占用率得以降低。 以下是优化的几个关键点
内存清理内存的清理效果超出了我们的预期。在完成入库时系统会瞬时清理无效的缓存和过期的内存标记文件整理内存降低水位为后续的查询提供更多的内存空间。在生产环境中这一内存清理操作经过多次验证对业务查询没有影响。 数据强一致性检查在使用 INSERT INTO 方式进行入库时如果数据在Spark或Flink任务中重复而检查机制不到位则可能会造成数据问题。在我们的方案中通过统计HDFS上的单个分区与生成的CK表的条数一旦发现重复系统会在合并时自动剔除重复数据从而确保入库数据的准确性。 数据时效提升对入库的数据进行统计检查发现重复数据问题有助于及时解决业务和数据上的bug计算、入库、合并三个阶段的耗时均有所下降在数据入库过程中资源使用更高效减少了CPU和内存的占用。
我们的生产效果验证了CK表的压缩算法及分区预生成的优化策略实现了资源的高效利用和性能的显著提升。这种方法不仅提升了入库效率还确保了数据质量与一致性是我们未来应用的一个重要方向。
性能对比分析
常规方式 vs CK File 方式
以下是生产上使用单节点900GB大小数据的性能对比分析 内存使用情况使用 INSERT INTO 方式时内存使用提升至80%约200-220GB可用资源但随即出现内存回落现象。而使用CK File方式时内存基本没有上升并且会释放部分内存最终稳定在50GB左右。 CPU占用在使用之前的JDBC方式时CPU使用率明显上升而CK File方式的CPU上升幅度较小整体减少了资源占用。 IO性能在JDBC与CK File的对比中尽管峰值没有太大差距因磁盘使用率较高但CK File的写入速度更快显著减少了入库所需时间。
存储与压缩算法
整体性能提升还依赖于文件大小的减少采用CK表的压缩算法默认LZ4。我们建议设定为ZSTD以提高压缩率从而降低存储压力。不过ZSTD对CPU的要求相对较高。
合并速度优化
通过控制预分区和生成的表分区块大小目前设置为每个分区1,000万个数据显著减少了分区块的数量从而加快了合并速度不消耗内存。
资源管理与扩展
在CK中单个节点的资源是固定的例如64核、256GB内存。若需扩容只能进行横向扩展。然而将部分机器资源转移至Yarn后Yarn可以复用这些资源使得CK的计算在Yarn上进行从而有效提升计算效率。在理想情况下可能将CK输入库的数据处理时间缩短至两个小时。
数据处理收益分析
在资源管理方面尽管我们在计算能力上有所提升但实际使用的资源上升时间反而减少。这是因为机器的计算能力能够更有效地均摊和利用为其他业务线提供服务。 经过一段时间的验证我们的数据处理效果显著提升基本上都在一倍以上。
例如原始文件大小为 910 GB 的数据处理后仅减少至 160 GB实现了 82% 的压缩。数据传输时间从 35 小时降至 1.5 小时效率提升了 95%。
在入库环节耗时从 50 分钟降至 20 分钟并且这一过程几乎不消耗内存。合并时间更是从 6 小时缩短至 2 小时极大地提升了数据处理的时效性。
Spark资源管理
通过优化资源配置我们在 Spark 的资源使用上有所提升虽然单个执行器的资源需求增大但整体处理时长却下降了近一半。
此外在过去的一段时间里我们遇到了内存使用不均和入库失败的问题但自从系统上线以来这些问题得到了有效解决数据处理过程也变得更加平稳。
资源要求由于调大了1,000万和1GB的资源要求单个Executor的资源需求有所上升。整体时长处理时长下降接近一半。
内存管理与性能
内存的使用情况表现为时高时低这主要是由于每次数据入库后系统会进行内存清理有效降低内存水位确保机器处于良好的状态。
这种管理策略提高了系统的容错性。在执行大型查询任务时我们能够提前释放内存以满足高内存需求的任务从而为业务场景提供更多的应用可能。 在上线前内存水位和OOM产生问题较为明显特别是在7月底的某个时间段内常出现OOM入库失败和数据条数不一致的问题。自7月24日至25号大规模投产后数据和机器的压力显著下降运行状态趋于平稳。
这一功能确保了后续查询能够获得更多的内存资源进而提升了查询效率。同时我们的内存清理策略并没有对业务查询造成影响这一策略的成功实施为后续的业务需求提供了强有力的支持。
以上是我们在数据处理中的一些收益和经验分享希望对你有帮助和启发欢迎大家提出疑问或进行交流与研究。 本文由 白鲸开源科技 提供发布支持
