
ClickHouse v23.3.6.7-lts 更新解析LDAP 缓存哈希修正、进度条优化与 Docker 镜像构建改进【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse本篇以 v23.3.6.7-lts 变更记录 为核心逐条解析该 LTS 版本相对 v23.3.5.9-lts 引入的三项改动file/s3/hdfs/url表函数进度条的增量统计优化、官方 Docker 镜像RUN指令的拆分与瘦身、以及 LDAP 外部认证缓存条目的参数哈希类型修正。读完本篇你可以理解这三项改动各自的实现位置、影响范围以及如何在当前仓库源码中定位到对应实现进行核对。版本定位与适用范围该变更记录的标题明确了版本关系ClickHouse release v23.3.6.7-lts (7e3f0a271b7) as compared to v23.3.5.9-lts (f5fbc2fd2b3)即这是一个LTS长期支持分支上的点版本升级采用“相比上一版本逐条列出差异”的回溯式backport记录方式。需要注意的适用前提本变更记录属于 2023 年归档文档面向的是 23.3 LTS 分支的历史版本而非仓库当前主开发版本。当前仓库主版本可通过 cmake/autogenerated_versions.txt 查看该文件由 CI 自动维护记录VERSION_MAJOR/VERSION_MINOR/VERSION_PATCH等字段。变更记录中每条均标注 “Backported in #issue”表示这些改动最初提交到主干、再回溯合入 LTS 分支因此阅读时应把条目理解为“主干特性在 LTS 上的同步”而非 LTS 首发特性。该条目按类别分为Improvement改进、Build/Testing/Packaging Improvement构建/测试/打包改进、Bug Fix用户可见的官方稳定版缺陷修复三档下文按此结构展开。改进一file/s3/hdfs/url表函数进度条优化改动内容继承自原文档变更记录Improvement一节原文Backported in #51240: Improve the progress bar for file/s3/hdfs/url table functions by using chunk size from source data and using incremental total size counting in each thread. Fix the progress bar for *Cluster functions. This closes #47250. #51088 (Kruglov Pavel)。即改进file、s3、hdfs、url等“从外部数据源读取”的表函数的进度条核心手段有两点使用源数据的 chunk size按分块粒度推进而不是逐行/逐字节累加在每个读取线程内做增量式总大小统计incremental total size counting避免全局锁竞争与重复计数。同时修复了*Cluster例如s3Cluster、urlCluster等集群版表函数的进度条问题并关闭了 #47250 这一长期反馈。源码佐证总字节数如何被统计在当前仓库的表函数实现中可以定位到“总待读取字节数”这一核心状态。TableFunctionFile.cpp 中对source.total_bytes_to_read的累加逻辑正是进度条“总量分母”的来源result.total_bytes_to_read source.total_bytes_to_read;从源码结构看total_bytes_to_read由各个数据源source分别计算后再汇总这与改动描述中“在每个线程内做增量统计、再聚合”的思路一致——每个读取线程维护自身增量最后归并到查询级的进度反馈中。S3/HDFS 等对象存储与远端表函数的实现见 TableFunctionObjectStorage.cpp同样依赖这类按源统计的总量字段因此进度条改进是跨file/s3/hdfs/url共用的机制。对使用者的实际意义当使用SELECT * FROM file(big.parquet)或url(https://...)读取大对象时客户端进度条能够基于真实的分块读取进度平滑推进而不是长时间停留在 0% 或跳变尤其在大文件、多分片场景下体验更稳定。改进二官方 Docker 镜像构建改进改动内容继承自原文档变更记录Build/Testing/Packaging Improvement一节原文Backported in #51529: Split hugeRUNin Dockerfile into smaller conditional. Install the necessary tools on demand in the sameRUNlayer, and remove them after that. Upgrade the OS only once at the beginning. Use a modern way to check the signed repository. Downgrade the base repo to ubuntu:20.04 to address the issues on older docker versions. Upgrade golang version to address golang vulnerabilities. #51504 (Mikhail f. Shiryaev)。拆解为若干可执行原则拆分巨型RUN把原本一条超大RUN拆成更小的、带条件判断的指令提升可读性与分层缓存命中率按需安装、装后清理在同一个RUN层内安装必要的构建工具用完即删避免工具残留膨胀镜像OS 升级只发生在开头一次避免重复apt upgrade用现代方式校验签名仓库signed repository基础镜像回退到ubuntu:20.04以兼容旧版本 Docker升级 golang 版本修复 golang 相关安全漏洞。源码佐证当前 Dockerfile 的分层策略当前仓库的官方镜像构建文件 docker/server/Dockerfile 体现了“按职责拆分RUN层 层内清理”的风格例如在基础层内安装必要包后立即清理 apt 缓存RUN sed -i -e s|http://archive.ubuntu.com|${apt_archive}|g \ -e s|http://ports.ubuntu.com|${apt_ports_archive}|g /etc/apt/sources.list \ groupadd -r clickhouse --gid101 \ useradd -r -g clickhouse --uid101 --home-dir/var/lib/clickhouse --shell/bin/bash clickhouse \ apt-get update --error-onany \ apt-get install --yes --no-install-recommends \ busybox ca-certificates locales tzdata wget \ busybox --install -s \ rm -rf /var/lib/apt/lists/* /var/cache/debconf /tmp/*可以看到几个与改动原则吻合的设计预创建固定 uid/gid 的clickhouse用户101并注释说明这是为 rootless 容器与挂载卷权限准备的使用apt-get update --error-onany严格校验仓库索引拉取对应“用现代方式校验签名仓库”的意图方向每层安装后立即rm -rf /var/lib/apt/lists/* /var/cache/debconf /tmp/*清理安装 ClickHouse 包的层见 docker/server/Dockerfile在末尾执行apt-get autoremove --purge -yq dirmngr gnupg2移除临时依赖正是“装后清理、减小镜像体积”的典型做法。说明ubuntu:20.04基础镜像与 golang 升级属于该 v23.3.6.7-lts 时点的构建决策当前仓库 HEAD 的 Dockerfile 已演进到更新的基座与下载/签名流程。因此本节以“该版本当时引入的构建原则”解读具体基座版本请以目标发行版的 Dockerfile 为准不应把当前 HEAD 的ubuntu:22.04当作 v23.3 的构建事实。缺陷修复LDAP 服务器参数哈希类型修正改动内容继承自原文档变更记录Bug Fix (user-visible misbehavior in an official stable release)一节原文Fix type of LDAP server params hash in cache entry #50865 (Julian Maicher)。一句话概括修正 LDAP 服务器参数哈希在缓存条目中的存储类型。这是一处“用户可见的官方稳定版误行为”修复影响使用 LDAP 外部认证、且开启了验证缓存冷却verification_cooldown的场景。源码佐证哈希类型为何重要LDAP 缓存条目的结构定义在 ExternalAuthenticators.hstruct LDAPCacheEntry { UInt128 last_successful_params_hash 0; std::chrono::steady_clock::time_point last_successful_authentication_timestamp; LDAPClient::SearchResultsList last_successful_role_search_results; };其中last_successful_params_hash的当前类型为UInt128。这条修复的核心就在于把该哈希的存储/计算类型对齐到 128 位。相关计算逻辑在 ExternalAuthenticators.cpp 的computeParamsHashstatic UInt128 computeParamsHash(const LDAPClient::Params params, const LDAPClient::RoleSearchParamsList * role_search_params) { SipHash hash; params.updateHash(hash); if (role_search_params) { for (const auto params_instance : *role_search_params) params_instance.updateHash(hash); } return hash.get128(); }从源码结构看缓存命中判定ExternalAuthenticators.cpp会比较entry.last_successful_params_hash params_hash以决定能否安全复用上一次成功的认证结果、跳过对 LDAP 服务器的实际访问。如果哈希位宽不一致例如计算侧产出 128 位、存储侧只保留低位/高位就可能出现误命中不同参数组合被判定为相同缓存被错误复用误失效相同参数被判定为不同缓存频繁失效导致每次都要真正回源认证增加 LDAP 服务器负载与延迟。因此该修正保证了“参数哈希 → 缓存复用”这条路径的类型一致性与正确性。相关的缓存条目与参数蓝图blueprint整体由ldap_client_params_blueprint与ldap_caches两张表维护见 ExternalAuthenticators.h并受同一把mutex保护保证了多线程下的访问安全。对使用者的意义在配置了ldap_servers且设置了verification_cooldown的部署里该修复使“冷却期内复用成功认证”这一优化能稳定生效既减少了对外部 LDAP 目录的重复请求也避免了因哈希类型不匹配带来的认证判定异常。小结v23.3.6.7-lts 相对 v23.3.5.9-lts 的三项改动虽体量不大但各有明确的工程落点进度条改进#51240 / #51088让file/s3/hdfs/url及*Cluster表函数基于源数据分块与线程内增量统计给出平滑进度对应源码中按源累加的total_bytes_to_readTableFunctionFile.cpp。Docker 构建改进#51529 / #51504拆分RUN、按需装后清理、OS 只升级一次、现代签名校验、基座回退与 golang 升级当前 docker/server/Dockerfile 的分层与清理策略正是这一原则的延续。LDAP 参数哈希类型修正#50865把缓存条目中的参数哈希统一为UInt128确保verification_cooldown冷却期内的认证结果复用正确可靠见 ExternalAuthenticators.h 与 ExternalAuthenticators.cpp。以上条目均以变更记录 v23.3.6.7-lts 为事实来源并结合当前仓库源码定位了各自的实现位置与影响路径便于在对应版本升级或安全审查时逐条核对。【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考