大数据的一点感悟

     年初过来，公司决定搞大数据，大数据越来越流行，必须跟上时代的脚步，大数据开源软件都是在Linux安装，我们选择了开源的Centos系统。正式环境10台以上的机器进行负载均衡。  

     主体思路和业务逻辑，不算太复杂，但是难度系数是层级递增，如果公司没有对应的java人才，需要招聘java人才；如果公司没有对应的实施，需要招聘大数据实施；如果现场实施玩不转，需要公司大量出差和现场支援。同时，上大数据对硬件的需求也比较大，虚拟系统不实用，出现问题，要排查的细节比较多，虽然现在大数据很流行，如果从成本的角度，确实需要考虑很多。

      从实用的角度，如果数据达到一个量级，目前还不知道这个量级是多大，目前能感受到的优势是分布式存储确实速度和数据的备份、数据的流转确实快了很多，但是读取操作速度没有感受到特别的提升。

     我们回到最初的目标上，随着现代人数据量的大批量增加，需要进行大量数据存储、分析和调阅。

      如何提升数据的存储速度，肯定多端口多机器一起执行比一个人比较快。比如一个人一天的活分给多个人干，从理论基础砍，肯定比一个人干快，但是你不能保证其中有没有人偷懒，如果有一个人不能保证工作进度，进行拖延，可能还没一个人干得快。你肯定会反驳人会偷懒机器不会偷懒，但是机器会故障，可能出现网络或硬件或软件方面得故障，故障了就等于罢工了。现在网络环境越来越复杂，我想这也是为什么数据库上云的原因，不能只针对一个机器的防护，需要进行整个体系的安全防护，从网络、硬件、软件多层级防护。不上云是否可行，是可行的，但是投入和收入比可能不成正比，私人公司如果在这块能够做得很好，也就可以开展云端业务，但是这块是可以看见得的，投入巨大。回到正题，我们把资源分给每个机器进行工作，可能需要有个管理者，就像一个部门一样，每天、每个小时、随时领导都需要知道你部门的情况，这就要求管理源(master)将资源分配给机器执行时，同步监控他们得响应情况和结果，还要保持各人之间的因果结果能够交叉进行，业务保持一致性等，管理源操心的事情太多了，这时候对管理源会变成整个系统的一个瓶颈，我们能否将部门细分，部门领导---组---组员，这样分的话，部门领导只需要监控各组长，组长监控组员就像，但是这要求组与组之间耦合性降到最低，才能提升性能，打个比方，组A经常需要组B的数据才能出得出结果，这样组B和部门领导需要经常协调资源，出现瓶颈。这也是为什么会出现微服务的原因，将系统中的功能细分给每个组，每个组将结果汇总到部门领导，打个现实中的比分：比如看病，肚子疼，先有个急诊或其他科室，先定位，定位到胃把你分到胃科，定位到具体哪个科把你分到哪个科，如果不能定位就对他进行会诊，这也类似我们系统中的耦合关系，数据入口在A，A先看是否是我这边的业务，不是的告诉master，master根据A的分析结果分配给B或C，如果这个业务比较大，可能都有涉及，这时多个分组或西医会诊就没有中医好了，中医不是细节而是从整体分析，然后业务都被划分成一个组一个组，从业务角度分析如何整体分析呢？这时候就需要一个架构团队或业务团队，对这个问题进行整体过滤，这个问题，A、B、C分别能处理哪些，有人说master不就能管？那你对master的要求也太高了，要求他能管理、能架构、能懂业务，人的精力是有限的，机器的资源也是有限的，他无法处理这么多的事情。

       任何一个新技术的出现必然有它得道理，技术的创新，是为了解决问题，但一个技术不可能解决所有问题。