专业 靠谱 的软件外包伙伴

您的位置:首页 > 新闻动态 > 数据分析密集型软件系开发统架构设计案例!

数据分析密集型软件系开发统架构设计案例!

2016-05-24 11:50:23

数据密集型系统架构设计

按照使用的资源类型划分,我们可以把系统分为三大类型:IO密集型、计算密集型,数据密集型。系统的类型反映了系统的主要瓶颈。现实情况中,大部分系统在由小变大的过程中,最先出现瓶颈的是IO。IO问题体现在两个方面:高并发,存储介质的读写(例如数据库,磁盘等)。随着业务逻辑的复杂化,接下来出现瓶颈的是计算,也就是常说的CPU idle不足。出现计算瓶颈的时候,一般会使用水平扩展(加机器)和垂直扩张(服务拆分)两个方法。随着数据量(用户数量,客户数量)的增长,再接下来出现瓶颈的是内存。

如今,内存的合理使用比以往更加重要。一方面,大数据理论已经非常普及,用数据驱动产品也已经被普遍接受并落地,同时数据分析也促使产品设计的更加精细,因此系统承载的数量比以前有了很大的变化,系统遇到内存瓶颈的时间也比以前大大缩短了。另一方面,内存依然是相对昂贵的硬件,不能无限制的使用。即使在Amazon等云服务上,大内存的实例也是很昂贵的,并且大内存的实例往往伴随着高性能型CPU,这对一些数据密集型系统是一个浪费。因此,本文重点探讨数据密集系统如何应对出现的瓶颈。

1. 拆库

任何工程上的问题最基本的思路都是“分而治之”。因此,当内存不够时,很自然的想法是将数据拆分到多台机器中,俗称拆库。沿用数据库拆分的术语,拆库又分为“水平拆分”和“垂直拆分”两个派别。

1.1 水平拆分

水平拆分是指将同一种数据的不同记录进行拆分。

例如我们有一亿条商品数据供查询。如果单机无法存储,可以使用四台机器,每台机器存储2500万条商品数据。其中,每台机器称为一个“分片”,同一个分片的多台机器组成一个“分组”,从四个分组各选出一台机器组成一个完整的服务。当上游服务进行查询时,同时查询四台机器,并对返回结果做合并。

在使用水平拆分的方案时,需要重点考虑以下问题:

  • 索引服务

如前几篇文章所述,任何大数据量系统中,在启动之前都需要加载索引数据。索引数据一般是预先计算好的,并且以二进制格式持久化的文件。因为服务进行了拆分,每一台机器只需要加载一部分数据,因此需要为每个分组的机器单独计算索引数据,这样减少了系统启动时处理的数据量,加快启动速度。

  • 数据更新

同样,由于每台机器只需要加载一部分数据,那么也只需要处理这部分数据的更新。目前主流的更新数据流都是使用 Mesage Queue 作为传输和持久化系统个,在服务端接收 Message Queue 的数据并持久化到本地,供在线服务定期读取。一般同一类的数据使用一个 Topic 传输,同时 Message Queue 一般都支持 Partition 的机制。即在向 MQ 中发送一条数据时,可以指定将该条数据发送到哪个 Partition;在从 MQ 中读取数据时,可以指定只读取哪些 Partition 的数据。例如上文的例子,存储商品数据的服务器分了四个组,因此可以将传输商品更新数据的 Topic 划分为四个 Partition,每个分组的机器只需要订阅其需要的 Partition 即可。在实际操作中,为了保持未来的扩展性,一般 Partition 的数量都会设置为分组数量的若干倍,例如八个或者十六个,这样在未来数据量进一步增长导致分组个数进一步增加时,不需要修改 MQ 的 Partition 配置。

利用 MQ 这个机制,可以使每台机器只订阅自己需要处理的数据,减少带宽,也减少更新时处理的数据量,避免浪费资源。

  • 服务管理的复杂性

在我们管理上下游机器时,一般会使用以 ZooKeeper 为核心的服务管理系统。即每个服务都注册在 ZooKeeper 中,当上游服务需要访问下游服务时,去 ZooKeeper 中查询可用的下游服务列表,并同时考虑负载均衡等因素,选择最合适的一个下游服务实例。

当一个服务出现分组时,管理的难度会增大。服务管理系统需要确保一个服务的每个分组的实例同样多,并且负载基本保持平衡。另外,当任何一台机器出现 故障导致的宕时,需要启动备用机器。这时,需要判断是哪个分组的机器发生了故障,并启动相关分组的机器实例,重新注册到 ZK 中。

  • 无法拆分的数据

有很多数据是无法拆分的。一方面有些数据是天然不可拆分的,例如各种策略使用的词典;另一方面,有些数据即使可以拆分,但和系统中其他数据的拆分规则不同,那么系统也无法保证所有数据都能被拆分,只能优先拆分主要数据。

1.2 垂直拆分

在传统关系型数据库的设计上,垂直拆分是指将一种数据的不同列进行拆分;在对系统架构的设计上,垂直拆分是只将一个服务的不同计算逻辑拆分为多个服务。在使用垂直拆分的方案时,需要重点考虑以下问题:

  • 增加网络请求次数,增加系统响应时间

如果是对响应时间要求很高的系统,一定会尽可能地避免垂直拆分,例如搜索。而有一些对逻辑确实很复杂,对时间又不太敏感的系统,一般都会优先选择垂直拆分,例如支付。

  • 增加系统复杂度

将服务进行了分层,更加了开发成本,对运维的要求也更高。

  • 数据冗余

