从海量数据处理到大数据架构设计思想之-分而治之

微信公众号:[深广大数据Club]

关注可了解更多关于大数据技术的资讯。问题或建议,请公众号留言;

[如果你觉得深广大数据Club对你有帮助,欢迎赞赏][1]

本文主要从海量数据处理到大数据解决方案的架构设计,讨论其中共通的一些解决思路、设计思想 -- 分而治之。

其实生活中这样的例子无处不在,例如让你抗一袋沙子,我一次抗不动,那么我拿个小桶,分开一桶一桶的搬,这其实就是分而治之的思路。具体映射到软件行业可以继续往下看。

海量数据处理的分而治之

所谓海量数据处理,其实很简单,海量,海量,何谓海量,就是数据量太大,所以导致要么是无法在较短时间内迅速解决,要么是数据太大,导致无法一次性装入内存。

那解决办法呢?针对空间,无非就一个办法:大而化小:分而治之/hash映射,你不是说规模太大嘛,那简单啊,就把规模大化为规模小的,各个击破不就完了嘛。

例如:海量日志数据,提取出某日访问百度次数最多的那个IP

把整个大文件映射为1000个小文件,再找出每个小文中出现频率最大的IP(可以采用Hash_map进行频率统计,然后再找出频率最大的几个)及相应的频率。然后再在这1000个最大的IP中,找出那个频率最大的IP,即为所求。

大数据框架设计的分而治之

在大数据框架设计的过程中,框架开发者都会考虑框架的运行环境问题:单机模式,集群模式。

通俗点来讲,单机就是处理装载数据的机器有限(只要考虑cpu,内存,硬盘的数据交互),而集群,服务器有多台,适合分布式处理,并行计算(更多考虑节点和节点间的数据交互)。

另外还会考虑文件的存储问题,怎样的存储结构才能让我们更快,更高效的定位到数据的存放位置,且能够保证数据的不丢失。

以hdfs为例,文件存储以块的形势存储,用户写入一个大于设置的块大小的大文件时,大文件分拆成小文件(按照128m为一个块划分),存储到不同的集群节点中,并加以冗余。

无论文件由大到小进行拆分处理,处理从单节点执行到多节点执行,其实都是一个分而治之的思想

在大数据框架功能设计上,分而治之也是无处不在的。

例如:当一份数据需要写入到多个存储系统中时,或许你会想到flume,通过flume的channel将数据分发到不同的sink,通过sink写入到不同的存储系统中去

kafka中的partition与consumer group:一个topic 可以配置几个partition,produce发送的消息分发到不同的partition中,consumer接受数据的时候是按照group来接受,kafka确保每个partition只能同一个group中的同一个consumer消费,如果想要重复消费,那么需要其他的组来消费。

架构设计的分而治之

从数据端获取数据,然后进行事实/离线计算,将计算结果持久化。

假如数据端无法提供数据直接写入到kafka,那么又该如何对架构进行修改呢?

数据端最终数据会持久化到MySqlDB,那我们从DB端下手,将数据从DB端抽取出来存放到kafka集群中,进而执行接下来的计算工作。

从上图可见,我们将数据读取修改为从mysql binlog的方式去获取数据,采用canal进行binlog日志的获取以及解析。这其实也是一个拆分的思想,从原先的数据端到kafka,拆分成数据端-DB-canal-Kafka,过程虽然变长了,但是业务需求得以满足.

在理想情况下,我们在不清楚业务系统需求的时候,设计出来的架构跟具体业务系统的架构是不吻合的。当业务系统无法提供你所要的需求的时候,从不同的层面去思考,将业务进行拆分,或许会给你不一样的解决方案。

赞赏

如果你觉得到深广大数据Club对你有帮助,欢迎赞赏,有你的支持,我们一定会越来越好!

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180817G0XTCJ00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券