使用ORACLE GATEWAY 与Greenplum HAWQ 1.0 互通

现场环境:Oracle 11g 64bit linux edition

Greenplum Pivotal HD HAWQ 1.0

操作系统 RHEL 6.3 x86_64

为了实现在Oracle中直接访问HAWQ中的数据,需要首先安装Oracle Gateway 11g x86_64 linux edition

 

需要安装的软件:Oracle Gateway 11g x86_64 linux edition

DATADIRECT_CONNECT64_ODBC_7.0.1for Greenplum (必须是7版本的,6的不行,rhel6带的unixodbc也不行)

 

( 后记,Oracle 11g database server 中貌似也带了hs的功能,直接使用database server 当gateway应也可,不用再单独安装gateway)

安装路径: Oracle Gateway:/home/oracle/product/11.2.0/tg_1

Datadirect ODBC :/home/oracle/ddodbc

Oracle database :/home/oracle/app/oracle/product/11.2.0/dbhome_1

 

配置:

修改/home/oracle/product/11.2.0/tg_1/hs/admin/initdg4odbc.ora

# This is a sample agent init file that contains the HS parameters that are
# needed for the Database Gateway for ODBC
#
# HS init parameters
#
HS_FDS_CONNECT_INFO = Greenplum
#HS_FDS_TRACE_LEVEL = 0
HS_FDS_TRACE_LEVEL= ODBC
HS_FDS_TRACE_FILE_NAME = /home/oracle/odbc_trace.log
HS_FDS_SHAREABLE_NAME = /usr/lib64/libodbc.so
HS_FDS_SUPPORT_STATISTICS = FALSE
#HS_LANGUAGE=AMERICAN_AMERICA.WE8ISO8859P1
HS_LANGUAGE = AMERICAN_AMERICA.UTF8
HS_FDS_TIMESTAMP_MAPPING = “TIMESTAMP(6)”
HS_FDS_FETCH_ROWS=1
#HS_FDS_SQLLEN_INTERPRETATION=32
HS_KEEP_REMOTE_COLUMN_SIZE=LOCAL
HS_NLS_NCHAR = UCS2
#
# ODBC specific environment variables
#
set ODBCINI=/etc/odbc.ini
set ODBCINST=/etc/odbcinst.ini

修改/home/oracle/app/oracle/product/11.2.0/dbhome_1/network/admin/listener.ora

备注,此处直接使用database的listener。未使用gateway的listener ,在文件后追加:

SID_LIST_LISTENER =
        (SID_LIST =
                (SID_DESC =
                        (SID_NAME = dg4odbc)
                        (ORACLE_HOME =/home/oracle/product/11.2.0/tg_1 )
                        (ENV=”LD_LIBRARY_PATH=/usr/local/lib:/home/oracle/product/11.2.0/tg_1/lib:/home/oracle/ddodbc/lib”)
                        (PROGRAM = dg4odbc)
                )
        )
)
修改/home/oracle/app/oracle/product/11.2.0/dbhome_1/network/admin/tnsnames.ora
增加:
dg4odbc  =
  (DESCRIPTION=
    (ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521))
    (CONNECT_DATA=(SID=dg4odbc))
    (HS=OK)
  )
修改/etc/odbc.ini
[oracle@server3 admin]$ cat /etc/odbc.ini
[ODBC Data Sources]
Greenplum=Greenplum
[ODBC Data Sources]
Greenplum Wire Protocol=DataDirect 7.0 Greenplum Wire Protocol
[ODBC]
IANAAppCodePage=4
InstallDir=/home/oracle/ddodbc
Trace=0
TraceFile=odbctrace.out
TraceDll=/home/oracle/ddodbc/lib/ddtrc26.so
[Greenplum]
Driver=/home/oracle/ddodbc/lib/ddgplm26.so
Description=DataDirect 7.0 Greenplum Wire Protocol
AlternateServers=
ApplicationUsingThreads=1
ConnectionReset=0
ConnectionRetryCount=0
ConnectionRetryDelay=3
Database=haier
DefaultLongDataBuffLen=2048
EnableDescribeParam=0
EnableKeysetCursors=0
EncryptionMethod=0
ExtendedColumnMetadata=0
FailoverGranularity=0
FailoverMode=0
FailoverPreconnect=0
FetchTSWTZasTimestamp=0
FetchTWFSasTime=0
HostName=server3
InitializationString=
KeyPassword=
KeysetCursorOptions=0
KeyStore=
KeyStorePassword=
LoadBalanceTimeout=0
LoadBalancing=0
LoginTimeout=15
LogonID=
MaxPoolSize=100
MinPoolSize=0
Password=
Pooling=0
PortNumber=54321
QueryTimeout=0
ReportCodepageConversionErrors=0
TransactionErrorBehavior=1
XMLDescribeType=-10
Charset=utf8
[ODBC]
TraceFile=/tmp/sql.log
Trace=1

 

 

修改/etc/odbcinst.ini

[ODBC Drivers]
DataDirect 7.0 Greenplum Wire Protocol=Installed
[ODBC Translators]
OEM to ANSI=Installed
[Administrator]
HelpRootDirectory=/home/oracle/ddodbc/adminhelp
[ODBC]
#This section must contain values for DSN-less connections
#if no odbc.ini file exists. If an odbc.ini file exists,
#the values from that [ODBC] section are used.
[DataDirect 7.0 Greenplum Wire Protocol]
Driver=/home/oracle/ddodbc/lib/ddgplm26.so
Setup=/home/oracle/ddodbc/lib/ddgplm26.so
APILevel=0
ConnectFunctions=YYY
DriverODBCVer=3.52
FileUsage=0
HelpRootDirectory=/home/oracle/ddodbc/help
SQLLevel=0

 

重启listener

lsnrctl status 中应有一下内容:

Listening Endpoints Summary…
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=server3)(PORT=1521)))
Services Summary…
Service “dg4odbc” has 1 instance(s).
  Instance “dg4odbc”, status UNKNOWN, has 1 handler(s) for this service…
而后在数据库中创建dblink,注意用户名和密码需要使用双引号

create database link DBLINK
connect to “gpadmin” identified by “gpadmin”
using ‘dg4odbc’;

执行sql语句即可返回成功(注意HAWQ中的表名和字段名需要使用双引号,用小写表示):

select count(*) from “poc1″@dblink;

 

HADOOP 的安全性

背景

当Hadoop在2004年开始开发的时候,对如何创建一个安全的分布式计算式环境上没有考虑,Hadoop框架对用户及服务的验证和授权严重不足,用户可以仿冒任意一个HDFS和mapreduce上的用户,恶意的代码可以以任何一个用户提交到Job tracker,尽管在版本0.16以后, HDFS增加了文件和目录的权限,但由于用户无需认证,HDFS的权限控制也极其容易绕过,允许一个用户伪装成任意一个用户,同时计算框架也没有进行双向验证,一个恶意的网络用户可以模拟一个正常的集群服务加入到hadoop集群,去接受JobTracker, Namenode的任务指派。

此时HADOOP要安全只能靠严格的的网络隔离,能访问hadoop集群的用户都是完全可信赖的用户。

到了2009年,关于hadoop安全性的讨论已经接近白热化了,安全被作为一个高优先级的问题摆了出来,Hadoop 2010年的开发计划就包含的用户与服务的双向认证,并且对终端用户透明。具体可参见【HADOOP-4487 Security features for Hadoop7】

安全设计时有以下6大目标:

1.2 Requirements

1. Users are only allowed to access HDFS files that they have permission to access.

2. Users are only allowed to access or modify their own MapReduce jobs.

3. User to service mutual authentication to prevent unauthorized NameNodes, DataNodes, JobTrackers, or TaskTrackers.

4. Service to service mutual authentication to prevent unauthorized services from joining a cluster’s HDFS or MapReduce service.

