如果您的Hadoop项目将有新的突破，那么它必定与下边介绍的七种常见项目很相像。有一句古老的格言是这样说的，如果你向某人提供你的全部支持和金融支持去做一些不同的和创新的事情，他们最终却会做别人正在做的事情。如比较火爆的Hadoop、Spark和Storm，每个人都认为他们正在做一些与这些新的大数据技术相关的事情，但它不需要很长的时间遇到相同的模式。具体的实施可能有所不同，但根据我的经验，它们是最常见的七种项目。

项目一：数据整合

称之为“企业级数据中心”或“数据湖”，这个想法是你有不同的数据源，你想对它们进行数据分析。这类项目包括从所有来源获得数据源(实时或批处理)并且把它们存储在hadoop中。有时，这是成为一个“数据驱动的公司”的第一步;有时，或许你仅仅需要一份漂亮的报告。“企业级数据中心”通常由HDFS文件系统和HIVE或IMPALA中的表组成。未来，HBase和Phoenix在大数据整合方面将大展拳脚，打开一个新的局面，创建出全新的数据美丽新世界。

销售人员喜欢说“读模式”，但事实上，要取得成功，你必须清楚的了解自己的用例将是什么(Hive模式不会看起来与你在企业数据仓库中所做的不一样)。真实的原因是一个数据湖比Teradata和Netezza公司有更强的水平扩展性和低得多的成本。许多人在做前端分析时使用Tabelu和Excel。许多复杂的公司以“数据科学家”用Zeppelin或IPython笔记本作为前端。

项目二：专业分析

许多数据整合项目实际上是从你特殊的需求和某一数据集系统的分析开始的。这些往往是令人难以置信的特定领域，如在银行领域的流动性风险/蒙特卡罗模拟分析。在过去，这种专业的分析依赖于过时的，专有的软件包，无法扩大数据的规模经常遭受一个有限的功能集(大部分是因为软件厂商不可能像专业机构那样了解的那么多)。

在Hadoop和Spark的世界，看看这些系统大致相同的数据整合系统，但往往有更多的HBase，定制非SQL代码，和更少的数据来源(如果不是唯一的)。他们越来越多地以Spark为基础。

项目三：Hadoop作为一种服务

在“专业分析”项目的任何大型组织(讽刺的是，一个或两个“数据整理”项目)他们会不可避免地开始感觉“快乐”(即，疼痛)管理几个不同配置的Hadoop集群，有时从不同的供应商。接下来，他们会说，“也许我们应该整合这些资源池，”而不是大部分时间让大部分节点处于资源闲置状态。它们应该组成云计算，但许多公司经常会因为安全的原因(内部政治和工作保护)不能或不会。这通常意味着很多Docker容器包。

我没有使用它，但最近Bluedata(蓝色数据国际中心)似乎有一个解决方案，这也会吸引小企业缺乏足够的资金来部署Hadoop作为一种服务。

项目四：流分析

很多人会把这个“流”，但流分析是不同的，从设备流。通常，流分析是一个组织在批处理中的实时版本。以反洗钱和欺诈检测：为什么不在交易的基础上，抓住它发生而不是在一个周期结束?同样的库存管理或其他任何。

在某些情况下，这是一种新的类型的交易系统，分析数据位的位，因为你将它并联到一个分析系统中。这些系统证明自己如Spark或Storm与Hbase作为常用的数据存储。请注意，流分析并不能取代所有形式的分析，对某些你从未考虑过的事情而言，你仍然希望分析历史趋势或看过去的数据。

项目五：复杂事件处理

在这里，我们谈论的是亚秒级的实时事件处理。虽然还没有足够快的超低延迟(皮秒或纳秒)的应用，如高端的交易系统，你可以期待毫秒响应时间。例子包括对事物或事件的互联网电信运营商处理的呼叫数据记录的实时评价。有时，你会看到这样的系统使用Spark和HBase——但他们一般落在他们的脸上，必须转换成Storm，这是基于由LMAX交易所开发的干扰模式。

在过去，这样的系统已经基于定制的消息或高性能，从货架上，客户端-服务器消息产品-但今天的数据量太多了。我还没有使用它，但Apex项目看起来很有前途，声称要比Storm快。

有时你想捕捉流数据并把它们存储起来。这些项目通常与1号或2号重合，但增加了各自的范围和特点。(有些人认为他们是4号或5号，但他们实际上是在向磁盘倾倒和分析数据。)，这些几乎都是Kafka和Storm项目。Spark也使用，但没有理由，因为你不需要在内存分析。

SAS是精细，是好的但SAS也很贵，我们不需要为你的数据科学家和分析师买存储你就可以“玩”数据。此外，除SAS可以做或产生漂亮的图形分析外，你还可以做一些不同的事情。这是你的“数据湖”。这里是IPython笔记本(现在)和Zeppelin(以后)。我们用SAS存储结果。

当我每天看到其他不同类型的Hadoop，Spark，或Storm项目，这些都是正常的。如果你使用Hadoop，你可能了解它们。几年前我已经实施了这些项目中的部分案例，使用的是其它技术。

如果你是一个老前辈太害怕“大”或“做”大数据Hadoop，不要担心。事情越变越多，但本质保持不变。你会发现很多相似之处的东西你用来部署和时髦的技术都是围绕Hadooposphere旋转的。

从菜鸟到架构师，不仅需要的是时间的磨练，更需要的是机会和平台。对于大数据技术的应用，不管是传统行业还是互联网行业，已经开始大范围的应用。很多人也轰轰烈烈的加入到大数据技术学习的行列中来，但大多数是三分钟热情高涨但又无法坚持到底。原因不是不想学，而是太复杂，坑太多。

对于接触过大数据技术的人应该比较清楚，大数据技术框架都是开源的，一个项目的完成需要众多技术的整合，包括安装、部署、开发、集成等。开源的也就免费，免费的东西有好的一方面，也有不好的一方面，好的一面就是企业应用不用花钱，尽管用。不好的一面也是学习者都感同身受，比较苦恼，就是坑太多，不是这个版本有bug，就是那个版本不兼容。在企业应用中对框架补漏修改是常有的事。也正因为这个，成就了行业很多的技术高手。当然，这也是为啥大数据人才稀缺并且薪水高的原因。

所以本篇我们为大家分享一套完整的大数据项目架构设计与实施方案，也是希望有基础的学习者能通过这个课程，一点画面，系统的学习，并且能彻彻底底的感受学习大数据技术所带来的成就感。体验自己如何根据零碎的基础知识能快速的架构设计大数据项目，并且完整的得以实施。

先来谈谈我们的需求，我们要对某新闻网做用户行为分析，需要达到以下几个要求：

实时捕获用户浏览日志信息并且存储（TB级别）实时分析前20名流量最高的新闻话题实时统计当前线上已曝光的新闻话题量离线分析统计哪个时段用户浏览量最高报表对外发布数据

针对以上的需求，如果是你该如何架构设计满足用户需求的系统呢？

先来看看卡弗卡大数据对以上需求实现的需求结果：

以上图描述的很清晰，基本完成了我们三个需求。接下来就是我们要分享的核心：系统架构设计。这个是非常重要的，他是在你完全熟练掌握技术基础之上，根据业务需求的理解而进行的设计工作。我们来看第一张图：

系统架构设计

架构设计中的所有技术框架在我们的系统实施过程中都得到了应用，当然，如何没用，我们也不会放在架构图中。哈哈。如果你能看懂这张图，那得恭喜你，你快入行了，如果看不懂，那说明你还只是个菜鸟，继续努力吧。

系统数据流程设计

在需求中我们提的很明确，有三个要点：第一是数据实时获取并存储；第二是数据实时在线分析；第三数据批量离线分析。所以在流程图上会有两个不同颜色的流程分支，一个是代表实时数据处理，一个是代表离线批量数据处理。如果你想学点什么，你应该会仔细的看这张图，因为图上的每一个标识，不管图标大小所描述的都是核心，都是重点。切记！

集群服务节点规划

大数据项目，玩的都是集群。没有一个企业会在单节点机器上玩大数据应用。除非你自己学习之用。上图是我们对此系统的服务节点规划，一个机器上放什么节点服务，这都是有原因的。不是你想放什么节点就放什么节点。所以架构设计中的机器规划部署也是非常重要的，在业务需求的基础上要做好资源的合理规划，包括扩展性和稳定性。

说了这么多，该如何实施呢？

一个完整项目的全流程实施，从架构设计、技术选型、环境配置、安装部署、研发、整合集成、数据可视化交互等各个方面所要求的知识点很多，如果是新手或者初学者，不是几篇文章能说的清楚的，也不是一朝一夕你能的搞明白的。当然这不是个人能力的问题，而是大数据技术框架本身的坑很多，如果没有系统完整案例的指导，你可能得自己一个一个的去填坑才有可能到达你想要的结果。我说的一点也不严重，不信你可以去试试，呵呵。

如果你想尽快的掌握一个完整的大数据项目架构与实施，请参加我们的线上直播课，没有别的，只是让我们的经验有价值的得到分享。

1.前言

计算机的基本工作就是处理数据，包括磁盘文件中的数据，通过网络传输的数据流或数据包，数据库中的结构化数据等。随着互联网、物联网等技术得到越来越广泛的应用，数据规模不断增加，TB、PB量级成为常态，对数据的处理已无法由单台计算机完成，而只能由多台机器共同承担计算任务。而在分布式环境中进行大数据处理，除了与存储系统打交道外，还涉及计算任务的分工，计算负荷的分配，计算机之间的数据迁移等工作，并且要考虑计算机或网络发生故障时的数据安全，情况要复杂得多。

举一个简单的例子，假设我们要从销售记录中统计各种商品销售额。在单机环境中，我们只需把销售记录扫描一遍，对各商品的销售额进行累加即可。如果销售记录存放在关系数据库中，则更省事，执行一个SQL语句就可以了。现在假定销售记录实在太多，需要设计出由多台计算机来统计销售额的方案。为保证计算的正确、可靠、高效及方便，这个方案需要考虑下列问题：

