【t112017-数据工程和技术分会场】基于内存的分布式计算实践

《【t112017-数据工程和技术分会场】基于内存的分布式计算实践》由会员上传分享，免费在线阅读，更多相关内容在学术论文-天天文库。

1、基于内存的分布式计算主讲人：TalkingData企业产品研发总监周国平背景简介我们团队专注于移动运营平台企业版，客户的APP日活移动运营平台企业版小的有不到10万，大的可以达到数千万。产品进化图V4.0我们致力于让移动运营平台企业版能够弹性地支持小、V3.1V3.0中、大型企业客户，系统稳定且易于维护。V2.0V1.020132014201520162017问题我们团队负责事实证明移动运有一天，我们的一个客移动运营平台企业营平台企业版V3.0能户，他们上线了几个日活量版V3.0及后续版本够满足绝大多数企业较大的APP，系统的整体日活迭代，当时的设计客户的需求，能够稳达到了2000万

2、，运维人员反目标支撑500w日活，定地支撑他们的业务。映MySQL的binlog增长很快，数据库使用MySQL。快把剩余磁盘空间占满了。企业客户APP日活设计目标2000W500W500W问题分析1某APP某天0：0的初始活跃状态bitmap我们使用了bitmap索引第1位第2位第3位…第N-1位第N位技术保证移动运营各项指标设备1设备2设备3设备N-1设备N（如日活、留存、转化漏斗000000等）的实时计算，因为当天8：10，设备3和设备N-1访问了APPbitmap索引高效且能节省存bitmap储空间，它能很方便地做指123…N-1N标的实时排重。设备1设备2设备3设备N-1设备

3、N001010当天9：20，设备2和设备N-1访问了APPbitmap123…N-1N设备1设备2设备3设备N-1设备N011010问题分析2我们使用MySQL但是，MySQL本身我们将bitmap对象作存储bitmap索引，因在业务上是不支持为blob类型存入MySQL，对为MySQL稳定且易于bitmap类型的数据，不bitmap索引的某一位更新运维。能够发送指令给MySQL时需要先从DB查询出来，让它把bitmap的某一位更新之后再update到DB中。设置为1或0。更新前Bitmap网络IO1~3MBAPP数据处理1.查询某个维度的bitmap，程序比如说今天的活跃用户。My

4、SQL磁盘更新后4.写binlog（磁盘IO）2.设置某一位为13.更新到DB（网络IO）Bitmap1~3MB问题分析3每个bitmap对数据分析：象的大小从数百•100w存量用户，随机60w日活，每个bitmap原始大小KB到数MB不等。130KB，压缩后126KB•2000w存量用户，随机200w日活，每个bitmap原始大小2.6MB，压缩后1.5MB•1亿存量用户，随机500w日活，每个bitmap原始大小11.5MB，压缩后5.2MB频繁地更新blob二进制数据，导致binlog数据量极大，从而导致存储空间不够用。这就是前面某客户出现瓶颈的原因所在。问题域大块（1M~10

5、M）的二进制我们需要考虑如何在分布对象（约30w个bitmap对象）频式内存中计算以解决此类问题，繁读写，导致网络IO、磁盘IO等解决方案需要满足：资源耗费巨大，MySQLbinlog增•第一个，缓存备份长过快导致存储空间不够与浪费。•第二个，性能高•第三个，易于维护候选解决方案方案一：替换MySQL，使用方案二：在MySQL前面引入redis缓druid/rockdb等大数据组件存层，定时同步到MySQL方案三：调研使用ApacheIgnite组件为什么不选用Druid/RockDB方案我们在互联网研发线使用了此种方案，但调研下来不适合企业侧产品研发：•原来我们的系统运维工作很少，

6、整个2000万日活体量的系统，也只需要1个运维人员；而换了Druid/rockdb，需要有较多的运维工作，等于放弃了我们原有的优势，增加了对客户运维人员的要求。•Druid/RockDB需要大量的服务器资源。为什么不选用纯Redis缓存方案•Redis在高并发下不能支撑对较大bitmap索引的频繁更新，单个bitmap索引平均能够达到2、3MB，而Redis的value达到1MB时吞吐量不到1000每秒，远远达不到要求的吞吐量。•另外一个重要的原因是Redis的事件机制有问题，expired和eviction事件拿不到缓存对象的值，这样会导致一旦缓存对象过期或被驱逐，我们无法把缓存对

7、象更新到数据库。•对大块bitmap索引的频繁更新，导致存储空间耗用巨大，而且大块数据的复制延迟很严重，Redis变得不稳定。为什么不选用ApacheIgnite方案•使用了数据备份功能，因为频繁更新较大的bitmap索引，涉及到数据在不同节点的备份，导致系统不稳定，经常出现OOM问题。最终方案权衡下来，我们决定基于Ehcache、redis和zookeeper实现一套分布式缓存计算框架。分布式缓存计算框架简介代号Blade，意在像锋利的刀锋一样有效解决企