大数据学习笔记<一>

我所理解的大数据的处理流程为以下几步

1.数据采集

2.数据存储

3.数据处理

4.数据展示

类似下图

1.数据采集

数据采集方式

1.系统日志采集方式

采用日志的方法记录数据，然后对日志进行收集。

日志收集的工具主要有

• Apache Flume
• Fluentd
• Logstash
• Chukwa
• Scribe
• Splunk Forwarder

2.网络数据采集方法：对非结构化数据的采集

网络数据采集是指通过网络爬虫或网站公开API等方式从网站上获取数据信息。该方法可以将非结构化数据从网页中抽取出来，将其存储为统一的本地数据文件，并以结构化的方式存储。

3.其他数据采集方法

对于企业生产经营数据或学科研究数据等保密性要求较高的数据，可以通过与企业或研究机构合作，使用特定系统接口等相关方式采集数据。

2.数据存储

RDBMS（Relational Database Management System）传统关系型数据库，

MPP（Massively Parallel Processing）大规模并行处理系统，基于shared nothing 架构的面型结构化数据分析的数据库产品。例如：Greenplum（基于postgresql的分布式数据库），Vertical，Asterdata。这样的系统是由许多松耦合的处理单元（非处理器 ）组成的，每个处理单元内的cpu都有自己私有的资源，如总线，内存，硬盘灯。在每个单元内都有操作系统和管理数据库的实例副本，这种架构最大的特点是不共享资源。

 这些系统大部分采用了关系数据模型并且支持SQL查询，但为了能够并行执行SQL的查询操作，系统中采用了两个关键技术：关系表的水平划分和SQL查询的分区执行。
水平划分的主要思想就是根据某种策略将关系表中的元组分布到集群中的不同节点上，这些节点上的表结构是一样的，这样就可以对元组并行处理。现有的分区策略有哈希分区、范围分区、循环分区等。例如，哈希分区策略是将表T中的元组分布到n个节点上，可以使用统一的哈希算法对元组中的某个或某几个属性进行哈希，如hash(T.attribute1) mod n，然后根据哈希值将元组放置到不同的节点上。
在分区存储的表中处理SQL查询需要使用基于分区的执行策略，如获取表T中某一数值范围内的元组，系统首先为整个表T生成总的执行计划P，然后将P拆分成n个子计划{P1,…,Pn}，子计划Pi在节点ni上独立执行，最后每个节点将生成的中间结果发送到某一选定的节点上，该节点对中间结果进行聚集产生最终的结果。
并行数据库系统的目标是高性能和高可用性，通过多个节点并行执行数据库任务，提高整个数据库系统的性能和可用性。最近一些年不断涌现一些提高系统性能的新技术，如索引、压缩、实体化视图、结果缓存、I/O共享等，这些技术都比较成熟且经得起时间的考验。与一些早期的系统如Teradata必须部署在专有硬件上不同，最近开发的系统如Aster、Vertica等可以部署在普通的商业机器上，这些数据库系统可以称得上准云系统。
并行数据库系统的主要缺点就是没有较好的弹性，而这种特性对中小型企业和初创企业是有利的。人们在对并行数据库进行设计和优化的时候认为集群中节点的数量是固定的，若需要对集群进行扩展和收缩，则必须为数据转移过程制订周全的计划。这种数据转移的代价是昂贵的，并且会导致系统在某段时间内不可访问，而这种较差的灵活性直接影响到并行数据库的弹性以及现用现付商业模式的实用性。

并行数据库的另一个问题就是系统的容错性较差，过去人们认为节点故障是个特例，并不经常出现，因此系统只提供事务级别的容错功能，如果在查询过程中节点发生故障，那么整个查询都要从头开始重新执行。这种重启任务的策略使得并行数据库难以在拥有数以千个节点的集群上处理较长的查询，因为在这类集群中节点的故障经常发生。基于这种分析，并行数据库只适合于资源需求相对固定的应用程序。不管怎样，并行数据库的许多设计原则为其他海量数据系统的设计和优化提供了比较好的借鉴。

引自http://blog.csdn.net/broadview2006/article/details/8812742

MPP架构数据库应具有的特征：

● 任务并行执行;● 数据分布式存储(本地化);● 分布式计算;● 私有资源;● 横向扩展;

个人理解：把小数据库组织起来，联合成一个大型数据库。将数据分片，存储在每个节点上。每个节点仅查询自己的数据。所得到的结果再经过主节点处理得到最终结果。通过增加节点数目达到系统线性扩展。

