rocksdb

本文首发于 vivo互联网技术 微信公众号 链接： https://mp.weixin.qq.com/s/u1LrIBtY6wNVE9lzvKXWjA 作者：黄伟锋 本文旨在介绍 vivo 内部的特征存储实践、演进以及未来展望，抛砖引玉，吸引更多优秀的想法。 一、需求分析 AI 技术在 vivo 内部应用越来越广泛，其中特征数据扮演着至关重要的角色，用于离线训练、在线预估等场景，我们需要设计一个系统解决各种特征数据可靠高效存储的问题。 1. 特征数据特点 （1）Value 大 特征数据一般包含非常多的字段，导致最终存到 KV 上的 Value 特别大，哪怕是压缩过的。 （2）存储数据量大、并发高、吞吐大 特征场景要存的数据量很大，内存型的 KV（比如 Redis Cluster）是很难满足需求的，而且非常昂贵。不管离线场景还是在线场景，并发请求量大，Value 又不小，吞吐自然就大了。 （3）读写性能要求高，延时低 大部分特征场景要求读写延时非常低，而且持续平稳，少抖动。 （4）不需要范围查询 大部分场景都是单点随机读写。 （5）定时灌海量数据 很多特征数据刚被算出来的时候，是存在一些面向 OLAP 的存储产品上，而且定期算一次，希望有一个工具能把这些特征数据及时同步到在线 KV 上。 （6）易用 业务在接入这个存储系统时，最好没有太大的理解成本。 2. 潜在需求 扩展为通用磁盘

3 月，跳不动了？>>> 本文描述了一些配置选项，这些选项将帮助您有效地管理规划 Apache Flink 中 RocksDB state backend 的内存大小。在前面的文章[1]中，我们描述了 Flink 中支持的可选 state backend 选项，本文将介绍跟 Flink 相关的一些 RocksDB 操作，并讨论一些提高资源利用率的重要配置。 Tips ：从 Flink 1.10 开始，Flink 自动管理 RocksDB 的内存，详细介绍如下： https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/state/state_backends.html#memory-management RocksDB 的状态后端 在深入了解配置参数之前，先回顾一下在 Apache Flink 中如何使用 RocksDB 来进行状态管理。当选择 RocksDB 作为状态后端时，状态将作为序列化字节串存在于堆外内存（off-heap) 存储或本地磁盘中。 RocksDB 是一个以日志合并树( LSM 树）作为索引结构的 KV 存储引擎。当用于在 Flink 中存储 kv 状态时，键由 的序列化字节串组成，而值由状态的序列化字节组成。每次注册 kv 状态时，它都会映射到列族（column-family）

Flink 1.10 release 文档描述了一些比较重要的点，比如配置、操作、依赖、1.9 版本和 1.10 版本之间的区别，如果你准备将 Flink 升级到 1.10 版本，建议仔细看完下面的内容。 集群和部署 •文件系统需要通过插件的方式加载•Flink 客户端根据配置的类加载策略加载，parent-first 和 child-first 两种方式•允许在所有的 TaskManager 上均匀地分布任务，需要在 flink-conf.yaml 配置文件中配置 cluster.evenly-spread-out-slots: true 参数•高可用存储目录做了修改，在 HA_STORAGE_DIR/HA_CLUSTER_ID 下， HA_STORAGE_DIR 路径通过 high-availability.storageDir 参数配置， HA_CLUSTER_ID 路径通过 high-availability.cluster-id 参数配置•当使用 -yarnship 命令参数时，资源目录和 jar 文件会被添加到 classpath 中•移除了 --yn/--yarncontainer 命令参数•移除了 --yst/--yarnstreaming 命令参数•Flink Mesos 会拒绝掉所有的过期请求•重构了 Flink 的调度程序，其目标是使调度策略在未来可以定制