5. The acquisition and use of Kerberos credentials will be transparent to the user and applications, provided that the operating system acquired a Kerberos Ticket Granting Tickets (TGT) for the user at login.

6. The degradation of GridMix performance should be no more than 3%.

为了达到这目标,开发者决定使用kerberos进行认证。选择kerberos而非SSL基于以下理由:

1. kerberos使用对称密钥可以达到更高的性能,比使用公钥的SSL更快。

2. 简化了用户管理。例如,取消一个用户只需要简单的将用户从KDC里面删除即可,而如果使用SSL就需要生成证书注销列表(CRL) 并分发到所有服务器。

Hadoop的安全设计有以下七大假设

1.For backwards compatibility and single-user clusters, it will be possible to configure the cluster with the current style of security.

2. Hadoop itself does not issue user credentials or create accounts for users. Hadoop depends on external user credentials (e.g. OS login, Kerberos credentials, etc). Users are expected to acquire those credentials from Kerberos at operating system login. Hadoop services should also be configured with suitable credentials depending on the cluster setup to authenticate with each other.

3. Each cluster is set up and configured independently. To access multiple clusters, a client needs to authenticate to each cluster separately. However, a single sign on that acquires a Kerberos ticket will work on all appropriate clusters.

4. Users will not have access to root accounts on the cluster or on the machines that are used to launch jobs.

5. HDFS and MapReduce communication will not travel on untrusted networks.

6. A Hadoop job will run no longer than 7 days (configurable) on a MapReduce cluster or accessing HDFS from the job will fail.

7. Kerberos tickets will not be stored in MapReduce jobs and will not be available to the job’s tasks. Access to HDFS will be authorized via delegation tokens as explained in section 4.1.

以上七个假设基本就是Hadoop安全设计的七大安全缺陷。了解以后也就可以更有针对的对安全问题进行防范。

为了保证开发进度以及保证向后兼容,开发者在设计过程中对安全设计进行了部分妥协,首先新的设计要求终端用户不能在集群中的任何机器上拥有高权限的管理帐户,例如root。如果终端用户对集群中的机器拥有root权限,他就可以发现 Delegation Tokens, Job Tokens, Block Access Tokens或者symmetric encryption keys ,进而颠覆整个系统的安全保证。同时在开发过程中决定保证安全的新功能对于集群性能的影响不大于3%,这导致的开发者倾向使用对称加密算法,并且对网络传输不加密。

 部署hadoop kerberos方案后的安全顾虑

在hadoop新的安全设计中使用的 “threat model” 引起了一些新的安全性上的考虑。首先是SASL (Simple Authenticationand Security Layer)默认提供的安全保护,广泛分发的对称密钥。二是因为强调性能以及加密耗费资源的前提假设,hadoop使用了非常低的默认SASL  QoP (Quality of Protection),尽管SASL over kerberos其实可以做到更好。但hadoop的默认QoP只是进行认证,对于网络通信的完整性以及加密功能并未提供。Hadoop的PRC通信就可以被窃听及修改。同时新的Hadoop 安全设计依赖于HMAC-SHA1 这个对称密钥加密算法。因为Block Access Token 需要,HMAC-SHA1的对称密钥需要分发到Namenode以及所有的datanode机器,这意味着成百上千台的服务器。如果密钥被攻击者发现那么所有datanode上的数据都极其容易受到攻击。只要知道DATAID,攻击者就可以仿冒一个Block Access Token ,进而将hadoop的安全行降低到上一个版本的水平。而且HDFS Proxy使用的是基于IP的认证。一旦获得了HDFS Proxy Server的访问权,就可以读取HDFS Proxy Server 所被授权的所有数据。

二.CDH 4 mrv1 与kerberos集成

测试使用版本如下:

kerberos server 版本:krb5-server-1.9-33.el6.x86_64

Hadoop 版本: CDH4 W/ MRV1

操作系统版本:Redhat Enterprise Linux 6 update 3 64bit

JAVA版本:jdk-6u35-linux-x64

 

服务器名 IP 用途
rhel227.hadoop.hylandtec.com 172.16.130.227 Kerberos 服务器
rhel63.hadoop.hylandtec.com 172.16.130.234 Hadoop服务器

两台服务器均已经在DNS server上配置好正向及反向解析。hadoop.hylandtec.com 指向kerberos服务器。

安装kerberos服务器

作为测试,仅使用kerberos作为认证服务器,安装系统盘中的krb5-server-1.9-33.el6.x86_64.rpm,krb5-libs-1.9-33.el6.x86_64, krb5-workstation-1.9-33.el6.x86_64

kerberos realm 我们规划为HADOOP.HYLANDTEC.COM,以下配置中注意realm 必须为大写!

编辑/etc/krb5.conf

[logging]

default = FILE:/var/log/krb5libs.log

kdc = FILE:/var/log/krb5kdc.log

admin_server = FILE:/var/log/kadmind.log

[libdefaults]

default_realm = HADOOP.HYLANDTEC.COM

dns_lookup_realm = false

dns_lookup_kdc = false

ticket_lifetime = 24h

renew_lifetime = 7d

forwardable = true

[realms]

HADOOP.HYLANDTEC.COM = {

kdc = rhel227.hadoop.hylandtec.com:88

admin_server = rhel227.hadoop.hylandtec.com:749

default_domain = HADOOP.HYLANDTEC.COM  }

[domain_realm]

.hadoop.hylandtec.com = HADOOP.HYLANDTEC.COM

hadoop.hylandtec.com = HADOOP.HYLANDTEC.COM

[kdc]

profile = /var/kerberos/krb5kdc/kdc.conf

以root用户执行,按照提数输入master key:

 kdb5_util create -s

编辑/var/kerberos/krb5kdc/kdc.conf 文件。设置如下:

[kdcdefaults]

kdc_ports = 88

kdc_tcp_ports = 88

[realms]

HADOOP.HYLANDTEC.COM = {

#master_key_type = aes256-cts

max_renewable_life = 7d

max_life = 2d 0h 0m 0s

default_principal_flags = +renewable

krbMaxTicketLife = 172800

krbMaxRenewableAge = 604800

acl_file = /var/kerberos/krb5kdc/kadm5.acl

dict_file = /usr/share/dict/words

admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab

supported_enctypes =  aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal

}

编辑/var/kerberos/krb5kdc/kadm5.acl 文件,配置如下:

*/admin@HADOOP.HYLANDTEC.COM    *

执行以下命令,新增root用户

kadmin.local  -q “addprinc root/admin@HADOOP.HYLANTEC.COM

配置完成后执行以下命令启动kerberos服务:

service krb5kdc start

service kadmin start

经配置好的/etc/krb5.conf 文件分发至hadoop各台机器即可。kerberos服务器安装完成。

 

HADOOP kerberos 配置

按照官方文档配置即可,没有问题。

https://ccp.cloudera.com/display/CDH4DOC/Configuring+Hadoop+Security+in+CDH4

有时候kerberos出错的提示很不明朗的时候。设置如下环境变量很有帮助:

export HADOOP_OPTS=”-Dsun.security.krb5.debug=true”

参考资料:

【1】 Hadoop Securit Design  

【2】Hadoop Security Design Just Add Kerberos? Really?

【3】Hadoop Security Overview

【4】Hadoop Kerberos安全机制介绍

【5】Configuring Hadoop Security in CDH4

 

RFC 3961

