【T112017 数据工程和技术分会场】基于内存的分布式计算实践
2020-03-01 170浏览
- 1.基于内存的分布式计算 主讲人：TalkingData 企业产品研发总监 周国平
- 2.背景简介 我们团队专注于移动运营 平台企业版，客户的APP日活 移动运营平台企业版 小的有不到10万，大的可以达 产品进化图 到数千万。 V4.0 我们致力于让移动运营平 台企业版能够弹性地支持小、 中、大型企业客户，系统稳定 V3.0 V3.1 2015 2016 且易于维护。 V2.0 V1.0 2013 2014 2017
- 3.问题 我们团队负责 事实证明移动运 有一天，我们的一个客 移动运营平台企业 营 平 台 企 业 版 V3.0 能 户，他们上线了几个日活量 版 V3.0 及 后 续 版 本 够满足绝大多数企业 较大的APP，系统的整体日活 迭代，当时的设计 客户的需求，能够稳 达到了2000万，运维人员反 目标支撑500w日活 ， 定地支撑他们的业务。 映MySQL的binlog增长很快， 快把剩余磁盘空间占满了。 数 据 库 使 用 MySQL 。 企业客户APP日活设计目标 500 W 2000 W 500 W
- 4.问题分析 1 我们使用了bitmap索引 技术保证移动运营各项指标 （如日活、留存、转化漏斗 等）的实时计算，因为 bitmap索引高效且能节省存 储空间，它能很方便地做指 标的实时排重。 bitmap 某APP某天0：0的初始活跃状态 第1位 设备1 第2位 设备2 第3位 设备3 … 第N-1位 设备N-1 第N位 设备N 0 0 0 0 0 0 bitmap 当天8：10，设备3和设备N-1访问了APP 1 设备1 2 设备2 3 设备3 … N-1 设备N-1 N 设备N 0 0 1 0 1 0 bitmap 当天9：20，设备2和设备N-1访问了APP 1 设备1 2 设备2 3 设备3 … N-1 设备N-1 N 设备N 0 1 1 0 1 0
- 5.问题分析 2 我 们 使 用 MySQL 但 是 ， MySQL 本 身 我 们 将 bitmap 对 象 作 存 储 bitmap 索 引 ， 因 在业务上是不支持 为blob类型存入MySQL，对 为 MySQL 稳 定 且 易 于 bitmap类型的数据，不 bitmap 索 引 的 某 一 位 更 新 运维。 能够发送指令给MySQL 时需要先从DB查询出来， 让它把bitmap的某一位 更新之后再update到DB中。 设置为1或0。 网络IO APP数据处理 程序 2.设置某一位为 1 更新前 Bitmap 1~3MB 1.查询某个维度的bitmap， 比如说今天的活跃用户。 更新后 Bitmap 1~3MB MySQL 磁盘 4.写binlog（磁盘IO） 3.更新到DB（网络IO）
- 6.问题分析 3 每个bitmap对 象的大小从数百 数据分析： • KB到数MB不等。 100w存量用户，随机60w日活，每个bitmap原始大小 130KB，压缩后126KB • 2000w存量用户，随机200w日活，每个bitmap原始大小 2.6MB，压缩后1.5MB • 1亿存量用户，随机500w日活，每个bitmap原始大小 11.5MB，压缩后5.2MB 频繁地更新blob二进制数据，导致binlog数据量极大，从而导致存储空间不够用。 这就是前面某客户出现瓶颈的原因所在。
- 7.问题域 大块（1M~10M）的二进制 我们需要考虑如何在分布 对象（约30w个bitmap对象）频 式内存中计算以解决此类问题， 繁读写，导致网络IO、磁盘IO等 解决方案需要满足： 资源耗费巨大，MySQL binlog增 • 第一个，缓存备份 长过快导致存储空间不够与浪费。 • 第二个，性能高 • 第三个，易于维护
- 8.候选解决方案 方 案 一 ： 替 换 MySQL ， 使 用 方案二：在MySQL前面引入redis缓 druid/rockdb等大数据组件 存层，定时同步到MySQL 方案三：调研使用Apache Ignite组件
- 9.为什么不选用Druid/RockDB方案 我们在互联网研发线使用了此种方案，但调研下来不适合企业侧产品研发： • 原来我们的系统运维工作很少，整个2000万日活体量的系统，也只需要1个运维人 员；而换了Druid/rockdb，需要有较多的运维工作，等于放弃了我们原有的优势， 增加了对客户运维人员的要求。 • Druid/RockDB 需要大量的服务器资源。
- 10.为什么不选用纯Redis缓存方案 • Redis在高并发下不能支撑对较大bitmap索引的频繁更新，单个bitmap索引平均能 够达到2、3MB，而Redis的value达到1MB时吞吐量不到1000每秒，远远达不到要 求的吞吐量。 • 另外一个重要的原因是Redis的事件机制有问题，expired和eviction事件拿不到缓 存对象的值，这样会导致一旦缓存对象过期或被驱逐，我们无法把缓存对象更新 到数据库。 • 对大块bitmap索引的频繁更新，导致存储空间耗用巨大，而且大块数据的复制延 迟很严重，Redis变得不稳定。
- 11.为什么不选用Apache Ignite方案 • 使用了数据备份功能，因为频繁更新较大的bitmap索引，涉及到数据在不同节点 的备份，导致系统不稳定，经常出现OOM问题。
- 12.最终方案 权衡下来，我们决定基于Ehcache、redis和zookeeper实现一套分布式缓存计算框架。
- 13.分布式缓存计算框架简介 代号 Blade，意在像锋利的刀锋一样有效解决企业产品的问题 • 它是一个bitmap索引计算的加速框架，专门针对海量bitmap索引计算时频繁更新 DB操作进行优化。 • 它会把bitmap索引缓存在内存中，数据处理程序只需要告诉Blade修改哪个bit即可， 无需把整条bitmap索引从DB拉取到本地更新后再写回DB，Blade会负责内存中的 bitmap索引与MySQL的同步。 网络IO 2.设置某一位为1 APP数据处理 1.设置某个维度的 bitmap的某一位为1 程序 Blade 4.设置某些位为 1 更新前 Bitmap 1~3MB 3.定时（如每两小时） 获取该维度的bitmap 。 更新后 Bitmap 1~3MB MySQL 5.更新到DB （网络IO） 磁盘 6.写binlog（磁盘IO）
- 14.为什么Blade？ Blade能够减少更新MySQL中bitmap索引数据的频率，彻底解决大活跃客户出现的问 题，对比之前提出的三种候选解决方案，它主要有如下优势： • 基于成熟的组件（Ehcache、redis、zookeeper），易于维护； • 对比单纯使用redis，不需要处理达2到3MB的bitmap索引数据，系统 稳定，高并发有保证； • 能够实现Apache Ignite的Expired、Eviction等缓存功能，频繁更新时 不会出现OOM问题。 那么，Blade具体是怎么做到的呢？
- 15.Blade主要功能 • 提供分布式内存缓存，缓存对象支持Replication、 Expired、 Eviction等 • 提供UI监控、管理
- 16.Blade主要模块及架构 日志 Application(数据处理程序) Blade Client 客户端 • Blade Client 客户端 • Blade Cluster 集群 ZooKeeper 协调器 Replica Group 复制组 Blade Server 服务 • Blade Data Sync 数据同步 Blade Server(Primary) 主服务 Blade Server(Secondary) 从服务 Blade Server(Primary) 主服务 Replica Group 复制组 • Blade Admin Replica Group 复制组 Blade Cluster 集群 管理 Blade Admin 管理 Blade Data Sync Backup 从数据同步 Blade Data Sync 主数据同步 Data Persistence （MySQL）
- 17.模块：Blade Client • Blade Client是一个Jar，应用程序用这个Jar的API发起对Blade Cluster的 调用。 • Blade Client在启动时，会从ZK上获取到整个Blade Cluster的运行情况。 它会监听ZK事件，当Primary Node宕机或新的Secondary Node启动了， 它可以立刻得到通知。 • Blade Client使用一致性Hash算法，把Key尽量均匀分布在整个Blade Cluster的所有ReplicaGroup上。
- 18.模块：Blade Server Blade Server可以有三种架构： EhCache(Key) EhCache(Key) Jetty Server EhCache(Key) Jetty Server EhCache(Value) Redis Node 1 (Value) Redis Node 2 (Value) Jetty Server Redis(Value) Blade Server Blade Server Blade Server 目前，我们选择第二种，即一个Blade Server包含一个Jetty和一个Redis。 Jetty和Redis部署在一个节点上，能够保证在不占用系统带宽的情况下实现对bitmap 索引的高速存取。Redis只作为一个大缓存使用，Redis本身的分片、集群、主备等功能 全部都不使用，因为Blade本身架构就已经实现了这些功能。
- 19.模块：Replica Group Set bit 5 = 1 where key = a Blade Client 1 Set bit 5 = 1 where key = a Seq num = 198776658388 BladeServer Set bit 5 = 1 where key = a Seq num = 198776658388 BladeServer Bitmap (Key=a) Bitmap (Key=a) Primary Node Secondary Node Replica Group • Replica Group复制组主要用于防止单节点Blade Server宕机后，丢失缓存对象信息， 同一个复制组中的Blade Server缓存对象会保持一致。 • 每个复制组中可以有1到N个Blade Server。一般来说，每个复制组中有2个Blade Server足以。需要注意的是，相同Replica Group中的Blade Server的硬件配置需要一致， 最好分别运行在不同的主机上。
- 20.模块：Data Sync Dispatcher Thread Dispatcher Thread Hash Queue 1 Queue 2 Queue 3 Sync Thread 1 Sync Thread 2 Sync Thread N Sync Thread Group • Data Sync负责把缓存中的bitmap索引定时同步到Data Persistence中。 • Data Sync采用主备架构，平时由主节点负责同步数据，当主节点挂掉时由从节点负责同步 数据。 • Data Sync使用Dispatcher Thread遍历Primary Node的所有Key，Dispatch Thread会根 据Key做Hash，把Key的同步操作分配给后面的Sync Thread Group中的一个线程来执行。 • 为了提高性能，每个Sync Thread都有一个Queue，异步处理请求。
- 21.模块：Blade Admin Blade Admin主要用于监控整个Blade Cluster的情况： l 每个Blade Server的情况 l Replica Group的情况 l Blade Data Sync的同步情况 Blade Admin还提供以下管理功能： l 启动某个Replica Group的Primary Node、Secondary Node之间的同步 l 启动Blade Data Sync的同步
- 22.压力测试：测试场景 2000w日活 20 条日志/用户 4.8TB 数据 12 KB/日志 模拟2000w日活用户，每个用户产生20条日志，每条日志大小约为12KB，总计 约4.8TB数据。
- 23.压力测试：资源配置
- 24.压力测试：测试结果（不使用Blade） • MySQL binlog 2TB 左右 • 处理4.8T数据约需要70小时 • 不能支撑2000万日活
- 25.压力测试：测试结果（Blade架构） • MySQL binlog 50GB 左右 • 处理4.8T数据约需要20小时 • 能够支撑2000万日活
- 26.压力测试：测试结果（对比） Binlog对比 l 同样机器资源下，Blade完全能够支撑 2000万日活，而之前的架构不能。 （单位：GB） 2000 l 两种数据处理方式，实时写MySql的 binlog为分布式缓存同步DB（2小时同 50 NO Blade 步一次）的近40倍。 Blade 计算资源对比 （单位：个） l 对比之前某客户，在支撑同样2000w日 60 40 活的情形下，为客户节省了近1/3的计算 资源。 NO Blade Blade
- 27.THANKS
