神策数据张铎：一文读懂神策私有化部署的架构演进

在神策 2021 数据驱动大会北京场技术论坛上，神策数据首席架构师张铎发表了主题为《神策私有化部署的架构演进》的演讲，本文为精选内容。主要包括：

私有化部署的意义
神策私有化部署的演进及技术挑战
SaaS 化部署的意义及技术挑战
SaaS 化的分析云
神策部署模式的未来

在开始演讲前先问大家一个问题，作为技术人员，你愿意选择几个大的 SaaS 集群还是选择上千个私有化部署的小集群来实现技术指标？

如果是我的话，我会愿意选大集群，因为挑战高并发、巨大数据量会更有成就感；如果选小集群的话，可能会遇到很多比大集群更麻烦、更意想不到的问题。神策数据选择的就是充满挑战的私有化部署。截止目前，神策数据每天帮助客户处理超过 2500 亿行数据的导入，数百万次 SQL 的查询。

一、私有化部署的意义

为什么选择私有化部署？其实这不是一个技术决策，而是业务决策。

首先，在神策数据创业初期，因企业知名度及客户忠诚度有待提升，部分客户对神策数据的 SaaS 模式慎之又慎。因此，私有化部署成为神策数据业务拓展的必然选择。

其次，私有化部署是符合中国国情的选择。在国内市场，部分行业管制严格，比如以证券、保险、银行为代表的金融业，他们的业务数据几乎不会上云。

基于以上两点考量，神策数据选择了私有化部署。

二、神策私有化部署的演进及技术挑战

神策私有化部署的演进，总共分为三个阶段。

第一阶段：2015-2018 年，单一产品线时代

这个阶段神策数据会通过私有化部署来争取更多客户，具体表现为：根据客户的现有资源和业务需求，针对性提供产品与服务支持，对于一些特定场景的诉求会尽力去满足。

总结起来，这个阶段虽然我们在业务上很成功，但在技术上并非无可挑剔。

第二阶段：2018-2019 年，产品矩阵时代

随着业务的逐步发展，神策数据的客户越来越多，客户需求也越来越复杂，单靠神策分析一个产品已经无法满足客户的所有需求，因此，我们开始打造神策产品矩阵。

在私有化部署这件事儿上，我们开始尝试标准化，也就是将客户环境标准化。但在实际落地时却发现困难重重，客户环境不是标准化也很难实现标准化。为了能够尽快推动交付不影响客户的业务进度，我们会通过多方案针对性解决问题，但这不可避免地会增加交付和技术团队的工作量。

第三阶段：2020 年至今，云操作系统时代

在吸取了之前的经验教训之后，我们总结，标准化是必须要做的，但不能只局限于机器环境——在应用服务化方面，通过抽象的 API 接口，把服务之间相互依赖的部分标准化。

同时，神策数据秉承声明式的设计理念，通过声明式资源定义，将外部依赖的资源也进行标准化。作为平台提供方，神策数据让业务线只需要关心或声明想要达到的状态，而不需要关心怎么达到这个状态。

此外，我们把有状态服务和无状态服务进行拆分，用不同的管理系统进行分别管理。针对无状态服务，我们会进行容器化，或者用 K8s 进行管理。

这个阶段我们需要做到全面标准化，但又要足够灵活。最终达到的目的是绝大部分客户的环境都成为了“标准”环境。目前来看这一套标准化的方案进展正常，这为我们后续服务更多客户打下了坚实的基础。

在以上三个阶段的演进过程中，我们也面临着如下挑战：

挑战一：支持各种模式的混合部署

针对客户的版本、业务需求等提供个性化支持以及各种模式的混合部署。

挑战二：历史版本收敛

为避免线上并行多个版本导致维护成本急剧增加，需要针对私有化部署的客户进行历史版本收敛。神策数据通过订阅制的付费模式，在版本更新后主动为客户进行升级。

挑战三：小集群 K8s 化的难点

K8s 是业界通用的资源抽象模式，但是其搭建成本较高，比如控制面至少需要三台机器等。对此，我们尝试通过 K3s 来解决这个问题。对于已经在云上的小规模客户，后续可能采用直接云上托管 K8s 服务。

挑战四：内存不够

随着产品组件越来越多，功能越来越复杂，客户私有化集群的资源量却是不变的，因此，内存成了私有化部署演进过程中不可忽视的问题。针对 Java 程序本身内存涨上去难以下降的问题，我们自行编译了 JDK，引入了新的 GC 算法，让 Java 程序的堆内存占用可以在低峰期收缩。

挑战五：资源受限的情况下查询优化

在资源受限的情况下，如何进行查询优化？

首先，我们针对用户行为分析场景进行定向优化。

（1）用户行为分析数据本身是有序的，通过重写 SQL，我们将 join 全排序变为归并排序，这是我们做的第一个优化。

（2）为了避免某些场景中的无效用户量增加，我们采用两种解决方案，一是客户在数据治理上清理重复数据；二是在查询方面记录用户最后的活跃时间，直接过滤掉不活跃用户，避免过多数据的干扰。

（3）外连接消除。当用户上报和增加限制条件后的实际连接不一致时，我们会依据实际连接进行计算，有效节省资源。

（4）高基数分组优化。对于数据量级较大但看数需求稳定在 Top1000 左右的客户，我们会将提取 Top1000 的操作放到内层，提前把不需要的数据过滤掉。

其次，我们还会做查询资源预估。在资源不够时，针对并行的多个查询任务，将其按照顺序依次进行；同时基于历史资源消耗进行预估，客户使用频次越高，估算越准确。

最后，我们还做了神策数仓负载管理平台，帮助客户清楚地了解内部资源是如何消耗的，查询使用是否合理等。

挑战六：各种意想不到的问题

在私有化部署过程中，还会遇到各种意想不到的问题。比如遇到客户机房着火导致机房中大部分机器物理损坏，我们需要从仅有的一台机器上抢救数据；或者遇到客户机房所有机器一起瞬间断电，导致数据损坏丢失等。

诸如此类的问题，都需要我们在做系统时考虑到。

三、SaaS 部署的意义及技术挑战

私有化部署的主要局限点在于 SLA 无法做到很高。因为私有化部署的机器都部署在客户环境中，系统一旦出现问题，光是连接到客户的环境都需要耗费不少时间，再加上诸如安全性等种种限制，排查问题耗时较久。另外，因为客户环境本身是物理断网的，必须派人去现场勘察，恢复时间较长，如此种种原因导致 SLA 不能达到特别高。

那为什么神策分析云使用私有化部署时能够成功，客户能够接受？这是因为神策分析云是一个旁路系统，且是离线场景，不会直接影响到客户的业务。

而神策营销云则不同，营销云是一个业务系统，这意味着对 SLA 要求很高，一旦营销活动出现问题将会直接影响客户经营，这种情况下 SaaS 化就成了神策营销云的优先选择。

同样地，SaaS 化部署也会迎来新的技术挑战。除了大家比较常见的 SaaS 集群要多租户之类，还面临着两个特殊的挑战：

第一个就是营销云 SaaS 化，但分析云依然是私有化部署，而营销云需要用到分析云里面的数据，这时该如何做？针对这个问题，神策数据开发了一条私有端到 SaaS 端的数据通路，保证营销云可以利用分析云的数据进行营销触达。关于安全性我们也有特别的考虑：一方面，这个通道是加密的，保证安全不会泄露；另一方面，该通道具体传了什么样的数据都是可以追踪的。此外，即便是结果数据，也只是暂存而不是长期储存在 SaaS 端。