Kerberos ETypes Kerberos加密类型代码

 

	encryption type                etype      section or comment
      -----------------------------------------------------------------
      des-cbc-crc                        1             6.2.3
      des-cbc-md4                        2             6.2.2
      des-cbc-md5                        3             6.2.1
      [reserved]                         4
      des3-cbc-md5                       5
      [reserved]                         6
      des3-cbc-sha1                      7
      dsaWithSHA1-CmsOID                 9           (pkinit)
      md5WithRSAEncryption-CmsOID       10           (pkinit)
      sha1WithRSAEncryption-CmsOID      11           (pkinit)
      rc2CBC-EnvOID                     12           (pkinit)
      rsaEncryption-EnvOID              13   (pkinit from PKCS#1 v1.5)
      rsaES-OAEP-ENV-OID                14   (pkinit from PKCS#1 v2.0)
      des-ede3-cbc-Env-OID              15           (pkinit)
      des3-cbc-sha1-kd                  16              6.3
      aes128-cts-hmac-sha1-96           17          [KRB5-AES]
      aes256-cts-hmac-sha1-96           18          [KRB5-AES]
      rc4-hmac                          23          (Microsoft)
      rc4-hmac-exp                      24          (Microsoft)
      subkey-keymaterial                65     (opaque; PacketCable)

 

 

hadoop 0.20.2 capacity scheduler 配置方法

本文采用的是CDH4+MAPREDUCE 0.20

hadoop中共有6台机作为tasktracker ,每台机配置map和reduce个2个slots

队列名 Capacity Maximum  Capacity
 defaults  10%
 edp  50%  90%
 hive  40%  80%

设置完资源后,设置队列的ACL,必须具有相关权限才能向指定队列中提交任务。

队列名 权限
 defaults 所有用户可提交
 edp xhdeng可提交
 hive root及hive用户可提交

登录jobtracker机器

将/usr/lib/hadoop-0.20-mapreduce/contrib/capacity-scheduler/下的hadoop-capacity-scheduler-2.0.0-mr1-cdh4.0.1.jar 复制到/usr/lib/hadoop/lib/目录下

修改/etc/hadoop/conf 下的mapred-site.xml 在其中新增

<property>
<name>mapred.jobtracker.taskScheduler</name>
<value>org.apache.hadoop.mapred.CapacityTaskScheduler</value>
</property>

<property>
<name>mapred.queue.names</name>
<value>default,edp,hive</value>
</property>

<property>
<name>mapred.acls.enabled</name>
<value>true</value>
<description> Specifies whether ACLs should be checked
for authorization of users for doing various queue and job level operations.
ACLs are disabled by default. If enabled, access control checks are made by
JobTracker and TaskTracker when requests are made by users for queue
operations like submit job to a queue and kill a job in the queue and job
operations like viewing the job-details (See mapreduce.job.acl-view-job)
or for modifying the job (See mapreduce.job.acl-modify-job) using
Map/Reduce APIs, RPCs or via the console and web user interfaces.
</description>
</property>

在/etc/hadoop/conf 下新建capacity-scheduler.xml

<?xml version=”1.0″?>

<!– This is the configuration file for the resource manager in Hadoop. –>
<!– You can configure various scheduling parameters related to queues. –>
<!– The properties for a queue follow a naming convention,such as, –>
<!– mapred.capacity-scheduler.queue.<queue-name>.property-name. –>

<configuration>

<property>
<name>mapred.capacity-scheduler.maximum-system-jobs</name>
<value>6</value>
<description>Maximum number of jobs in the system which can be initialized,
concurrently, by the CapacityScheduler.
</description>
</property>

<property>
<name>mapred.capacity-scheduler.queue.default.capacity</name>
<value>10</value>
<description>Percentage of the number of slots in the cluster that are
to be available for jobs in this queue.
</description>
</property>

<property>
<name>mapred.capacity-scheduler.queue.default.maximum-capacity</name>
<value>-1</value>
<description>
maximum-capacity defines a limit beyond which a queue cannot use the capacity of the cluster.
This provides a means to limit how much excess capacity a queue can use. By default, there is no limit.
The maximum-capacity of a queue can only be greater than or equal to its minimum capacity.
Default value of -1 implies a queue can use complete capacity of the cluster.

This property could be to curtail certain jobs which are long running in nature from occupying more than a
certain percentage of the cluster, which in the absence of pre-emption, could lead to capacity guarantees of
other queues being affected.

One important thing to note is that maximum-capacity is a percentage , so based on the cluster’s capacity
the max capacity would change. So if large no of nodes or racks get added to the cluster , max Capacity in
absolute terms would increase accordingly.
</description>
</property>

<property>
<name>mapred.capacity-scheduler.queue.default.supports-priority</name>
<value>false</value>
<description>If true, priorities of jobs will be taken into
account in scheduling decisions.
</description>
</property>

<property>
<name>mapred.capacity-scheduler.queue.default.minimum-user-limit-percent</name>
<value>100</value>
<description> Each queue enforces a limit on the percentage of resources
allocated to a user at any given time, if there is competition for them.
This user limit can vary between a minimum and maximum value. The former
depends on the number of users who have submitted jobs, and the latter is
set to this property value. For example, suppose the value of this
property is 25. If two users have submitted jobs to a queue, no single
user can use more than 50% of the queue resources. If a third user submits
a job, no single user can use more than 33% of the queue resources. With 4
or more users, no user can use more than 25% of the queue’s resources. A
value of 100 implies no user limits are imposed.
</description>
</property>

<property>
<name>mapred.capacity-scheduler.queue.default.user-limit-factor</name>
<value>1</value>
<description>The multiple of the queue capacity which can be configured to
allow a single user to acquire more slots.
</description>
</property>

<property>
<name>mapred.capacity-scheduler.queue.default.maximum-initialized-active-tasks</name>
<value>200000</value>
<description>The maximum number of tasks, across all jobs in the queue,
which can be initialized concurrently. Once the queue’s jobs exceed this
limit they will be queued on disk.
</description>
</property>

<property>
<name>mapred.capacity-scheduler.queue.default.maximum-initialized-active-tasks-per-user</name>
<value>100000</value>
<description>The maximum number of tasks per-user, across all the of the
user’s jobs in the queue, which can be initialized concurrently. Once the
user’s jobs exceed this limit they will be queued on disk.
</description>
</property>

<property>
<name>mapred.capacity-scheduler.queue.default.init-accept-jobs-factor</name>
<value>10</value>
<description>The multipe of (maximum-system-jobs * queue-capacity) used to
determine the number of jobs which are accepted by the scheduler.
</description>
</property>

<!– The default configuration settings for the capacity task scheduler –>
<!– The default values would be applied to all the queues which don’t have –>
<!– the appropriate property for the particular queue –>
<property>
<name>mapred.capacity-scheduler.default-supports-priority</name>
<value>false</value>
<description>If true, priorities of jobs will be taken into
account in scheduling decisions by default in a job queue.
</description>
</property>

<property>
<name>mapred.capacity-scheduler.default-minimum-user-limit-percent</name>
<value>100</value>
<description>The percentage of the resources limited to a particular user
for the job queue at any given point of time by default.
</description>
</property>
<property>
<name>mapred.capacity-scheduler.default-user-limit-factor</name>
<value>1</value>
<description>The default multiple of queue-capacity which is used to
determine the amount of slots a single user can consume concurrently.
</description>
</property>

<property>
<name>mapred.capacity-scheduler.default-maximum-active-tasks-per-queue</name>
<value>200000</value>
<description>The default maximum number of tasks, across all jobs in the
queue, which can be initialized concurrently. Once the queue’s jobs exceed
this limit they will be queued on disk.
</description>
</property>

<property>
<name>mapred.capacity-scheduler.default-maximum-active-tasks-per-user</name>
<value>100000</value>
<description>The default maximum number of tasks per-user, across all the of
the user’s jobs in the queue, which can be initialized concurrently. Once
the user’s jobs exceed this limit they will be queued on disk.
</description>
</property>

<property>
<name>mapred.capacity-scheduler.default-init-accept-jobs-factor</name>
<value>10</value>
<description>The default multipe of (maximum-system-jobs * queue-capacity)
used to determine the number of jobs which are accepted by the scheduler.
</description>
</property>

<!– Capacity scheduler Job Initialization configuration parameters –>
<property>
<name>mapred.capacity-scheduler.init-poll-interval</name>
<value>5000</value>
<description>The amount of time in miliseconds which is used to poll
the job queues for jobs to initialize.
</description>
</property>
<property>
<name>mapred.capacity-scheduler.init-worker-threads</name>
<value>5</value>
<description>Number of worker threads which would be used by
Initialization poller to initialize jobs in a set of queue.
If number mentioned in property is equal to number of job queues
then a single thread would initialize jobs in a queue. If lesser
then a thread would get a set of queues assigned. If the number
is greater then number of threads would be equal to number of
job queues.
</description>
</property>

<property>
<name>mapred.capacity-scheduler.queue.hive.capacity</name>
<value>40</value>
</property>
<property>
<name>mapred.capacity-scheduler.queue.hive.maximum-capacity</name>
<value>80</value>
</property>
<property>
<name>mapred.capacity-scheduler.queue.hive.supports-priority</name>
<value>false</value>
</property>
<property>
<name>mapred.capacity-scheduler.queue.hive.minimum-user-limit-percent</name>
<value>20</value>
</property>
<property>
<name>mapred.capacity-scheduler.queue.hive.user-limit-factor</name>
<value>10</value>
</property>
<property>
<name>mapred.capacity-scheduler.queue.hive.maximum-initialized-active-tasks</name>
<value>200000</value>
</property>
<property>
<name>mapred.capacity-scheduler.queue.hive.maximum-initialized-active-tasks-per-user</name>
<value>100000</value>
</property>
<property>
<name>mapred.capacity-scheduler.queue.hive.init-accept-jobs-factor</name>
<value>100</value>
</property>

<!– queue: edp –>
<property>
<name>mapred.capacity-scheduler.queue.edp.capacity</name>
<value>50</value>
</property>
<property>
<name>mapred.capacity-scheduler.queue.edp.maximum-capacity</name>
<value>90</value>
</property>
<property>
<name>mapred.capacity-scheduler.queue.edp.supports-priority</name>
<value>false</value>
</property>
<property>
<name>mapred.capacity-scheduler.queue.edp.minimum-user-limit-percent</name>
<value>100</value>
</property>
<property>
<name>mapred.capacity-scheduler.queue.edp.user-limit-factor</name>
<value>1</value>
</property>
<property>
<name>mapred.capacity-scheduler.queue.edp.maximum-initialized-active-tasks</name>
<value>200000</value>
</property>
<property>
<name>mapred.capacity-scheduler.queue.edp.maximum-initialized-active-tasks-per-user</name>
<value>100000</value>
</property>
<property>
<name>mapred.capacity-scheduler.queue.edp.init-accept-jobs-factor</name>
<value>10</value>
</property>

</configuration>

在/etc/hadoop/conf 下新建mapred-queue-acls.xml

<configuration>
<property>
<name>mapred.queue.edp.acl-submit-job</name>
<value>xhdeng</value>
<description> Comma separated list of user and group names that are allowed
to submit jobs to the ‘default’ queue. The user list and the group list
are separated by a blank. For e.g. user1,user2 group1,group2.
If set to the special value ‘*’, it means all users are allowed to
submit jobs. If set to ‘ ‘(i.e. space), no user will be allowed to submit
jobs.

It is only used if authorization is enabled in Map/Reduce by setting the
configuration property mapred.acls.enabled to true.
Irrespective of this ACL configuration, the user who started the cluster and
cluster administrators configured via
mapreduce.cluster.administrators can submit jobs.
</description>
</property>
<property>
<name>mapred.queue.hive.acl-submit-job</name>
<value>hive,root</value>
<description> Comma separated list of user and group names that are allowed
to submit jobs to the ‘default’ queue. The user list and the group list
are separated by a blank. For e.g. user1,user2 group1,group2.
If set to the special value ‘*’, it means all users are allowed to
submit jobs. If set to ‘ ‘(i.e. space), no user will be allowed to submit
jobs.

It is only used if authorization is enabled in Map/Reduce by setting the
configuration property mapred.acls.enabled to true.
Irrespective of this ACL configuration, the user who started the cluster and
cluster administrators configured via
mapreduce.cluster.administrators can submit jobs.
</description>
</property>
<property>
<name>mapred.queue.default.acl-submit-job</name>
<value>*</value>
<description> Comma separated list of user and group names that are allowed
to submit jobs to the ‘default’ queue. The user list and the group list
are separated by a blank. For e.g. user1,user2 group1,group2.
If set to the special value ‘*’, it means all users are allowed to
submit jobs. If set to ‘ ‘(i.e. space), no user will be allowed to submit
jobs.

It is only used if authorization is enabled in Map/Reduce by setting the
configuration property mapred.acls.enabled to true.
Irrespective of this ACL configuration, the user who started the cluster and
cluster administrators configured via
mapreduce.cluster.administrators can submit jobs.
</description>
</property>
</configuration>

重启jobtracker,登录hadoop的map/reduce administration即可发现新的调度器生效。

 

Scheduling Information

Queue Name State Scheduling Information
hive running Queue configuration
Capacity Percentage: 40.0%
User Limit: 20%
Priority Supported: NO
————-
Map tasks
Capacity: 4 slots
Maximum capacity: 9 slots
Used capacity: 0 (0.0% of Capacity)
Running tasks: 0
————-
Reduce tasks
Capacity: 4 slots
Maximum capacity: 9 slots
Used capacity: 0 (0.0% of Capacity)
Running tasks: 0
————-
Job info
Number of Waiting Jobs: 0
Number of Initializing Jobs: 0
Number of users who have submitted jobs: 0
default running Queue configuration
Capacity Percentage: 10.0%
User Limit: 100%
Priority Supported: NO
————-
Map tasks
Capacity: 1 slots
Used capacity: 0 (0.0% of Capacity)
Running tasks: 0
————-
Reduce tasks
Capacity: 1 slots
Used capacity: 0 (0.0% of Capacity)
Running tasks: 0
————-
Job info
Number of Waiting Jobs: 0
Number of Initializing Jobs: 0
Number of users who have submitted jobs: 0
edp running Queue configuration
Capacity Percentage: 50.0%
User Limit: 100%
Priority Supported: NO
————-
Map tasks
Capacity: 6 slots
Maximum capacity: 10 slots
Used capacity: 0 (0.0% of Capacity)
Running tasks: 0
————-
Reduce tasks
Capacity: 6 slots
Maximum capacity: 10 slots
Used capacity: 0 (0.0% of Capacity)
Running tasks: 0
————-
Job info
Number of Waiting Jobs: 0
Number of Initializing Jobs: 0
Number of users who have submitted jobs: 0

 

如果修改了调度器的配置文件,无需重启整个jobtracker,使用以下命令刷新即可。

hadoop mradmin -refreshQueues

查看当前用户的acl可以使用以下命令查看。

mapred queue -showacls

Queue acls for user : root

Queue Operations
=====================
hive submit-job,administer-jobs
default submit-job,administer-jobs
edp administer-jobs

用root用户往edp队列中跑一个任务测试一下:

sudo  hadoop jar    hadoop-mapreduce-client-jobclient-2.0.0-cdh4.0.1-tests.jar TestDFSIO -D mapred.job.queue.name=edp  -write -nrFiles 6 -fileSize 1000

然后,必然的,报错了。

12/11/23 16:16:19 ERROR security.UserGroupInformation: PriviledgedActionException as:root (auth:SIMPLE) cause:org.apache.hadoop.security.AccessControlException: User root cannot perform operation SUBMIT_JOB on queue edp.
Please run “hadoop queue -showacls” command to find the queues you have access to .

用root用户往edp用户中跑一个任务测试一下:

sudo  hadoop jar    hadoop-mapreduce-client-jobclient-2.0.0-cdh4.0.1-tests.jar TestDFSIO  -write -nrFiles 6 -fileSize 1000

然后,必然的,报错了。

default running Queue configuration
Capacity Percentage: 10.0%
User Limit: 100%
Priority Supported: NO
————-
Map tasks
Capacity: 1 slots
Used capacity: 1 (100.0% of Capacity)
Running tasks: 1
Active users:
User ‘root’: 1 (100.0% of used capacity)
————-
Reduce tasks
Capacity: 1 slots
Used capacity: 0 (0.0% of Capacity)
Running tasks: 0
————-
Job info
Number of Waiting Jobs: 0
Number of Initializing Jobs: 0
Number of users who have submitted jobs: 1

跑起来了,很悲催的是只能使用1个slot。。。

那往hive队列上再调一次。。

 

Queue Name State Scheduling Information
hive running Queue configuration
Capacity Percentage: 40.0%
User Limit: 20%
Priority Supported: NO
————-
Map tasks
Capacity: 4 slots
Maximum capacity: 9 slots
Used capacity: 6 (150.0% of Capacity)
Running tasks: 6
Active users:
User ‘root’: 6 (100.0% of used capacity)
————-
Reduce tasks
Capacity: 4 slots
Maximum capacity: 9 slots
Used capacity: 0 (0.0% of Capacity)
Running tasks: 0
————-
Job info
Number of Waiting Jobs: 0
Number of Initializing Jobs: 0
Number of users who have submitted jobs: 1

提示:我们设置的capacity是4,而实际的则是Used capacity: 6 (150.0% of Capacity),符合我们的预期。

使用capacity scheduler ,集群的资源得到有效的管理可控制,即不会让一个用户跑死整个集群,也不会管得过死造成资源闲置。

 

 

 

 

Hadoop内置作业调度器与调度平台的集成

Hadoop 现在几乎已经成为业界在大数据上事实的标准,越来越多的企业开始采用hadoop进行数据的存储及处理。既然涉及数据处理,一个不可不提的术语就是“作业” or “job”,大量的作业必然要引入作业管理及调度,hadoop也不能例外。

传统企业中的调度工具,不管像是简单crontab,或者企业级的如control-M,很容易注意到,他们都主要考虑的是将作业分配到集群中的某一台,或者其中某几台上面运行。但是像hadoop  这种大规模分布式计算的集群,考虑都不足。通常Hadoop整个集群是作为一个整体对外服务,考虑的是集群整体资源利用的最大化,HDFS的多副本策略使得集群某一单独节点运行是否正常不再重要,hadoop的一个重要理念是移动计算而不是数据,所以hadoop会尽量在数据存储的节点进行运算,而传统调度工具需要支持这些特点就需要进行大量的改造,本文只讨论传统调度工具如何与hadoop内置调度器更好结合。作业监控部分则不在本文讨论范围内。

 hadoop 的内置调度机制

在 2008 年以前,集成在 JobTracker 中的原有调度算法仅有 FIFO。在 FIFO 调度中,JobTracker 从工作队列中拉取作业,最老的作业最先。当hadoop最初出现的时候,主要是设计用来进行大型的批处理例如网页索引,日志挖掘,用户将任务提交至队列,而后集群按照提交的先后顺序执行即可,FIFO也足够用了。然后,当越来越多的数据放在hadoop集群后,另一个问题出现了,人们开始希望在多个用户间共享集群。而此时Hadoop 只支持与 JobTracker 逻辑混合在一起的单一调度器。

于是2008年5月18日有人提交了一个Improvement的issue 。HADOOP-3412 (Refactor the scheduler out of the JobTracker ),调度器从jobtracker的代码中分离出来,调度器变成可插入式的,在JobTracker中加载和调用,用户可以在配置文件mapred-site.xml中的mapred.jobtracker.taskScheduler属性中指定自己的调度器。

当前Hadoop自带的调度器随着hadoop版本的不同会略有区别,但是最常见的三种调度器,分别是FIFO(默认调度器),Capacity Scheduler (容量调度器)和FairScheduler(公平调度器)以下逐一介绍其算法及其适用场景:

1. FIFO

 1.1 简介

FIFO(First In First Out)算法。所有用户的作业都被提交到一个队列中,然后由JobTracker按照作业提交时间的先后顺序选择将被执行的作业。 在hadoop的后期版本中,增加了优先级处理功能,可以通过设置mapred.job.priority属性 或者在JobClient 调用 setJobPriority() 方法来进行优先级设置(优先级可以设置为 VERY_HIGH, HIGH, NORMAL, LOW, VERY_LOW), Job scheduler在选择下一运行作业时,会选择一个最高优先级的作业,而后再根据提交时间排序,但是由于FIFO调度器不支持抢占,所以一个高优先级作业仍然可能被一个长期运行的低优先级作业所阻塞。FIFO不考虑各种作业资源需求的不同。

FIFO 是hadoop的默认调度器。

1.2 与传统调度工具的集成

FIFO方式适用于单系统,单用户的hadoop集群,作业提交给hadoop集群时一般需要传递的参数只有优先级

调度平台改造部分:

1)增加作业类型:map-reduce,hive,sqoop 。使得作业的命令行可以在调度平台中配置产生。

2)将作业的优先级转换成为hadoop标准(VERY_HIGH, HIGH, NORMAL, LOW, VERY_LOW), 并在想hadoop集群提交作业时同时设置作业优先级。

