一天有一个pengpeng-优快云博客

原创数据管理平台（DMP）工程实践（二）：数据接入模块

数据仓库里的离线表（MaxCompute、Hive 等）对象存储上的文件（OSS、S3）客户上传的 CSV / Excel第三方供应商推送的数据包这些数据格式不同、存储位置不同、更新频率不同、质量参差不齐。每个下游都要处理数据源差异，重复造轮子数据口径不一致，同一个用户在不同模块看到不同结果上游数据变更时，下游无法及时感知数据接入模块的价值就是在异构数据源和下游消费之间建立一层标准化抽象，让下游只需要关心"数据集"和"样本"这些业务概念，而不需要知道数据到底存在哪里、是什么格式。

2026-10-23 17:09:23 173

原创数据管理平台（DMP）工程实践（一）：DMP 是什么，为什么需要它

DMP 是数据管理平台，核心功能是整合多方数据、构建标签体系、支持人群圈选和洞察分析。数据接入：对接内部数据（行为日志、交易数据）和外部数据（第三方标签、媒体数据）标签管理：定义、计算、存储用户标签（如"高价值用户"、“母婴人群”、“近期活跃”）人群圈选：基于标签组合、行为规则、模型预测等方式圈定目标人群画像洞察：分析人群的特征分布、偏好倾向、与其他人群的差异数据输出：把圈定的人群或标签结果输出到下游系统使用DMP 是一类在广告、营销、用户运营领域非常常见的系统。它的核心价值是。

2026-09-17 15:58:10 56

原创私有化部署实践（二）：数据流转方案

Python + 数据库驱动：灵活，适合小数据量或特殊格式。Flink CDC / Debezium：适合实时捕获数据库变更并同步。云厂商 DMS / DTS：如果客户已经在使用某云厂商，可以直接用其托管迁移服务。数据流转是私部署的"血管系统"。血管不通，再强的业务能力也送不到客户侧。数据的所有权和边界在哪里？客户能接受什么样的网络方案？数据量有多大、更新频率有多高？失败时谁来排查、谁来恢复？把这些想清楚了，工具选型、增量策略、幂等设计都会水到渠成。

2026-09-11 17:50:08 76

原创私有化部署实践（一）：当客户的一方数据不能出域时

一方数据（First-Party Data）指的是企业自己采集、自己拥有、自己管理的数据。用户在 App 或小程序里的行为日志注册用户的基本信息和交易记录企业内部的设备 ID、会员 ID通过自有渠道积累的标签和画像高价值和高敏感度。高价值是因为它们直接反映企业的核心用户资产；高敏感度是因为一旦泄露或被滥用，可能带来合规风险、商业损失甚至法律责任。私有化部署很麻烦。它意味着平台要放弃一部分控制权，意味着交付周期变长，意味着每个客户的环境都可能不一样。

2026-09-11 17:46:53 173

原创 DataX 深入理解：异构数据源之间的离线同步实践

DataX 是连接异构数据源的离线数据搬运工。它不解决实时同步问题，也不替代数据库，但在"把业务库数据搬到数仓"、“把数仓结果搬到查询引擎”、"把平台数据交付到客户私域"这几条链路上，几乎是国内大数据工程里的标配工具。用插件化 Reader/Writer 屏蔽异构差异，用 Framework 提供工程化能力。掌握它的并发模型、切分策略、限速机制和脏数据处理，再结合 OSS 内网传输、PostgreSQL AB 表切换这些周边设计，就能应付大多数离线数据同步需求。这个数据库系列到这里就告一段落了。

2026-09-10 15:31:32 351

原创 MaxCompute（ODPS）深入理解：从存算分离到大规模计算，一文掌握 ODPS 的核心设计与实战

前面讲过的 MySQL、MongoDB、ClickHouse，都是存算一体的架构——数据存储和计算发生在同一台机器上。ClickHouse 查询时直接读本地磁盘，所以快；但扩容时需要同时扩磁盘和 CPU，数据也需要重新迁移。存算分离。数据存在分布式文件系统上（一组独立的存储节点），计算由独立的计算节点执行。两者可以独立扩缩容。fill:#333;important;important;fill:none;color:#333;color:#333;important;fill:none;

2026-09-10 14:40:31 238

原创 ClickHouse 深入理解：从列式存储到向量化执行，一文掌握 OLAP 引擎的核心设计与实战

前面六篇文章覆盖了 MySQL、PostgreSQL、Redis、MongoDB 和 HBase/Lindorm。它们各有所长，但都有一个共同的短板：不擅长分析型查询。什么是分析型查询？典型场景是"统计最近 30 天每个城市的日活用户数，按日期排序"——这类查询需要扫描海量数据、做聚合计算（SUM、COUNT、AVG），但只返回少量结果。MySQL 处理这种查询时，即使加了索引，也需要扫描大量无关数据，因为它是按行存储的——即使你只需要和两列，MySQL 也会把整行（包括、、等几十个字段）全部读

2026-08-24 16:34:26 199

原创 HBase & Lindorm 深入理解：从 LSM-Tree 到多模超融合，一文掌握列式数据库的核心设计与实战