如何为每台机器分配任务，是先按商品种类对销售记录分组，不同机器处理不同商品种类的销售记录，还是随机向各台机器分发一部分销售记录进行统计，最后把各台机器的统计结果按商品种类合并？上述两种方式都涉及数据的排序问题，应选择哪种排序算法？应该在哪台机器上执行排序过程？如何定义每台机器处理的数据从哪里来，处理结果到哪里去？数据是主动发送，还是接收方申请时才发送？如果是主动发送，接收方处理不过来怎么办？如果是申请时才发送，那发送方应该保存数据多久？会不会任务分配不均，有的机器很快就处理完了，有的机器一直忙着？甚至，闲着的机器需要等忙着的机器处理完后才能开始执行？如果增加一台机器，它能不能减轻其他机器的负荷，从而缩短任务执行时间？如果一台机器挂了，它没有完成的任务该交给谁？会不会遗漏统计或重复统计？统计过程中，机器之间如何协调，是否需要专门的一台机器指挥调度其他机器？如果这台机器挂了呢？（可选）如果销售记录在源源不断地增加，统计还没执行完新记录又来了，如何保证统计结果的准确性？能不能保证结果是实时更新的？再次统计时能不能避免大量重复计算？（可选）能不能让用户执行一句SQL就可以得到结果？

上述问题中，除了第1个外，其余的都与具体任务无关，在其他分布式计算的场合也会遇到，而且解决起来都相当棘手。即使第1个问题中的分组、统计，在很多数据处理场合也会涉及，只是具体方式不同。如果能把这些问题的解决方案封装到一个计算框架中，则可大大简化这类应用程序的开发。

2004年前后，Google先后发表三篇论文分别介绍分布式文件系统GFS、并行计算模型MapReduce、非关系数据存储系统BigTable，第一次提出了针对大数据分布式处理的可重用方案。在Google论文的启发下，Yahoo的工程师Doug Cutting和Mike Cafarella开发了Hadoop。在借鉴和改进Hadoop的基础上，又先后诞生了数十种应用于分布式环境的大数据计算框架。本文在参考业界惯例的基础上，对这些框架按下列标准分类：

如果不涉及上面提出的第8、9两个问题，则属于批处理框架。批处理框架重点关心数据处理的吞吐量，又可分为非迭代式和迭代式两类，迭代式包括DAG（有向无环图）、图计算等模型。若针对第8个问题提出来应对方案，则分两种情况：如果重点关心处理的实时性，则属于流计算框架；如果侧重于避免重复计算，则属于增量计算框架。如果重点关注的是第9个问题，则属于交互式分析框架。

本文下面分别讨论批处理、流计算、交互式分析三种类别的框架，然后简要介绍大数据计算框架的一些发展趋势。文章最后介绍这一领域的学习资料。

图1.大数据计算框架全景图2.批处理框架

2.1.Hadoop

Hadoop最初主要包含分布式文件系统HDFS和计算框架MapReduce两部分，是从Nutch中独立出来的项目。在2.0版本中，又把资源管理和任务调度功能从MapReduce中剥离形成YARN，使其他框架也可以像MapReduce那样运行在Hadoop之上。与之前的分布式计算框架相比，Hadoop隐藏了很多繁琐的细节，如容错、负载均衡等，更便于使用。

Hadoop也具有很强的横向扩展能力，可以很容易地把新计算机接入到集群中参与计算。在开源社区的支持下，Hadoop不断发展完善，并集成了众多优秀的产品如非关系数据库HBase、数据仓库Hive、数据处理工具Sqoop、机器学习算法库Mahout、一致性服务软件ZooKeeper、管理工具Ambari等，形成了相对完整的生态圈和分布式计算事实上的标准。

图2.Hadoop生态圈（删减版）

MapReduce可以理解为把一堆杂乱无章的数据按照某种特征归并起来，然后处理并得到最后的结果。基本处理步骤如下：

把输入文件按照一定的标准分片，每个分片对应一个map任务。一般情况下，MapReduce和HDFS运行在同一组计算机上，也就是说，每台计算机同时承担存储和计算任务，因此分片通常不涉及计算机之间的数据复制。按照一定的规则把分片中的内容解析成键值对。通常选择一种预定义的规则即可。

执行map任务，处理每个键值对，输出零个或多个键值对。

MapReduce获取应用程序定义的分组方式，并按分组对map任务输出的键值对排序。默认每个键名一组。

待所有节点都执行完上述步骤后，MapReduce启动Reduce任务。每个分组对应一个Reduce任务。

执行reduce任务的进程通过网络获取指定组的所有键值对。

把键名相同的值合并为列表。

执行reduce任务，处理每个键对应的列表，输出结果。

图3.MapReduce处理过程

在上面的步骤中，应用程序主要负责设计map和reduce任务，其他工作均由框架负责。在定义map任务输出数据的方式时，键的选择至关重要，除了影响结果的正确性外，也决定数据如何分组、排序、传输，以及执行reduce任务的计算机如何分工。前面提到的商品销售统计的例子，可选择商品种类为键。MapReduce执行商品销售统计的过程大致如下：

把销售记录分片，分配给多台机器。每条销售记录被解析成键值对，其中值为销售记录的内容，键可忽略。

执行map任务，每条销售记录被转换为新的键值对，其中键为商品种类，值为该条记录中商品的销售额。

MapReduce把map任务生成的数据按商品种类排序。

待所有节点都完成排序后，MapReduce启动reduce任务。每个商品种类对应一个reduce任务。

执行reduce任务的进程通过网络获取指定商品种类的各次销售额。

MapReduce把同一种商品下的各次销售额合并到列表中。

执行reduce任务，累加各次销售额，得到该种商品的总销售额。

上面的过程还有优化的空间。在传输各种商品每次的销售额数据前，可先在map端对各种商品的销售额进行小计，由此可大大减少网络传输的负荷。MapReduce通过一个可选的combine任务支持该类型的优化。

2.2.DAG模型

现在假设我们的目标更进一步，希望知道销售得最好的前10种商品。我们可以分两个环节来计算：

统计各种商品的销售额。通过MapReduce实现，这在前面已经讨论过。对商品种类按销售额排名。可以通过一个排序过程完成。假定商品种类非常多，需要通过多台计算机来加快计算速度的话，我们可以用另一个MapReduce过程来实现，其基本思路是把map和reduce分别当作小组赛和决赛，先计算各分片的前10名，汇总后再计算总排行榜的前10名。

从上面的例子可以看出，通过多个MapReduce的组合，可以表达复杂的计算问题。不过，组合过程需要人工设计，比较麻烦。另外，每个阶段都需要所有的计算机同步，影响了执行效率。

为克服上述问题，业界提出了DAG（有向无环图）计算模型，其核心思想是把任务在内部分解为若干存在先后顺序的子任务，由此可更灵活地表达各种复杂的依赖关系。Microsoft Dryad、Google FlumeJava、Apache Tez是最早出现的DAG模型。Dryad定义了串接、全连接、融合等若干简单的DAG模型，通过组合这些简单结构来描述复杂的任务，FlumeJava、Tez则通过组合若干MapReduce形成DAG任务。

图4.MapReduce（左）与Tez（右）执行复杂任务时对比

MapReduce的另一个不足之处是使用磁盘存储中间结果，严重影响了系统的性能，这在机器学习等需要迭代计算的场合更为明显。加州大学伯克利分校AMP实验室开发的Spark克服了上述问题。Spark对早期的DAG模型作了改进，提出了基于内存的分布式存储抽象模型RDD（Resilient Distributed Datasets，可恢复分布式数据集），把中间数据有选择地加载并驻留到内存中，减少磁盘IO开销。与Hadoop相比，Spark基于内存的运算要快100倍以上，基于磁盘的运算也要快10倍以上。

图5.MapReduce与Spark中间结果保存方式对比

Spark为RDD提供了丰富的操作方法，其中map、 filter、 flatMap、 sample、groupByKey、 reduceByKey、union、join、cogroup、mapValues、sort、partionBy用于执行数据转换，生成新的RDD，而count、collect、 reduce、lookup、save用于收集或输出计算结果。如前面统计商品销售额的例子，在Spark中只需要调用map和reduceByKey两个转换操作就可以实现，整个程序包括加载销售记录和保存统计结果在内也只需要寥寥几行代码，并且支持Java、Scala、Python、R等多种开发语言，比MapReduce编程要方便得多。下图说明reduceByKey的内部实现。

图6.RDD reduceByKey内部实现

RDD由于把数据存放在内存中而不是磁盘上，因此需要比Hadoop更多地考虑容错问题。分布式数据集的容错有两种方式：数据检查点和记录数据的更新。处理海量数据时，数据检查点操作成本很高，因此Spark默认选择记录更新的方式。不过如果更新粒度太细太多，记录更新成本也不低。因此，RDD只支持粗粒度转换，即只记录单个块上执行的单个操作，然后将创建RDD的一系列变换序列记录下来，类似于数据库中的日志。

当RDD的部分分区数据丢失时，Spark根据之前记录的演变过程重新运算，恢复丢失的数据分区。Spark生态圈的另一项目Alluxio（原名Tachyon）也采用类似的思路，使数据写入速度比HDFS有数量级的提升。

下面总结Spark对MapReduce的改进：

MapReduce抽象层次低，需要手工编写代码完成；Spark基于RDD抽象，使数据处理逻辑的代码非常简短。MapReduce只提供了map和reduce两个操作，表达力欠缺；Spark提供了很多转换和动作，很多关系数据库中常见的操作如JOIN、GROUP BY已经在RDD中实现。MapReduce中，只有map和reduce两个阶段，复杂的计算需要大量的组合，并且由开发者自己定义组合方式；Spark中，RDD可以连续执行多个转换操作，如果这些操作对应的RDD分区不变的话，还可以放在同一个任务中执行。MapReduce处理逻辑隐藏在代码中，不直观；Spark代码不包含操作细节，逻辑更清晰。MapReduce中间结果放在HDFS中；Spark中间结果放在内存中，内存放不下时才写入本地磁盘而不是HDFS，这显著提高了性能，特别是在迭代式数据处理的场合。MapReduce中，reduce任务需要等待所有map任务完成后才可以开始；在Spark中，分区相同的转换构成流水线放到同一个任务中运行。3.流计算框架

