本文回答一个问题：一个埋点事件，从用户在浏览器里点了一下，到最终被 Kafka 接住，中间的 SDK 和 Collector 做了多少你看不见的工程？ 答案是：比你想象的多得多。

一、为什么"采集"这件事很难

很多人以为埋点 SDK 就是 fetch('/report', { body: event })。这在 demo 里成立，在生产里不成立。真实的采集层要回答这些问题：

• 页面随时可能关闭——用户点完就关 tab，残留事件怎么办？
• 网络随时可能抖动——一次失败就丢数据？还是重试？重试几次？退避多久？
• 服务端可能限流——429 要重试，但 401（鉴权失败）不该重试，怎么区分？
• 批量还是单条——单条上报开销大，批量要攒多久、攒多少？
• 客户端环境千差万别——浏览器的 sendBeacon、Unity WebGL 不能用 HttpClient、小程序没有 localStorage……
• 凭证放哪——放 Header 还是 body？前者标准但不支持 sendBeacon。

本文回答一个问题：25 个分析模型（漏斗 / 留存 / LTV / 归因 / 路径……）在 ClickHouse 和 Doris 上，到底是用什么 SQL 写出来的？双引擎又是怎么做到"一份业务模型，两份实现"的？

一、为什么是双引擎？

先说结论：GoWind UBA 支持 ClickHouse 和 Apache Doris 二选一，部署时按需选其一，运行时通过一个开关切换。这是一个很有意思的工程选择——为什么不让用户自己写 SQL，而要维护两份？

本文回答一个问题：一个 SaaS 级 UBA 平台，怎么保证租户 A 绝对看不到租户 B 的数据？ 答案藏在两层完全不同的机制里——而它们的边界差异，恰恰是最值得讲的部分。

一、两套机制，一个真相

先说结论：GoWind UBA 的多租户隔离不是一套统一机制，而是两套独立的、设计哲学迥异的机制：

本文回答一个问题：当一个用户行为从浏览器发出，到最终在 Vue 看板上变成一条留存曲线，中间经过了哪些服务、哪些代码、哪些取舍？

一、先看全貌：四个角色的接力

GoWind UBA 不是单体，也不是"微服务为了微服务"。它把用户行为分析的链路切成职责清晰的三段服务，外加一个采集 SDK：

SDK 上报 ──HTTP──▶ Collector ──Publish──▶ Kafka ──▶ Core ──▶ OLAP
                                                       │
                  Vue 看板 ◀──HTTP/SSE── Admin ◀──gRPC──┘