导航：首页 > 科技资讯 >

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

发表于：2024-11-24 作者：创始人

编辑最后更新 2024年11月24日，在神策 2021 数据驱动大会北京场技术论坛上, 神策数据首席架构师张铎发表了主题为《神策私有化部署的架构演进》的演讲, 本文为精选内容。主要包括:私有化部署的意义神策私有化部署的演进及技术挑战Saa

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

私有化部署的意义

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

SaaS 化部署的意义及技术挑战

SaaS 化的分析云

神策部署模式的未来

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

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

关注神策数据公众号, 回复"2021 演讲 PPT"即可下载完整版演讲 PPT。

一、私有化部署的意义

为什么选择私有化部署? 其实这不是一个技术决策, 而是业务决策。首先, 在神策数据创业初期, 因企业知名度及客户忠诚度有待提升, 部分客户对神策数据的 SaaS 模式慎之又慎。因此, 私有化部署成为神策数据业务拓展的必然选择。其次, 私有化部署是符合中国国情的选择。在国内市场, 部分行业管制严格, 比如以证券、保险、银行为代表的金融业, 他们的业务数据几乎不会上云。基于以上两点考量, 神策数据选择了私有化部署。

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

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

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

这个阶段神策数据会通过私有化部署来争取更多客户, 具体表现为: 根据客户的现有资源和业务需求, 针对性提供产品与服务支持, 对于一些特定场景的诉求会尽力去满足。总结起来, 这个阶段虽然我们在业务上很成功, 但在技术上并非无可挑剔。

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

随着业务的逐步发展, 神策数据的客户越来越多, 客户需求也越来越复杂, 单靠神策分析一个产品已经无法满足客户的所有需求, 因此, 我们开始打造神策产品矩阵。在私有化部署这件事儿上, 我们开始尝试标准化, 也就是将客户环境标准化。但在实际落地时却发现困难重重, 客户环境不是标准化也很难实现标准化。为了能够尽快推动交付不影响客户的业务进度, 我们会通过多方案针对性解决问题, 但这不可避免地会增加交付和技术团队的工作量。

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

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

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

此外, 我们把有状态服务和无状态服务进行拆分, 用不同的管理系统进行分别管理。针对无状态服务, 我们会进行容器化, 或者用 K8s 进行管理。这个阶段我们需要做到全面标准化, 但又要足够灵活。最终达到的目的是绝大部分客户的环境都成为了"标准"环境。目前来看这一套标准化的方案进展正常, 这为我们后续服务更多客户打下了坚实的基础。在以上三个阶段的演进过程中, 我们也面临着如下挑战:

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

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

挑战二: 历史版本收敛

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

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

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

挑战四: 内存不够

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

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

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

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

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

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

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

(4) 高基数分组优化。对于数据量级较大但看数需求稳定在 Top1000 左右的客户, 我们会将提取 Top1000 的操作放到内层, 提前把不需要的数据过滤掉。其次, 我们还会做查询资源预估。在资源不够时, 针对并行的多个查询任务, 将其按照顺序依次进行; 同时基于历史资源消耗进行预估, 客户使用频次越高, 估算越准确。最后, 我们还做了神策数仓负载管理平台, 帮助客户清楚地了解内部资源是如何消耗的, 查询使用是否合理等。

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

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

关注神策数据公众号, 回复"2021 演讲 PPT"即可下载完整版演讲 PPT。

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

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

那为什么神策分析云使用私有化部署时能够成功, 客户能够接受? 这是因为神策分析云是一个旁路系统, 且是离线场景, 不会直接影响到客户的业务。而神策营销云则不同, 营销云是一个业务系统, 这意味着对 SLA 要求很高, 一旦营销活动出现问题将会直接影响客户经营, 这种情况下 SaaS 化就成了神策营销云的优先选择。同样地,SaaS 化部署也会迎来新的技术挑战。除了大家比较常见的 SaaS 集群要多租户之类, 还面临着两个特殊的挑战: 第一个就是营销云 SaaS 化, 但分析云依然是私有化部署, 而营销云需要用到分析云里面的数据, 这时该如何做? 针对这个问题, 神策数据开发了一条私有端到 SaaS 端的数据通路, 保证营销云可以利用分析云的数据进行营销触达。关于安全性我们也有特别的考虑: 一方面, 这个通道是加密的, 保证安全不会泄露; 另一方面, 该通道具体传了什么样的数据都是可以追踪的。此外, 即便是结果数据, 也只是暂存而不是长期储存在 SaaS 端。

第二个挑战是对于那些因为政策安全等原因, 仍然会选择私有化部署营销云的客户, 这种情况如何处理呢? 我们采用了一套代码和架构, 多种部署模式的思路, 也就是将神策数据整个通用的部署架构抽象成各种各样的组件, 有的是私有化部署和 SaaS 共享的组件, 有的则是两者分别特有的。

关注神策数据公众号, 回复"2021 演讲 PPT"即可下载完整版演讲 PPT。

四、SaaS 化的分析云

我们可以看到, 相较于私有化部署,SaaS 化有以下优势:

1、通过固定的机器进行成本分摊, 对于中小客户来说成本将显著降低。

2、利用云上的分层存储, 只缓存热数据, 可以降低存储成本。

3、SaaS 理论上可以保证更高的 SLA, 前面也提到, 这也是为什么营销云必须要 SaaS 化。

五、神策部署模式的未来

关于神策部署模式的未来, 主要有以下四点:

第一, 神策数据未来的部署模式将是私有化和 SaaS 并存的状态。

第二, 为了降低维护成本, 我们将坚持一套代码和架构、多种部署实现的方式。

第三, 我们会从客户实际需求出发, 根据客户的实际情况选择最适合的部署方式。