大数据的一切
共 21 条 · 按发布时间排列
一个数据库把存储、页格式、事务、系统目录、日志和执行器封在一个进程里；大数据生态把它们拆成对象存储、文件格式、表格式、Catalog、流存储和计算引擎，每一层都是独立的开源组件，靠公开的规范拼在一起。本文先把 HDFS、Parquet、Iceberg、Kafka、Spark、Flink、Doris 这些常用组件放回它们在数据库里对应的那一块，再在本机用 RustFS、Iceberg、REST Catalog 和 DuckDB 搭一个最小的湖仓，跟着一次写入和一次查询走一遍：查 10 月 21 日晚高峰各城市的销售额，在 60 MB 的表里只读了 0.9 MB。最后看拆开的代价。
递推、HyperLogLog、两阶段聚合、切片窗口，看起来是几套互不相干的技巧，其实都在利用聚合的两个性质：能不能合并，能不能撤销。本文用同一张订单表的四个指标讲清这两个问题，再看计算模式（只算变化的部分、把活拆开）和数据结构（又小又能合并的中间状态）怎样分别利用它们，最后给出拿到一个新指标时的判断顺序。
产品想知道：用户从点开商品到支付成功，每一步流失了多少？仿照 Chromium 的 Life of a Pixel，本文跟着订单 1001 走过诞生、采集、传输、计算、落盘、加工、服务，变成看板上的一个数字和一次 AB 实验，再看它被退款改写、被回溯修正、最终被清理；最后回答怎样算一个好的数仓。站在数据应用的角度，引擎内部只点到为止，每一站都指向知识库里深入的文章。
把前三篇放回一个真实场景：20 台双臂机器人做抓取和放置，新策略上线后在透明玻璃杯上频频失手。本文跟着一轮数据闭环走一圈：多路传感器怎样按时间对齐成明细表，数据怎样入湖、打标、算向量，再用失败案例做向量检索挖出难例，生成下一版可复现的训练集。每一步都对照数仓里熟悉的做法。
多模态数据的加工主力从 SQL 换成了解码和模型推理：解码在 CPU，推理在 GPU，模型要常驻显存，解码后的图像比压缩前大十几倍。为 SQL 设计、分阶段落盘的引擎在这里处处别扭。本文讲 Daft 的做法：图像和向量是原生类型，算子可以声明要几张 GPU、开几个常驻实例，各阶段流式执行；再用一个可调参数的实验找流水线的瓶颈。
多模态数据有三处差异落在存储上：训练要随机抽样，模型一升级就要给全表加列，「像不像」成了一种查询。为扫描聚合设计的 Parquet + Iceberg 正好不擅长这三件事。本文讲 Lance 的三个核心原理：把列式文件的最小读取单位做小，用片段、清单和版本让加列只写新列，以及在表里直接建向量索引。
做过数仓的人，对数据的直觉是一行几百字节、SQL 扫一遍做聚合、按天分区回溯。多模态数据把这些直觉逐一打破：一行 99% 是图像和视频，训练要随机抽样而不是扫描，模型一升级就要给全表加列，加工的主力是解码和 GPU 推理，「像不像」成了一种查询，关联靠时间而不是主键。本文逐条讲清这六处差异、数仓的做法为什么不够，以及 Lance、Daft 这类新工具分别接手了哪一处；分层、质量规则、血缘这些经验则可以照搬。
同一张订单宽表，实时链路秒级写入，离线链路天级整表覆盖，已经更新的行会被旧快照改回去。本文用这张表贯穿全文，从现状的实时、离线两条链路讲到 Fluss + Paimon 的改造，最后落到 Materialized Table 的增量语义：需求变了，只改一个 FRESHNESS 参数。衡量每一步的标准是：有多少原本只存在于人记忆里的约束，被系统接管了。
实时数仓的很多麻烦，根子在中间层用的 Kafka 是为事件流设计的，而实时业务大多是分析场景。本文从这个错配出发，看面向分析的流存储 Fluss 如何用主键表、部分列更新、Delta Join、全局字典、存储层聚合和湖流一体，把原本压在 Flink 状态里的工作交还给存储。
流式 SQL 的结果会随输入不断变化，回撤（Changelog）就是通知下游「之前那条作废」的机制，它是正确性的最小代价。但一次更新被拆成「撤回 + 新值」两条消息，会带来乱序和中间错误结果两类副作用。本文用词频统计讲清回撤的原理，再分别看引擎如何解决乱序、业务侧如何用版本列和自定义算子挡住中间结果。
分布式作业慢，多半不是算得慢，而是数据分得不均（倾斜）或搬得太多（Shuffle）。本文从这两点出发，讲清关联与聚合中的倾斜怎么识别、怎么打散，以及 MPP 引擎如何通过选择 Join 方式和 Runtime Filter 少搬数据。
报表可以只写 SQL 配出来，数据接口能不能也这样？这篇教程跟着 QFlink 里一个可以运行的极简 SQL2API 走一遍：把一个电影列表接口写成「一段 SQL 模板 + 一份参数声明」，看参数怎样变成 SQL、注入怎样被挡住，再用统一的请求协议连 SQL 都不写；最后讨论它的边界：数据开发做轻逻辑的数据服务，业务服务还是交给后端。
数据湖是放在对象存储上、用开放的表格式组织、可以被多种引擎读写的表。和传统的 Hive 表相比，它带来四个变化：能按行更新，不用每天全量重算；能流式提交，数据从 T+1 变成分钟级；元数据里带着统计信息，OLAP 引擎直接查湖表，湖仓一体；表格式成为开放标准，批、流、AI 共用同一份数据。本文用一张订单表走完这四个变化，说清数据湖是什么、解决了什么问题、带来了什么，也说清它的代价。
每天计算「近 30 天」指标时，常规写法要把 30 个分区重新扫一遍，其中 29 个昨天刚扫过。本文用一个递推公式把每天的扫描量从 N 个分区降到 3 个，再讨论最大值这类不能递推的指标怎么办，最后介绍让平台替你做这件事的渐进计算。
一段从离线 SQL 转向 Flink 的学习经历：为了一个实时监控需求，从 ProcessFunction 手动管状态写起，到 Window、Flink SQL，再到 SQL SDK、PyFlink 和流批一体。越往上层走开发越省事，但正是对底层的理解，让上层的路走得更远。
UV 这类去重计数不能直接相加，数据一大就成了性能瓶颈。本文按「精确 → 压缩 → 概率」的顺序比较 Set、Bitmap / RoaringBitmap、Bloom Filter 和 HyperLogLog，讲清每种方法的原理、代价和适用场景。
风控规则天天在变，Flink 作业却不能天天重启。本文先用一个能动手的欺诈检测实验看规则怎样触发告警，再结合 QFlink 的实现，讲清楚规则引擎的三件事：规则广播、动态分组，以及能随时改的窗口。
一条监控规则用一句 SQL 就能写完，规则多了怎么办？本文跟着需求从一条、两条到几十条逐步演进：把规则拆成过滤、分组、窗口、聚合、阈值五个要素存进表里，用几个 UDF 让一段固定的 SQL「解释」这些规则，做到改规则不改代码；最后也说清这种做法的边界在哪里。
SQL 写不下去的时候，用户自定义函数（UDF）就是扩展口。这篇教程用三类 UDF 解决三个具体问题：UDTF 让 ETL 里的正则只解析一次，UDAF 把 HyperLogLog 引入 SQL 算累计 UV，Python UDF 把机器学习模型接进实时流；每一步都能在 QFlink 里一条命令跑起来，并解释各自的原理和坑。
大数据开发就是把数据从一张表加工到另一张表。这篇教程用 Paimon + Flink SQL 走完一条完整链路：清洗日志、按窗口统计、切换批模式修数、实时监控告警和复杂事件匹配。每一步都能在 QFlink 里一条命令跑起来，还会亲眼看到同一段 SQL 在批模式下输出 5 个窗口、在流模式下只输出 3 个，以及原因。
PyFlink 的线程模式为什么能让 Java 算子直接调用 Python 函数？这篇教程跟着 QFlink 里的示例，从零搭一座 JNI + Python/C API 的桥：Java 传一个日期，Python 返回星期几。一条命令跑起来，再一步步拆开 Java、头文件、Python、C 和编译；亲手测一次 GIL 让多线程变慢，最后回到 PyFlink 和 PEMJA，对比进程模式与线程模式。