lnstagram优选“陶建辉入选2025中国大数据产业年度趋势人物·十年先锋人物”，这条消息是我在朋友圈刷到的。坦白讲，看到“十年先锋人物”这六个字，我第一反应不是替他高兴，而是觉得这个时间尺度选得有点狠——中国大数据行业最不缺的就是新概念、新榜单，但能把一个人放进十年的坐标里去审视，说明他扛过了不止一轮技术周期。
陶建辉这个名字，放在大数据圈子里辨识度很高：涛思数据创始人，TDengine时序数据库的作者，国内少有的坚持用C语言写数据库内核、还敢把核心代码全部开源的CEO。但“十年先锋人物”这个标签，真正想表彰的，其实不只是一款数据库产品的成功，而是他在中国大数据从“上半场讲故事”进入“下半场拼底层”的这十年里，始终站在最不好讲故事的那一侧——基础软件。这篇文章不打算写成颁奖词，我想以一个从业者的视角，聊聊为什么是这个人和这款产品，能从十年的筛子里留下来，顺便把时序数据库背后的技术逻辑和行业趋势一并拆开讲清楚。
1. 过去的十年，中国大数据产业完成了三次“换乘”
1.1 数据挖掘是一种思想，大数据是一套“工程”
很多人会把“数据挖掘”和“大数据”混为一谈，这恰恰是理解过去十年最重要的一条线索。
数据挖掘是早于大数据出现的，它本质上是统计学和机器学习的应用延伸，解决的是“如何从数据里发现规律”的问题。但到了大数据时代，问题变了：数据量从GB跳到TB甚至PB，单机装不下，算不动，你手里那些漂亮的算法模型，面对分布式存储和分布式计算时压根跑不起来。于是行业的重心从“挖掘规律”转移到“搭建管道”——怎么把数据搬进来、存下去、算得完。
陶建辉的经历刚好卡在这个分界点上。他是典型的理工科出身，早年接受的数理训练非常扎实，后来在海外长期从事通信、嵌入式、无线协议这类贴近底层的研发工作。这类工作的特点就是：不好看、不容易被普通人感知，但系统的每一毫秒延迟、每一字节开销，都会在规模放大后被看见。这种“底子”决定了他后来做数据库时，思考问题的路径和做应用层的人完全不一样——他关心的是数据落盘那一刻发生了什么。
1.2 Hadoop 教会了整个行业什么叫“重”
2015年前后，国内大数据创业进入一个井喷期，但你去看当时的技术栈，会觉得很割裂。
一个典型的大数据平台，至少需要 HDFS 存文件、YARN 管资源、Hive 做离线分析、Spark 做计算、Kafka 削峰填谷，每个组件单独部署、单独调优、单独运维。一个企业如果想跑通“从日志采集到报表展示”的完整链路，大概率要配一个专职的 Hadoop 运维团队。那时候的大数据工程师，一半时间在写代码，一半时间在跟 NameNode 内存溢出搏斗。
那个阶段最大的贡献，是让整个行业明白了大数据不是单机问题，而是分布式系统工程问题。但副作用也很明显：大数据被包装成一种“昂贵的重型装备”，只有大厂才玩得起。很多制造企业、能源企业、车联网公司，明明数据量已经很大了，却被 Hadoop 的部署复杂度挡在门外。
1.3 从批处理到实时，再到回归“引擎层”
十年间，这个行业经历了三次明显的转向。
第一次转向是从批处理到实时计算。Flink 的崛起把“流处理”这个概念彻底普及，人们不再满足于 T+1 看报表，而是要秒级看到数据背后的变化。但流计算框架并没有解决存储本身的痛点，它更像是在笨重的存储之上加了一层更快的外挂。
第二次转向是从“平台”到“资产”。数据中台这个概念火了两三年，几乎每个企业都在构建自己的数据中台，一时间数据治理、数据资产化成了最热门的方向。但后来很多人发现，中台建设容易变成一场组织架构的洗牌，离真正解决数据问题越来越远。于是行业开始冷静下来，重新审视那个最基础的问题：数据到底存在什么样的引擎里，才能让上层应用既查得快又花得省？
第三次转向，就是回归数据库引擎本身。大家终于意识到，与其在外围堆砌各种组件，不如把底层引擎做对。这个转向，恰恰让时序数据库、云原生数仓这类基础软件从幕后走到了台前。陶建辉和 TDengine 真正意义上的窗口期，就是在这个阶段打开的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 陶建辉为什么能“留下来”：一个不按大数据套路出牌的人
2.1 从通信底层到智能硬件：他一直在和设备数据打交道
陶建辉和很多大数据创业者有一个明显区别：他不是先从“大数据概念”出发，而是先碰到了一个具体到不能再具体的问题。
早年做通信和嵌入式开发，他面对的是设备之间一帧一帧的通信数据；后来回国创业，做的是智能母婴硬件。这个过程中，他发现自己始终在跟同一类数据打交道——由设备持续产生、带时间戳、按固定或近似固定频率上报的测量数据。今天我们把这类数据统称为“时序数据”，但在七八年前，这个词在国内还非常冷门，大部分人的认知还停留在“这不就是日志吗”。
正是这段经历，让他对物联网设备的“数据脾气”摸得很透：设备数量大、采集频率高、数据永远按时间顺序到达，但传统的通用数据库并不理解这种顺序性，它们只是机械地把每一条记录当作一次独立的随机写入来处理。这种错位，在设备规模小的时候不明显，一旦跑到几千台、几万台设备，后端数据库会第一个崩溃。
2.2 做智能硬件时踩的“数据坑”，成了后来创业的伏笔
他后来在很多场合聊过一个场景：智能硬件做出来以后，真正让人头疼的不是硬件本身，而是服务端要处理的数据量。
假设一台设备每 5 秒上报一次数据，一天就是 17280 条记录；如果有一万台设备在线，一天就是 1.7 亿条。这个量级放在通用关系型数据库里，是一个灾难：分库分表已经把开发复杂度拉满，查询还得靠应用层做聚合；换用 NoSQL，写入是解决了，但想按时间窗口做统计、按设备维度做对比，语句写起来绕得让人怀疑人生。更别提存储成本，海量的历史数据总不能无限堆下去。
如果当时他只是单纯地做一个“能抗住写入”的数据库，那市面上有很多选择。但他想的是更深一层的问题：物联网场景里的数据模型，能不能用一套更贴合自然规律的方式去建模？这个念头，后来演化成了 TDengine 最核心的设计思想——既然设备数据天然按时间产生，那为什么不让存储结构也按时间线来组织？
很多做了多年数据库的人，未必能跳出通用型产品的既定框架。陶建辉做的事情本质上是“回到数据产生的源头重新设计”，这种思维方式，和他早期被训练出来的底层系统直觉是分不开的。
2.3 小切口、高壁垒：时序数据库这条赛道，天生适合“一根筋”的人
从商业视角看，时序数据库并不是一个“性感”的赛道。比起通用数据库千万级的存量市场，时序数据库在几年前甚至被很多人认为是一个“伪需求小市场”。但从趋势上看，只要物联网、车联网、工业互联网持续渗透，时序数据的产生量就会一直增大，而通用数据库对这个场景的适配程度始终有限——这里有痛点，有付费意愿，有壁垒，而且竞争烈度远低于通用数据库领域。
所以陶建辉的选择，本质上是主动放弃做一个“什么都做”的数据库平台，转而把所有资源押在一个极端垂直的场景上。这种战略看起来很窄，但一旦做透，护城河反而很深。国内做基础软件的人不少，但能在“物联网时序数据”这个具体场景里扎根十年、把一款数据库从原型打磨成全球开发者都在用的开源项目的，确实屈指可数。
3. TDengine 的技术破局点：把“重”的大数据做“轻”
3.1 时序数据让传统数据库“难受”的地方到底在哪
理解 TDengine，不能只看它官网上的性能数字，得先理解时序数据到底给传统数据库出了什么难题。
第一，写多读少。设备数据一旦产生就几乎不再修改，数据库面临的是持续不断的顺序追加式写入。传统关系型数据库的 B+ 树结构，为了维护索引的有序性，每次插入都可能触发页分裂、随机 IO，写入吞吐被压得很低。
第二，数据带时间属性，天然有生命周期。昨天的数据有价值，一年前的数据多半只有冷备价值。传统数据库对“过期数据自动清理”这件事支持得很弱，需要用应用层定时任务去 delete，而 delete 在 B+ 树上的代价也非常高。
第三，规模维度来自设备数量，而不是单台设备的数据量。你以为数据量大是核心矛盾，其实是“设备多、表多、采集点多”才是核心矛盾。每个设备要单独分析，又不能为每个设备单独建库、单独运维。
第四，所有分析几乎都和时间窗口绑定。要看过去一分钟的平均值、过去一小时的最大值、过去一周的同比变化率，如果数据库本身没有时间维度的“感知”，上层应用就得自己写一大堆滑动窗口逻辑。
把这些问题叠在一起，你会发现通用大数据平台是“杀鸡用牛刀”，通用关系型数据库是“牛刀杀鸡但刀法不对”，真正缺的是一个从数据模型层面就为时间线而生的存储引擎。
3.2 “一个采集点一张表”：看起来土，却是最本质的解法
TDengine 最重要、也最反直觉的设计，是“一个采集点一张表”。
比如你有十万台设备，每台设备每秒上报一次温度，那在 TDengine 里，你会为每一台设备建一张独立的数据表。这个做法初听会觉得不可思议：十万台设备建十万张表，这不会把数据库压垮吗？
但细想就会发现，它恰恰解决了时序数据最核心的矛盾。每台设备的数据是天然按时间顺序产生的，如果给每台设备单独建表，那么这张表的写入就变成了“只有顺序追加，没有随机修改”。顺序写盘是所有存储引擎最喜欢的写入模式，没有索引维护的开销，没有页分裂，写入吞吐可以做到非常夸张。
那你可能会问，表数量如此庞大，管理和分析怎么办？这就是 TDengine 的第二个核心设计——超级表（STable）。超级表可以理解为一个“逻辑表模板”，它把一批结构相同、但彼此独立的物理表聚合起来。每张子表可以拥有不同的标签值（比如设备型号、地理位置、所属用户），而你查询时只需要面向超级表写 SQL，数据库会自动根据标签把你需要的子表圈选出来做聚合。
这个设计相当巧妙：物理上是隔离的、可以独立高速写入的，逻辑上却是统一的、可以像查询一张大表一样做分析。它本质上是一种“分而治之”的建模思想，避免了通用数据库对高基数设备的索引膨胀问题。
3.3 把时间处理能力做进引擎，而不只是做存储
如果 TDengine 只是解决写入问题，那它充其量是一个“时序版 NoSQL”。它真正让企业愿意替换旧方案的原因，是把很多原本需要外围组件完成的能力，直接集成到了数据库引擎里。
第一，完整支持 SQL。时序数据库最容易犯的毛病是自创一套查询语言，导致开发人员学习成本陡增。TDengine 选择完全拥抱 SQL，凡是会写 SQL 的开发人员，不需要学习专门语法就能完成大部分查询，这对企业的技术团队来说是一个巨大的决策成本优势。
第二，内置降采样和聚合窗口。查询“每台设备五分钟内的平均温度”，在传统架构里要么把原始数据拉到应用层算，要么借助流处理框架做实时聚合，复杂度都不小。TDengine 在 SQL 层直接支持时间窗口的自动聚合、降采样、插值，很多计算在存储引擎内部就处理掉了，减少了数据搬移。
第三，内建数据生命周期管理。你可以直接设置数据的保留时长，过期数据由数据库自动清理。用户不需要开发定时任务去删历史数据，因为对于物联网场景而言，绝大部分冷数据保留的价值很低，而自动清理能显著降低存储成本。
第四，存储与计算一体化设计。TDengine 的写入路径上自带缓存，最新一条数据可以不落盘就读取；同时支持类流式计算的连续查询。它在架构上追求的是用一套引擎解决物联网数据的接入、存储、计算、展示全过程，而不是像传统大数据架构那样，用五六种组件拼装。
3.4 底层抠出来的性能，省下的是真金白银
这些设计合在一起，最终体现为一个字：省。
省的是机器资源。在常见物联网写入场景下，TDengine 与传统通用 NoSQL 相比，写入吞吐能高出数倍甚至接近一个数量级，这意味着支撑同样规模设备所需要的服务器数量大幅减少。
省的是存储成本。时序数据的压缩率通常比通用存储高很多，因为同一台设备上报的数据变化平缓，相邻数据之间存在很强的时间相关性。有些工业现场项目反馈，换用 TDengine 后，同样的历史数据量占用的磁盘空间只有原来的几分之一。
省的是开发成本。以前要做一套车联网数据平台，可能需要维护 HDFS 集群、Kafka 集群、流处理作业、OLAP 引擎四套系统，规划、部署、联调就是几个月的周期；而现在，一套 TDengine 集群几乎承担了八成以上的工作，剩下的精力可以留给真正的业务逻辑。我在看过不少数据平台改造案例后越来越清楚一个事实：少一个组件，少一类故障，这是比性能数字更宝贵的东西。
4. 开源带来的杠杆：他把代码放到全球舞台，换回了什么
4.1 时序数据库走开源路线，几乎是一种必然
陶建辉在 2019 年把 TDengine 的核心代码全部开源，这个决定在当时的国内基础软件圈里需要不小的魄力。
很多人会问，开源是不是等于免费送？对时序数据库来说，恰恰相反，开源的底层逻辑是降低信任成本。企业的数据是核心资产，物联网数据更是涉及生产系统，如果数据库是闭源的，客户会有天然的顾虑：我用了你，万一你哪天不维护了怎么办？这个问题，再好的销售话术都很难化解。而开源相当于把代码放在阳光下，用户可以自己审查、自己测试、甚至在极端情况下自己接手维护。这种安全感，对攻城略地的早期商业化至关重要。
同时，时序数据库的客户场景千差万别，没有哪一家厂商能把所有行业的需求都猜准。开源以后，来自全球开发者的 issue、PR、场景反馈，成了产品迭代最宝贵的养料。这和开源操作系统的逻辑是一样的——你开放的不仅是一份代码，更是一张收集全球智慧的网。
4.2 开源不是终点，“开源之后”才是真正的分水岭
如果只从 GitHub Star 数来衡量，陶建辉那一步已经得到了巨大的回报。TDengine 开源之后，Star 增长速度非常快，长期排在时序数据库类目的前列，很多愿意尝鲜的开发者、企业用户，都是经过这个开源仓库认识它的。
但作为一个从技术商业化角度观察过不少公司的人，我必须说：Star 数不等于商业收入，开源项目的真正分水岭在“开源之后”。
代码开源了，用户自己部署出问题找谁？企业级客户需要多副本高可用、需要可视化运维、需要专业技术支持、需要云上一键托管，这些都是社区版难以替代的付费点。陶建辉团队在把核心引擎做到高性能的同时，也逐步构建起面向企业客户的商业化产品矩阵，包括集群版、云服务、技术支持等，形成了一条“开源吸引用户、产品化解需求、服务创造价值”的完整路径。这条路在今天看来顺理成章，但在当时，中国还没有多少基础软件公司能够走通它。
所以从 2019 年到现在，TDengine 的意义不只是“又一个数据库”，更像一个样本：它验证了中国工程师不仅能做上层应用的创新，还能在数据库内核这种硬核领域里，用开源的方式参与到全球竞争中去。
4.3 对数据行业新人来说，这是一个很好的“反向观察框”
我经常被问到一些大数据入门的问题，热搜里也常年挂着“大数据学习路线”“大数据面试题”“数据科学与大数据技术就业方向”。每次被问到，我都会建议对方先不要急着追最新的框架，而是找一个真实的数据项目，从头到尾走一遍数据生命周期。
你看看 TDengine 走过的路就会明白：真正值钱的能力，是理解一种数据模型的本质，然后知道在什么场景下选什么引擎、为什么这样设计。你可以不用自己写数据库，但如果能读懂 TDengine 为什么会为一个采集点建一张表、为什么会设计超级表，你看其他大数据组件时，就会从“会用”上升到“能设计”。这种能力，在面试里不会过时，在工作中会更值钱。
5. 下一个十年，大数据绕不开的几个底层趋势
5.1 AI 正在成为新的“数据消费者”，数据库要为 AI 供能
过去十年，大数据主要服务对象是人——给人做报表、做可视化、做 BI 分析。但未来十年，数据最大的消费方很可能是 AI 模型。
以工业智能化为例，预测性维护模型需要持续不断的高频传感器数据来训练和推理；车路协同系统需要低延迟地获取车辆轨迹数据；机器人在执行任务时，也需要以毫秒级的时间尺度感知周边环境。这些数据的共同特点是：由物理世界的设备产生、对时间极度敏感、实时性强。如果底层存储引擎不能高效处理时序数据，AI 的“感知”就会断粮。
TDengine 这类时序数据库在 AI 时代的价值，不在于它自己是不是 AI 数据库，而在于它能不能为 AI 提供干净、有序、低延迟到达的数据。数据库和 AI 之间的关系，正在从“AI 跑在数据库旁边”变成“数据库为 AI 持续供能”。
5.2 时序列数据的边界，正在从工业场景蔓延到智能终端
前几年说到时序数据，大家想到的是电力、石油、工厂里的传感器；但再过几年，这个边界一定会扩展。
车是最典型的移动物联网终端——每辆车每秒产生的轨迹、电池状态、驾驶行为数据，都是标准的时序数据。无人机、机器人、智能家居设备，本质上也是移动的或固定的传感器终端。当这些设备从“奢侈品”变成“基础设施”，时序数据的产生规模不会是线性增长，而是指数级增长。
到那时，企业面临的将不只是“存得下”的问题，而是“存得起”和“查得快”的问题。一套通用的、简单的、性价比极高的时序数据存储方案，会是比任何花哨平台都更刚需的基础设施。这也是为什么陶建辉这类“扎在底层”的人，反而能在趋势到来时提前卡住生态位。
5.3 基础软件的产品化能力，会成为下一个十年的决胜点
过去十年，中国大数据产业不缺应用创新，缺的是把底层技术产品化、并且被全球市场反复检验的耐心。基础软件不是一个可以靠资本催熟的行业，数据库内核里的每一个细节，都需要按年为单位去打磨。
陶建辉入选“十年先锋人物”，真正释放的信号是：行业开始愿意把荣誉给那些“背着代码走得很慢”的人。这不是对个人的嘉奖，更像是一种风向标——接下来十年，愿意深扎数据模型、存储引擎、开源社区的人，会获得比过去更大的产业价值回报。
这同时也给所有想进入数据领域的人提了一个醒：别只看数据应用层的热闹，底层引擎才是决定上层天花板的那个变量。不管你是学数据科学、大数据开发，还是做架构设计，多花一点时间研究数据在磁盘上是怎么组织的、在内存里是怎么流转的，这些知识会比任何“热门框架”更抗衰老。
我个人在这个行业看了很多项目、很多产品，也越来越倾向于一个判断：十年时间足够把一个概念从风口吹成泡沫，也足够把一个人从追风口的人，变成定义风口的人。陶建辉和 TDengine 的故事，属于后者。如果你正在选自己的技术方向或者创业方向，不妨也问一问自己：你现在做的事，配不配得上一个十年的尺度？想清楚这个问题，很多当下焦虑的选择，其实已经不那么难做了。