3.1.流计算概述

在大数据时代，数据通常都是持续不断动态产生的。在很多场合，数据需要在非常短的时间内得到处理，并且还要考虑容错、拥塞控制等问题，避免数据遗漏或重复计算。流计算框架则是针对这一类问题的解决方案。流计算框架一般采用DAG（有向无环图）模型。图中的节点分为两类：一类是数据的输入节点，负责与外界交互而向系统提供数据；另一类是数据的计算节点，负责完成某种处理功能如过滤、累加、合并等。从外部系统不断传入的实时数据则流经这些节点，把它们串接起来。如果把数据流比作水的话，输入节点好比是喷头，源源不断地出水，计算节点则相当于水管的转接口。如下图所示。

图7.流计算DAG模型示意图

为提高并发性，每一个计算节点对应的数据处理功能被分配到多个任务（相同或不同计算机上的线程）。在设计DAG时，需要考虑如何把待处理的数据分发到下游计算节点对应的各个任务，这在实时计算中称为分组（Grouping）。最简单的方案是为每个任务复制一份，不过这样效率很低，更好的方式是每个任务处理数据的不同部分。随机分组能达到负载均衡的效果，应优先考虑。不过在执行累加、数据关联等操作时，需要保证同一属性的数据被固定分发到对应的任务，这时应采用定向分组。在某些情况下，还需要自定义分组方案。

图8.流计算分组

由于应用场合的广泛性，目前市面上已经有不少流计算平台，包括Google MillWheel、Twitter Heron和Apache项目Storm、Samza、S4、Flink、Apex、Gearpump。

3.2.Storm及Trident

在流计算框架中，目前人气最高，应用最广泛的要数Storm。这是由于Storm具有简单的编程模型，且支持Java、Ruby、Python等多种开发语言。Storm也具有良好的性能，在多节点集群上每秒可以处理上百万条消息。Storm在容错方面也设计得很优雅。下面介绍Storm确保消息可靠性的思路。

在DAG模型中，确保消息可靠的难点在于，原始数据被当前的计算节点成功处理后，还不能被丢弃，因为它生成的数据仍然可能在后续的计算节点上处理失败，需要由该消�...

自从像AWS这样的公共云产品开辟了大数据分析功能以来，小企业通过挖掘大量的数据做到只有大企业才能做到的事情，至今大约有10年时间。这些事情其中包括网络日志、客户购买记录等，并通过按使需付费的方式提供低成本的商品集群。在这十年中，这些产品蓬勃发展，涵盖了从实时(亚秒级延迟)流媒体式分析到用于分析批量模式工作的企业数据仓库，而企业数据仓库则可能需要数天或数周才能完成。

以下将介绍用于大数据堆栈的五个最有用的架构，以及每个架构的优点，以便更好地理解和权衡。此外，还对成本(按$ - $$$$$的规模)、何时使用、热门产品，以及每种架构的提示和技巧进行了阐述。

五个大数据架构

在此并没有什么特别的顺序，用户在AWS公共云旅程中可能遇到的五个顶级大数据架构是：

流媒体- 允许摄取(并可能分析)任务关键型实时数据，这些数据可能会以爆发的形式出现在用户面前。通用(或特定)的批处理集群—在可扩展、经济高效的集群中提供通用存储和计算功能，可以执行其他四种架构的任何和所有功能。NoSQL引擎 - 使架构师能够处理“3V” —高速度、高容量，以及底层数据的多样性/可变性。企业数据仓库(EDW) - 允许组织为多年的历史数据维护一个单独的数据库，并对该数据运行各种长期运行的分析。就地分析 - 允许用户将数据“就地”保存在低成本存储引擎中，并针对该数据运行高性能的即席查询，而无需创建单独的、昂贵的“集群”。

1. 流媒体

流媒体解决方案由以下多个因素定义：

关键任务数据—即使丢失一笔交易也会给用户带来灾难性的后果。负载中的爆发尖峰——物联网的基础设施可能会从完全无声的状态转变为同时与其通话设备中的一个。实时响应 - 高延迟响应对用户来说可能是灾难性的。

这里有很多现实世界的例子，从特斯拉公司的电动汽车(基本上是移动的4G设备)不断将汽车的位置发送到数据中心，通知司机下一个充电站在哪里。此外，人们喜欢的日本一家高度自动化的寿司专营店：Sushiro。Sushiro所做的是将RFID传感器放在每个寿司盘底，然后，寿司传送带上的传感器跟踪每个盘子的动态，将数据点发送到AWS Kinesis，其后端响应仪表板的更新，通知寿司厨师，例如“丢掉即将过期变质的食物，或者制作更多的鸡蛋寿司，或者解冻更多的金枪鱼”，通过使用流媒体技术，该连锁店不仅有上述的实时效率推荐，而且还可以获得每家餐厅的历史信息，并且可以了解顾客购买的趋势。

Sushiro是一个很好的例子，因为它符合流媒体的所有三个要求。其仪表板现在对业务运营至关重要。

成本：$$ - $$$$$(通常为RAM密集型)适用性：任务关键型数据，负载爆发尖峰，实时响应。用户需要构建KPI的实时仪表板。注意事项：独立的流媒体解决方案的构建和维护成本很高。扩展可能具有挑战性，特别是如果在EC2上构建。失败对企业来说可能是灾难性的，但大多数产品都提供故障保护，例如复制优化、备份和灾难恢复，以避免这种情况。受欢迎的产品：Kinesis(托管服务)，Kafka(基于EC2)，Spark Streaming(作为托管服务和基于EC2)和Storm。提示和技巧：使用Kinesis作为初学者(易于使用、体积小、成本低)。许多组织转向基于EC2的Kafka(如果他们只需要流媒体)或Spark Streaming，以获得更好的控制，并降低大批量成本。这是AWS中为数不多的几次托管任务，像Kinesis这样的托管服务最终会比基于EC2的Kafka解决方案花费更多的费用。

2. 通用(或特定)的批处理集群

使用Hadoop/Spark这些系统，用户可以获得高度可扩展、低成本(商用硬件和开源软件)存储和计算，这些存储和计算可能会遇到大量问题，从而以尽可能低的成本对数据进行批量分析。

Hadoop技术非常成熟，提供了一个非常丰富的软件生态系统，可以利用这些通用计算和存储资源提供从数据仓库到流媒体，甚至NoSQL的所有内容。

在Hadoop之上，现在可以运行Spark，它带有自己的可扩展框架，以低延迟(高内存)方式提供上述所有功能，甚至适用于流媒体和NoSQL。

成本：$ - $$$$(高度依赖于内存需求)适用性：最低成本、最大灵活性。如果希望采用一个集群完成所有任务，并从Hadoop或Spark内部部署转移，那么这是一个不错的选择，非常适合机器学习。注意事项：一个全能的系统很少把每件事都做好，但这可以通过使用Spark和为每个工作量身定制的集群来大大减轻工作负荷。热门产品：EMR(托管服务，也将运行Spark)，Cloudera(基于EC2)，Hortonworks(通过EMR作为托管服务，基于EC2)。提示和技巧：在S3存储桶中长期存储源数据，构建集群，并根据需要将数据加载到集群中，然后在分析任务完成后立即关闭所有数据。这实际上正是默认情况下EMR的工作原理，但即使使用的是Cloudera或Hortonworks(现在功能几乎相同)，也可以轻松编写上述所有内容。利用EC2现场实例可以节省80%-90%的成本，并检查自己的分析，以便可以向上或向下旋转集群。以利用成本最低的spot窗口。

3. NoSQL引擎

Velocity(并发事务)在这里特别重要，这些引擎被设计为处理任意数量的并发读写。虽然其他系统通常不能用于最终用户(需要低延迟响应)和员工分析团队(可能会使用长时间运行的查询锁定多个表)，同时，NoSQL引擎可以扩展以适应一个系统的两个主服务器。一些开发允许以低延迟方式实时加入和查询该数据。

成本：$$ - $$$(通常为内存密集型)适用性：“3V”问题。简单和/或快速变化的数据模型。需要构建KPI的实时仪表板。警告：必须放弃交易和丰富多样的SQL。由于它不使用SQL，因此无法使用Tableau和Microstrategy等可视化工具直接查询数据。扩展(尤其是添加新节点和重新平衡)可能很困难，并且会影响用户延迟和系统可用性。受欢迎的产品：DynamoDB(托管服务)，Neptune(托管服务，目前仍处于测试阶段)，Cassandra(基于EC2)，CouchDB(基于EC2)和HBase(通过EMR作为托管服务，基于EC2)。提示和技巧：努力采用AWS管理的服务DynamoDB，而不是配置EC2并加载第三方系统。定期修剪最终用户DynamoDB表，并在这些历史表上创建每周或每月的表。使用Dynamic DynamoDB“自动调整”配置的容量，使其始终满足消耗。使用DynamoDB Streams可以对客户服务取消等关键事件进行实时响应，或者在第二个区域提供备份。

4. 企业数据仓库(EDW)

企业数据仓库(EDW)与此处提到的其他系统截然不同。它提供了人们称之为“OLAP”(在线分析处理，可以支持来自内部用户的一些长时间运行的查询)与“OLTP”(在线事务处理，可以支持来自最终用户的大量读取和写入)功能，如Oracle的RDBMS或MySQL。当然，可以使用OLTP系统作为企业数据仓库(EDW)，但是大多数人都将OLTP数据库集中在最近用户的低延迟，最近事件(如“跟踪上周的订单”)需求和定期(通常是每天)窗口更旧数据输出到OLAP系统，业务用户可以在数月或数年的数据中运行长时间的查询。

