在神策 2021 数据驱动大会北京场技术论坛上，神策数据首席架构师张铎发表了主题为《神策私有化部署的架构演进》的演讲，本文为精选内容。主要包括：在开始演讲前先问大家一个问题，作为技术人员，你愿意选择几个大的 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 的操作放到内层，提前把不需要的数据过滤掉。其次，我们还会做查询资源预估。在资源不够时，针对并行的多个查询任务，将其按照顺序依次进行；同时基于历史资源消耗进行预估，客户使用频次越高，估算越准确。最后，我们还做了神策数仓负载管理平台，帮助客户清楚地了解内部资源是如何消耗的，查询使用是否合理等。挑战六：各种意想不到的问题
在私有化部署过程中，还会遇到各种意想不到的问题。比如遇到客户机房着火导致机房中大部分机器物理损坏，我们需要从仅有的一台机器上抢救数据；或者遇到客户机房所有机器一起瞬间断电，导致数据损坏丢失等。私有化部署的主要局限点在于 SLA 无法做到很高。因为私有化部署的机器都部署在客户环境中，系统一旦出现问题，光是连接到客户的环境都需要耗费不少时间，再加上诸如安全性等种种限制，排查问题耗时较久。另外，因为客户环境本身是物理断网的，必须派人去现场勘察，恢复时间较长，如此种种原因导致 SLA 不能达到特别高。
那为什么神策分析云使用私有化部署时能够成功，客户能够接受？这是因为神策分析云是一个旁路系统，且是离线场景，不会直接影响到客户的业务。而神策营销云则不同，营销云是一个业务系统，这意味着对 SLA 要求很高，一旦营销活动出现问题将会直接影响客户经营，这种情况下 SaaS 化就成了神策营销云的优先选择。同样地，SaaS 化部署也会迎来新的技术挑战。除了大家比较常见的 SaaS 集群要多租户之类，还面临着两个特殊的挑战：第一个就是营销云 SaaS 化，但分析云依然是私有化部署，而营销云需要用到分析云里面的数据，这时该如何做？针对这个问题，神策数据开发了一条私有端到 SaaS 端的数据通路，保证营销云可以利用分析云的数据进行营销触达。关于安全性我们也有特别的考虑：一方面，这个通道是加密的，保证安全不会泄露；另一方面，该通道具体传了什么样的数据都是可以追踪的。此外，即便是结果数据，也只是暂存而不是长期储存在 SaaS 端。第二个挑战是对于那些因为政策安全等原因，仍然会选择私有化部署营销云的客户，这种情况如何处理呢？我们采用了一套代码和架构，多种部署模式的思路，也就是将神策数据整个通用的部署架构抽象成各种各样的组件，有的是私有化部署和 SaaS 共享的组件，有的则是两者分别特有的。我们可以看到，相较于私有化部署，SaaS 化有以下优势：
1、通过固定的机器进行成本分摊，对于中小客户来说成本将显著降低。2、利用云上的分层存储，只缓存热数据，可以降低存储成本。3、SaaS 理论上可以保证更高的 SLA，前面也提到，这也是为什么营销云必须要 SaaS 化。第一，神策数据未来的部署模式将是私有化和 SaaS 并存的状态。第二，为了降低维护成本，我们将坚持一套代码和架构、多种部署实现的方式。
第三，我们会从客户实际需求出发，根据客户的实际情况选择最适合的部署方式。
第四，回到神策数据的价值观——为客户带来价值，不管技术上进行什么样的突破和改变，我们最终都是为了更好地为客户带来价值。
点击文末“阅读原文”，下载完整版演讲 PPT，了解更多精彩内容！
神策数据的私有化部署靠什么取胜？
▼ 点击“阅读原文” ，下载演讲 PPT