在 Flink 社区中，最常被问到的问题之一是：在从开发到生产上线的过程中如何确定集群的大小。这个问题的标准答案显然是“视情况而定”，但这并非一个有用的答案。本文概述了一系列的相关问题，通过回答这些问题，或许你能得出一些数字作为指导和参考。 计算并建立一个基线 第一步是仔细考虑应用程序的运维指标，以达到所需资源的基线。 需要考虑的关键指标是： 每秒记录数和每条记录的大小 已有的不同键（key）的数量和每个键对应的状态大小 状态更新的次数和状态后端的访问模式 最后，一个更实际的问题是与客户之间围绕停机时间、延迟和最大吞吐量的服务级别协议（sla），因为这些直接影响容量规划。 接下来，根据预算，看看有什么可用的资源。例如： 网络容量 ，同时把使用网络的外部服务也纳入考虑，如 Kafka、HDFS 等。 磁盘带宽 ，如果您依赖于基于磁盘的状态后端，如 RocksDB（并考虑其他磁盘使用，如 Kafka 或 HDFS） 可用的机器数量、CPU 和内存 基于所有这些因素，现在可以为正常运行构建一个基线，外加一个资源缓冲量用于恢复追赶或处理负载尖峰。建议您在建立基线时也考虑检查点期间（checkpointing）使用的资源情况。 示例：数据说明 当前在假设的集群上计划作业部署，将建立资源使用基线的过程可视化。这些数字是粗略的值，它们并不全面——在文章的最后将进一步说明在进行计算过程中遗漏的部分

新特性及优化 内存管理及配置优化 Flink 目前的 TaskExecutor 内存模型存在着一些缺陷，导致优化资源利用率比较困难，例如： 流和批处理内存占用的配置模型不同； 流处理中的 RocksDB state backend 需要依赖用户进行复杂的配置。 为了让内存配置变的对于用户更加清晰、直观，Flink 1.10 对 TaskExecutor 的内存模型和配置逻辑进行了较大的改动 （FLIP-49 [7]）。这些改动使得 Flink 能够更好地适配所有部署环境（例如 Kubernetes, Yarn, Mesos），让用户能够更加严格的控制其内存开销。 ■ Managed 内存扩展 Managed 内存的范围有所扩展，还涵盖了 RocksDB state backend 使用的内存。尽管批处理作业既可以使用堆内内存也可以使用堆外内存，使用 RocksDB state backend 的流处理作业却只能利用堆外内存。因此为了让用户执行流和批处理作业时无需更改集群的配置，我们规定从现在起 managed 内存只能在堆外。 ■ 简化 RocksDB 配置 此前，配置像 RocksDB 这样的堆外 state backend 需要进行大量的手动调试，例如减小 JVM 堆空间、设置 Flink 使用堆外内存等。现在，Flink 的开箱配置即可支持这一切，且只需要简单地改变

摘要：本文由 bilibili 大数据实时平台负责人郑志升分享，基于对 bilibili 实时计算的痛点分析，详细介绍了 bilibili Saber 实时计算平台架构与实践。本次分享主要围绕以下四个方面： 一、实时计算的痛点 二、Saber 的平台演进 三、结合 AI 的案例实践 四、未来的发展与思考 重要：点击「 PPT 」可下载 Flink Forward Asia 大会全部PPT。 一、实时计算的痛点 1.痛点 各个业务部门进行业务研发时都有实时计算的需求。早期，在没有平台体系做支撑时开发工作难度较大，由于不同业务部门的语言种类和体系不同，导致管理和维护非常困难。其次，bilibili 有很多关于用户增长、渠道投放的分析等 BI 分析任务。而且还需要对实时数仓的实时数据进行清洗。此外，bilibili 作为一个内容导向的视频网站，AI 推荐场景下的实时计算需求也比较强烈。 2.痛点共性 开发门槛高 ：基于底层实时引擎做开发，需要关注的东西较多。包括环境配置、语言基础，而编码过程中还需要考虑数据的可靠性、代码的质量等。其次，市场实时引擎种类多样，用户选择有一定困难。 运维成本高 ：运维成本主要体现在两方面。首先是作业稳定性差。早期团队有 Spark 集群、YARN 集群，导致作业稳定性差，容错等方面难以管理。其次，缺乏统一的监控告警体系，业务团队需要重复工作，如计算延时、断流