用顺序写换随机写，在海量数据下保持高吞吐。LSM-Tree 把写入全部变成顺序追加，列族存储让稀疏数据不浪费空间，Region 分片让数据可以无限水平扩展。代价是查询能力受限、运维复杂度上升。Lindorm 在 HBase 的基础上解决了这些痛点——全局二级索引弥补了查询能力的不足，多模引擎覆盖了时序、搜索、向量等多种场景，存算分离和冷热分层大幅降低了成本，SQL 接口降低了使用门槛。从 HBase 到 Lindorm，本质上是从"一个高性能的 KV 存储"进化为"一个面向海量数据的多模数据库平台"。

2026-08-24 11:36:25 398

原创 MongoDB 深入理解：从文档模型到分片集群，一文掌握 MongoDB 的核心设计与实战

让存储适应业务，而不是让业务适应存储。文档模型消除了 Schema 变更的成本，水平分片消除了容量上限的焦虑，丰富的索引和聚合能力覆盖了大部分查询需求。但"灵活"不等于"随意"。不理解文档建模的原则，就可能嵌套过深导致更新性能崩溃；不理解 WiredTiger 的内存管理，就可能因为缓存配置不当导致频繁磁盘 IO；不理解片键的设计原则，就可能在分片集群上遇到严重的数据倾斜。MongoDB 的真正功力，不在于会不会，而在于能不能根据业务特点选择合适的文档结构、索引策略和部署架构。

2026-08-23 00:13:55 195

原创 Redis 深入理解：从数据结构到缓存架构，一文打通 Redis 的核心设计与实战

Redis 支持执行 Lua 脚本，整个脚本作为一个原子操作执行——执行期间不会被其他命令插入。这是实现复杂原子逻辑的关键手段。-- 原子扣减库存（库存不足返回 -1）return -1 -- key 不存在endelsereturn -1 -- 库存不足end在 Java 中通过EVAL命令调用，或者把脚本内容缓存起来用EVALSHA执行（避免每次传输完整脚本）。Lua 脚本执行期间会阻塞其他命令，所以脚本要尽量短小——避免大循环和大量数据操作。

2026-08-19 11:20:16 221

原创 PostgreSQL 深入理解：从架构到 MVCC，一文掌握 PG 的核心设计

从进程模型到堆表存储，从元组版本标记到 VACUUM 清理，从六种索引到 SSI 串行化——PG 的每一个设计选择和 MySQL 都不一样，但都自洽且有道理。PG 的 MVCC 不需要 undo log，但需要 VACUUM；PG 的堆表没有聚簇索引的优势，但给了索引设计更大的灵活性；PG 的进程模型连接开销大，但隔离性更强。每个数据库都是一套 trade-off 的集合。理解 trade-off，才能在工程中做出正确的选择。后续会持续输出数据库相关的技术内容。

2026-08-18 16:53:17 205

原创 MySQL 深入理解：从一条 SELECT 看 InnoDB 的完整执行链路

MySQL InnoDB 的索引结构是 B+ Tree。理解 B+ Tree 的设计，需要回到磁盘 I/O 这个根本约束。磁盘读写的最小单位是页（4KB 或 8KB），一次 I/O 操作读取一个页。用最少的 I/O 次数找到目标数据。非叶子节点只存 key，不存数据：这意味着一个页能容纳更多的 key，树更矮。一棵 3 层的 B+ Tree 可以索引上千万行数据——只需要 3 次磁盘 I/O。叶子节点通过双向链表连接：范围查询（）只需要找到起点，然后沿着链表顺序扫描，不需要回溯到父节点。

2026-08-14 10:46:29 220

原创后端工程师的数据库选型全景指南：从关系型到向量数据库，一文建立全局认知

回到开头的三个问题：数据模型、数据量级、读写特征。把这三个问题想清楚，数据库选型的答案自然就出来了。不要陷入"哪个数据库更好"的争论——每个数据库都是为特定场景而生的，合适的才是最好的。作为后端工程师，建立全局认知比精通某一个产品更重要。后续文章会逐类深入，结合真实业务场景和量化数据，把每一类数据库的设计细节讲透。这是「数据库选型」系列的第一篇。后续会逐类深入，结合真实业务场景和量化数据，把每一类数据库的设计细节讲透。

2026-08-10 17:16:24 266

原创高并发系统的数据编码设计：字典编码与增量编码

宽表里一行 2000 个字段，字段名平均 15 字节，值是 8 字节的浮点数——光字段名就占了一半以上。几亿行数据下，超过一半的存储和 IO 花在了重复的字段名上。收益换算关系存储成本压缩率直接乘上行数与副本数。3 倍压缩率就是存储账单打到三分之一磁盘 IO 带宽双向受益：离线导入的写入量变小，导入窗口缩短；在线查询每次读取的字节数变少，同样的 IO 带宽能支撑更高的 QPS反序列化 CPU少构造几千个对象，GC 压力和响应时间一起降第二条往往被低估。

2026-08-04 15:29:53 168

原创高并发计量计费引擎：10 万 QPS 实时去重、无锁扣减与离线审计闭环