优先级设置的方法有以下两种

#1:作业源码中调用API       JobConf.setJobPriority(JobPriority.NORMAL)

#2:在执行的时候在命令行中添加以下参数 -D mapred.job.priority=HIGH

实际调度中通常会由调度平台动态生成命令行的方式进行。

 

2.Capacity Scheduler

2.1 简介

CapacityScheduler 是Yahoo开发并捐献的,容量调度器是设计目标是让hadoop应用程序真正成为一个共享的,多租户的集群,并且使得集群的吞吐量和利用率最大化。说的有点绕口,咱们细说下容量调度器的来龙去脉。

传统上企业中每个系统都会有自己的私有服务器用来保证自己的系统在高峰情况,或者接近高峰情况下也能达到预设的SLA,而这样基本上都会导致很差的资源平均利用率,并且企业内众多的独立集群也带来更大的管理成本。

在企业内共享大规模的hadoop集群使得我们可以更加高效,低成本的使用计算资源,但是人们总是担心使用共享集群的话,如果其他系统占用了大量资源的话将会使得他们自己的应用在需要的时候无法获取足够的资源以致应用无法达到预定的SLA.

而容量调度器正是设计用来共享一个大规模的集群,并给予每个系统性能保证。中心思想是各系统按照自己计算的需要,共同投资一个hadoop集群,集群中的可用资源在各系统中分享。这样的集群有个附加的好处是单个系统可以利用别的系统的闲置计算资源进行计算,使得资源的利用更加弹性及高效。