有一些数据会被拆分过的多个服务使用,会出现在上下游多个服务中,那么数据的分发、更新都会更加复杂,即浪费资源,又进一步增加了系统的复杂度。因此,在垂直拆分的过程中,一定要尽可能将服务的功能做良好的划分,避免一种数据被多个服务使用的情况。

垂直拆分的方案中,有一种情况可以大幅减少机器数量,即:一部分数据的存在并不是在处理请求的时候被直接使用,其存在是为了维护被处理请求的逻辑直接使用的数据。

一个典型的例子是检索服务中的正排索引。检索服务在查询时,直接使用的是倒排索引,而倒排索引是根据正排索引生成的。正排索引往往有多种数据,当一条数据发生更新时,会影响其他类别的数据。因此,一条数据的更新信息无法被单独处理,在系统的内存中往往同时维护正排索引和倒排索引,导致内存翻倍。这种情况下,如果我们把正排索引独立到一台离线机器中,这台机器维护正排索引的全部数据,当正排索引发生更新时,倒排索引的更新信息,并分发给所有在线机器。那么,在线服务就不需要维护正排索引,能够大幅度减少内存的使用。

1.3 综述

实际情况中,大型系统往往同时使用水平拆分和垂直拆分两种方案。一方面,水平拆分虽然服务内部进行了分组,但对外仍然是单一的服务,因此从业务逻辑上来讲更加简单。另一方面,垂直拆分可以将非常复杂、计算资源有不同需求的业务逻辑进行很好的隔离,方便系统中各业务逻辑可以针对自己的特点进行开发和部署。因此,在选择拆分方案时,要结合系统的主要矛盾以及目前团队成员的技术特点,综合考虑做出选择。

2. 多级存储

俗话说,当上帝为你关上了一扇门,必(可)定(能)为你打开了一扇窗。如果说大数据是上帝为架构师关上的一扇门,那么热点数据就是打开的那扇窗。虽然在现实世界中的数据是海量难以估算的,但幸运的是,有价值或者说值得关注的数据总是少数的。在大型系统中,请永远把二八法则的重要性放在第一位。

一般来说,计算机的存储系统分为三级:CPU Cache,内存,磁盘。这三者的访问速度依次降低(并且是数量级的降低),单位存储的成本也依次降低(也是数量级的降低)。多级存储的基本思想是,按照被访问频率的不同给数据分类,访问频率越高的数据应当放在访问速度越快的存储介质中。

三种系统都使用页式存储的结构,页也是其处理数据的最小单位。由于这个特性,我们一般在编写程序时,尽可能地将连续访问的数据放在内存的相邻位置,以提高CPU Cache的命中率,也就是常说的 locality principle。

随着SSD的出现,对磁盘的使用已经出现了新的方法论。机械磁盘的随机读写速度在10ms左右,不太可能供实时系统使用。而SSD磁盘的随机读写速度在100us左右,对于有些秒级响应的系统来说,已经可以作为实时系统的存储介质。一种典型的情况是系统存在相当数量的冷门数据。系统对于热点数据可以快速地反馈,对于很少被访问的冷门数据可以存储在SSD磁盘中。当冷门数据被访问时,只要latency仍然可以控制在秒级,就可以在保证用户体验只有很少的损害的情况下,大幅减少系统成本。

一种典型的场景是电商的商品信息。经常被访问的商品可能不到商品总量的1%。像淘宝这样规模的电商系统,实际可能比1%还低。

另一种典型的场景是用户评论。无论按评论发表的先后顺序,还是按某种规则计算出的评论的质量度排序,总是前100个左右的评论被经常访问,后面的评论几乎不会被访问到。

另外,回想上文提到的检索服务的案例。正排索引除了可以拆分为单独的服务之外,还可以存储在磁盘中。更新正排索引的时候直接从磁盘读取数据,修改后写会磁盘,同时更新内存的倒排索引。如果使用SSD磁盘,虽然更新的延迟会增长,但也会控制在毫秒级,对于系统完全是可以接受的。要知道,在一条数据到达检索服务之前,都会经过若干次网络传输,由磁盘引起的延迟并不是主要因素。

在使用磁盘作为可以提供实时查询功能的存储介质时,很常见的方案是将磁盘作为二级缓存,将最近访问的数据保存在内存中,当访问的数据不在内存中时,从磁盘读取,并放入内存中。这个方案的假设是,最近被访问的数据很可能在接下来仍然被访问。采用这种方案需要重点注意,防止爬虫或者外部的恶意请求短期内访问大量冷门数据,造成实际的热点数据被换出缓存,导致处理真实请求时有大量的缓存失效。

大数据技术对商业效果的提升已经在越来越多的行业中被证明,未来的服务,无论是在线还是离线,处理的数据都会有数量级甚至几个数量级的增长。同时,我们看到内存除了访问速度越来越快,在存储的数据量和成本上并没有太大的变化。因此,未来越来越多的系统的主要瓶颈会从计算、IO转移到数据量上,内存密集型系统会变得越来越重要,相信其架构在未来几年也会有很多新的方式出现。

 

关于:中科研拓

深圳市中科研拓科技有限公司专注提供软件外包、app开发、智能硬件开发、O2O电商平台、手机应用程序、大数据系统、物联网项目等开发外包服务,十年研发经验,上百成功案例,中科院软件外包合作企业。通过IT技术实现创造客户和社会的价值,致力于为用户提供很好的软件解决方案。联系电话400-0316-532,邮箱sales@zhongkerd.com,网址www.zhongkerd.com


  上一篇   [返回首页] [打印] [返回上页]   下一篇