|
三 27
|
|
三 27
|
host文件增加如下:
|
三 19
|
把集群升级到20.1之后，map/reduce的效率提升的不是一点半点啊。
升级步骤：
- 执行./bin/stop-all.sh
- mv 旧版本到一个新的目录
- 把配置好的新版本mv过来
- 同步到各个机器上
- hadoop namenode -upgrade
- 启动集群
原先在19.2上需要执行2个多小时的job，到新版本只需要1小时零几分就能完成了。
|
三 18
|
集群搭建
- 通常，集群里的一台机器被指定为 NameNode，另一台的机器被指定为JobTracker，这些机器是masters。余下的机器即作为DataNode也作为TaskTracker。这些机器是slaves。
- 对Hadoop的配置通过conf/目录下的两个重要配置文件完成：
- 此外，通过设置conf/hadoop-env.sh中的变量为集群特有的值，你可以对bin/目录下的Hadoop脚本进行控制。
- 配置Hadoop守护进程的运行参数
- 这部分涉及Hadoop集群的重要参数，这些参数在conf/hadoop-site.xml中指定。
- hadoop-default.xml – 只读的默认配置。
- hadoop-site.xml – 集群特有的配置。
| 参数 | 取值 | 备注 |
| fs.default.name | NameNode的URI。 | hdfs://主机名/ |
| mapred.job.tracker | JobTracker的主机（或者IP）和端口。 | 主机:端口。 |
| dfs.name.dir | NameNode持久存储名字空间及事务日志的本地文件系统路径。 | 当这个值是一个逗号分割的目录列表时，nametable数据将会被复制到所有目录中做冗余备份。 |
| dfs.data.dir | DataNode存放块数据的本地文件系统路径，逗号分割的列表。 | 当这个值是逗号分割的目录列表时，数据将被存储在所有目录下，通常分布在不同设备上。 |
| mapred.system.dir | Map/Reduce框架存储系统文件的HDFS路径。比如/hadoop/mapred/system/。 | 这个路径是默认文件系统（HDFS）下的路径， 须从服务器和客户端上均可访问。 |
| mapred.local.dir | 本地文件系统下逗号分割的路径列表，Map/Reduce临时数据存放的地方。 | 多路径有助于利用磁盘i/o。 |
| mapred.tasktracker.{map|reduce}.tasks.maximum | 某一TaskTracker上可运行的最大Map/Reduce任务数，这些任务将同时各自运行。 | 默认为2（2个map和2个reduce），可依据硬件情况更改。 |
| dfs.block.size | 每个block的大小，byte | |
| dfs.replication | Block缺省的副本数量 | |
| mapred.reduce.tasks | 每个任务启动的reduce task数量 |
HDFS架构和设计简介
- HDFS采用master/slave架构。一个HDFS集群是由一个Namenode和一定数目的Datanodes组成。Namenode是一个中心服务器，负责管理文件系统的名字空间(namespace)以及客户端对文件的访问。集群中的Datanode一般是一个节点一个，负责管理它所在节点上的存储。HDFS暴露了文件系统的名字空间，用户能够以文件的形式在上面存储数据。从内部看，一个文件其实被分成一个或多个数据块，这些块存储在一组Datanode上。Namenode执行文件系统的名字空间操作，比如打开、关闭、重命名文件或目录。它也负责确定数据块到具体Datanode节点的映射。Datanode负责处理文件系统客户端的读写请求。在Namenode的统一调度下进行数据块的创建、删除和复制。
- 文件系统的名字空间 (namespace)
HDFS支持传统的层次型文件组织结构。 Namenode负责维护文件系统的名字空间，任何对文件系统名字空间或属性的修改都将被Namenode记录下来
- 数据复制
每个文件存储成一系列的数据块，除了最后一个，所有的数据块都是同样大小的。为了容错，文件的所有数据块都会有副本
- 副本选择
为了降低整体的带宽消耗和读取延时，HDFS会尽量让读取程序读取离它最近的副本
- 安全模式
Namenode启动后会进入一个称为安全模式的特殊状态。 Namenode从所有的 Datanode接收心跳信号和块状态报告，块状态报告包括了某个Datanode所有的数据块列表。 阅读全文 »
|
三 18
|
Why Cassandra
MySQL drives too many random I/Os
File-based solutions require far too many locks
Cassandra vs MySQL with 50GB of data
| MySQL | Cassandra |
| ~300ms write | ~0.12ms write |
| ~350ms read | ~15ms read |
分布式领域CAP（Consistency, Availability, Partition tolerance）理论
Consistency(一致性), 数据一致更新，所有数据变动都是同步的
Availability(可用性), 好的响应性能
Partition tolerance(分区容错性) 可靠性
定理：任何分布式系统只可同时满足二点，没法三者兼顾。（这个定理并没有被证明）
忠告：架构师不要将精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。
Cassandra特点
- High availability高可用性
- Incremental scalability可扩展
- Eventually consistent最终一致性
- Tunable tradeoffs between consistency and latency
- 灵活的schema，不需要象数据库一样预先设计schema，增加或者删除字段非常方便（on the fly）。
- 支持range查询：可以对Key进行范围查询。
- Minimal administration
- 单点故障不影响集群服务No SPF (Single Point of Failure) 阅读全文 »
|
一 03
|
|
十一 17
|
编辑C:\WINDOWS\system32\drivers\etc\hosts文件
增加
近期评论