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

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

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

海量数据处理的分而治之

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

那解决办法呢?针对空间，无非就一个办法：大而化小：分而治之/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，过程虽然变长了，但是业务需求得以满足.

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

关注公众号

架构设计 大数据

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。