10 万 QPS 的流量下，每个请求要在毫秒内判断"这条数据历史上向这个客户交付过没有"——历史交付集合有数亿个 ID，判断结果直接决定这一笔收不收钱。精确集合存不下，离线计算追不上，错一个方向就是资损或客诉。这是本篇两大主题之一：去重计费。几十台机器同时扣减同一个客户的配额，怎么保证不超卖、不少扣？一个客户有多个订单（先买 100 万次、又续 500 万次），扣完一个怎么无缝切到下一个？一次请求要扣 5 次费，但余额只剩 3 次了，是全拒绝还是给一部分？

2026-07-31 17:40:06 281

原创高并发系统的动态限流设计：三级令牌桶与增量热更新

限流是每个在线系统的"保险丝"。用什么算法？令牌桶、漏桶、滑动窗口还是简单计数？限流粒度怎么划分？全局一刀切，还是按 API、按客户精细控制？限流器放在请求链路的哪个位置？网关层还是应用层？鉴权前还是鉴权后？限流阈值怎么调整？改配置重启，还是运行时热更新？热更新时已积累的令牌怎么办？多台机器部署时，单机限流够不够？什么时候必须上分布式限流？本篇基于我负责的一个 10 万 QPS 数据交付系统的实践，把这些问题的答案抽象为可迁移的设计模式。

2026-07-31 10:39:10 202

原创 10 万 QPS 下的请求上下文：一个 ThreadLocal 串起全链路

创建与清理同源——同一个拦截器的 preHandle/afterCompletion，从结构上杜绝 ThreadLocal 泄漏和跨请求脏数据。谁产生谁填写——字段按填充阶段分组，日志字段有问题时一眼定位到责任组件。有机器消费方的日志，格式是契约——顺序显式声明、变更只许追加、用单测守护，别让下游数据悄悄变脏。系列文章上一篇：02 - Caffeine 多级缓存——6 种缓存策略深度对比与源码分析下一篇预告：04 - 动态限流——Guava RateLimiter 三级粒度与增量热更新。

2026-07-21 17:51:51 324

原创高并发系统的本地缓存设计：6 种策略的取舍之道

缓存设计的核心不是"怎么用 Caffeine API"——那只是 5 分钟就能学会的事情。真正的功夫在于根据数据特征选择策略会变的数据→异步刷新，牺牲秒级一致性换取零毛刺不变的连接→长周期回收，减少对象创建不变的计算→容量驱逐，用内存换 CPU被推送的配置→volatile整体替换，零开销读取需要主动探测的状态→ 后台轮询 + 三层兜底查不到的结果→ 负缓存 + 定时清理，止血穿透没有最好的缓存策略，只有最匹配数据特征的缓存策略。下一篇预告。

2026-06-29 19:38:26 236

原创分布式异步任务编排框架：设计与实践

Override// 1. 检查中断标志return;// 2. 检查前置任务是否全部成功if (!throw new TaskCanRetryException("前置任务没有全部执行成功");// 3. 模板方法执行（由 TaskRunnerRunnable 拦截异常并记录日志）@Override// 前置处理（子类可覆盖）// 核心业务逻辑（子类实现）// 后置处理（更新状态为 SUCCEEDED）}.run();

2026-06-29 11:55:03 332

原创 10 万 QPS 在线数据交付系统架构全景

层次核心技术解决的问题拦截器链4 层 Interceptor + 2 个 Advice，精心编排的 Order关注点分离，每层单一职责缓存层Caffeine 6 种 LoadingCache + 启动预热消灭数据库 RT，亚毫秒级鉴权计费层Redis 原子计数 + 多订单级联 + 去重两阶段并发安全扣减，T+1 去重精度限流层Guava RateLimiter 三级粒度 + 配置中心热更新运行时动态限流数据压缩索引 + 增量编码 + 模板方法 Decoder。

2026-06-02 11:19:26 405

原创 JAVA集合—ArrayList源码深度解析

ArrayList 可能是每个 Java 开发者最早接触、使用最频繁的集合类。但你是否真正理解过它的内部实现？比如：扩容机制是什么？为什么扩容是 1.5 倍？add()和remove()的时间复杂度分别是多少？本文基于 JDK 21 源码，逐行分析 ArrayList 的核心实现，覆盖日常开发中的高频知识点。文末附有常见问题汇总，可直接跳转查阅。List<E>：有序集合，支持按索引访问：标记接口（没有方法），表示支持快速随机访问。会根据这个标记决定使用索引遍历还是迭代器遍历Cloneable：支持。

2026-04-09 17:10:32 533

原创 Java 集合—框架全景图：一篇文章带你认识所有集合类

Java 集合框架（Java Collections Framework）是日常开发中使用频率最高的 API 之一，但很多开发者只熟悉 ArrayList、HashMap 这几个"常客"，对整个集合体系的全貌缺乏系统认知。本文将把 Java 集合框架中所有常用和不常用的集合类全部列举出来，按体系结构分类介绍，帮你建立一个完整的知识图谱。后续文章会对核心集合（HashMap、ConcurrentHashMap、ArrayList、LinkedList）进行源码级深入分析。

2026-04-06 14:09:58 661 1

m0_62386619的博客