而在各系统间共享集群就必须使系统对多租户( multi-tenancy)设计有很强的支持,因为必须给予每个系统性能保证。并且要确保集群在遇到一个异常的应用/用户/数据集等也不受影响。CapacityScheduler提供一系列严格的限制来确保一个应用/用户/队列不能消耗不恰当的集群资源,同时CapacityScheduler还限制了一个单一的用户/队列可以初始化/等待的应用程序数量来确保集群的公平使用和稳定性。

利用闲置资源有个问题,大部分的系统是一个大的项目群,里面有众多的子系统,他们希望闲置资源优先用于满足同一项目群内子系统的需求,如仍有剩余再共享给其他系统使用,[MAPREDUCE-824]提出了层次队列(hierarchical queues )的概念,资源优先在子队列中共享,如还有剩余再共享给其他队列。此功能在0.21.0版本中实现。

2.2 特性

以下是Apache Hadoop 2.0.2-alpha官方文档中的特性说明,很官方,很权威。

 

层次队列-层次队列的支持可以确保资源在一个系统的子队列中共享,而后才允许其他队列使用空闲资源,使得资源分配更加可控及可预测。

性能保证-各个队列只分配了集群的一小部分性能,这样只有部分容量供队列进行处置。所有提交进同一个队列的应用程序都可以访问队列所分配的容量,管理员可以给每一个队列配置软性的限制或者硬性限制。