2019 年 11 月初，我们开启了「TiDB 挑战赛第一季之 性能挑战赛 」，比赛为期三个月，期间选手将通过完成一系列难度不同的任务来获得相应的积分。赛程过去三分之一时，已经取得了十分耀眼的 阶段性成果 。三个月过去，性能挑战赛已经圆满落幕，最终的积分排行也新鲜出炉，选手们的参赛成果让人非常惊喜，让我们回顾一下选手们是如何在“TiDB 性能提升”之路上，过五关斩六将的吧～ 最终积分排名与奖项揭晓 注：本次比赛的完整积分榜详见 活动页面 。 本次 TiDB 性能挑战赛，总共有 165 位社区开发者参赛，包括 23 支参赛队伍和 122 位个人参赛者（按照比赛规则，有 PingCAP 人员参与的小组不计入挑战赛最终排名，即上图中有 TiDB Logo 标示的选手）。 本次比赛奖项设置为：一等奖 1 名，二等奖 2 名，三等奖 3 名，其余分数高于 600 分的团队或个人为优秀奖，各团队和个人的获奖情况如下： 一等奖：.* Team（15050 积分）。 二等奖：niedhui（4300 积分）和 catror（3500 积分）。 三等奖：pingyu（2600 积分）、Renkai（2550 积分）和 js00070（1800 积分）。 优秀奖：ekalinin（1450 积分）、mmyj（1050 积分）、AerysNan（750 积分）、MaiCw4J（650 积分）

RocksDB介绍 RocksDB简介 RocksDB是基于C++语言编写的嵌入式KV存储引擎，它不是一个分布式的DB，而是一个高效、高性能、单点的数据库引擎。它是由Facebook基于Google开源的kv存储LevelDB开发开发。RocksDB使用LSM存储引擎。它针对不同的生产环境进行调优，可以直接使用内存、也可以使用Flash、或者用硬盘或者HDFS。而且支持不同的压缩算法，有一整套的工具用于生产、调试使用。RocksDB是一种嵌入式、KV型、持久化的存储。 使用嵌入式的数据存储原因有很多，当数据频繁访问内存、或者存储时，网络延迟会增加响应时间。 RocksDB的主要应用场景 适应于多CPU场景 一般的商业服务器有很多的CPU核，例如：志强E5系列 - 6核 RocksDB可以高效运行在多核服务器上 它提供的RocksDB语义比传统DBMS更简单 高效利用存储 RocksDB可以在快速存储上高效运行且不会成为性能瓶颈 RocksDB采用LSM引擎，对比B-Tree引擎，它有更好的压缩和更小的写放大 弹性架构，支持扩展 支持IO-bound、in-memory、write-once 入门案例 为了简单说明RocksDB，我们这里使用RocksDB的Java版本来编写。 导入Maven依赖 <dependencies> <!-- https://mvnrepository

寒假把RocksDB学习完成，很多设计理念很先进，也很成熟。 RocksDB系列一：RocksDB基础和入门 https://www.jianshu.com/p/061927761027 LSM：log-structured merge，RockDB中的实现是memtable->sstfile，下面有个详解的： LSM解读：https://cloud.tencent.com/developer/news/340271 整体描述：https://www.cnblogs.com/pdev/p/11277784.html 源码解读：https://blog.csdn.net/flyqwang/article/details/50096377 来源： https://www.cnblogs.com/kuang17/p/12242123.html

文章目录 前言： 介绍一下rocksdb的三种compaction机制 1、Leveled Compaction 策略 优缺点 2、Universal compaction 策略 优缺点 FIFO compaction 策略 rocksdb写数据库 策略 总结rocksdb配置参数 关于放大问题 总结 参考文档 前言： 生产环境现场报过来一个现象： 16节点环境，一共5个mon，但凡起mon服务的节点，系统卡消耗寿命均在60%以上，所以os组以及测试部一口咬定是我们ceph mon引起的问题，通过查看mon数据库内容，数据库记录内容虽然多，但是要说mon能每秒2M的速度写数据库，感觉十分不合理。最后发现mon数据库频繁发生compaction，并且compaction的时候存在如下几种写盘场景： 1、rocksdb的memtable写系统卡之前，会先先写个log，防止意外发生掉电导致数据丢失。 2、memtable到leveldb0的写入过程 3、sst表文件每次compaction的时候会重新被写入（大头应该是这里、sst文件最大情况下可能好几G，这样每次compaction，重写一遍，后果可想而知了） 后面要了一下现场ceph日志，主要排查了一下mon compaction情况，发现如下两种情况： 1、生产环境有一个节点挂了，6小时后被发现，恢复了环境，这六个小时mon