企业互联网+转型实战：如何进行PB级别数据的架构变迁

发布时间：2021-01-05 08:27 所属栏目：53 来源：网络整理

导读：《企业互联网+转型实战：如何进行PB级别数据的架构变迁》要点：本文介绍了企业互联网+转型实战：如何进行PB级别数据的架构变迁，希望对您有用。如果有疑问，可以联系我们。随着DT时代的来临,数据对于企业经营决策的价值日益凸显,而企业在进行互联网+转型的

《企业互联网+转型实战：如何进行PB级别数据的架构变迁》要点：
本文介绍了企业互联网+转型实战：如何进行PB级别数据的架构变迁，希望对您有用。如果有疑问，可以联系我们。

随着DT时代的来临,数据对于企业经营决策的价值日益凸显,而企业在进行互联网+转型的过程中,如何让数据架构平滑迁移到大数据平台,对于传统业务的转型升级至关重要.企业IT部门该如何进行PB级别大数据平台的迁移规划呢,请看云智慧运维总监张克琛带来的经验分享.

提到PB级别的大数据解决方案市面上有很多,比较火的有Hadoop、Spark、Kafka等等,如果是一个新上线的系统,相信大家都能找到适合自己的方案.但“大数据”在09年才逐渐成为互联网信息技术的流行词汇,一个较老的系统如何平滑迁移到PB级数据架构呢?

云智慧的第一款产品监控宝是08年启动的,在设计之初缓存使用的是Redis,?数据库使用的是MySQL,随着业务的高速发展和全球分布式监控点的陆续建立,数据量也从开始的GB级迅速发展到PB级,大数据成为必然的选择.面对PB级别数据存储,云智慧一路走来也踩过很多坑,下面就给大家分享一下监控宝系统架构变迁的几个比较重要的点.

一、Redis的扩展

我们面临的第一个的问题是Redis的扩展,Redis进程无法使用多核,云智慧监控宝当时的Redis进程并发1.5W,单core??CPU占用率95%,偶发会达到100%,监控宝的任务调度会出现延迟现象,我们做了三套方案：

方案1 ：改程序逻辑,基于任务ID的一致性hash支持Redis多实例,但由于研发忙于产品功能,没空修改,此方案只能放弃；

方案2 ：Redis?Cluster,看到官方架构图,我就直接将此方案放弃了.监控宝有大量的写操作,如果每个点都同步写操作,理论上瓶颈无法解决,不适合我们的使用场景,而且生产环境用这个的好像也不多.

方案3：Codis,Twemproxy.

最终我们选择了Codis,目前线上稳定运行一年多,从未出现任何问题.QPS 已经达到每秒15万次.整个架构每一层都支持扩展,并且无单点,架构图如下：

Codis有很多优点,而我们选择的理由如下：

1、平滑迁移：Codis提供了迁移工具,比较容易操作.我们生产环境已经验证,从redis迁到codis 对业务影响为0,不过redis有些命令是不支持的,迁移之前还是要仔细读下codis的文档,是否适合自己的生产环境.

2、扩展容易：Codis将数据默认分了1024个slot,看到这个当时就很开心,以后基本不用担心数据量的问题了.理论上是可以扩展到1024个redis实例,扩展的时候先把新的redis实例加入到集群中,再将部分slot迁移至新的实例中就可以了,包括后面将要提到的Mycat 2.0 也会采用这种设计.

3、友好的管理页面：扩展的操作直接就可以通过管理页面做了.

下面是迁移管理图：

而上面这几点Twemproxy是不具备的,Codis唯一的缺点就是稍稍复杂一些,入门的时候稍需要多花些时间,但相比其优点这些都微不足道了.

二、使用MySQL处理PB级别的数据存储

我们面临的第二个问题是PB级别的数据存储,就拿监控宝的网站监控功能来说,云智慧在全球分布有200+个监测点,这些监测点按用户设置的频率访问指定的网站页面,监测数据传到我们的数据中心.这个服务目前有30多万用户在使用,平均数据日增量在1TB以上.

这部分数据类似于日志数据,使用MySQL来存这些数据并不是什么高大上的做法,如果大家使用过ELK的话,会推荐我们使用elasticsearch来存储这些日志数据吧.的确是这样,我们的新产品透视宝、压测宝都在用elasticsearch,也用到了hadoop、spark、suro、kafka、druid等大数据相关的框架应用,直接使用文件来存储也是可以的.

但老系统的问题必须要解决.

使用MySQL做大量数据存储很容易就想到分库分表,提到分库分表自然就会想到MySQL的中间件,大家在网站可以查到一些常用的分库分表的中间件,包括大家比较熟悉的Atlas、Mycat(cobar)、TDDL 、HEISENBERG、OCEANUS、VITESS、ONEPORXY、DRDS 等,先不谈这些中间件之间的区别,他们共有一个特性,只能在一个维度上对数据进行拆分或者说只能对数据进行一次拆分.

切分数据库分为垂直切分和水平切分,先介绍一个比较简单的垂直切分场景：

有几个数据库在同一个MySQL实例中,但因数据库A 的IO相对较高,希望将其单独拉到另外一台服务器上,又不想让研发改动代码.

以前一直以为Mycat只能做水平切分,其实也可以垂直切分,很实用,配置也很简单,因各种原因希望将原来一个MySQL实例中的多个库分布到多个实例中,直接使用Mycat就可以做到,对应用程序来看还是同一个实例,在拆分过程可以通过主从同步实现平滑迁移.

接下来介绍水平切分,水平切分是指将某个表按照某个字段的某种规则来分散到多个表之中,每个表中包含一部分数据.

常用的根据主键或非主键的分片规则：

1、枚举法：

比如数据是按照地区省份来保存的,用户通过多级别划分的,本规则适用于这些特定的场景.

2、求模：

如果分片字段为数字,对分片字段进行十进制/百进制求模运算,数据可以均匀落在各分片内.也见过网友分享的对字符串hash取模,支持存在符号字母的字段的分片.

3、范围约定

对分片字段约定一个范围,比如ID 100001~200000为一个分片,ID 200001~300000为一个分片

4、按日期