安全-每个队列都有严格的访问控制列表(ACLs) ,可以控制那个用户可以提交进入哪个队列,同时也有安全机制来保证用户不能查看 and/or 修改其他用户的程序,同样也支持按队列/按系统的管理角色。

弹性-空闲的资源可以分配给其他超过其处理容量的队列。如果将来某一个时刻先前空闲的队列再次需要这些资源,在这些资源所分配到的任务完成后,空闲资源会被重新分配给先前空闲的队列(不支持抢占)这样保证了资源以一种可预期,弹性的方式分配给队列。这个还能同时防止人为的资源孤岛,提高了集群的使用率。

多租户-提供了多种的限制来保证一个单应用/用户/队列独占队列或者集群,避免集群不堪重负。

易维护– 1)配置可动态加载,队列的定义及属性可以在运行时改变,可以将对晕乎的影响降到最低,同时也提供控制台接口可以让用户或者管理员查看当前系统中各个队列的资源分配情况,管理员可以在运行时增加队列,但是注意不能在运行时删除。2),清空队列,管理员可以在运行时停止一个队列,队列处于停止状态时已经在队列中的作业会继续完成,但是不能往里再新增作业

基于资源的调度 – 支持一些资源密集的作业,作业可以指定一个高于默认值的资源需求量,进而可以满足作业的不同的资源需求,当前,资源内存仅支持内存

上面的看起来有的复杂,还需要了解的几个很重要的特性是:

支持多用户多队列,支持多系统多用户共享集群

单个队列是FIFO调度方式,队列内可以开启优先级控制功能(优先级控制默认是关闭状态)。

支持资源共享,队列内资源有剩余时,可共享给其他缺资源的队列。

当某个tasktracker上出现空闲slot时,调度器的调度策略是,先选择资源利用率(numSlotsOccupied/capacity)低的队列,然后在队列中考虑FIFO和优先级进行作业选择,选择的时候会判断做业所在的用户资源未超限,以及有足够内存满足作业的内存需求。

计算能力调度器调度job时会考虑作业的内存限制,为了满足某些特殊job的特殊内存需求,可能会为该job分配多个slot;例如一个slot是1G内存,一个需要2G内存的程序就会被分配2个slot。fifo及公平调度器不具备此功能。

 

2.3  配置实例

 

2.4  与传统调度工具的集成

增加作业类型及优先级的需求同章节1.2,此外还需要进行队列配置

1)在调度平台上新增hadoop队列配置,配置好队列,及队列的资源限制后,可以使用调度工具指定作业在某一队列中运行。

map-reduce作业:可以在作业代码中设置代码属于的队列 conf.setQueueName(“queue1”);

或者在执行的时候在命令行中添加以下参数 -D mapred.job.queue.name=queue1

hive:在执行hive任务时,设置hive属于的队列,例如queue1:

set mapred.job.queue.name=queue1;

2)设置作业的内存资源量

通过设置一下两个属性,可以设置每个task所需要的内存量,如有必要,调度器会为每个task可以申请多个slot以获取根多内存,但最大值不超过mapred.cluster.max.map.memory.mb及mapred.cluster.max.map.memory.mb ,可以将值设置为-1以禁用此功能。

mapred.job.reduce.memory.mb

mapred.job.map.memory.mb

 

请注意:tasktracker需要先设置

mapred.tasktracker.vmem.reserved,

mapred.task.default.maxvmem,

mapred.task.default.maxvmem,以启用内存监控功能。

3.Fair Scheduler

 3.1 简介

公平调度器是由facebook贡献的,适合于多用户共享集群的环境的调度器.

公平调度器在设计时有以下4个主要目标:

1)即使在与大作业共享集群的时候也能迅速的完成小作业。不像Hadoop默认的FIFO调度器,公平调度器可以在大作业运行时让小作业的执行也能取得执行进展,同时又不会使大作业处于资源“饥饿”状态。

2)在一个共享集群里,可以同时运行一些实验性的作业同时对集群中的生产作业提供可靠的SLA。

3)便于管理及配置,程序在遇到一些异常情况的时候也能做出合适的处理,用户也仅在他们需要一些高级功能的时候才需要进行配置。

4)支持在运行时进行重配置,而不需要重启集群。

公平调度器按资源池(pool)来组织作业,并把资源公平的分到这些资源池里。默认情况下,每一个用户拥有一个独立的资源池,以使每个用户都能获得一份等同的集群资源而不管他们提交了多少作业。按用户的 Unix 群组或作业配置(jobconf)属性来设置作业的资源池也是可以的。在每一个资源池内,会使用公平共享(fair sharing)的方法在运行作业之间共享容量(capacity)。用户也可以给予资源池相应的权重,以不按比例的方式共享集群。

除了提供公平共享方法外,公平调度器允许赋给资源池保证(guaranteed)最小共享资源,这个用在确保特定用户、群组或生产应用程序总能获取到足够的资源时是很有用的。当一个资源池包含作业时,它至少能获取到它的最小共享资源,但是当资源池不完全需要它所拥有的保证共享资源时,额外的部分会在其它资源池间进行切分。

3.2 特性

公平调度器的主要特性如下:

支持多用户多队列

资源公平共享(公平共享量由优先级决定)

保证最小共享量

支持时间片抢占

限制作业并发量,以防止中间数据塞满磁盘

 

3.2.1 Pools

公平调度器将作业分为‘pools’,而后在pool间公平的共享资源,每个pool内可以使用FIFO或者公平共享(fair sharing)的方式进行调度。作业在哪个pool由一个Jobconf 属性决定,“pool name property”默认取mapreduce.job.user.name,所以是每个用户一个pool,但是也可以取其他属性,例如group.name,这样就可以每个unix 组一个group。

一个通常使用的方法是把pool名称设为一个未使用的属性名,例如pool.name,而后将此值默认设为mapreduce.job.user.name,这样既可以让每个用户一个pool,也可以通过直接设置pool.name 将作业制定到一个特殊的pool。以下是一个mapred-site.xml中进行配置的简单示例:

<property>

<name>mapred.fairscheduler.poolnameproperty</name>

<value>pool.name</value>

</property>

 

<property>

<name>pool.name</name>

<value>${mapreduce.job.user.name}</value>

</property>

 

3.2.2 最小份额

通常情况下,活动的pool(内有作业的)会在集群中平分map和reduce的slots,但是也可以对指定的pool设置一个最小的map和reduce的slot的份额。这样pool在活动时就会给予指定的slot数量,即便公平份额是小于指定的份额。这样设置以后在非生产作业与生产作业共享hadoop集群的时候对保证生产作业的SLA非常有用。最小份额的设置有以下3个影响

1)pool的公平份额会大于等于其设置的最小份额,slot会冲其他pool的份额中取缺额以达到pool预设份额,有个例外是如果每个活动pool的最小份额加起来大于集群中全部slot的数量,如果遇到这种情况,每个pool中的份额都会成比例的缩小。

2)少于其最小份额的pool会在slot有空闲时最先获得slot。

3)可以给pool设置一个抢占超时(preemption timeout)属性,如果获得的slot不足最小份额,允许其杀死其他作业的task来获得slot,带抢占的最小份额实际使用起来有点像SLA。

请注意,如果一个pool不是活动的,其最小份额并不会被预留,slot会分配给其他pools。

 

