本页内容
关于 Wyze
Wyze 是一家总部位于美国的智能家居公司，为数百万家庭提供高性价比的智能摄像头、传感器和家居自动化设备，产品覆盖全球多个区域。对 Wyze 来说，设备上报的可观测数据不只是运维工具，而是驱动产品质量的一手依据——某次固件更新是否让设备更稳定、某个区域的连接质量是否变差，答案都藏在这些数据里。
一条新建的实时链路
随着装机量涨到千万级，Wyze 决定新建一条实时的设备可观测链路。
难点在于，要处理千万级设备的时序数据，传统做法往往要搭好几套系统：Kafka 加 Flink 做流处理，再配 ClickHouse 或 InfluxDB 做时序存储。这样一条链路建下来，团队得同时维护流处理和时序存储，数据在其间来回流转，运维和排障的复杂度都不低，成本也很高。
传统方案：需要独立部署与运维的三套系统，数据在其间来回流转
落到数据本身，几个要求很明确。千万级设备持续上报，写入吞吐和稳定性的压力始终在；团队要按多维度交叉分析，还要从原始粒度一路聚合到分钟、小时、天级；设备横跨多个时区，各地团队想基于本地时间看数，而传统时序库里的时区转换偏偏很繁琐；原始数据和聚合数据的保留需求又不一样，得靠自动化 TTL 来压住存储成本。
Wyze 想要的不是拼装多套组件，而是用一个平台把流计算和时序存储收拢到一起。
为什么选了 GreptimeDB
对比过多种时序数据库后，Wyze 选择了 GreptimeDB。真正打动团队的，是它能一次性回应上面这些问题，而不是每个问题都要再引进一个新系统。
最关键的是流计算和存储合一。GreptimeDB 内置 Flow 引擎，数据写入后直接在库内完成实时流式聚合，无需再单独部署 Kafka 和 Flink。传统方案里要三四个系统协作才能跑通的「采集—聚合—查询」，在一个数据库里就完成了。
写入性能是另一个契合点。智能家居的数据是不可变的事件流，写进去就不再更新，GreptimeDB 针对这种 append-only 模式优化了写入路径，能稳定扛住海量设备的持续导入。
存储直接建在对象存储上，是另一个重要考量。GreptimeDB 采用存算分离架构，数据落在 S3 上，存储成本随对象存储走、容量近乎无上限，计算节点则按负载独立伸缩，不必为了留存历史数据而堆本地磁盘。对要长期保留海量设备数据的 Wyze 来说，这把存储成本压到了很低的水平，扩容也更从容。
时区处理原本是个不起眼却很磨人的地方。GreptimeDB 提供时区感知的时间窗口聚合，团队可以直接按任意时区聚合和查询，不用在应用层再写一层转换。
除此之外，GreptimeDB 兼容 MySQL 协议，Wyze 现有的 BI 系统和 MySQL 生态工具不改造就能直接查。从开源版迁到企业版后，团队还用上了 Dashboard、MySQL 元数据后端和生产级 Helm Chart，运维负担进一步减轻。
架构设计
Wyze 用一套统一的模式覆盖了所有时序场景：原始事件以 append-only 方式写入、保留较短周期，Flow 引擎在库内实时做预定义的聚合，结果落到聚合表、保留更长时间。
一个数据库统一存储与计算：原始事件写入原始表，Flow 引擎库内实时聚合，结果落到聚合表
真正的取舍落在两张表上。原始表要扛住极高的写入吞吐，同时保证查询性能不随数据量增长而明显退化；聚合表要足够灵活，能覆盖多维交叉分析，又不能让存储失控。GreptimeDB 的分区策略、跳数索引和 TTL 机制在这里各自发挥了作用。
同一套模式，Wyze 落地了三类场景。设备端指标记录设备运行时上报的性能与状态数据，用来评估软件版本和运行环境对设备行为的影响；连接状态监控追踪设备与云端的连接稳定性，用来判断设备群整体健康度、在异常时快速圈定问题范围；移动端体验则来自移动端应用上报的性能指标，用来量化每次功能迭代对体验的实际影响。三类数据走的是同样的「原始表 → Flow 聚合 → 聚合表」链路，只是聚合维度、窗口大小和关注点各有侧重。
部署与运维
Wyze 的 GreptimeDB 跑在 AWS 上，数据存在 S3，元数据放在托管的 MySQL 里。部署方式从早期的虚拟机手动部署，演进到用 Helm Chart 统一管理的 Kubernetes 集群，运维方式随之标准化。
整套 GreptimeDB 是私有化部署在 Wyze 自己的 AWS 账户里的：数据自始至终留在 Wyze 的基础设施内，Greptime 团队不接触任何用户数据。对有安全和隐私合规要求的智能家居业务来说，这一点很关键。
这次升级的跨度不小：跨了多个大版本，同时改了部署形态（裸机 → Kubernetes）和元数据后端（etcd → MySQL）。改动一多，风险也就上来了，团队没有直接切，而是先做了一轮完整预演——把数据导到一套独立环境、用同规格拉起新集群、跑通读写测试，确认无误再正式切换。
过程里也踩到几个坑。跨版本迁移后，节点路由、Flow 任务这些和集群拓扑绑定的状态需要在新集群重新对齐和重建；还有一两个属于边界场景的问题，反馈给 Greptime 团队后在后续版本里得到修复。好在有预演兜底，这些问题都在正式切换前就暴露并解决，最终业务无中断完成升级。
收益
最直接的一点是，这条新链路没有变成多套系统的拼装。按传统方案本要 Kafka、Flink 加独立时序库协作，Wyze 用一个数据库就把它建了起来，团队不必在多套系统之间协调数据链路和维护成本。
实时性是另一处收获。Flow 引擎在秒级完成聚合，运维和产品团队不用等批处理调度就能看到最新汇总；换作批处理，从数据产生到可查往往有分钟级甚至小时级的延迟，故障发现和根因定位也会慢下来。
分析这一头，团队可以按多维度按需查询，同一套数据同时服务运维监控和产品迭代。时区感知让各区域团队都能按本地时间看数，省掉了应用层的转换。成本这一头，数据存在 S3 上本就便宜，再加上自动化 TTL 接管原始数据和聚合数据的整个生命周期，团队几乎不用操心存储的膨胀和清理。
在这之上，Wyze 还接入了 GreptimeDB MCP Server，把库里的时序数据接进了 AI 工作流。每天的运维报表和业务总结不再靠人工写：AI 直接从库里取最新指标和聚合结果，用自然语言给出对设备健康度、连接质量等指标的解读。
小结
Wyze 用 GreptimeDB 把智能家居设备监控的整条链路——原始事件采集、实时流式聚合、时区感知的多维分析——放进了同一个时序数据库，数据直接落在对象存储上，成本和扩展性都更可控。在支撑千万级设备持续上报的同时，性能、成本和可维护性之间拿到了平衡。对于要新建实时时序链路、又不想为流计算和存储各维护一套系统的团队，这是一条值得参考的路径。
参考资料
本文提到的 GreptimeDB 特性，可在官方文档进一步了解：