这些OLAP系统使用诸如列式存储、数据非规范化(创建具有几乎无限维度的“数据立方体”)等策略，并提供RDBMS级ANSI 92 SQL依从性，这意味着可以完全访问SQL功能，并且可以定制Tableau等可视化工具直接与他们合作。

成本：$$ - $$$$$(通常需要大量节点来存储和处理大量数据)。适用性：如果希望专门针对业务价值分析数据或构建KPI的实时仪表板。警告：确保团队了解OLAP和OLTP之间的区别，并确保他们以正确的方式使用每个OLAP和OLTP。提示和技巧：与EMR/Hadoop一样，只在需要时启动集群，将源数据保存在S3存储桶中(这实际上是Redshift默认工作的方式)。标记集群，以便用能够以自动方式快速识别和关闭未使用的容量。考虑保留以控制成本。真正了解可用的不同节点类型(高存储、高吞吐量)以便利用每个节点类型。采用本机加密，因为它可以将性能降低多达20%-25%。通过O'Reilly课程深入了解Redshift，或考虑通过出色的“数据仓库”课程进行面对面培训，该课程几乎完全涵盖Redshift。

5. 就地分析

几年前，Presto通过提供高性能的数据分析改变了游戏规则，而无需将数据从原生的、低成本的长期存储中移出。其最终结果是，可以简单地运行查询，而不是必须为昂贵的EMR或Redshift集群支付全部费用。而是只按使用的内容收费。

此外，人们需要很多时间来尝试选择(然后管理)EMR或Redshift集群的正确节点和节点数。采用Presto，人们不再知道也不关心这种差别，而这一切都在用户需要的时候起到作用。

最后，Presto支持RDBMS级别的ANSI-92 SQL兼容性，这意味着所有可视化工具都可以直接使用它，具有的SQL背景可以在ad-hoc查询中全面使用。

费用：$ - $$适用性：成本极低。没有任何管理。可以作为低成本、中等性能的企业数据仓库(EDW)。它不需要将数据复制到第二个系统。大型连接和复杂分析效果很好。警告：需要最低延迟。为了获得不错的性能，可能会使用序列化格式Parquet、压缩、重新分区等重新格式化存储的数据。可能需要多轮查询调整和/或重新格式化才能获得正确的结果。目前不支持UDF或事务。热门产品：AWS Athena(用于查询S3数据的托管服务)，EMR(托管服务-可以自动安装Presto)，自我管理的Presto(基于EC2–用户永远不想在AWS中执行此操作)。提示和技巧：只需使用Athena。利用AWS Glue构建ETL管道，以获取原始数据，并将其重新格式化为S3或Athena可以更有效地使用的内容。使用S3生命周期策略将原有的数据移动到低成本的归档存储(如Glacier)。

把它们放在一起

通过了解将在公共云中运行的五个顶级大数据架构，用户现在可以获得有关最佳应用位置的可操作信息，以及潜伏的位置。

一旦用户开始在AWS公共云中构建大数据架构，将很快了解到更多的架构，并且在很多情况下，企业可能会最终同时使用上述所有内容，可能使用Kinesis将客户数据流媒体传输到DynamoDB和S3。用户可能偶尔会在该源数据上启动EMR(进行某些机器学习)或Redshift(分析KPI)集群，或者可以选择以可以通过AWS Athena就地访问的方式格式化数据，让它像企业数据仓库(EDW)一样发挥作用。

具有执行TMTOWTDI的能力是一件好事，AWS公司努力提供最适合用户需求的服务。如果用户从头开始，在AWS认证的全球知识培训课程中花费三天时间将可以提供满足其需求的服务，并让用户尽快开始运营，并且顺利实施。

作者：Rich Morrow

概述

今天给大家一个福利，私信我可免费获取java资源，Dubbo、Redis、Netty、zookeeper、Spring cloud 等你来领取！！！

一丶大数据协作框架是Hadoop 2.x生态系统中几个辅助框架。最为常见的是以下几个：

数据转换工具Sqoop

文件收集库框架Flume

任务调度框架Oozie

大数据web工具Hue

Flume，抽取系统日志文件进入HDFS。Sqoop，完成关系型数据库和Hdfs的数据抽取。Oozie：ETL作业管理，实现多任务的定时调度和多任务之间的依赖调度。Hue提供了一个web界面，管理大数据框架的所有组件。

由于Hadoop生态框架的不同组件在使用时，可能会出现一些兼容性的问题（不同组件来自于不同的公司，并贡献给Apache基金会），所以在学习Sqoop、Hbase、Oozie等框架如果再使用Apache的原生态版本会出现很多问题。

二丶安装CDH版本hadoop：

选择版本、下载解压安装文件：

首先选取一个CDH版本，下载对应的安装包，我选用5.3.6，根据这个版本选各个组件就可以了。下载地址

下载 XX.tar.gz版本，并下载，解压。

$ tar zxf hadoop-2.5.0-cdh5.3.6.tar.gz -C /opt/modules/$ tar zxf hive-0.13.1-cdh5.3.6.tar.gz -C /opt/modules/$ tar zxf sqoop-1.4.5-cdh5.3.6.tar.gz -C /opt/modules/$ tar zxf zookeeper-3.4.5-cdh5.3.6.tar.gz -C /opt/modules/

修改hadoop配置文件：

hadoop的配置文件都在 /opt/modules/hadoop-2.5.0-cdh5.3.6/etc/hadoop 下

（1）配置env文件：

ls env.sh 找到需要修改的文件， 有如下几个：hadoop-env.sh、mapred-env.sh 、yarn-env.sh。 添加java环境变量。

export JAVA_HOME=/opt/modules/jdk1.7.0_67

（2）修改*.xml文件。

需要修改以下文件：core-site.xml、hdfs-site.xml、yarn-site.xml 和 slaves文件：

core-site.xml：

fs.defaultFShdfs://hadoop-senior01.pmpa:8020hadoop.tmp.dir/opt/modules/hadoop-2.5.0-cdh5.3.6/data

hdfs-site.xml：

dfs.replication3dfs.namenode.http-addresshadoop-senior01.pmpa:50070dfs.namenode.secondary.http-addresshadoop-senior03.pmpa:50090dfs.permissions.enabledtrue

yarn-site.xml：

yarn.nodemanager.aux-servicesmapreduce_shuffleyarn.resourcemanager.hostnamehadoop-senior02.pmpayarn.log-aggregation-enabletrueyarn.log-aggregation.retain-seconds86400

mapred-site.xml

mapreduce.framework.nameyarnmapreduce.jobhistory.addresshadoop-senior03.pmpa:10020mapreduce.jobhistory.webapp.addresshadoop-senior03.pmpa:19888

slaves文件：

hadoop-senior01.pmpahadoop-senior02.pmpahadoop-senior03.pmpa

设置开机自启动Hadoop相关服务（HDFS、Yarn、Zookeeper等）。

设置开机自启动，需要修改/etc/rc.local文件。由于hadoop相关组件使用natty用户启动，所以需要切换用户，-c选项指定运行脚本（需要指定绝对路径）。（未生效）

#hadoop-senior01：su - natty -c /opt/modules/hadoop-2.5.0-cdh5.3.6/sbin/hadoop-daemon.sh start namenodesu - natty -c /opt/modules/hadoop-2.5.0-cdh5.3.6/sbin/hadoop-daemon.sh start datanodesu - natty -c /opt/modules/hadoop-2.5.0-cdh5.3.6/sbin/yarn-daemon.sh start nodemanagersu - natty -c /opt/modules/zookeeper-3.4.5-cdh5.3.6/bin/zkServer.sh start#hadoop-senior02：su - natty -c /opt/modules/hadoop-2.5.0-cdh5.3.6/sbin/hadoop-daemon.sh start datanodesu - natty -c /opt/modules/hadoop-2.5.0-cdh5.3.6/sbin/yarn-daemon.sh start nodemanagersu - natty -c /opt/modules/hadoop-2.5.0-cdh5.3.6/sbin/yarn-daemon.sh start resourcemanagersu - natty -c /opt/modules/zookeeper-3.4.5-cdh5.3.6/bin/zkServer.sh start#hadoop-senior03：su - natty -c /opt/modules/hadoop-2.5.0-cdh5.3.6/sbin/yarn-daemon.sh start nodemanagersu - natty -c /opt/modules/hadoop-2.5.0-cdh5.3.6/sbin/mr-jobhistory-daemon.sh start historyserversu - natty -c /opt/modules/zookeeper-3.4.5-cdh5.3.6/bin/zkServer.sh startsu - natty -c /opt/modules/hadoop-2.5.0-cdh5.3.6/sbin/hadoop-daemon.sh start datanodesu - natty -c /opt/modules/hadoop-2.5.0-cdh5.3.6/sbin/hadoop-daemon.sh start secondarynamenode

（3）修改环境变量：

切换root用户，在senior01主机上修改/etc/profile文件

#HADOOP HOMEHADOOP_HOME=/opt/modules/hadoop-2.5.0-cdh5.3.6#HIVE HOMEHIVE_HOME=/opt/modules/hive-0.13.1-cdh5.3.6

（4）同步安装目录到其余服务器：

$ scp -r hadoop-2.5.0-cdh5.3.6/ natty@hadoop-senior02.pmpa:/opt/modules/$ scp -r hadoop-2.5.0-cdh5.3.6/ natty@hadoop-senior03.pmpa:/opt/modules/

（5）测试安装：

a. 格式化namenode：

$ bin/hdfs namenode -format

b.启动hdfs、 Yarn 、 jobhistory：

$ sbin/start-dfs.sh$ sbin/start-yarn.sh$ sbin/mr-jobhistory-daemon.sh start historyserver$ bin/hdfs dfs - mkdir /input$ bin/hdfs dfs -put etc/hadoop/core-site.xml /input$ bin/hdfs dfs -text /input/core-site.xml$ bin/yarn jar share/hadoop/mapreduce/hadoop-mapreduce-examples-2.5.0-cdh5.3.6.jar wordcount /input/core-site.xml /output

