111

1MapReduce:大规模数据集的并行运算

2,

YANR本质上是一个资源统一管理系统,这一点与几年前的mesos(http://www.mesosproject.org/),更早的Torque(http://www.adaptivecomputing.com/products/open-source/torque/)基本一致。将各种框架运行在YARN之上,可以实现框架的资源统一管理和分配,使他们共享一个集群,而不是“一个框架一个集群”,这可大大降低运维成本和硬件成本。
如果你还没有意识到当前已经进入多计算框架纵横捭阖的新时代,那让我来给你细数一下当前出现的,已小有名气的计算框架吧:

1) MapReduce:  这个框架人人皆知,它是一种离线计算框架,将一个算法抽象成Map和Reduce两个阶段进行处理,非常适合数据密集型计算。

2) Spark:  我们知道,MapReduce计算框架不适合(不是不能做,是不适合,效率太低)迭代计算(常见于machine learning领域,比如PageRank)和交互式计算(data mining领域,比如SQL查询),MapReduce是一种磁盘计算框架,而Spark则是一种内存计算框架,它将数据尽可能放到内存中以提高迭代应用和交互式应用的计算效率。官方首页:http://spark-project.org/

3) Storm:  MapReduce也不适合进行流式计算、实时分析,比如广告点击计算等,而Storm则更擅长这种计算、它在实时性要远远好于MapReduce计算框架。官方首页:http://storm-project.net/

4) S4: Yahoo开发的流式计算框架,与Storm较为类似。官方首页:http://incubator.apache.org/s4/

5) Open MPI: 非常经典的消息处理框架,非常适合高性能计算,现在仍被广泛使用。

6) HAMA:  基于BSP(bulk-synchronous parallel model)模型的分布式计算框架,与Google的Pregel类似,可用于大规模科学计算,如矩阵,图算法,网络算法等,官方首页:http://hama.apache.org/synchronous--同步的。bulk--大的。parallel--平行的。

7) Cloudera Impala/ Apache Drill: 基于Hadoop的更快的SQL查询引擎(比Hive快得多),Google Dremel的模仿者。Cloudera Impala官方首页:https://github.com/cloudera/impala,Apache Drill官方首页:http://incubator.apache.org/drill/

8) Giraph:图算法处理框架,采用BSP模型,可用于计算pagerank,shared connections, personalization-based popularity等迭代类算法。官方首页:http://giraph.apache.org/

上面很多框架正在或正准备往YARN上迁移,具体见:http://wiki.apache.org/hadoop/PoweredByYarn/

3,Hadoop

Hadoop是一个由Apache基金会所开发的 分布式系统基础架构。
用户可以在不了解分布式底层细节的情况下,开发分布式程序。充分利用集群的威力进行高速运算和存储。
[1]   Hadoop实现了一个 分布式文件系统(Hadoop Distributed File System),简称HDFS。HDFS有高 容错性的特点,并且设计用来部署在低廉的(low-cost)硬件上;而且它提供高吞吐量(high throughput)来访问 应用程序的数据,适合那些有着超大数据集(large data set)的应用程序。HDFS放宽了(relax)POSIX的要求,可以以流的形式访问(streaming access)文件系统中的数据。
Hadoop的框架最核心的设计就是:HDFS和MapReduce。HDFS为海量的数据提供了存储,则MapReduce为海量的数据提供了计算。 [2]  
4,hbase

Hbase是运行在Hadoop上的NoSQL数据库,它是一个分布式的和可扩展的大数据仓库,也就是说HBase能够利用HDFS的分布式处理模式,并从Hadoop的MapReduce程序模型中获益。这意味着在一组商业硬件上存储许多具有数十亿行和上百万列的大表。除去Hadoop的优势,HBase本身就是十分强大的数据库,它能够融合key/value存储模式带来实时查询的能力,以及通过MapReduce进行离线处理或者批处理的能力。总的来说,Hbase能够让你在大量的数据中查询记录,也可以从中获得综合分析报告。

谷歌曾经面对过一个挑战的问题:如何能在整个互联网上提供实时的搜索结果?答案是它本质上需要将互联网缓存,并重新定义在这样庞大的缓存上快速查找的新方法。为了达到这个目的,定义如下技术:

  • 谷歌文件系统GFS:可扩展分布式文件系统,用于大型的、分布式的、数据密集型的应用程序。
  • BigTable:分布式存储系统,用于管理被设计成规模很大的结构化数据:来自数以千计商用服务器的PB级别的数据。
  • MapReduce:一个程序模型,用于处理和生成大数据集的相关实现。