3.2.3 抢占

就像上一小节说到的那样,调度器会将一个pool中作业的task杀死一边满足另一个pool的最小份额,我们把这样的动作成为抢占,准确的说这个称为最小份额抢占(min share preemption),因为还有一个类型的抢占称为公平份额抢占(fair share preemption),如果pool间slot份额未公平共享,也自动会将作业的task杀死以公平分配slot。公平份额的抢占远比最小份额抢占保守,因为未获得公平份额的作业通产是一些非生产的作业,可以容忍一定程度的不公平,公平份额抢占只有在一个pool只获得低于一半的公平份额,并且达到一个预设的抢占超时后才会发生,这个超时通常会设置的比较高(例如10分钟)

两种抢占调度器都会从过度调度的pools中杀死最近启动的一个task,以使抢占导致的资源浪费降到最低。

 

3.2.4 运行作业限制

公平调度器可以限制每个pool,每个用户可以并行运行的作业。这样就可以有效限制集群上产生的中间文件,作业根据提交时间和优先级运行,如果提交的作业超过限制则会等到正在运行的作业完成后再调起。

 

3.2.5 作业优先级

在pool内,无论pool内的调度模式是FIFO还是公平共享(fair sharing)都可以使用优先级来控制作业调度。

1)在FIFO的pools中,作业使用hadoop的默认调度器FIFO,首先根据优先级,而后根据提交时间排序决定下一调起作业。

2)在公平共享的pools中,作业优先级被用来设置作业的权重以控制作业所得到的slot份额,普通优先级的权重是1.0,每个优先级级别间权重为上一级别的两倍。例如一个高优先级的权重为2.0,这样他就得到普通优先级两倍的slot份额。

 

3.2.6 pool 权重

pool可以赋予权重以使集群中的资源不公平的共享。例如一个权重设为2.0的pool得到一个设为1.0的pool的两倍的份额。

3.2.7 延迟调度

公平调度器包含一个延迟调度的算法以提高数据的本地性。hadoop的一个重要理念是移动计算而非移动数据,计算尽量在存储数据的节点上运行,但是公平调度的算法是总是将slot分配给份额比较少的pool中的第一个作业,这就引起作业的数据本地性很差,需要通过网络将数据传输到本地。 1)如果队列头的作业是一个小作业,那么在集群的一个心跳期间接受到的数据就是作业所需的本地数据的几率会很低,从而如果我们总是将slot分配给队列头作业的话,小作业的本地性就会很差。

2)公平调度器有个很强的趋势是给作业分配刚刚完成task的slot,因为当一个task完成,作业就低于其公平份额,

延迟调度算法可以暂时的牺牲公平性来提高数据的本地性,如果队列头的任务无法在tasktracker中进行一个本地任务,他会发出心跳,并且跳过,这样其他的运行作业就会根据pool份额和pool内的调度规则来寻找一个可以运行本地task的作业,但是如果队列头的作业等待的了足够长的时间,他就会允许在数据同一机架的服务器上调去,如果再有足够长的时间,就会允许在不同机架上调起。这个延迟的时间被称为本地延迟(locality delays),通常只延迟几秒就已经足够答复提供数据的本地性。本地延迟在mapred-site.xml中设置,可以设置为0表示禁用。默认值设为1.5倍心跳时间。

3.2.8 管理

公平调度器包含一个web界面可以显示活动pools,作业和其公平公平份额,将作业在pool间移动或者改变作业的优先级。同时,作业的配置文件在被改变时会自动重新加载以便在运行状态下自动重配置。

3.2.9 调度算法

公平分享的一个简单的实现方式就是,无论何时一个slot空闲下来,就将其分配到运行task数最少的那个pool,这样就保证了各个pool间获得相等的slots,除非pool的需求少于其公平份额,那多余的slots就会在其他pool间平分。一下两个特性让公平调度器的算法更加复杂

1) Pool权重意味着某些pool会获得根多的slots,例如一个权重为2的pool获得的slots就会比一个权重为1多两倍,这个通过把调度算法改为将slot分配到runningTasks/Weight 最小的pool来实现。

2)最小份额意味着少于其最小份额的pool会最先得到slots,当我们把pools排序来选择下一个调度的pool时候,我们将少于其最小份额的pool放在大于其最小份额的pool前面,而那些小于其最小份额的pool通过其少于最小份额的比例进行排序。

公平调度器采用一个层次的调度来分配tasks,首选根据如上策略选择一个pool来分配task,而后pool内通过fifo或者fair sharing 来进行作业的内部调度。

 3.2.10 fair share 计算

最后再说一下pool的公平共享量的计算方法。公平共享量是基于最小共享量和共享资源量计算得到的,它反映的是某个pool经过资源共享(某些pool的资源用不了,会自动共享给其他pool)之后,一共可以获取的资源总量,一般会大于等于最小共享量。

如果每个pool没有配置最小共享量,且提交了无限量的作业,则让每个pool的slotsAssigned / weight值相同即可。(其中slotsAssgined表示分配给该pool的slot数,weight表示pool的权重)。

而有了最小共享量minShare和pool中的需求量demand(该pool中所有作业尚需的slot总数)后,计算公平共享量fairShare需注意以下两种情况:

(1) 某些pool中的最小共享量可能用不完

(2) 给配给某些pool的资源量小于其最小共享量

考虑到以上两种情况,调度器设计了基于比率R的公平资源分配方法(设集群中资源总量为totalSlots):

[1] 如果一个pool的demand<R*weight,则该pool的fairShare=demand

[2] 如果一个pool的minShare>weight,则该pool的fairShare=minShare

[3] 除此之外,所有pool的fairShare=R*weight

[4] 所有pool的的fairShare之和应为totalSlots

通过以上算法计算出的公平共享量即为“公平调度器”的“公平”含义之所在,应尽量保证每个pool获取的资源量为fairshare,如果一定时间期限内达不到,则抢占资源。

r的算法详见下图:

 

 

 3.3  与传统调度工具的集成

集成上与2.4节类似,调度服务器通过使用不同的操作系统用户调起作业进入合适的pool。

 

参考资料

——————————————————————————————————

【1】 Hadoop 中的调度

【2】Refactor the scheduler out of the JobTracker

【3】如何编写Hadoop调度器

【4】Hadoop MapReduce Next Generation – Capacity Scheduler

【5】(MAPREDUCE-824)Support a hierarchy of queues in the capacity scheduler

【6】Hadoop-0.21.0公平调度器算法解析

 

 

Hadoop 各商业发行版之比较

Hadoop的发行版除了社区的Apache hadoop外,cloudera,hortonworks,mapR,EMC,IBM,INTEL,华为等等都提供了自己的商业版本。商业版主要是提供了专业的技术支持,这对一些大型企业尤其重要。每个发行版都有自己的一些特点,本文就各发行版做简单介绍。

2008 年成立的 Cloudera 是最早将 Hadoop 商用的公司,为合作伙伴提供 Hadoop 的商用解决方案,主要是包括支持,咨询服务,培训。2009年hadoop的创始人 Doug Cutting也任职于 Cloudera 公司。Cloudera产品主要为CDH,Cloudera Manager,Cloudera Support。CDH是Cloudera的hadoop发行版,完全开源,比Apache hadoop在兼容性,安全性,稳定性上有增强。Cloudera Manager是集群的软件分发及管理监控平台,可以在几个小时内部署好一个hadoop集群,并对集群的节点及服务进行实时监控。Cloudera Support即是对hadoop的技术支持。cloudera的标价为每年每个节点4000美元。