基于hadoop环境的各种nosql

数据的操作语言是sql，目标是能够在Hadoop上使用SQL，这些工具有些只是在MapReduce之上做了简单的包装，有些则是在HDFS上实现了完整的数据仓库

Apache Hive将sql转换为一系列可以再标准Hadoop Task Trackers上运行的MapReduce任务，Hive通过一个metastore（本身就是一个数据库）存储表模式、分区和位置以期提供像mysql一样的功能。

Hive的查询性能通常很低，它会把sql转换为运行的较慢的MapReduce任务。

Cloudera Impala

Presto

Shark

Apache Drill

HAWQ

BigSQL等

附：行存储与列存储的对比

3.数据处理

• 仅批处理框架： Apache Hadoop
• 仅流处理框架： Apache Storm、Apache Samza
• 混合框架： Apache Spark、Apache Flink

批处理系统

批处理主要操作大容量静态数据集，并在计算过程完成后返回结果。

批处理模式中使用的数据集通常符合下列特征

• 有界：批处理数据集代表数据的有限集合
• 持久：数据通常始终存储在某种类型的持久存储位置中
• 大量：批处理操作通常是处理极为海量数据集的唯一方法

批处理非常适合需要访问全套记录才能完成的计算工作。例如在计算总数和平均数时，必须将数据集作为一个整体加以处理，而不能将其视作多条记录的集合。这些操作要求在计算进行过程中数据维持自己的状态。

需要处理大量数据的任务通常最适合用批处理操作进行处理。无论直接从持久存储设备处理数据集，或首先将数据集载入内存，批处理系统在设计过程中就充分考虑了数据的量，可提供充足的处理资源。由于批处理在应对大量持久数据方面的表现极为出色，因此经常被用于对历史数据进行分析。

大量数据的处理需要付出大量时间，因此批处理不适合对处理时间要求较高的场合。

流处理系统

流处理系统会对随时进入系统的数据进行计算。相比批处理模式，这是一种截然不同的处理方式。流处理方式无需针对整个数据集执行操作，而是对通过系统传输的每个数据项执行操作。

流处理中的数据集是“无边界”的，这就产生了几个重要的影响：

• 完整数据集只能代表截至目前已经进入到系统中的数据总量。

• 工作数据集也许更相关，在特定时间只能代表某个单一数据项。

• 处理工作是基于事件的，除非明确停止否则没有“尽头”。处理结果立刻可用，并会随着新数据的抵达继续更新。

流处理系统可以处理几乎无限量的数据，但同一时间只能处理一条（真正的流处理）或很少量（微批处理，Micro-batch Processing）数据，不同记录间只维持最少量的状态。虽然大部分系统提供了用于维持某些状态的方法，但流处理主要针对副作用更少，更加功能性的处理（Functional processing）进行优化。

功能性操作主要侧重于状态或副作用有限的离散步骤。针对同一个数据执行同一个操作会或略其他因素产生相同的结果，此类处理非常适合流处理，因为不同项的状态通常是某些困难、限制，以及某些情况下不需要的结果的结合体。因此虽然某些类型的状态管理通常是可行的，但这些框架通常在不具备状态管理机制时更简单也更高效。

此类处理非常适合某些类型的工作负载。有近实时处理需求的任务很适合使用流处理模式。分析、服务器或应用程序错误日志，以及其他基于时间的衡量指标是最适合的类型，因为对这些领域的数据变化做出响应对于业务职能来说是极为关键的。流处理很适合用来处理必须对变动或峰值做出响应，并且关注一段时间内变化趋势的数据。

混合处理系统：批处理和流处理

一些处理框架可同时处理批处理和流处理工作负载。这些框架可以用相同或相关的组件和API处理两种类型的数据，借此让不同的处理需求得以简化。

如你所见，这一特性主要是由Spark和Flink实现的，下文将介绍这两种框架。实现这样的功能重点在于两种不同处理模式如何进行统一，以及要对固定和不固定数据集之间的关系进行何种假设。

虽然侧重于某一种处理类型的项目会更好地满足具体用例的要求，但混合框架意在提供一种数据处理的通用解决方案。这种框架不仅可以提供处理数据所需的方法，而且提供了自己的集成项、库、工具，可胜任图形分析、机器学习、交互式查询等多种任务。

详情 http://36kr.com/p/5061463.html

4.数据展示