三间机房，改成一条流水线
想象一家餐厅：订单先由一套系统接收，再交给另一套系统统计，最后送进第三套系统供前台查询。每套系统都能胜任，但菜单一改，三处都可能要跟着调整。人和订单越来越多后，维护系统之间的接口，反而成了额外工作。
Twilio 的 Voice & Video Insights 团队面对的就是类似问题。其通话分析管道长期同时使用 Kafka、Spark Streaming 和 Elasticsearch：Kafka 传递原始通话指标，Spark Streaming 持续加工数据，Elasticsearch 再把结果提供给 Twilio 控制台和 REST APIs——供其他软件调用数据的接口。
据 dbt 官方博客对 dbt Summit 2026 演讲的转述，Twilio 后来把摄取、转换和结果服务集中到一条由 ClickHouse 支撑的管道，并用 dbt 和 GitOps 管理它。这里的“合三为一”指主要数据承载层的收敛，不是整个技术栈只剩 ClickHouse。本文的迁移事实也都来自这一篇报道及同场讲者，尚缺少独立信源交叉验证。
为什么旧系统会越用越重？
Voice Insights 最初并不是面向客户销售的产品。据 Twilio 介绍，它原本是给客服团队使用的内部排障工具。因为反馈很好，团队在 2016 年将其推向公开测试，经过三年扩展后于 2019 年正式普及。当时，它每天已分析数百亿次通话事件。
流处理——数据一到达便持续加工，而不是攒成一批文件再计算——很适合这种场景。但 Kafka、Spark 和 Elasticsearch 分工不同，也意味着团队要维护三套分布式系统、它们之间的接口，以及各自的配置和部署流程。
问题在数据结构变化时尤其明显。所谓 schema，可以理解为数据表的“格式说明书”：有哪些字段、每个字段是什么类型。开发者和管道增多后，直接在生产集群里手工改 schema，风险也随之上升。按照演讲中的说法，这套组合带来了沉重的基础设施和运维负担，不过报道没有给出成本、故障率或人力投入的前后数字。
ClickHouse接过了哪些工作？
ClickHouse 是面向高速分析的开源列式数据库。它按列组织数据，适合在大量事件记录上做聚合查询。Twilio 用它同时承接数据摄取、转换和结果服务。
其中关键的一步是 materialized views，中文常译为“物化视图”。它可以在新数据进入时，按预先写好的规则生成并保存转换结果。过去由定制 Spark Scala 应用承担的流式转换，因此变成了 ClickHouse 中的 SQL 模型和物化视图。SQL 是描述数据查询与转换规则的语言，通常比维护一套专用流处理程序更直接。
但 ClickHouse 并没有独自完成所有工作。Twilio 使用 dbt 管理转换、测试和 lineage。dbt 可以把 SQL 转换规则组织成可测试、可复用的工程项目；lineage，也就是“数据血缘”，记录一份结果由哪些上游数据和步骤产生。团队还利用 dbt 运行后生成的 artifacts——包含模型和依赖关系的机器可读产物——自动绘制血缘，替代人工维护的架构图。
管道增多后，Twilio 又把一个单体 dbt 项目拆成多个按产品领域划分的项目，并保留一层共享逻辑。任务由 Argo Workflows 编排。它是在 Kubernetes 环境中安排任务执行顺序的工具，作用类似 Airflow。换句话说，数据主要收进了 ClickHouse，项目组织、部署和任务调度仍由其他组件配合完成。
真正值得拆的是变更流程
这次迁移不只是更换数据库。Twilio 的工作流经历了几个阶段：先在共享文档里记录 DDL 变更——DDL 是创建或修改数据表结构的命令；随后引入版本控制，但仍允许直接修改集群；再加入迁移工具和 GitOps，最终接入 dbt 与开源的 dbt-clickhouse adapter。
GitOps 的核心，是把 Git 仓库里的声明式配置当作系统的期望状态。Twilio 将 schema 作为代码存入 GitHub，使生产变更能够经过版本控制和审计。数据库修改由此更像普通软件开发：先提交代码、接受检查，再进入部署流程，而不是直接在生产环境里动手。
测试方式也随之改变。因为 ClickHouse 是开源软件，开发者可以在本地和 CI——代码提交后的自动检查流程——启动真实的 ClickHouse 测试容器，不必只依赖模拟环境。每名开发者还可以用一部分生产数据部署独立预览环境。团队称之为“database per branch”，即每个代码分支配一套数据库环境，先验证变更，再考虑合并。
Twilio 还把自身需要的物化视图模型更新能力贡献回开源 dbt-clickhouse 项目。整合后的同一套管道可以在 Twilio 的不同 regions，也就是不同部署区域，一致地重新部署。
为什么这个案例值得看？
它展示的不是“数据库取代一切”，而是一种更克制的数据栈收敛：让 ClickHouse 接下原本分散在消息摄取、流式计算和查询服务中的主要工作，再用 dbt、GitHub、Argo Workflows 和 Kubernetes 管理模型、变更与执行。
这种收敛的价值，首先是减少系统边界。其次是把过去散落在专用程序、共享文档和人工架构图里的知识，变成 SQL 模型、测试、版本记录和自动血缘。公司层面的规模背景也不小：据 Twilio 自述，它每年为包括 Best Buy、Netflix 和 Uber 在内的客户处理超过 2.5 万亿次 interactions。不过这不是 Voice Insights 管道的处理量，不能拿来证明本次迁移的性能。
局限与未知
- 报道没有提供迁移前后的延迟、成本、可靠性或运维人力数据，因此无法判断性能和效率具体改善了多少。
- “三套系统变成一套”是对承载层的概括。新架构仍依赖 dbt、GitHub、Argo Workflows 和 Kubernetes 等组件。
- 报道称长期使用的 dbt v1 ClickHouse adapter 仍获完整支持，v2 adapter 已进入 public beta；但原始材料末尾不完整，其功能状态和后续时间表仍需谨慎看待。
还有一个更基础的提醒。Twilio Changelog 记录过一次颇具代表性的误报：Voice Insights 曾把系统主动移除的 DTMF 按键音和 Comfort Noise 数据包识别成网络丢包，导致通话被贴上“高丢包”标签，尽管摘要中的丢包率又显示为 0%。统一数据栈可以减少接口和变更管理的复杂度，却不会自动保证指标定义正确。流水线更整齐了，仍要确认它究竟在计算什么。