在谷歌发布这些技术的文档之后, 不久以后我们就看到了它们的开源实现版本 ,就在2007年,Mike Cafarella发布了BigTable开源实现的代码,他称其为HBase,自此,HBase成为Apache的顶级项目,并运行在Facebook,Twitter,Adobe……仅举几个例子。

http://blog.jobbole.com/83614/

熟悉hadoop/hbase/spark/storm等至少一种分布式系统

熟悉map-reduce/BSP/实时计算等分布式计算科学



熟悉常用的经典的大数据相关开源软件,比如Hadoop(HDFS,YARN),HBase,spark,storm,zookeeper,kafka,hawq,presto,aerospike,redis

了解大数据平台生态圈,了解mesos,flink,tachyon,impala,kylin,kubernetes,docker,etcd

ZooKeeper是一个 分布式的,开放源码的 分布式应用程序协调服务,是 Google的Chubby一个 开源的实现,是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等。
ZooKeeper的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户。
ZooKeeper包含一个简单的原语集, [1]   提供Java和C的接口。
ZooKeeper代码版本中,提供了分布式独享锁、选举、队列的接口,代码在zookeeper-3.4.3\src\recipes。其中分布锁和队列有Java和C两个版本,选举只有Java版本。
( Zookeeper 分布式服务框架是 Apache Hadoop 的一个子项目,它主要是用来解决分布式应用中经常遇到的一些数据管理问题,如:统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。本文将从使用者角度详细介绍 Zookeeper 的安装和配置文件中各个配置项的意义,以及分析 Zookeeper 的典型的应用场景(配置文件的管理、集群管理、同步锁、Leader 选举、队列管理等),用 Java 实现它们并给出示例代码。)

Kafka是一种高吞吐量的分布式发布订阅消息系统,它可以处理消费者规模的网站中的所有动作流数据。 这种动作(网页浏览,搜索和其他用户的行动)是在现代网络上的许多社会功能的一个关键因素。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。 对于像Hadoop的一样的日志数据和离线分析系统,但又要求实时处理的限制,这是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理,也是为了通过集群机来提供实时的消费。

HAWQ 是 Pivotal 设计的一个大规模并行 SQL 分析处理引擎,支持事务处理。HAWQ 将复杂的查询分割成简单的任何,并分发到并行处理系统中的处理单元执行。

Presto是一个开源的分布式SQL查询引擎,适用于交互式分析查询,数据量支持GB到PB字节。

Presto的设计和编写完全是为了解决像Facebook这样规模的商业数据仓库的交互式分析和处理速度的问题。

无热点! Aerospike  Server 使用复杂的哈希函数来确保数据均等地分布到所有可用节点,从而将需求平均分布到各资源上。 

AerospikeDB以低延迟和高吞吐量而闻名,已经用于许多大型的、要求堪称苛刻的实时平台。而Redis同样以速度著称,并且也经常用作缓存。有鉴于此,Aerospike团队近日联合拥有大数据和云架构师、AWS社区英雄、谷歌云开发专家、微软MVP(SQL Server)等众多头衔的Lynn Langit在AWS云的虚拟机上对AerospikeDB和Redis进行了基准测试,测试结果已经发布在Aerospike官方博客上。而Lynn也发表了题为《学到的经验——在AWS云上进行NoSQL基准测试(AerospikeDB与Redis)》的博文,对测试过程和结果进行了更为详细的描述。

由于AerospikeDB是多线程的,而Redis是单线程的,所以为了公平起见,需要对Redis进行扩展,以便它能够使用每个AWS EC2实例上的多个内核。在这个过程中,Lynn发现了AerospikeDB和Redis在扩展或分片的可管理性方面的差异:

  • Redis需要开发人员自己管理分片并提供分片算法用于在各分片之间平衡数据;而AerospikeDB可以自动处理相当于分片的工作;
  • 在Redis中,为了增加吞吐量,需要增加Redis分片的数量,并重构分片算法及重新平衡数据,这通常需要停机;而在AerospikeDB中,可以动态增加数据卷和吞吐量,无需停机,并且AerospikeDB可以自动平衡数据和流量;
  • 在Redis中,如果需要复制及故障转移功能,则需要开发人员自己在应用程序层同步数据;而在AerospikeDB中,只需设置复制因子,然后由AerospikeDB完成同步复制操作,保持即时一致性;而且AerospikeDB可以透明地完成故障转移;
  • 此外,AerospikeDB既可以完全在内存中运行,也可以利用Flash/SSD存储的优点。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值