（6）配置Hive：

配置hive非常简单，参考文章8。

三丶Sqoop介绍：

1.简单介绍：

Sqoop ： SQL-to-Hadoop

用途：把关系型数据库的数据转移到HDFS（Hive、Hbase）（重点使用的场景）；Hadoop中的数据转移到关系型数据库中。Sqoop是java语言开发的，底层使用mapreduce。

2.版本

Sqoop有2个版本：Sqoop 1 和 Sqoop 2。但是目前企业使用的主要还是Sqoop 1，2版本还不稳定，使用时bug很多。

Sqoop2的改进：

1.引入server，集中化管理connnector。

2.多种访问方式： CLI、Web UI

3.引入基于角色的安全机制。

Sqoop设计

需要注意的是，Sqoop主要使用的是Map，是数据块的转移，没有使用到reduce任务。

3.使用要点

下图描述了Sqoop的主要使用命令：

sqoop使用要点

上图中，有2个主要的命令，即export 和 import，导入导出。

这里的导入和导出是相对于HDFS来讲的。例如，从RDBMS中导入到Hive中，就是导入（import）；从Hive导入到Mysql中，就是导出（export）。

四丶Sqoop安装配置和简单使用：

1.sqoop安装

Sqoop类似于Hive，只是一个客户端，不需要在每个节点上都安装。

（1）下载解压安装包。

（2）修改配置：

cd到目录$SQOOP_HOME/conf，修改配置文件。

$ cp -a sqoop-env-template.sh sqoop-env.sh

修改配置文件sqoop-env.sh，配置以下选项：

#Set path to where bin/hadoop is availableexport HADOOP_COMMON_HOME=/opt/modules/hadoop-2.5.0-cdh5.3.6#Set path to where hadoop-*-core.jar is availableexport HADOOP_MAPRED_HOME=/opt/modules/hadoop-2.5.0-cdh5.3.6#Set the path to where bin/hive is availableexport HIVE_HOME=/opt/modules/hive-0.13.1-cdh5.3.6#Set the path for where zookeper config dir isexport ZOOCFGDIR=/opt/modules/zookeeper-3.4.5-cdh5.3.6/conf

2.sqoop使用

查看命令帮助：

$ bin/sqoop help

因为sqoop是使用JDBC连接关系型数据库，并完成数据的转移的，所以很明显我们需要jdbc驱动，将jdbc驱动jar包复制到$SQOOP_HOME/lib下：

$ cp mysql-connector-java-5.1.27-bin.jar /opt/modules/sqoop-1.4.5-cdh5.3.6/lib/

查看某一个具体命令的帮助：

$ bin/sqoop list-databases --help

我们使用所有Sqoop命令都可以组合使用上边2个help命令来定位该命令的使用方法。

下面运行一个命令，来测试sqoop功能。 list-databases，该命令展示mysql库的所有数据库。因为展示所有数据库，所以JDBC url没有指定库。

$ bin/sqoop list-databases --connect jdbc:mysql://hadoop-senior01.pmpa:3306/ --username root --password 123456

五丶从mysql库import数据到HDFS：

sqoop从mysql数据库抽取数据到hive，使用import命令。主要需要2个步骤：（1）收集元数据；（2）提交只包含map的job。

sqoop import步骤

1.在mysql创建测试表并准备数据。

$ mysql -hlocalhost -uroot -p123456mysql> create database pma_test;mysql> use pma_test;mysql> select database();create table `cities` (`id` int not null auto_increment,`city` varchar(255) default null,`country` varchar(255) default null,PRIMARY KEY (`id`));insert into cities values (1,'Tokyo','Japan');insert into cities values (2,'Osaka','Japan');insert into cities values (3,'Yokohama','Japan');insert into cities values (4,'Nagoya','Japan');insert into cities values (5,'New York','USA');insert into cities values (6,'Boston','USA');insert into cities values (7,'Berlin','Germany');insert into cities values (8,'London','UK');

2.使用不同方式将mysql数据表导入hdfs

（1）直接将mysql表导入到HDFS上：

下例中，将mysql中的表pma_test.cities导入到hdfs。

$ bin/sqoop import --connect jdbc:mysql://hadoop-senior01.pmpa:3306/pma_test --username root --password 123456 --table cities

不指定导入目录，默认情况是导入到hdfs上面用户家目录下边。

那么上边的文件将会导入到HDFS的目录是：/user/natty/cities

（2）指定HDFS的目录和mapper数量：

先创建一个hdfs目录，然后将mysql数据import指定到这个目录。

$ bin/hdfs dfs -mkdir /user/hive/warehouse/testdb.db/cities;$ bin/sqoop import --connect jdbc:mysql://hadoop-senior01.pmpa:3306/pma_test --username root --password 123456 --table cities --num-mappers 1 --target-dir /user/hive/warehouse/testdb.db/cities/ --delete-target-dir

--num-mappers 1 ： 指定mapper的数量是1；

--target-dir ：为import操作指定目标目录，也就是需要将数据import到哪个目录下。

--delete-target-dir ：指定了该参数后，如果hdfs的目标路径已经存在了的话，就先删除该目录，再进行import（会重新创建该目录）。

（3）指定分隔符

默认情况下，import导入hdfs的文件，字段分隔符是逗号。可以使用参数 --fields-terminated-by 来修改字段分隔符。 下边例子改为TAB分隔字段。

$ bin/sqoop import --connect jdbc:mysql://hadoop-senior01.pmpa:3306/pma_test --username root --password 123456 --table cities --num-mappers 1 --target-dir /user/natty/sqoop/cities --delete-target-dir --fields-terminated-by \t'

--fields-terminated-by ： 指定字段的分隔符为 \t' 。

查看导入hdfs的文件，可以看到，字段分隔符是tab键。

$ bin/hdfs dfs -text /user/natty/sqoop/cities/pa*

（4）增量导入数据文件：

可以按照mysql表的PK，增量导入数据。只导入变化的数据。

$ bin/sqoop import --connect jdbc:mysql://hadoop-senior01.pmpa:3306/pma_test --username root --password 123456 --table cities --num-mappers 1 --target-dir /user/natty/sqoop/cities --check-column id --incremental append --last-value 7 --fields-terminated-by \t'

--check_column ： 是指定增量的字段，通过id字段获取增量数据。

--incremental ：指定导入的方式，追加。

--last-value ：从哪行开始导入，表示从第8行开始导入。

需要注意：当使用增量导入时，选项--delete-target-dir 不可以使用，否则报错。

通过结果发现，id为8的记录导入了2次。

（5）选择文件的保存格式：

默认情况下，导出的文件格式是textfile，可以指定参数修改导出格式。

$ bin/sqoop import --connect jdbc:mysql://hadoop-senior01.pmpa:3306/pma_test --username root --password 123456 --table cities --num-mappers 1 --delete-target-dir --target-dir /user/natty/sqoop/cities --fields-terminated-by \t' --as-parquetfile

--as-parquetfile ： 指定文件的导出格式为parquet。

生成了类似"7185ff10-b9e5-4b14-9ef2-c24c3a7e3bba.parquet"格式的文件。

（6）是否压缩，和压缩方式选择：

默认情况下，文件不压缩。可以指定压缩，并选择压缩格式。

$ bin/sqoop import --connect jdbc:mysql://hadoop-senior01.pmpa:3306/pma_test --username root --password 123456 --table cities --num-mappers 1 --delete-target-dir --target-dir /user/natty/sqoop/cities --compress

--compress ： 表示对文件压缩。

压缩之后，hdfs目录生成了part-m-00000.gz文件，导入hdfs的文件已经进行了压缩。

（7）其他常用的参数：

还包括

--query ：后接sql语句，按照sql语句抽取文件。

--columns ： 选择某些字段来抽取。

--where ： 查询的where条件。

一般情况下，可以使用--query指定完整的sql语句来替代table、columns、where选项。使用--query时，要指定--target-dir

Instead of using the --table, --columns and --where arguments, you can specify a SQL statement with the --query argument.

第一种情况，使用colums、where条件，这时候需要指定--table项。

$ bin/sqoop import --connect jdbc:mysql://hadoop-senior01.pmpa:3306/pma_test --username root --password 123456 --table cities --num-mappers 1 --delete-target-dir --target-dir /user/natty/sqoop/cities --columns 'id','city' --where 'id>=4'

第二种情况，使用--query选项。

$ bin/sqoop import --connect jdbc:mysql://hadoop-senior01.pmpa:3306/pma_test --username root --password 123456 --num-mappers 1 --delete-target-dir --target-dir /user/natty/sqoop/cities --query "select * from cities where country = 'Japan' and $CONDITIONS"

注意： 条件$CONDITIONS必须添加，...

大数据已然成为当今最热门的技术之一，正呈爆炸式增长。每天来自全球的新项目如雨后春笋般涌现。幸运地是，开源让越来越多的项目可以直接采用大数据技术，下面就来盘点最受欢迎的十大开源的大数据技术。

大数据已然成为当今最热门的技术之一，正呈爆炸式增长。每天来自全球的新项目如雨后春笋般涌现。幸运地是，开源让越来越多的项目可以直接采用大数据技术，下面就来盘点最受欢迎的十大开源的大数据技术。

1.Hadoop——高效、可靠、可伸缩，能够为你的数据存储项目提供所需的YARN、HDFS和基础架构，并且运行主要的大数据服务和应用程序。

2.Spark——使用简单、支持所有重要的大数据语言(Scala、Python、Java、R)。拥有强大的生态系统，成长迅速，对microbatching/batching/SQL支持简单。Spark能更好地适用于数据挖掘与机器学习等需要迭代的MapReduce的算法。

3.NiFi——Apache NiFi是由美国国家安全局(NSA)贡献给Apache基金会的开源项目，其设计目标是自动化系统间的数据流。基于其工作流式的编程理念，NiFi非常易于使用、强大、可靠、高可配置。两个最重要的特性是其强大的用户界面和良好的数据回溯工具。堪称大数据工具箱里的瑞士军刀。

