根据不同业务特点、业务场景通过部署多个集群实现物理隔离，避免业务相互影响，同时资源使用上可以互补。
**① 分析性查询和日常报表隔离。**分析性查询涉及到大查询和时间跨度比较大的查询，占用大量的资源，可能会影响到其他业务，这两部分业务尽量不要放在一个集群中。
**② 高并发和低延迟场景隔离。**因为高并发会大量占用集群CPU和内存，影响其他业务的查询和写入；低延时隔离，低延时指数据需要秒级写入，会有大量小文件写入，在数据合并中压力比较大，影响其他业务的写入。
**③ 业务级别隔离。**重要业务需要更高的保障确保高可用，避免因为一些低优先级的业务占用资源导致高优业务出现事故，也可以低优和高优搭配，在集群资源不足时，通过对低优降级支援高优业务。
**④ 实时和离线隔离。**像离线主要是大存储，大数据量写入时耗费磁盘资源和IO性能，而实时往往是大数据的计算CPU使用率比较高，如果实时和离线的使用量并不是很大，也可以混布，这样可以充分利用资源。
为了保证集群的稳健、业务的高可用、提升资源的利用率以及降低业务间的相互影响，我们通过多租户、配额和权限管理进行限制。我们的目标是通过配额来限制非预期的行为，特别是错误的使用导致集群不稳定。
**① 系统限制。**设置服务最大内存不超过服务器物理内存的80%，集群总的并行的Query数为CPU核数的2-5倍，避免内存资源不足导致OOM和CPU 负载过高。
**② 查询大小。**从内存占用、所需的线程数和查询耗时上限制，设置单个的查询占用内存资源为系统资源的20%，单个Query的线程数为CPU核数的20%；查询时长10-30s，写入时长60-180s。
**③ 查询次数。**限制并发查询数，比如5/节点；或者为了保证高峰数据的稳定性，可以限制20个query/节点/10秒。一般是并发数和query数同时限制。
**④ 账号分离。**我们针对账号进行了分离，比如同一个业务分为查询账号、导数账号、下载账号，对各种账号分别设置配额，同时，针对配额我们也是严格先压测在设置符合业务实际需要的配额。
**⑤ 读写分离和SQL追踪。**在每个SQL的前面有一段/TraceID/的跟踪ID是上层生成的，TraceID中包含产品、模块、功能、接口等信息，通过TraceID我们很容易找到慢查询、错误查询等SQL的位置。
OLAP中既有存储又有计算，是计算和存储都密集型，离线和实时的场景对机型性能的要求不同，所以按需选择不同的机型，做到资源的合理搭配。
**① 资源类型配比要合理。**不同场景资源类型的需求是不一样的。按照我们的经验，计算量大的业务，选择CPU核数多主频高的，比如分组和去重的计算；数据保留时间长的业务，磁盘空间则需要大；如果使用字典，数据需要加载到内存，则需要考虑大一点内存。一般来说有一个基线的配置如CPU32核内存64-128G磁盘2-10T。
**② 离线推荐HDD磁盘。**在离线场景中，需要存储数年的数据，存储空间占用大，一般采用普通机械磁盘，数据在外部排序顺序写入，磁盘写入速度和IO都能满足要求。使用HDD磁盘时，需要坚持小批次大批量的原则，尽量降低小文件对系统的负担，采用大容量的磁盘，一个好处就是可以做一些物化视图，来提升查询性能，以空间换时间。而实时场景，我们一般选择SSD或NVME，随机写入能性能好，可以低延时高频写入小文件，能获得更低的数据延时，更低的IO繁忙率。
**③ 优先选择单机性能高。**分组或去重计算，需要把全部或部分数据汇聚到少量实例中，然后在汇聚实例中计算，依赖单节点的计算性能，集群相同核数的情况下优先选择CPU核数多和主频高的，比如32核的10台和64核的5台，后者在某些场景下计算性能更优。
支持多副本、多实例、多磁盘集群部署
**① 如何确定分片、副本数。**根据业务存储的量级进行预估分片的数量，尽量让每个分片数据大小控制在在1-10G左右（1M-10M/条），每个分片的磁盘空间不要超过60%；为了保证数据的可靠性，通过配置多副本的方式避免单点故障造成数据不可访问，建议副本数是2个以上、一个副本QPS大概是10-300，如果QPS特别大，则需要更多的副本，我们单集群QPS最高能达到2000。
**② 流行的CH部署方。**流行的CH部署方是单实例的，比如5分片2副本，需要10台服务器，每台服务器部署一个节点，如果查询并发少CPU和内存会有浪费。因此，我们采用多实例多副本的部署模式，如下图4台服务器，我们部署了4分片和2副本，当然我们天然也支持单实例多副本的模式。