前言
上次作者分享了大数据的前序，本次和下次将继续为读者分享大数据方面的拙见。从大数据的定义、发展历程，到大数据VS小数据、大数据通用技术，最后从安全行业大数据的角度，漫谈大数据相关概念及其在应用实践中的一些思考，同时分享大数据在流量分析和日志的简单实践，期望能给读者带来对大数据一个更好的认知和应用。
上次前篇漫谈大数据的定义、发展历程，中篇我们将从大数据VS小数据、以及大数据通用技术简要的介绍对大数据方面的理解。
小数据 VS 大数据
先举个简单例子吧，比如学生成绩管理系统，在不同的情况下这个系统的架构是完全不同的。下面分三种情形讨论：
(1)如果仅仅做一个班级的学生成绩管理，那么最简单的方法是采用一个EXCEL，然后利用一些EXCEL分析的函数等对成绩进行管理、排序、查找和保存等操作。打开EXCEL，把成绩录入即OK，多简单高效，一目了然，用EXCEL也可以导出很多数据分析的报表，一个EXCEL的中高手绝对能搞定这简单的需求。
(2)如果是管理一个学校的成绩呢，那如果还用EXCEL来管理，估计需要很多的EXCEL统计信息。不仅需要的量多，那如果两个班级进行横向比较怎么办?如果按照某科目进行纵向排名怎么办?显然用EXCEL不是最好的解决方案了，就算EXCEL的高手也望尘莫及，那就需要我们学习IT刚刚毕业的小菜鸟四两拨千斤，一个简单的数据库就搞定了。犹记得当年在那个小机房，用着纯平的显示器，拿着上机卡，运用SQL SERVER 2000和Visual C++6.0，灵活应用成绩录入、查询和保存等按钮的学生成绩管理系统，一切搞定!
(3)当然，往往事情没那么简单，永远也没有一切搞定的时候，如果用当前互联网的思维，我们要管理的不仅仅是一个学校的成绩，我们要管理整个省各大高校的成绩，甚至全国各大高校的成绩，如果思维再发散一些，我们要做个系统，不仅仅是管理学生的成绩，我们还想要通过学生平时的作业情况，上课考勤情况，以及学生在社交网络上的所有相关信息以及所喜欢的电影，兴趣爱好等去综合分析预测这个学生本学期的成绩，那怎么办?这里，我们不仅仅简单的存结构化的成绩信息了，数据的来源更加多源，需要分析的数据更加多元化，并且数据量和数据组织形式让SQL SERVER和ORACLE无法存储处理和查询。比如由于数据量太大用ORACLE查询十分钟都无法返回结果。那么，我们需要大数据技术，采取新的数据架构体系来管理分析这些数据，这也是何谓大数据中所谈到的。
这就是所谓的小数据和大数据。小数据(量)，采用传统的关系型数据库处理起来更为简单高效，比如情形1和情形2。大数据(量)，采用传统的数据库无法处理，那只能用大数据的技术架构去分析处理，比如情形3。那是否可以用大数据的技术处理小数据呢，当然可以。但是，不是很好的解决方案。首先，系统越复杂，所要处理的问题越多，不仅仅实现上困难，而且在维护也举步维艰。其次，采用大数据的技术不会带来更好更高效的结果，相反，小数据采用传统的关系型数据库，无论技术还是实现方式更为成熟，数据查询分析的速度更为高效。打蚊子用高射炮浪费资源不说，而且不一定好使，还不如一个打蚊拍来的更为合适。
当然，上面大数据与小数据的讨论主要体现在数据量和处理方式方面，更核心的大数据和小数据有很多内容。《大数据时代》作者维克托•舍恩伯格提出了大数据三原则：要全体不要抽样、要效率不要精确、要相关不要因果。从中可以看出，大数据时代的核心特征是相关性，其特点是全量、多元、数据价值密度低等。而小数据应该指采用调查方法获得的抽样数据或者是结构化的海量数据，通常采用传统的统计分析方法，往往依托数理统计的大数定律，描述抽样理论下样本最终服从中心极限定理的正态分布理论，强调描述性统计学和推断统计学。两者之间的对比可以简略的概括为：大数据重预测、发现、相关、全体、感知;对应的小数据重解释、实证、因果、抽样、精确。从这也可以看出，大数据与小数据没有孰好孰坏，在做好大数据的基础上，能够提取具有鲜明特征，具有高密度价值的小数据，从个体角度量身定做，进行更加精准的个性化推荐和预测，也是极好的。
大数据包含哪些技术?
大数据包含哪些技术呢?引入杨义先老师的最新力作《安全简史》里面的例子，咱们先看看大数据产业和垃圾处理回收产业。
通俗的说，大数据产业，无论从工作原理、原料结构，还是从利润率等方面来看，能够与大数据产业相比拟的，也许只有垃圾处理和废品回收!
废品收购和垃圾收集，算是“数据收集”;将废品和垃圾送往集中处理工场，算是“数据集成”;将废品和垃圾初步分类，算是“数据规约”;将废品和垃圾适当清洁和整理，算是“数据清理”;将破沙发拆成木、铁、皮等原料，算是“数据变换”;认真分析如何将这些原料卖个好价值，算是“数据挖掘”;不断总结经验，选择并固定上下游卖家和买家，算是“模式评估”;把这些技巧整理成口诀，算是“知识表示”!
再看原料结构。与大数据的异构特性一样，生活垃圾、工作垃圾、建筑垃圾、可回收垃圾和不可回收垃圾等，无论从外形、质地，还是从内涵等方面来看，也都是完全不同的。与大数据一样，垃圾的数量也很多，产生的速度也很快，处理起来也很困难。
最后来看利润率。确实有人曾在纽约路边的垃圾袋里，一分钱不花就捡到了价值百万美元的，墨西哥著名画家鲁菲诺·塔马约的代表作《三人行》。而从废品中掏出宝贝，更是家常便饭。即使不考虑这些“天上掉下来的馅饼”，就算将收购的易拉罐转手卖掉，也胜过铝矿利润率;将旧家具拆成木材和皮料，其利润率也远远高于木材商和皮货商;总之，只要垃圾专家们愿意认真分捡，那么，他们的利润率可以超过任何相关行业。与垃圾专家一样，大数据专家也能将数据(废品)中挖掘出的旅客出行规律卖给航空公司，将某群体的消费习惯卖给百货商店，将网络舆情卖给相关的需求方等等，总之，大数据专家完全可以“一菜多吃”，反复卖钱，不断“冶金”，而且一次更比一次赚钱，时间越久，价值越大。
言归正传，和传统数据处理类似，大数据技术主要包括：数据采集、数据传输、数据存储、数据查询、数据分析和数据可视化。只是，由于数据量以及数据的多源异构，每一个都是一个非常复杂的系统，比如说从一个位置向另外一个位置进一步传输数据的数据是比较简单的，但对大量数据就是非常复杂的问题了，这些都需要非常先进的技术才能够解决。比如怎么保证海量数据的传输速度?怎么保证海量数据的不丢失?怎么保证不同的模型所选取数据全集中所需要的子集?怎么保证数据产生源产生的海量数据毫无压力的全部存储到磁盘或者文件系统?这些都是大数据技术中需要解决的问题。那么问题来了，当前大数据包含哪些技术，每种技术有哪些相应的解决方案?
这个问题的回答就没有那么容易了，一两句话也讨论不清楚。借用QCon 2016(QCon是由InfoQ主办的全球顶级技术盛会)分享的内容，这里以偏盖全大概介绍一下。
对数据的管理和查询分析大概包括这些步骤，数据的传输，数据的处理，数据的存储和数据的查询，每个过程包括不同的组件去实现各自的功能。
(1)数据传输
在数据传输领域可以说通用的标准式的组件有Kafka(由Apache软件基金会开发的一个开源流处理平台)。目前我们做大数据安全分析平台的数据传输也是kafka。它提供了资源的分区，把生产数据和消费数据直接分开，现在这个架构是根据分布式逻辑来进行的，你可以从分布式逻辑上来收集数据，这是一个非常好的描述数据的一个方式。
此外，MQ(Message Queue消息队列，用于上下游传递消息)也是提取数据的系统，它和Kafka不完全一样，这两个架构有些不同，不同的架构，不同的结构可以产生不同范围，不同规模的表现性能，以提升不同的操作性能。
(2)数据处理
数据处理又分为离线处理、在线处理、流式处理。这里仅简单的对比一下基于文件系统、基于内存和流式处理三种方式。
如图所示，第一种是类似于MapReduce的基于Hadoop的批处理技术，他主要通过磁盘和网络移动数据，每次数据处理之后的结果存入磁盘。这种处理方式有很大的局限性，因为要磁盘读取，并通过网络传输，处理速度就相对来慢，比较适合于离线的批处理。
第二种方式是在最近几年当中非常流行的Spark的工作方式就是考虑你的处理过程，将它想象成一个过程或者一个舞台，Spark做的就是非常有效地利用内存，每一个计算过程都会输出一个结果，Spark会把这些结果做一个统计，这种工作的方法是迭代式的，而且是非常高效的迭代式。Spark会把所有的数据都进行统一的整理，而且Spark比Hadoop的API更加有优势，同时Spark的MLIB集成了大部分机器学习的算法，迭代式的内存处理也非常适合算法的多次迭代求解。所以在过去几年当中，Spark几乎慢慢地变成了批处理的标配。
第三种方式是以Storm、Spark Streaming为主的流式处理框架。Hadoop的高吞吐，海量数据处理的能力使得人们可以方便地处理海量数据。但是，Hadoop不擅长实时计算，因为它天然就是为批处理而生的。举个搜索场景中的例子，当一个卖家发布了一条宝贝信息时，他希望的当然是这个宝贝马上就可以被卖家搜索出来、点击、购买啦，相反，如果这个宝贝要等到第二天或者更久才可以被搜出来，估计这个大哥就要骂娘了。这是因为后台系统做的是每天一次的全量处理，而且大多是在夜深人静之时做的，那么你今天白天做的事情当然要明天才能反映出来啦。而Storm令持续不断的流计算变得容易，弥补了Hadoop批处理所不能满足的实时要求。Storm经常用于在实时分析、在线机器学习、持续计算、分布式远程调用和ETL(Extract-Transform-Load，用来描述将数据从来源端经过抽取(Extract)、交互转换(Transform)、加载(Load)至目的端的过程。)等领域。
(3)数据存储
数据存储这里简单介绍基于Hadoop的技术扩展和封装，围绕Hadoop衍生出相关的大数据技术，应对传统关系型数据库较难处理的数据和场景，例如针对非结构化数据的存储和计算等，充分利用Hadoop开源的优势，伴随相关技术的不断进步，其应用场景也将逐步扩大，目前最为典型的应用场景就是通过扩展和封装Hadoop来实现对互联网大数据存储、分析的支撑。这里面有几十种NoSQL技术，也在进一步的细分。对于非结构、半结构化数据处理、复杂的ETL流程、复杂的数据挖掘和计算模型，Hadoop平台更擅长。
(4)数据查询
SQL on Hadoop：很多SQL on Hadoop都支持SQL查询的功能，SQL可以帮助你非常便捷得到想得到的数据。但是缺点是处理速度非常慢，因为中间涉及到一些过程要从HDFS提取数据，处理数据，然后再放到存储器当中。这样就会非常慢，如果需要快速反应的话，这种小的延迟期的操作还需要进一步的提升。所以我们就需要进一步提高优化存储。
Key/Value Stores：另一种加速查询速度的方法就是要把资料库进行优化，这样就能够打造一种非常快速的查询的架构。它可以支持非常快速的查找，也可以进行快速的写入，我们有很多时间序列的数据库都有键值存储。
Column stores：你可以存储并且扫描你的数据，然后把这些数据进行列存储，根据查询的关键字，电脑可以快速查询各个列，这样的话你就可以在不同的列当中创造不同的关键字，以及指标。这是性能查询方面非常大的进步。
当然，这里说的仅仅是带入大家简单的了解大数据处理的四项(大数据传输、处理、存储、查询)技术的基本概念，目的是让大家对大数据技术不再那么陌生，但是这些如开始所说仅仅是一些基础的需要，是一个以偏概全的概念，其中包含很多的开源框架去实现你的诉求，包含很多其他的问题需要去解决，比如：大数据的集群是怎么管理的?多源异构的数据接入进来用什么数据接入引擎，怎么保证多源异构的数据进行数据标准化的存储，以便进一步的数据融合?大数据处理中的任务怎么调度?大数据平台对外如何快速的进行可视化分析和研究?大数据平台的体系安全性怎么保证，不仅包括数据的安全，还包括平台的安全…….太多的问题，而且每个问题其实也可以作为一个课题或者一个方向进行深入的研究。
一个实用性能优异的大数据平台需要在实践中慢慢完善，迭代开发而成，并且要结合具体的业务场景建立相应的场景大数据解决方案，搭建适合自己的大数据分析平台，后续我们将从流量分析和日志分析上进行具体举例说明，敬请期待下周的终篇。
【本文为51CTO专栏作者“中国保密协会科学技术分会”原创稿件，转载请联系原作者】
