随着DT时代的来临，数据对于企业经营决策的价值日益凸显，而企业在进行互联网+转型的过程中，如何让数据架构平滑迁移到大数据平台，对于传统业务的转型升级至关重要。企业IT部门该如何进行PB级别大数据平台的迁移规划呢，请看云智慧运维总监张克琛带来的经验分享。
提到PB级别的大数据解决方案市面上有很多，比较火的有Hadoop、Spark、Kafka等等，如果是一个新上线的系统，相信大家都能找到适合自己的方案。但“大数据”在09年才逐渐成为互联网信息技术的流行词汇，一个较老的系统如何平滑迁移到PB级数据架构呢？文章源自运维生存时间-https://www.ttlsa.com/news/how-to-carry-out-the-structure-change-of-pb-level-data/
云智慧的第一款产品监控宝是08年启动的，在设计之初缓存使用的是Redis, 数据库使用的是MySQL，随着业务的高速发展和全球分布式监控点的陆续建立，数据量也从开始的GB级迅速发展到PB级，大数据成为必然的选择。面对PB级别数据存储，云智慧一路走来也踩过很多坑，下面就给大家分享一下监控宝系统架构变迁的几个比较重要的点。文章源自运维生存时间-https://www.ttlsa.com/news/how-to-carry-out-the-structure-change-of-pb-level-data/
一、Redis的扩展
我们面临的第一个的问题是Redis的扩展，Redis进程无法使用多核，云智慧监控宝当时的Redis进程并发1.5W，单core CPU占用率95%，偶发会达到100%，监控宝的任务调度会出现延迟现象，我们做了三套方案：文章源自运维生存时间-https://www.ttlsa.com/news/how-to-carry-out-the-structure-change-of-pb-level-data/
方案1：改程序逻辑，基于任务ID的一致性hash支持Redis多实例，但由于研发忙于产品功能，没空修改，此方案只能放弃；文章源自运维生存时间-https://www.ttlsa.com/news/how-to-carry-out-the-structure-change-of-pb-level-data/
方案2：Redis Cluster，看到官方架构图，我就直接将此方案放弃了。监控宝有大量的写操作，如果每个点都同步写操作，理论上瓶颈无法解决，不适合我们的使用场景，而且生产环境用这个的好像也不多。文章源自运维生存时间-https://www.ttlsa.com/news/how-to-carry-out-the-structure-change-of-pb-level-data/
文章源自运维生存时间-https://www.ttlsa.com/news/how-to-carry-out-the-structure-change-of-pb-level-data/
方案3：Codis, Twemproxy.文章源自运维生存时间-https://www.ttlsa.com/news/how-to-carry-out-the-structure-change-of-pb-level-data/
最终我们选择了Codis，目前线上稳定运行一年多，从未出现任何问题。QPS 已经达到每秒15万次。整个架构每一层都支持扩展，并且无单点，架构图如下：文章源自运维生存时间-https://www.ttlsa.com/news/how-to-carry-out-the-structure-change-of-pb-level-data/
文章源自运维生存时间-https://www.ttlsa.com/news/how-to-carry-out-the-structure-change-of-pb-level-data/
Codis有很多优点，而我们选择的理由如下：文章源自运维生存时间-https://www.ttlsa.com/news/how-to-carry-out-the-structure-change-of-pb-level-data/
- 平滑迁移：Codis提供了迁移工具，比较容易操作。我们生产环境已经验证，从redis迁到codis 对业务影响为0，不过redis有些命令是不支持的，迁移之前还是要仔细读下codis的文档，是否适合自己的生产环境。
- 扩展容易：Codis将数据默认分了1024个slot，看到这个当时就很开心，以后基本不用担心数据量的问题了。理论上是可以扩展到1024个redis实例，扩展的时候先把新的redis实例加入到集群中，再将部分slot迁移至新的实例中就可以了，包括后面将要提到的Mycat 2.0 也会采用这种设计。
- 友好的管理页面：扩展的操作直接就可以通过管理页面做了。
下面是迁移管理图：文章源自运维生存时间-https://www.ttlsa.com/news/how-to-carry-out-the-structure-change-of-pb-level-data/
文章源自运维生存时间-https://www.ttlsa.com/news/how-to-carry-out-the-structure-change-of-pb-level-data/
而上面这几点Twemproxy是不具备的，Codis唯一的缺点就是稍稍复杂一些，入门的时候稍需要多花些时间，但相比其优点这些都微不足道了。文章源自运维生存时间-https://www.ttlsa.com/news/how-to-carry-out-the-structure-change-of-pb-level-data/
二、使用MySQL处理PB级别的数据存储
我们面临的第二个问题是PB级别的数据存储，就拿监控宝的网站监控功能来说，云智慧在全球分布有200+个监测点，这些监测点按用户设置的频率访问指定的网站页面，监测数据传到我们的数据中心。这个服务目前有30多万用户在使用，平均数据日增量在1TB以上。文章源自运维生存时间-https://www.ttlsa.com/news/how-to-carry-out-the-structure-change-of-pb-level-data/
这部分数据类似于日志数据，使用MySQL来存这些数据并不是什么高大上的做法，如果大家使用过ELK的话，会推荐我们使用elasticsearch来存储这些日志数据吧。的确是这样，我们的新产品透视宝、压测宝都在用elasticsearch，也用到了hadoop、spark、suro、kafka、druid等大数据相关的框架应用，直接使用文件来存储也是可以的。文章源自运维生存时间-https://www.ttlsa.com/news/how-to-carry-out-the-structure-change-of-pb-level-data/
但老系统的问题必须要解决。文章源自运维生存时间-https://www.ttlsa.com/news/how-to-carry-out-the-structure-change-of-pb-level-data/
使用MySQL做大量数据存储很容易就想到分库分表，提到分库分表自然就会想到MySQL的中间件，大家在网站可以查到一些常用的分库分表的中间件，包括大家比较熟悉的Atlas、Mycat（cobar）、TDDL 、HEISENBERG、OCEANUS、VITESS、ONEPORXY、DRDS 等，先不谈这些中间件之间的区别，他们共有一个特性，只能在一个维度上对数据进行拆分或者说只能对数据进行一次拆分。文章源自运维生存时间-https://www.ttlsa.com/news/how-to-carry-out-the-structure-change-of-pb-level-data/
切分数据库分为垂直切分和水平切分，先介绍一个比较简单的垂直切分场景：文章源自运维生存时间-https://www.ttlsa.com/news/how-to-carry-out-the-structure-change-of-pb-level-data/
有几个数据库在同一个MySQL实例中，但因数据库A 的IO相对较高，希望将其单独拉到另外一台服务器上，又不想让研发改动代码。文章源自运维生存时间-https://www.ttlsa.com/news/how-to-carry-out-the-structure-change-of-pb-level-data/
文章源自运维生存时间-https://www.ttlsa.com/news/how-to-carry-out-the-structure-change-of-pb-level-data/
以前一直以为Mycat只能做水平切分，其实也可以垂直切分，很实用，配置也很简单，因各种原因希望将原来一个MySQL实例中的多个库分布到多个实例中，直接使用Mycat就可以做到，对应用程序来看还是同一个实例，在拆分过程可以通过主从同步实现平滑迁移。
接下来介绍水平切分，水平切分是指将某个表按照某个字段的某种规则来分散到多个表之中，每个表中包含一部分数据。
常用的根据主键或非主键的分片规则：
1、枚举法：
比如数据是按照地区省份来保存的，用户通过多级别划分的，本规则适用于这些特定的场景。
2、求模：
如果分片字段为数字，对分片字段进行十进制/百进制求模运算，数据可以均匀落在各分片内。也见过网友分享的对字符串hash取模，支持存在符号字母的字段的分片。
3、范围约定
对分片字段约定一个范围，比如ID 100001~200000为一个分片，ID 200001~300000为一个分片
4、按日期
可以按月，按天，按小时分片
5、一致性hash
一致性hash算法有效解决了分布式数据的扩容问题。这个大家可以查下具体的算法实现。
以上是常用的几种方式，也有一些分片方式是根据上面5种变化得来，比如对日期字段hash再分片的。
单独使用一种分片规则是很难支撑大量数据的存储，哪怕使用一致性hash在生产环境中也是很麻烦的事情，光是数据迁移就是一件让运维头疼的事了，这时候我们需同时采用垂直分片和水平分片，甚至多次水平分片，下面聊一下我们在实际生产中如何使用这些分片规则的。
以监控宝API监控为例，先介绍下应用场景，现在我们手机里安装的是各种APP，其架构中必然存在大量的API，我们的用户不但要监控单个API请求，还要监控连续请求构成的事务, 监控宝API监控的正确性是以断言来判断的，每个监测点都会对用户的API做出请求，请求数据及断言的结果都将被存储到数据中心。
我们借助于cobar, 对数据做了两次分片，分片逻辑图如下：
a、 首先我们是通过cobar ，采用枚举法按监测点ID对DB这层进行了数据分片，这样做的话物理上同一个监测点的数据在一起，业务上也是好理解的。
b、在程序逻辑中按天对表进行了分片。每天都会有脚本将一月之内的表都创建好。
从上图中大家可以看到，这里扩展上是存在问题的。我们一共有200多个监测点，在第一阶段，数据量没有那么大的时候，为了节约成本，我们仅使用了10台机器做存储，一台机器存有多个监测点的数据。
随着数据量增大，发展到第二阶段，当某台机器硬盘快存满的时候，我需要将一些监测点的数据迁移至新增进集群的机器中，按这个架构，最多我们可以扩展到200+台机器。
在生产环境中用户对北上广的监测点是最有兴趣的，所以这些监测点的数据量是最大的。 这样就会发展到第三阶段，部分监测点的数据量大到单台机器的硬盘存不下了。
这时候如何解决问题呢，我们来分析一下数据，单个数据库中是按日期来分表的，而大于3个月的历史数据较少有人查询，用户也可以接受历史数据查询时间稍长一些，于是我们选用了TokuDB来压缩历史数据，基本上1T的数据压缩之后在100G左右。1:10的压缩例，即使这样，理论上最多也只能存储4P左右的数据（数据放在UCLOUD上，云主机支持的最大硬盘为2T）。
我们在网站监控的数据分库中解决了这个问题，逻辑图如下，我们从4个维度对数据进行了分片
1、按日期为第一维度对数据库分片，必须按日期做第一次分片，并且分片时间点可以在配置文件中自定义。
2、按监测点ID为第二维度对数据库分片
3、按实际分片数量对任务ID动态取模为第三维度对数据库分片
4、对任务ID 100取模为第四维度对数据表分片。
创建后的数据库类名似于db-201501-monitor01-01、 db-201501-monitor01-02 …… 每个库是有100张表。这样可以的好处：
1、冷热数据自然分离
2、可以根据日期无限次分片
3、在同一个时间段里实际分片数可以自定义。理论上可以无限次分片。每次分片服务器的数量是可控的，并且下次分片的时间也变的可预期。可以在最大程度是节约成本。
4、数据无需迁移我
细心的同学会发现这样对数据分片造成一个小问题，我们对任务ID做了两次取模，会造成部分实例中的某些表中数据是空的，不过并不影响应用。
以上就是云智慧在过去几年里从传统数据架构向大数据迁移过程中的一些经验，希望为大家的数据架构迁移提供参考。
评论