4.Apache Hive 2.1——Hive是建立在 Hadoop 上的数据仓库基础构架。它提供了一系列的工具，可以用来进行数据提取转化加载(ETL)，这是一种可以存储、查询和分析存储在 Hadoop 中的大规模数据的机制。随着最新版本的发布，性能和功能都得到了全面提升，Hive已成为SQL在大数据上的最佳解决方案。

5.Kafka——Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模网站中的所有动作流数据。它已成为大数据系统在异步和分布式消息之间的最佳选择。从Spark到NiFi再到第三方插件工具以至于Java到Scala，它都提供了强大的粘合作用。

6.Phoenix—是HBase的SQL驱动。目前大量的公司采用它，并扩大其规模。HDFS支持的NoSQL能够很好地集成所有工具。Phoenix查询引擎会将SQL查询转换为一个或多个HBase scan，并编排执行以生成标准的JDBC结果集。

7.Zeppelin——Zeppelin 是一个提供交互数据分析且基于Web的笔记本。方便你做出可数据驱动的、可交互且可协作的精美文档，并且支持多种语言，包括 Scala(使用 Apache Spark)、Python(Apache Spark)、SparkSQL、 Hive、 Markdown、Shell等。

8.Sparkling Water——H2O填补了Spark’s Machine Learning的缺口，它可以满足你所有的机器学习。

9.Apache Beam——在Java中提供统一的数据进程管道开发，并且能够很好地支持Spark和Flink。提供很多在线框架，开发者无需学习太多框架。

10.Stanford CoreNLP——自然语言处理拥有巨大的增长空间，斯坦福正在努力增进他们的框架。

原文地址：http://linuxprobe/ten-linux-data.html

随着大数据越来越被重视，数据采集的挑战变的尤为突出。今天为大家介绍几款数据采集平台：

Apache Flume Fluentd Logstash Chukwa Scribe Splunk Forwarder

大数据平台与数据采集

任何完整的大数据平台，一般包括以下的几个过程：

数据采集–>数据存储–>数据处理–>数据展现(可视化，报表和监控)

其中，数据采集是所有数据系统必不可少的，随着大数据越来越被重视，数据采集的挑战也变的尤为突出。这其中包括：

我们今天就来看看当前可用的六款数据采集的产品，重点关注它们是如何做到高可靠，高性能和高扩展。

1、Apache Flume

Flume 是Apache旗下的一款开源、高可靠、高扩展、容易管理、支持客户扩展的数据采集系统。 Flume使用JRuby来构建，所以依赖Java运行环境。

Flume最初是由Cloudera的工程师设计用于合并日志数据的系统，后来逐渐发展用于处理流数据事件。

Flume设计成一个分布式的管道架构，可以看作在数据源和目的地之间有一个Agent的网络，支持数据路由。

每一个agent都由Source，Channel和Sink组成。

Source

Source负责接收输入数据，并将数据写入管道。Flume的Source支持HTTP，JMS，RPC，NetCat，Exec，Spooling Directory。其中Spooling支持监视一个目录或者文件，解析其中新生成的事件。

Channel

Channel 存储，缓存从source到Sink的中间数据。可使用不同的配置来做Channel，例如内存，文件，JDBC等。使用内存性能高但不持久，有可能丢数据。使用文件更可靠，但性能不如内存。

Sink

Sink负责从管道中读出数据并发给下一个Agent或者最终的目的地。Sink支持的不同目的地种类包括：HDFS，HBASE，Solr，ElasticSearch，File，Logger或者其它的Flume Agent。

Flume在source和sink端都使用了transaction机制保证在数据传输中没有数据丢失。

Source上的数据可以复制到不同的通道上。每一个Channel也可以连接不同数量的Sink。这样连接不同配置的Agent就可以组成一个复杂的数据收集网络。通过对agent的配置，可以组成一个路由复杂的数据传输网络。

配置如上图所示的agent结构，Flume支持设置sink的Failover和Load Balance，这样就可以保证即使有一个agent失效的情况下，整个系统仍能正常收集数据。

Flume中传输的内容定义为事件(Event)，事件由Headers(包含元数据，Meta Data)和Payload组成。

Flume提供SDK，可以支持用户定制开发：

Flume客户端负责在事件产生的源头把事件发送给Flume的Agent。客户端通常和产生数据源的应用在同一个进程空间。常见的Flume 客户端有Avro，log4J，syslog和HTTP Post。另外ExecSource支持指定一个本地进程的输出作为Flume的输入。当然很有可能，以上的这些客户端都不能满足需求，用户可以定制的客户端，和已有的FLume的Source进行通信，或者定制实现一种新的Source类型。

同时，用户可以使用Flume的SDK定制Source和Sink。似乎不支持定制的Channel。

2、Fluentd

Fluentd是另一个开源的数据收集框架。Fluentd使用C/Ruby开发，使用JSON文件来统一日志数据。它的可插拔架构，支持各种不同种类和格式的数据源和数据输出。最后它也同时提供了高可靠和很好的扩展性。Treasure Data, Inc 对该产品提供支持和维护。

Fluentd的部署和Flume非常相似：

Fluentd的架构设计和Flume如出一辙：

Fluentd的Input/Buffer/Output非常类似于Flume的Source/Channel/Sink。

Input

Input负责接收数据或者主动抓取数据。支持syslog，http，file tail等。

Buffer

Buffer负责数据获取的性能和可靠性，也有文件或内存等不同类型的Buffer可以配置。

Output

Output负责输出数据到目的地例如文件，AWS S3或者其它的Fluentd。

Fluentd的配置非常方便，如下图：

Fluentd的技术栈如下图：

FLuentd和其插件都是由Ruby开发，MessgaePack提供了JSON的序列化和异步的并行通信RPC机制。

Cool.io是基于libev的事件驱动框架。

FLuentd的扩展性非常好，客户可以自己定制(Ruby)Input/Buffer/Output。

Fluentd从各方面看都很像Flume，区别是使用Ruby开发，Footprint会小一些，但是也带来了跨平台的问题，并不能支持Windows平台。另外采用JSON统一数据/日志格式是它的另一个特点。相对去Flumed，配置也相对简单一些。

3、Logstash

Logstash是著名的开源数据栈ELK (ElasticSearch, Logstash, Kibana)中的那个L。

Logstash用JRuby开发，所有运行时依赖JVM。

Logstash的部署架构如下图，当然这只是一种部署的选项。

一个典型的Logstash的配置如下，包括了Input，filter的Output的设置。

几乎在大部分的情况下ELK作为一个栈是被同时使用的。所有当你的数据系统使用ElasticSearch的情况下，logstash是首选。

4、Chukwa

官网：https://chukwa.apache.org/

Apache Chukwa是apache旗下另一个开源的数据收集平台，它远没有其他几个有名。Chukwa基于Hadoop的HDFS和Map Reduce来构建(显而易见，他用Java来实现)，提供扩展性和可靠性。Chukwa同时提供对数据的展示，分析和监视。很奇怪的是它的上一次 github的更新事7年前。可见该项目应该已经不活跃了。

Chukwa的部署架构如下：

Chukwa的主要单元有：Agent，Collector，DataSink，ArchiveBuilder，Demux等等，看上去相当复杂。由于该项目已经不活跃，我们就不细看了。

5、Scribe

代码托管：https://github/facebookarchive/scribe

Scribe是Facebook开发的数据(日志)收集系统。已经多年不维护，同样的，就不多说了。

6、Splunk Forwarder

以上的所有系统都是开源的。在商业化的大数据平台产品中，Splunk提供完整的数据采金，数据存储，数据分析和处理，以及数据展现的能力。

Splunk是一个分布式的机器数据平台，主要有三个角色：

Search Head负责数据的搜索和处理，提供搜索时的信息抽取。

Indexer负责数据的存储和索引 Forwarder，负责数据的收集，清洗，变形，并发送给Indexer

Splunk内置了对Syslog，TCP/UDP，Spooling的支持，同时，用户可以通过开发 Input和Modular Input的方式来获取特定的数据。在Splunk提供的软件仓库里有很多成熟的数据采集应用，例如AWS，数据库(DBConnect)等等，可以方便的从云或者是数据库中获取数据进入Splunk的数据平台做分析。

这里要注意的是，Search Head和Indexer都支持Cluster的配置，也就是高可用，高扩展的，但是Splunk现在还没有针对Farwarder的Cluster的功能。也就是说如果有一台Farwarder的机器出了故障，数据收集也会随之中断，并不能把正在运行的数据采集任务Failover到其它的 Farwarder上。

总结

我们简单讨论了几种流行的数据收集平台，它们大都提供高可靠和高扩展的数据收集。大多平台都抽象出了输入，输出和中间的缓冲的架构。利用分布式的网络连接，大多数平台都能实现一定程度的扩展性和高可靠性。

其中Flume，Fluentd是两个被使用较多的产品。如果你用ElasticSearch，Logstash也许是首选，因为ELK栈提供了很好的集成。Chukwa和Scribe由于项目的不活跃，不推荐使用。

Splunk作为一个优秀的商业产品，它的数据采集还存在一定的限制，相信Splunk很快会开发出更好的数据收集的解决方案。

目前，编程人员面对的最大挑战就是复杂性，硬件越来越复杂，OS越来越复杂，编程语言和API越来越复杂，我们构建的应用也越来越复杂。根据外媒的一项调查报告，以下列出了Java程序员在过去12个月内一直使用的一些工具或框架，或许会对你有意义。

1、MongoDB--最受欢迎的，跨平台的，面向文档的数据库。

MongoDB是一个基于分布式文件存储的数据库，使用C++语言编写。旨在为Web应用提供可扩展的高性能数据存储解决方案。应用性能高低依赖于数据库性能，MongoDB则是非关系数据库中功能最丰富，最像关系数据库的，随着MongDB 3.4版本发布，其应用场景适用能力得到了进一步拓展。MongoDB的核心优势就是灵活的文档模型、高可用复制集、可扩展分片集群。