2011年成立的Hortonworks是雅虎与硅谷风投公司Benchmark Capital合资组建的公司。公司成立之初吸纳了大约25名至30名专门研究Hadoop的雅虎工程师,上述工程师均在2005年开始协助雅虎开发Hadoop,这些工程师贡献了hadoop 80%的代码。。雅虎工程副总裁、雅虎Hadoop开发团队负责人Eric Baldeschwieler出任Hortonworks的首席执行官。Hortonworks 的主打产品是Hortonworks Data Platform (HDP),也同样是100%开源的产品,HDP除了常见的项目外还包含了Ambari,一款开源的安装和管理系统。HCatalog,一个元数据管理系统。

HDP的Datasheet中描述的版本特点是

集成和测试封装 – HDP包括稳定版本的Apache Hadoop的所有关键组件,集成和测试封装。

安装方便– HDP包括一个现代化的,直观的用户界面的安装和配置工具。

管理和监控服务 – HDP包括直观的仪表板,为监测集群和建立警示。

数据集成服务 – HDP包括Talend大数据平台,领先的开源整合工具,轻松连接Hadoop集群,而无需编写Hadoop代码的数据系统集成工具。

元数据服务 – HDP包括的Apache HCatalog,从而简化了Hadoop的应用程序之间和Hadoop和其他数据系统之间的数据共享。

高可用性– HDP与成熟的高可用性解决方案的无缝集成。

定价以集群为基础,每10个节点每年为12500美元。

cloudera和hortonworks均是在不断的提交代码完善Apache hadoop,而2009年成立的MapR公司在Hadoop领域显得有点特立独行,它提供了一款独特的发行版 。Hadoop在性能(在当前Hadoop的设计中,所有的meta data操作都要通过集中式的Namenode来进行,Namenode有可能是性能的瓶颈;M/R 应用程序需要通过DataNode来访问HDFS, 这就涉及到格外的进程切换和网络传输开销),可靠性与扩展性(namenode,jobtracker单点问题),企业级应用上的弱点(比如完全可读写的文件系统,snapshot,mirror等等)各大厂商均知,MapR则认为,Hadoop的这些缺陷来自于其架构设计本身,小修小补不能解决问题。他们选择了一条艰难得多的路: 用新架构重写HDFS,同时在API级别,和目前的Hadoop 发行版保持兼容。这家2009年成立的创业公司,在蛰伏了两年之后,终于一鸣惊人,大放异彩。他们成功的“构建一个HDFS的私有替代品,这个替代品比当前的开源版本快三倍,自带快照功能,而且支持无Namenode单点故障(SPOF),并且在API上和兼容,所以可以考虑将其作为替代方案。” mapR版本不再需要单独的namenode机器,元数据分散在集群中,也类似数据默认存储三份。也不再需要用NAS来协助namenode做元数据备份,提供了机器使用率。还有个重要的特点的可以使用nfs直接访问hdfs,提供了与旧有应用的兼容性。镜像功能也很适合做数据备份,而且支持跨数据中心的镜像,快照功能对于数据的恢复作用明显。据报道mapR标价也为每年每个节点4000美元。

mapR有免费和商业两个版本,免费版本在功能上有所缩减。

EMC的Greenplum HD是基于mapR版本二次开发改造而成,特点同mapR。

IBM在去年5月推出了InfoSphere BigInsights软件。该软件包括Apache Hadoop发行版、面向MapReduce编程的Pig编程语言、针对IBM的DB2数据库的连接件以及IBM BigSheets,后者是一种基于浏览器的、使用电子表格隐喻(spreadsheet-metaphor)的界面,用于探究和分析Hadoop里面的数据。IBM在平台管理,安全认证,作业调度算法,与DB2及netezza的集成上做了增强。从IBM中国开发中心信息管理总经理朱辉下面这句话就可以看出IBM对于biginsights的定位:BigInsights并没有替代OLAP(Online Analytical Processing)或OLTP(Online Transaction Processing)应用程序,但它可以整合其中,用于“过滤大量原始数据并合并结果,将结果以结构化数据的形式保存在DBMS或数据仓库中”。

传统的硬件厂商,华为,Intel也提供hadoop的版本

Intel 的商业版本,主要是强调其能提供全面的软硬件解决方案设计,针对硬件具有更好的性能优化,以及提供集群管理工具和安装工具简化了 Hadoop 的安装和配置,能够提供项目规划到实施各阶段专业的咨询服务,实际中采购Intel版本貌似动力不足。

华为在硬件上具有天然的优势,在网络,虚拟化,PC机等都有很强的硬件实力。华为的hadoop版本基于自研的Hadoop HA平台,构建NameNode、JobTracker、HiveServer的HA功能,进程故障后系统自动Failover,无需人工干预,这个也是对hadoop的小修补,远不如mapR解决的彻底。华为在hadoop社区中的Contributor和committer也是国内最多的,算是国内技术实力较强的公司。

———————————————————————————————————

各发行版大事记

mapR

2011-05-25 :宣布与EMC合作,EMC GREENPLUM HD 提供hadoop基础版本。

2012-01-18:宣布与rainstor合作,

2012-03-05:宣布与informatica合作

2012-06-13:宣布成为Amazon Elastic MapReduce的计算选项

2012-06-28:成为Google App Engine的计算引擎

HortonWorks

2011-10-12:微软宣布将于从雅虎分拆出来的Hortonworks合作开发,在Apache Hadoop上实现搭建Windows Server以及Windows Azure平台。Hortonworks作为微软的战略合作伙伴将会借助自己在此领域的专长帮助最大化将Hadoop集成到微软的产品之中。

2011-11-02:Hortonworks,Apache Hadoop项目的一个主要贡献者,将分发Informatica HParser Community Edition。为Hadoop推出Informatica HParser。作为业界首个针对Hadoop环境的数据解析转换解决方案,Informatica HParser利用MapReduce框架的并行性以有效地在Hadoop中把非结构化复杂数据变成一个结构化或半结构化的格式。

2011-03-03 在今年3月初的Strate大会上,开源数据集成软件厂商Talend宣布Hortonworks达成协议,将合作把Talend开源数据集成工具带入Apache

2012-03-12 :TeraData就在周二宣布将与Hortonworks合作,并为客户提供产品和服务。

2012-06-17:Hortonworks宣布将与VMware合作并推出一套运行于HDP高可靠性模式的工具。VMware的vSphere可监测Hadoop的NameNode和JobTracker服务。如果服务出现错误时,vSphere可重定向操作实时备份服务,以保持集群的运行。

 

Cloudera:

2011年8月5日 – 戴尔宣布Cloudera新的合作伙伴关系

2011年10月20日 – SGI和Cloudera联合宣布,他们的公司已经签署协议,为SGI分发Cloudera的软件预装在SGI Hadoop集群中。

2012-01-26:今年1月发布的甲骨文大数据机(Oracle Big Data Appliance)将甲骨文-Sun分布式计算平台与Cloudera的Apache Hadoop发行版、Cloudera管理器管理控制台、R分析软件的开源发行版以及甲骨文NoSQL数据库结合起来。甲骨文还包括连接件,因而让数据能够在大数据机与甲骨文Exadata或传统的甲骨文数据库部署环境之间来回传送。

2012-04-26:IBM宣布将Cloudera作为Hadoop商用版本的首选大数据平台。

 

———————————————————————————————————————-

除了mapR以外的发行版。基本都是在Apache hadoop上做了略微改进,只有mapR与Apache hadoop有较大区别,以下表格是一些功能上的区别,EMC Greenplum HD 是基于mapR所以功能同mapR。

http://www.slideshare.net/mcsrivas/design-scale-and-performance-of-maprs-distribution-for-hadoop

http://qing.weibo.com/2294942122/88ca09aa330003wz.html

http://qing.weibo.com/2294942122/88ca09aa330003x6.html

http://qing.weibo.com/2294942122/88ca09aa330003zv.html

http://qing.weibo.com/2294942122/88ca09aa330003zz.html

https://issues.apache.org/jira/browse/HDFS-347