How does Apache Pegasusused in SensorsData

Editor's Notes

• #2: 基础研发部-存储组-分布式研发工程师 孵化器
• #3: pegasus 在神策的使用
• #5: 下定义 paxos 算法，早于 raft 出现 分布式业界通用的实例扩容的表现也非常好 redis 接口
• #6: MetaServer 一主多备 table 的概念可以由右图来呈现（4分片的表），每一个 paritition 的数据集叫 replica（分片），图中 的表现为 primary & secondary，pegasus 默认规定仅由 primary 对访问提供读写服务
• #7: 接口简洁：对用户提供最简单的接口，将寻址和容错等细节封装在内部 配置简单：用户只需通过配置文件指定 MetaServer 地址列表，就可以访问集群，类似于 ZK、hdfs MetaServer 所有的状态都会持久化到 ZK上 同时 MetaServer 通过 ZK进行选主，当 leader 故障后，另一台 backup 立即抢到锁，然后从 Zookeeper 上恢复状态，成为新的 leader
• #8: Facebook，SQLite overlap SST：Sorted Sequence Table，内部无 overlap L0：SST之间可以有 overlap L1~Ln：各层内SST有序排列，无 overlap L0~Ln：各层间有 overlap immutable 不可变的
• #9: 右图展示了一行数据的路由过程： 首先通过用户自定义的 hashkey 计算出他所属的 partition 的 id，拿到partition id 之后通过路由表，确定读写这行数据应该与哪台 replicaServer交互
• #10: 同时，两级 key 的数据模型还可以用于模拟数据结构使用，比如 map 等
• #11: 数据操作类的用户接口，按照 haskkey & sortkey 的数量以及操作类型做了简单分类 拿 get 类请求举例，当指定获取 1 个 hashkey 和 1 个 sortkey 时，接口是 get； 当指定获取 1 个 hashkey 和多个 sortkey 时，接口是 multiGet；（这里还有一组特殊的范围数值获取，也可以使用该接口） 当指定获取 N 组 key-value 数据时（他们的 hashkey 可以不相同），接口是 batchGet 当指定获取 N 组 key-value 数据时（他们的 hashkey 可以有相同的），接口是 batchMultiGet 可以保证原子性的，这可以丰富用户的应用场景
• #12: 这里简单列举了 Pegasus 的历史版本迭代，标注了后期几个版本的个别新特性 早先的迭代方向都是朝着稳定性和满足基本使用需求去着手的，存储系统发版慢，着重于稳定 目前着手于 2.5 版本的发布
• #13: 业界流行的YCSB测试框架来做测试 针对2.4版本 测试了只读、只写、读写混合等场景，注意其中延迟的单位是微秒
• #15: 相比于使用API的方式导入数据效率能提升一个数量级
• #16: 将分片一分为二，降低单分片的数据量，提升读写效率。 仅在注册的时候短暂的停止读写。 清理掉多使用的磁盘空间。
• #17: 读请求长尾产生的特性 能够及时的得到响应 同时能缓解热点访问问题
• #18: 热点 key 是指表中某一个 key 的读写请求量远远高于平均水平，而这个 key 所属分片所在的 replica server 将承受远高于其他节点的请求量，导致单点压力问题 注意这里的分桶bucket是一个虚拟的概念 分为3个阶段可以将检测过程中对正常的读写性能尽量降到最低
• #20: 这里同步的粒度是表 需求是能够容忍源端和目的端集群存在较大的网络延迟的场景，跨区域下提供低延迟的读写分离等
• #21: 表级别环境变量 背景：当数据写入速度超过 flush & compaction 能力，会主动停写或者慢写 作用：针对不同的应用环境，使得存储引擎表现更优，降低读写放大 流量控制 作用：1.出现大流量访问时容易占用集群资源，需要控制访问来减小集群压力，提升稳定性和性能 2.多租户环境，不同业务之间降低相互的影响 实现：客户端限流（JAVA client: FlowController），服务端限流（表级别、QPS、流量） Manual Compaction：单次/例行 1.gc 多版本数据，只保留最新的数据 2.gc 掉已经删除的数据，降低磁盘使用率 3.结合 bulk load 功能，完成数据规整
• #23: 既然是基于神策自身的特点，首先来看下生产环境的特点： 1. 私有部署集群对于运维来说是个挑战： （1）私有集群的数量非常多； （2）某些集群是无法连接外网的，只能现场操作 2. 部分集群预算有限 1.规模非常小，甚至是单节点部署的 2.硬件配置不高，比如内存较小、磁盘性能比较低（使用HDD盘） 3.每台机器上部署的组件比较多，因此需要各个组件限制对CPU和内存这样的资源的使用 这为我们最后选择 pegasus 埋下了伏笔
• #24: 耗内存，会影响同一机器上的其他组件 关联关系数据随时间逐渐膨胀，冷数据增多 早期客户集群以单机版为主，数据量不大，因此单机 redis 是够用的
• #25: 随着神策由单一产品变为产品矩阵，越来越多产品线需要 KV 存储，客户规模也越来越大，有了新的存储需求
• #28: 目的：降低运维操作复杂度 根据机器资源，计算合理配置值（data_dirs 磁盘、block_cache 内存） 建表因子：整个集群的磁盘数量关联，部署、扩缩容、加减盘更新 由于不同客户的机器配置的差异化，建表参数需要适配到具体环境 小表：大部分业务表数据量小，多租户的表数量很多（会回收删除），分片数需要尽量小 大表：需要匹配具体环境，更合理利用 io 资源，每块磁盘提供读写服务的 rocksdb 引擎数量 支持热升级：执行后检测集群规模，按照机器个数生成步骤列表，逐一完成重启以及重启前后的配置设置动作
• #29: 优先级
• #31: 可用性：存活的角色实例数、存活的 replica 数量 资源使用：内存、磁盘、sst 文件数量，ReplicaServer 队列长度、cache 命中率 性能：p99、延迟、qps
• #32: 信创、国产化： 数据安全、网络安全的基础，也是新基建的重要组成部分 鲲鹏安全、麒麟软件
• #33: 指标系统：falcon -> 普罗米修斯 借鉴 kudu 的实现 1.指标名冗余，不易读，大量无用指标（理清指标的类型，从概念、作用、实现、性能方向重新定义指标） 2.指标类型不符合规范，比如 counter 一类标准方案下单调递增的类型，包含了 set 方法 3.不在使用的指标不会释放，占用内存资源 4.性能问题 2节点的集群，2 -> 3 动态修改副本数：1.扩容集群，2节点->3节点 2.迁移场景，目标集群创建单副本表来进行复制数据，复制速度将会大大提升，等待迁移完成后修改副本数满足可靠性 该操作最终实现为使用运维工具 pegasus_shell 来触发，原理简单陈述为修改元数据后，由 MetaServer 调度新增/减少副本的分配，ReplicaServer 接收 MetaServer 补充/inactive 分片
• #34: 之前的 batch 接口在客户端底层实际还是用 set/get 这类单独接口连续发送 RPC 来实现，优化逻辑是确定数据在 server 侧的 partition 后，打包数据发送 rpc 请求 内存控制： 1. RocksDB 对内存的使用（MemTables & Filter Blocks 与分片数量和 max open file 成正比）// 更新 RcoksDB 2.rDSN 对内存的使用：预写日志 log 的块大小可配置 3.新增 jemalloc 的支持，丰富可配置的参数 4.加快 jemalloc/tcmalloc 的内存回收速度：独立专门的线程来进行 gc，改善线程尾延迟，改善内存分配不频繁时的内存归还