假如重新设计一套大数据系统架构

如何设计大数据架构

最近在反思最近两年来做了什么。突然想到一个问题： 如果由我重新设计一套大数据系统的架构，我该如何设计呢？

具体如何设计估计3天都讲不完。

架构设计对一套系统会产生深远影响，有些影响甚至是不可逆，或者重构成本很高。

今天就重点讲讲需要考量的方方面面吧，具体如何设计日后再谈。

 

采集系统的设计

采集系统做了两年多，实际经验发现数据丢失问题很严重。

字段扩展问题也是个麻烦问题。

时间戳不准确也影响数据质量。

还有间歇漏报数据，

重复数据。

以上都是最近两年来遇到频率比较高的问题，设计一套大数据架构系统一定要提前慎重考虑这些因素。

 

数据仓库的设计

数据仓库，data warehouse也叫DW，其实主要是一个概念。

就像现实中的仓库一样，是一个数据的大集市，分门别类。

 

我认为数据仓库的设计其实根本点在于基础表的设计。

需要采集什么样的表，采集什么字段，采集频率，采集后是否能有效挖掘分析出想要的价值数据。

这些是数据仓库的基础，至于中间表设计，报表的设计，其实从架构上来讲是其次的，因为这些东西很容易重做，代价不高。

 

有个重要的问题是如何通过设计表结构来控制表的数据量。

 

批量计算

批量计算是一个大问题。

我所做的一个项目，单表有时候达到了490亿，常规的手段几乎没法查看，即便用集群分布式计算来查询也要几分钟。太慢了。

即便缩小到100亿规模，也还是很慢，需要30秒左右。

分布式计算其实节点多了也是有瓶颈的。

 

如何控制表的数据量并不是分布式计算中要考虑的，而是在数据仓库的设计时考量。

 

当数据量达到一定规模，上百TB时，分布式计算消耗的资源就很可观了。

这个时候内存溢出，计算缓慢，系统不稳定等等都是要重点考虑的问题。

 

流式计算

有的时候，大数据系统中的流式计算往往很有价值。

因为流式计算几乎不消耗存储空间，时效性很好。

而要想使用流式计算，分布式消息队列是必须的。

用不用消息队列会深刻的影响大数据的系统架构；引入消息队列会大幅增加系统复杂度，增加了pipeline长度，增加了一致性的难度，往往还需要引入一套校验机制。

另外消息队列在高并发时还会有稳定性问题。比如分区混乱，分区不均衡，服务崩溃，消息丢失，消息积压等等。

 

架构师需要权衡，是否有必要仅仅因为需要流式计算就在整个系统的架构的前置环节引入消息队列？

 

流式计算到底是用spark streaming还是flink更好？

 

 

其他因素

除了上述问题，还有很多细节。包括一些协议规范的设计。比如是用http还是tcp，如果用http是用长连接还是短连接。如果是用tcp，使用哪种rpc框架，还是项目或产品中开发一套nio的高并发服务？

hive为什么有时候会崩溃？

HDFS为什么会变慢？

如果HDFS挂掉超过副本数的节点会出现什么问题？

HDFS的权限问题如何管理？

namenode的元数据如何备份和恢复？

hbase的key如何设计，如何充分利用HBase的长处，规避它的短处？

什么时候用ES比较合适？

推荐系统的pipeline如何设计？

什么数据是有价值的，如何挖掘出来？如何做成平台化？

 

今天先到这。有经验的同行也可以交流一下观点？