目录
大数据概述
大数据生态圈：Hadoop生态圈，Spark生态圈
大数据的4V特性：
Variety 多样的数据类型、Velocity 快速的数据流转、Value 发现数据价值、Volume 海量数据规模
大数据涉及的技术
数据采集、数据存储、数据处理/分析/挖掘可视化
Google大数据技术
MapReduce（解决计算效率）、BigTable（解决读写速度）、GFS(解决存储容量)
数据计算类型
批处理计算
批处理计算只要解决针对大规模数据的批量处理，MapReduce是最具有代表性和影响力的大数据批处理技术，用于大规模数据集（1TB以上）的并行计算。Spark基于内存分布数据集，比MapReduce快很多。
流计算
流数据是指在时间分布和数量上无线的一系列动态数据集合体，数据的价值随着时间的流逝降低，因此需要采用实时计算的方式给出秒级响应。
图计算
许多大数据都是以大规模图或网络的形式呈现，如社交网路、传染病传播途径、交通事故对路网的影响。
Mapreduce作为单输入、两阶段、粗粒度数据并行的分布式计算框架，在表达多迭代、稀疏结构和细粒度数据时，力不从心。
大数据包括静态数据和动态数据（流数据），大数据计算包括批量计算和实时计算。
大数据技术板块
|
功能 |
框架 |
|
数据采集 |
●flume ●kafka ●logstash ●filebeat |
|
数据存储 |
●redis ●mongdb ●hbase ●hdfs |
|
数据查询 |
●hive ●impala ●elasticsearch ●kylin ●clickhouse |
|
数据计算 |
实时计算(流式计算) ●storm ●spark streaming ●flink 离线计算 ●hadoop ●spark |
|
数据传递转换 |
●Sqoop（主要用于在Hadoop(Hive)与传统的数据库(mysql、postgresql…)间进行数据的传递） |
Lambda架构
从底层的数据源开始，通过Kafka、Flume等大数据组件，将各种各样的数据同步到大数据平台，然后分成两条线进行计算。一条线进入离线批量数据处理平台（Spark、Hive、MapReduce等），去计算T+1或者H+1的业务指标，这些指标需要T+1或者H+1才能看到；另外一条线是进入到实时数据处理平台（Flink、SparkStreaming等），去计算实时统计指标。
大数据框架对比
Hadoop对比Storm
●Hadoop是磁盘级计算，进行计算时，数据在磁盘上，需要读写磁盘；
Storm是内存级计算，数据直接通过网络导入内存。读写内存比读写磁盘速度快n个数量级。
●Hadoop M/R基于HDFS，需要切分输入数据、产生中间数据文件、排序、数据压缩、多份复制等，效率较低。
Storm 基于ZeroMQ这个高性能的消息通讯库，不持久化数据。
●两者面向的领域也不完全相同，一个是批量处理，基于任务调度的；另外一个是实时处理，基于流。
Hadoop对比Spark
Spark仅仅是计算框架，不包含存储，对比的应该是MapReduce。
●MapReduce和Spark的主要区别在于，MapReduce使用持久存储，而Spark使用弹性分布式数据集(RDDS)。
●MapReduce是批处理框架，而Spark支持流式。
●Spark易用性要好。
Storm对比Spark Streaming
Flume对比Kafka
●kafka和flume都是日志系统。kafka是分布式消息中间件，自带存储，提供push和pull存取数据功能。
●kafka做日志缓存应该是更为合适的，但是 flume的数据采集部分做的很好，可以定制很多数据源，减少开发量。所以比较流行flume+kafka模式，如果为了利用flume写hdfs的能力，也可以采用kafka+flume的方式。
●Flume 是管道流方式，提供了很多的默认实现，让用户通过参数部署，及扩展API.
相关技术拓展
NoSQL
分布式计算框架Flink
Spark 掀开了内存计算的先河，也以内存为赌注，赢得了内存计算的飞速发展。Spark 的火热或多或少的掩盖了其他分布式计算的系统身影。
在国外一些社区，有很多人将大数据的计算引擎分成了 4 代：
●首先第一代的计算引擎，无疑就是 Hadoop 承载的 MapReduce。这里大家应该都不会对 MapReduce 陌生，它将计算分为两个阶段，分别为 Map 和 Reduce。对于上层应用来说，就不得不想方设法去拆分算法，甚至于不得不在上层应用实现多个 Job 的串联，以完成一个完整的算法，例如迭代计算。
●由于这样的弊端，催生了支持 DAG （有向无环图）框架的产生。因此，支持 DAG 的框架被划分为第二代计算引擎。如 Tez 以及更上层的 Oozie。这里我们不去细究各种 DAG 实现之间的区别，不过对于当时的 Tez 和 Oozie 来说，大多还是批处理的任务。
●接下来就是以 Spark 为代表的第三代的计算引擎。第三代计算引擎的特点主要是 Job 内部的 DAG 支持（不跨越Job），以及强调的实时计算。在这里，很多人也会认为第三代计算引擎也能够很好的运行批处理的 Job。
●随着第三代计算引擎的出现，促进了上层应用快速发展，例如各种迭代计算的性能以及对流计算和 SQL 等的支持。Flink 的诞生就被归在了第四代。这应该主要表现在 Flink 对流计算的支持，以及更一步的实时性上面。当然Flink 也可以支持 Batch 的任务，以及 DAG 的运算。
Flink 是一个针对流数据和批数据的分布式处理引擎。它主要是由 Java 代码实现。目前主要还是依靠开源社区的贡献而发展。对 Flink 而言，其所要处理的主要场景就是流数据，批数据只是流数据的一个极限特例而已。再换句话说，Flink 会把所有任务当成流来处理，这也是其最大的特点。
Flink 可以支持本地的快速迭代，以及一些环形的迭代任务。并且 Flink 可以定制化内存管理。在这点，如果要对比 Flink 和 Spark 的话，Flink 并没有将内存完全交给应用层。这也是为什么 Spark 相对于 Flink，更容易出现 OOM的原因（out of memory）。就框架本身与应用场景来说，Flink 更相似与 Storm。
大数据处理神器Beam （Dataflow）
Apache Beam 最初叫 Apache Dataflow，由谷歌和其合作伙伴向Apache捐赠了大量的核心代码，并创立孵化了该项目。该项目的大部分大码来自于 Cloud Dataflow SDK，其特点有以下几点：
- 统一数据批处理（Batch）和流处理（Stream）编程的范式
- 能运行在任何可执行的引擎之上
ApacheBeam项目的重点，在于数据处理的编程范式和接口定义，事实上，它并不涉及具体的执行引擎的实现，而且，能够基于Beam开发的数据处理程序可以执行在任意的分布式计算引擎上，也是它的目标。综上，统一批处理和流处理的编程范式是ApacheBeam的主要目标，因为这样能够为无限、乱序、web-scale的数据集处理提供简单灵活、功能丰富以及表达能力十分强大的SDK。
ApacheBeam，能够在Java中提供统一的数据进程管道开发，而且能够很好地支持Spark和Flink。由于ApacheBeam提供了很多在线框架，所以开发者也就无需学习太多框架。同时，它也提供了一个模板更方便用户去进行数据处理——BeamModel。我们都知道，无限的时间乱序数据流，是BeamModel处理的目标数据，不考虑时间顺序或是有限的数据集可看作是无限乱序数据流的一个特例。而用户只需要在Model的每一步中根据业务需求，按照以下几个维度调用具体的API，即可生成分布式数据处理Pipeline，并提交到具体执行引擎上执行。这几个维度抽象出来，便是BeamSDK。
Hadoop集群的5大管理工具
当你利用Hadoop进行大数据分析和处理时，首先你需要确保配置、部署和管理集群。这个即不容易也没有什么乐趣，但却受到了开发者们的钟爱。本文提供了5款工具帮助你实现。
Apache Ambari
Apache Ambari是对Hadoop进行监控、管理和生命周期管理的开源项目。它也是一个为Hortonworks数据平台选择管理组建的项目。Ambari向Hadoop MapReduce、HDFS、 HBase、Pig, Hive、HCatalog以及Zookeeper提供服务。
Apache Mesos
Apache Mesos是集群管理器，可以让用户在同一时间同意集群上运行多个Hadoop任务或其他高性能应用。Twitter的开放源代码经理Chris Aniszczyk表示，Mesos可以在数以百计的设备上运行，并使其更容易执行工作。
Platform MapReduce
Platform MapReduce提供了企业级可管理性和可伸缩性、高资源利用率和可用性、操作便利性、多应用支持以及一个开放分布式系统架构，其中包括对于Hadoop分布式文件系统（HDFS）和Appistry Cloud IQ的即时支持，稍后还将支持更多的文件系统和平台，这将确保企业更加关注将MapReduce应用程序转移至生产环境中。
StackIQ Rocks+ Big Data
StackIQ Rock+ Big Data是一款Rocks的商业流通集群管理软件，该公司已加强支持Apache Hadoop。Rock+支持Apache、Cloudera、Hortonworks和MapR的分布，并且处理从裸机服务器来管理Hadoop集群配置的整个过程。
Zettaset Orchestrator
Zettaset Orchestrator是端到端的Hadoop管理产品，支持多个Hadoop的分布。Zettaset吹捧Orchestrator的基于UI的经验和MAAPS（管理、可用性、自动化、配置和安全）的处理能力。
数据可视化
协同过滤
1、基于用户的协同过滤
算法思想
基于用户的协同过滤算法（UserCF算法）是推荐系统中最古老的。
（1）找到和目标用户兴趣像素的用户集合；
（2）找到该集合中用户所喜欢的、且目标用户没有听说过的物品推荐给目标用户。
计算用户相似度
相似度算法：
- 泊松相关系数
- 余弦相似度
- 调整余弦相似度
2、基于物品的协同过滤
算法思想
简称ItemCF:
（1）计算物品之间的相似度；
（2）根据物品的相似度和用户的历史行为，给用户生成推荐列表。
UserCF算法推荐的是那些和目标用户有共同兴趣爱好的其他用户所喜欢的物品，ItemCF算法则推荐那些和目标用户之前喜欢的物品类似的其他物品。
UserCF算法适合用于新闻推荐、微博话题等，单随着用户数量增大，计算用户相似度越来越困难，时间和空间复杂度与用户增长近似于平方关系。
ImteCF在电子商务、电影、图书等应用场景中，可以利用用户的历史行为给推荐结果做出解释。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/200310.html原文链接：https://javaforall.net