2、Elasticsearch --为云构建的分布式RESTful搜索引擎。

ElasticSearch是基于Lucene的搜索服务器。它提供了分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是比较流行的企业级搜索引擎。

3、Cassandra--开源分布式数据库管理系统，最初是由Facebook开发的，旨在处理许多商品服务器上的大量数据，提供高可用性，没有单点故障。

Apache Cassandra是一套开源分布式NoSQL数据库系统。集Google BigTable的数据模型与Amazon Dynamo的完全分布式架构于一身。于2008开源，此后，由于Cassandra良好的可扩展性，被Digg、Twitter等Web 2.0网站所采纳，成为了一种流行的分布式结构化数据存储方案。

4、Redis --开源(BSD许可)内存数据结构存储，用作数据库，缓存和消息代理。

Redis是一个开源的使用ANSI C语言编写的、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

5、Hazelcast --基于Java的开源内存数据网格。

Hazelcast 是一种内存数据网格 in-memory data grid，提供Java程序员关键任务交易和万亿级内存应用。虽然Hazelcast没有所谓的‘Master’，但是仍然有一个Leader节点(the oldest member)，这个概念与ZooKeeper中的Leader类似，但是实现原理却完全不同。同时，Hazelcast中的数据是分布式的，每一个member持有部分数据和相应的backup数据，这点也与ZooKeeper不同。

6、EHCache--广泛使用的开源Java分布式缓存。主要面向通用缓存、Java EE和轻量级容器。

EhCache 是一个纯Java的进程内缓存框架，具有快速、精干等特点，是Hibernate中默认的CacheProvider。主要特性有：快速简单，具有多种缓存策略;缓存数据有两级，内存和磁盘，因此无需担心容量问题;缓存数据会在虚拟机重启的过程中写入磁盘;可以通过RMI、可插入API等方式进行分布式缓存;具有缓存和缓存管理器的侦听接口;支持多缓存管理器实例，以及一个实例的多个缓存区域;提供Hibernate的缓存实现。

7、Hadoop --用Java编写的开源软件框架，用于分布式存储，并对非常大的数据集进行分布式处理。

用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群进行高速运算和存储。Hadoop实现了一个分布式文件系统(Hadoop Distributed File System)，简称HDFS。Hadoop的框架最核心的设计就是：HDFS和MapReduce。HDFS为海量的数据提供了存储，MapReduce则为海量的数据提供了计算。

8、Solr --开源企业搜索平台，用Java编写，来自Apache Lucene项目。

Solr是一个独立的企业级搜索应用服务器，它对外提供类似于Web-service的API接口。用户可以通过http请求，向搜索引擎服务器提交一定格式的XML文件，生成索引;也可以通过Http Get操作提出查找请求，并得到XML格式的返回结果。

9、Spark --Apache Software Foundation中最活跃的项目，是一个开源集群计算框架。

Spark 是一种与 Hadoop 相似的开源集群计算环境，但是两者之间还存在一些不同之处，这些不同之处使 Spark 在某些工作负载方面表现得更加优越，换句话说，Spark 启用了内存分布数据集，除了能够提供交互式查询外，它还可以优化迭代工作负载。

Spark 是在 Scala 语言中实现的，它将 Scala 用作其应用程序框架。与 Hadoop 不同，Spark 和 Scala 能够紧密集成，其中的 Scala 可以像操作本地集合对象一样轻松地操作分布式数据集。

10、Memcached --通用分布式内存缓存系统。

Memcached是一套分布式快取系统，当初是Danga Interactive为了LiveJournal所发展的，但被许多软件(如MediaWiki)所使用。Memcached作为高速运行的分布式缓存服务器，具有以下的特点：协议简单，基于libevent的事件处理，内置内存存储方式。

11、Apache Hive --在Hadoop之上提供类似SQL的层。

Hive是一个基于Hadoop的数据仓库平台。通过hive，可以方便地进行ETL工作。hive定义了一个类似于SQL的查询语言，能够将用户编写的SQL转化为相应的Mapreduce程序基于Hadoop执行。目前，已经发布了Apache Hive 2.1.1 版本。

12、Apache Kafka --最初是由LinkedIn开发的高吞吐量，分布式订阅消息系统。

Apache Kafka是一个开源消息系统项目，由Scala写成。该项目的目标是为处理实时数据提供一个统一、高通量、低等待的平台。Kafka维护按类区分的消息，称为主题(topic)。生产者(producer)向kafka的主题发布消息，消费者(consumer)向主题注册，并且接收发布到这些主题的消息。

13、Akka --用于在JVM上构建高并发，分布式和弹性消息驱动应用程序的工具包。

Akka 是一个用 Scala 编写的库，用于简化编写容错的、高可伸缩性的 Java 和 Scala 的 Actor 模型应用。它已经成功运用在电信行业，系统几乎不会宕机。

14、HBase --开放源代码，非关系型，分布式数据库，采用Google的BigTable建模，用Java编写，并在HDFS上运行。

与FUJITSU Cliq等商用大数据产品不同，HBase是Google Bigtable的开源实现，类似Google Bigtable利用GFS作为其文件存储系统，HBase利用Hadoop HDFS作为其文件存储系统;Google运行MapReduce来处理Bigtable中的海量数据，HBase同样利用Hadoop MapReduce来处理HBase中的海量数据;Google Bigtable利用 Chubby作为协同服务，HBase利用Zookeeper作为对应。

15、Neo4j --在Java中实现的开源图形数据库。

Neo4j是一个高性能的NOSQL图形数据库，它将结构化数据存储在网络上而不是表中。它是一个嵌入式的、基于磁盘的、具备完全事务特性的Java持久化引擎。

16、CouchBase --开源分布式的NoSQL面向文档数据库，针对交互式应用程序进行了优化。

如果以前没有NoSQL的使用经验，那么理解couchbase的时候关键有两点：延后写入和松散存储。该产品基于Apache CouchDB，并整合了GeoCouch(一个基于Erlang、紧密集成的地理空间索引系统，可支持LBS应用)。

17、Apache Storm--开源分布式实时计算系统。

Apache Storm 是一个能近实时地在数据之上运行用户代码片段的流式数据处理框架。它实际上是一系列连在一起的管道。通常用于简单的分析任务 ，诸如计算，以及清洗，使其常规化，并且准备摄入用于长期存储的数据。

18、CouchDB--开源的面向文档的NoSQL数据库，使用JSON存储数据。

CouchDB 是一个开源的面向文档的数据库管理系统，可以通过 RESTful JavaScript Object Notation (JSON) API 访问。CouchDB落实到最底层的数据结构就是两类B+Tree 。

19、Oracle Coherence--内存数据网格解决方案，通过提供对常用数据的快速访问，使企业能够可预测地扩展关键任务应用程序。

简单来说，Coherence仅支持Java，.NET和C++ API三个版本，这三个都是面向对象的语言，这也说明Coherence和应用开发的亲和性。

20、Titan--可扩展的图形数据库，优化用于存储和查询包含分布在多机集群上的数百亿个顶点和边的图形。

21、Amazon DynamoDB--快速，灵活的全面管理NoSQL的数据库服务，适用于任何规模的要求一致性，单位毫秒延迟的应用程序。

Amazon DynamoDB 是一种完全托管的 NoSQL 数据库服务，提供快速而可预测的性能，能够实现无缝扩展。

22、Amazon Kinesis--AWS上的实时流式传输数据平台。

Web 应用程序、移动设备、可穿戴设备、行业传感器和许多软件应用程序和服务都可能生成大量的流数据(有时达到每小时数 TB)，需要对其进行连续地收集、存储和处理。Amazon Kinesis 就是针对这种需求产生的。

23、Datomic--完全事务，云就绪，分布式数据库，用Clojure编写。

Datomic 是一个灵活的、基于时间因子的数据库，支持联合查询，具有弹性的可扩展性以及支持ACID事务性。Datomic 提供高可用的、分布式存储服务。

随着这些年全世界数据的几何式增长，数据的存储和运算都将成为世界级的难题。之前小鸟给大家介绍过一些分布式文件系统，解决的是大数据存储的问题，今天小鸟给大家介绍一些分布式计算框架：

Hadoop框架

提起大数据，第一个想起的肯定是Hadoop，因为Hadoop是目前世界上应用最广泛的大数据工具，他凭借极高的容错率和极低的硬件价格，在大数据市场上风生水起。Hadoop还是第一个在开源社区上引发高度关注的批处理框架，他提出的Map和Reduce的计算模式简洁而优雅。迄今为止，Hadoop已经成为了一个广阔的生态圈，实现了大量算法和组件。由于Hadoop的计算任务需要在集群的多个节点上多次读写，因此在速度上会稍显劣势，但是其吞吐量也同样是其他框架所不能匹敌的。

Storm框架

与Hadoop的批处理模式不同，Storm采用的是流计算框架，由Twitter开源并且托管在GitHub上。与Hadoop类似的是，Storm也提出了两个计算角色，分别为Spout和Bolt。

如果说Hadoop是水桶，只能一桶一桶的去井里扛，那么Storm就是水龙头，只要打开就可以源源不断的出水。Storm支持的语言也比较多，Java、Ruby、Python等语言都能很好的支持。由于Storm是流计算框架，因此使用的是内存，延迟上有极大的优势，但是Storm不会持久化数据。

Samza框架

Smaza也是一种流计算框架，但他目前只支持JVM语言，灵活度上略显不足，并且Samza必须和Kafka共同使用。但是响应的，其也继承了Kafka的低延时、分区、避免回压等优势。对于已经有Hadoop+Kafka工作环境的团队来说，Samza是一个不错的选择，并且Samza在多个团队使用的时候能体现良好的性能。

Spark框架

Spark属于前两种框架形式的集合体，是一种混合式的计算框架。它既有自带的实时流处理工具，也可以和Hadoop集成，代替其中的MapReduce，甚至Spark还可以单独拿出来部署集群，但是还得借助HDFS等分布式存储系统。Spark的强大之处在于其运算速度，与Storm类似，Spark也是基于内存的，并且在内存满负载的时候，硬盘也能运算，运算结果表示，Spark的速度大约为Hadoop的一百倍，并且其成本可能比Hadoop更低。但是Spark目前还没有像Hadoop哪有拥有上万级别的集群，因此现阶段的Spark和Hadoop搭配起来使用更加合适。

Flink框架

Flink也是一种混合式的计算框架，但是在设计初始，Fink的侧重点在于处理流式数据，这与Spark的设计初衷恰恰相反，而在市场需求的驱使下，两者都在朝着更多的兼容性发展。Flink目前不是很成熟，更多情况下Flink还是起到一个借鉴的作用。

以上就是现在比较主流的大数据运算框架的介绍了，欢迎大家收藏转发。关注小鸟，获取更多大数据级相关技术的资讯与教程。

随着监管趋严和行业愈加规范化，大数据风控，尤其是基于弱数据的风控正成为线上信用贷业务最重要的核心竞争力。

本文授权转载 CreditX氪信， 作者 唐正阳

近日，中国人民银行成立金融科技（FinTech）委员会，旨在加强金融科技工作的研究规划和统筹协调。

随着AI、云计算在金融业务层面的快速渗透，也倒逼监管跟进升级，以进一步加强监管的有效性。事实上，这次央行提出监管科技（RegTech），也是对金融科技的肯定，希望其在驱动金融创新，引领金融规范化发展中发挥积极作用。

金融的核心在于风险，现下谈及互联网金融，很多人都对大数据风控并不陌生，也都在行业野蛮发展的过程中有自己的理解。但如果要定义什么是大数据风控，可能不少行业外围同学的看法难免有些偏颇和碎片化。下面笔者浅显地从大数据风控的基本内容和框架出发，主要为想要了解这个行业的同学简要做一个相对完整的介绍。

大数据到底有哪些？

首先我们需要厘清大数据的概念，当下各行各业都在探索大数据的价值，大数据的定义也很多。从技术的角度来理解，本质就是来自多个渠道和系统的结构化和非结构化数据，在金融领域，尤其是消费金融，我们界定大数据到底有哪些维度，其实芝麻信用分是一个非常典型例子，虽然不同公司有自己的分法，但数据主体大都可以归类为身份属性、信用属性、行为数据、消费属性、人脉关系这五大方面。

身份属性，这是最基础的，包括真实的身份信息、学历、就业经历等。

信用属性包含的方面比较多，比如过往的履约记录、固定资产、流动资产、收入等都会纳入进来用以衡量一个人还款能力和还款意愿。

过去我们去银行办理贷款，以上这两个维度就是传统风控的数据来源，但由于大多数人没有这方面比较完整的记录，且流程冗长麻烦，因此只有少部分人才能享受金融服务。

现在随着互联网的爆发式发展，以及普惠金融的崛起，越来越多的机构正将海量互联网数据和金融结合探索其在表征风险方面的价值。如上所述，长期缺乏金融产品的人群基数庞大，需求旺盛，因此从创业公司到BAT到金融机构，都在拓展更多领域的大数据以抢占消费金融爆发的窗口期。

数据拓展的第一个领域是消费属性，这块主要是电商或交易数据，比如日常购物商品、消费金额、消费时段等都可以从不同角度来分析出一个人消费稳定度，消费档次，还款能力等风险特征。

其次，人脉关系也是很重要的一个维度，俗话说“近朱者赤，近墨者黑”。很多时候你的微信朋友圈、经常打电话的朋友也反映了你在风险上的表征。生活中我们和同事沟通比较频繁，而如果一个人社交稳定度差，可能说明他经常换工作，显然风险也会相应增加。

最后一个维度是行为数据，这块数据涉及面比较广泛，主要是用户在APP上的活动所体现出的行为特点，包括浏览不同类目的频次、时间、风险偏好等等。

说到这，我们对大数据风控涉及的几类数据应该有了一个基本的认识，那在具体工作中，我们是不是应该先把这些数据都收集好才能做好工作呢？

答案是否定的，因为数据都是有成本的，开展一个金融业务，从数据、模型、服务再到最后的收益，更为关键的是业务本身的形态，再进一步扩展至产品、场景，我们会发现不同的场景面对不同的客群，风控关注的风险点都会有一定的差异，再反过来寻找能够表征这些风险点的数据也会有所侧重。因此，如果要厘清大数据风控该用哪些数据，首先要对风控场景有所了解，其中最为核心的是理解不同场景下要抓住哪些金融风险。

金融风险的理解

风险的概念比较大，为了给大家提供一个最基本的视角来了解，下面以线上信用贷款举例来阐述，这也是互联网消费金融最主要的方向之一。在这个场景下，我们面临的风险主要是信用风险和欺诈风险两块。

首先是欺诈风险，据数字，在中国，互联网金融50-70%的损失来自欺诈，这也可以说是风控业务中最困难的地方。造成这种现状的原因比较多，一方面是诸如现金贷类型的消费金融短期爆发式发展，大量创业公司涌入赛道以互联网获客运营的流量思路做金融，与此同时相应的风控经验和能力缺失，因此给专业的欺诈分子暴露了较大的风险敞口，通过简单研究业务规则漏洞，并通过互联网传播，可能带来较大的损失；另一方面也是欺诈产业链自身研究实力不断的完善有关，现在的欺诈已经从以往单一的个人欺诈演变为有组织、有规模的集团化欺诈，链条上盗号，数据泄露作为基础账号库，已衍生出一系列包括黑产交易、ID Mapping、定向攻击的完整产业链，其中的分工和技术也非常专业和精细化。

如图：这种设备称为养卡设备，俗称“猫池”， 实际上就是一个号码卡插槽，可以在不拆卡的情况下将整张卡插到猫池里，连接电脑后使用，还可以接收短信验证码。现在在各种平台注册时都需要填写短信验证码，“刷手”为了获取平台的福利会利用猫池养卡，规避平台的身份确认短信。

再比如短信拦截马，这是一种可以拦截他人短信的木马，让被攻击者收不到短信，并将短信内容截取到攻击者手机上。这种木马最常见的是通过钓鱼、诱骗、欺诈等方式诱导用户安装，然后通过拦截转发用户短信内容，以此获取各种用户重要的个人隐私信息，如用户姓名、身份证号码、银行卡账户、支付密码及各种登录账号和密码等，造成这些信息的泄露，再利用此信息从而达到窃取用户资金的目的，严重威胁用户的财产安全。

第二块简单谈一下信用风险，其定义是借款者违约的风险，换句话说，也就是借款人因各种原因未能及时、足额偿还债务或贷款而违约的可能性。一般，我们会从还款能力和还款意愿两个角度去分析信用风险，但在小额信用贷场景中，由于额度一般为2000左右，少就几百，多也就5000，一个正常有工作的人很少会不具备按期还款的能力。所以在这点上我们更多的是从还款意愿角度来看，即借款人对偿还贷款的态度，现实中有不少人会借钱不还，这就是常说的“老赖”，如果我们以违约概率的目标去识别他，还是能挑出不少有正常借款意图的人。

大数据风控体系的初步构建

现在我们有了对大数据和风险的基本认知，但如何真正从大数据提炼出风险表征，并进一步转化为实时的金融风险决策服务呢？事实上，这需要重构一整套风控数据架构体系，过去传统金融机构在身份属性和信用属性的数据上沉淀了丰富知识，但在互联网金融业务中，用户能够关联的更多是消费、社交和行为类数据，且越是小额分散的业务，数据的金融属性越弱。近两年小额现金贷也正是由于这部分数据的风控知识体系缺乏，因此陷入高利率覆盖高坏账、暴力催收等乱象。

随着监管趋严和行业愈加规范化，大数据风控，尤其是基于弱数据的风控正成为线上信用贷业务最重要的核心竞争力，除了基本的身份验证、合规、黑灰名单、规则过滤以外，要防控欺诈风险和信用风险，还需做好以下三个维度的准备：

第一是设备层面，现在成熟的APP都需要辟如更换登录设备时重新输入短信验证码，或者登录时得手动滑动验证码等，这些既是挡住黑产的第一道关，也是后续风控的重要数据基础。

第二是知识体系层面，拆解开来看，核心有2点，一是知识工程，二是模型。目前最领先的消金机构都有一套相对成熟的针对特定数据domain的风险特征库和分客群、分目标的模型，比如反欺诈模型、申请评分模型、风险行为预测模型等，贷后还会有催收模型、客户流失预测模型等。在这过程中，引入AI处理弱数据，并在大量样本上不断迭代模型是关键。

第三是系统层面，试想我们有了清晰的数据认知，结合到场景和风险理解我们也摸索了一套经验证的数据使用方式，但如何与我们的业务系统对接，成为实时的数据服务？这还需要一个完整的支持数据接入、加工处理、得出结果以及监控管理的在线引擎。随着线上个人贷款规模的爆发式增长，控制风险、解放人力已成为最紧迫的需求，数据智能自动化引擎是机构“跑起来”的强大推动力。

风控与征信

最后，简单谈一下大数据风控和征信的区别，不少同学会认为风控公司就是征信公司，这其中还是有较大区别的，尤其在大数据领域。

据百科，征信是专业化的、独立的第三方机构为个人或企业建立信用档案，依法采集、客观记录其信用信息，并依法对外提供信用信息服务的一种活动，它为专业化的授信机构提供了信用信息共享的平台。

应该看到，征信所对应的数据还局限在开头所说的身份属性和信用属性范围，也就是强金融数据，而大数据风控认为所有数据都是风险数据，更侧重于将弱数据金融化，再提炼出风险表征。因此，征信本质是大数据风控的子集，覆盖的人群和应用领域也更为狭窄。当下大数据风控和征信的确还处于混业经营的状态，但随着行业发展，可预见市场还会逐渐细分，届时前者将更注重在数据生态体系上的经验和沉淀，后者则侧重在独立性和公信力以及监管合规等方面。