ASPIRE

Hadoop的版本选型

=Start=

缘由：

最开始在接触到Hadoop这个概念的时候，我以为它就只有Apache一家在搞，只有版本不同的差异。最近在较为深入的了解之后才发现，根本不是这么回事，想搞清楚不容易。所以这里整理一下我在学习这方面知识时整理的一些资料，方便自己及后来者参考。

正文：

参考解答：

目前Hadoop的发行版除了Apache的开源版本之外，还有华为发行版、Intel发行版、Cloudera发行版(CDH)、Hortonworks发行版（HDP）、MapR等，所有这些发行版均是基于Apache Hadoop衍生出来的，因为Apache Hadoop的开源协议允许任何人对其进行修改并作为开源或者商业产品发布。国内大多数公司发行版是收费的，比如Intel发行版、华为发行版等。不收费的Hadoop版本主要有国外的四个，分别是Apache基金会hadoop、Cloudera版本（CDH）、Hortonworks版本（HDP）、MapR版本。

Apache社区版本优缺点

优点：

  • 完全开源免费
  • 社区活跃
  • 文档、资料详实

缺点：

  • 复杂的版本管理。版本管理比较混乱，各种版本层出不穷，让使用者不知所措。
  • 复杂的集群部署、安装、配置。通常按照集群需要编写大量的配置文件，分发到每一台节点上，容易出错，效率低下。
  • 复杂的集群运维。对集群的监控，运维，需要安装第三方的其他软件，如Ganglia，Nagois等，运维难度较大。
  • 复杂的生态环境。在Hadoop生态圈中，组件的选择、使用，比如Hive，Mahout，Sqoop，Flume，Spark，Oozie等等，需要大量考虑兼容性的问题，版本是否兼容，组件是否有冲突，编译是否能通过等。经常会浪费大量的时间去编译组件，解决版本冲突问题。
第三方发行版本（如CDH，HDP，MapR等）优缺点

优点：

  • 基于Apache协议，100%开源。
  • 版本管理清晰。比如Cloudera，CDH1，CDH2，CDH3，CDH4，CDH5等，后面加上补丁版本，如CDH4.1.0 patch level 923.142，表示在原生态Apache Hadoop 0.20.2基础上添加了1065个patch。
  • 比Apache Hadoop在兼容性、安全性、稳定性上有增强。第三方发行版通常都经过了大量的测试验证，有众多部署实例，大量的运行到各种生产环境。
  • 版本更新快。通常情况，比如CDH每个季度会有一个update，每一年会有一个release。
  • 基于稳定版本Apache Hadoop，并应用了最新Bug修复或Feature的patch
  • 提供了部署、安装、配置工具，大大提高了集群部署的效率，可以在几个小时内部署好集群。
  • 运维简单。提供了管理、监控、诊断、配置修改的工具，管理配置方便，定位问题快速、准确，使运维工作简单，有效。

缺点：

  • 有些会涉及到厂商锁定的问题（可以通过技术解决）。

版本选型时需要考虑的一些因素：
  1. 安装部署成本
  2. 稳定性
  3. 兼容性
  4. 扩展性
  5. 可运维性

更具体的需要结合公司的实际情况去进行选择。

 

参考链接：

=END=

Docker

,
, ,

《 “Hadoop的版本选型” 》 有 8 条评论

  4. 有赞大数据平台安全建设实践
    https://mp.weixin.qq.com/s/4G_OvlD_5uYr0o2m-qPW-Q
    `
    一、概述
    在大数据平台建设初期，安全也许并不是被重点关注的一环。大数据平台的定位主要是服务数据开发人员，提高数据开发效率，提供便捷的开发流程，有效支持数仓建设。大数据平台的用户都是公司内部人员。数据本身的安全性已经由公司层面的网络及物理机房的隔离来得到保证。那么数据平台建设过程中，需要考虑哪些安全性方面的问题？

    环境隔离，数据开发人员应当只需关注自己相关业务域的数据，也应该只能访问这一部分数据。从数据的角度，减小了被接触面，降低了被误操作的可能。从数据开发人员的角度，只能访问自己业务域的数据，在数据开发的过程中，可以减少干扰项，提高效率。

    数据脱敏，有些敏感数据即使是公司内部的数据开发人员，也需要限制其直接访问的权限。

    明晰权责，各业务域数据都有相应的负责人，对自己的数据负责。同时，所有数据访问与操作都有审计信息记录，对数据的转化与流动有据可查。

    最后，大数据平台的目标是赋能数据开发人员，提高数据开发效率，而安全管理必然会降低数据平台的便利性。如何平衡安全和便利性的关系，尤为重要。

    有赞大数据平台安全建设是在大数据平台本身的发展以及数仓元数据建设的过程中不断演进的。概括起来可以分为三个阶段。

    二、基于 ranger +组件 plugin 的权限控制
    三、基于 ranger 的权限管理服务
    四、基于 column masking 的数据脱敏
    我们使用 antlr4 来处理执行引擎的语法文件，实现 SQL 重写。其中，spark 和 presto 都是使用的 antlr4，所以他们的语法文件直接拿过来用即可。由于 hive 目前使用的是 antlr3 的版本，我们将 hive 的语法文件使用 antlr4 的语法重写了一遍。之所以要全部用 antlr4，是为了最大程度的重用 visitor 的逻辑。基于同样的方法，我们实现了字段血缘的追溯，从而可以进行字段的敏感等级传递。
    `

    回复

  5. Hadoop黑客赎金事件解读及防范
    https://developer.aliyun.com/article/68945
    `
    # 前言

    年关将至，Mongodb数据丢失的事情还在眼前，数以千计的Mongodb数据库已经被删除或者被黑客勒索，参考:MongoDB黑客赎金事件解读及防范。就在最近一段时间，黑客也在攻击Hadoop，有不少Hadoop集群的数据全部丢失，这些数据甚至有上TB的数据量，对企业造成了巨大的损失。 本文讲述这个问题及后续的预防方案。

    希望看到文章的同学及时修复问题，避免数据丢失。也欢迎转发，让更多的同学知晓。

    # 攻击手段

    一般使用者为了方便或者不注意，在电信IDC机房或者云上直接开放了HDFS的50070 web端口。那么黑客可以通过简单的几个命令，可以把tmp（可以其它目录）下的数据删除；也可以看到很多日志信息获取敏感数据；或者不断写，把HDFS写满；更加有一些黑客把数据备份走，再把HDFS删除，直接发送勒索邮件。
    其实这个不是HDFS的漏洞，是HDFS提供的webhdfs功能，不过很多同学没有意识到数据可以通过此途径删除。

    # 防护手段

    ## 基本的
    最好的处理方式是，把所有直接开放的端口，包括50070端口在内的所有端口对公网全部禁止。这些端口包括：
    Hadoop默认情况开放了很多端口提供WebUI， 下面列举了相关端口信息：
    * HDFS
    * NameNode 默认端口 50070
    * SecondNameNode 默认端口 50090
    * DataNode 默认端口 50075
    * Backup/Checkpoint node 默认端口 50105-
    * YARN（JobTracker）
    * ResourceManager 默认端口8088
    * JobTracker 默认端口 50030
    * TaskTracker 默认端口 50060
    * Hue 默认端口 8080
    等等
    如果不清楚，则按照最小化原则，开放最小化端口，如果实在需要访问这些端口：
    1、如果是云环境，可以在云上购买一台带界面的环境（win、linux等，这个机器就是跳板机），再最小化打通此机器跟Hadoop环境的通道。
    2、即使要开通公网的端口，可以到ecs的安全组中，开通到你本地环境的公网ip的端口，不要全网开通。
    PS：一些客户说我这个是测试环境，不是生产环境，丢失了没有关系。但是需要注意的是，如果客户攻击了你此台机器，此台机器沦为黑客的肉机不说，如果别的机器跟这些机器在一个安全组，则很有可能会攻击其他机器的。

    ## 高级的
    * 关闭webhdfs的功能，dfs.webhdfs.enabled设置为false
    * 开启类似kerberos功能（比较复杂，不过多表述）
    * 及时备份重要数据，比如云上备份到OSS中
    `

    回复

  6. 关于Hadoop未授权访问可导致数据泄露通知
    https://www.cnblogs.com/music378/p/6971057.html
    `
    【漏洞概述】

    互联网上暴露的Hadoop服务器如果没有配置访问认证均可能受影响，攻击者针对HDFS的攻击删除了大多数目录，并会添加一个名为“NODATA4U_SECUREYOURSHIT”的新目录和“PLEASE_README”的目录，攻击者可能备份业务数据后在服务器上删除这部分数据，然后直接发送勒索邮件并索要勒索赎金。

    【风险等级】

    高风险

    【漏洞风险】

    数据信息泄露

    【漏洞原因】

    该问题系由于管理员在配置失误所致，由于直接在云上开放了Hadoop机器HDFS的50070web端口及部分默认服务端口，黑客可以通过命令行操作多个目录下的数据，如进行删除操作。

    curl -i -X DELETE “http://ip:50070/webhdfs/v1/tmp?op=DELETE&recursive=true“

    curl -i -X PUT “http://ip:50070/webhdfs/v1/NODATA4U_SECUREYOURSHIT?op=MKDIRS“

    【检测方法】

    检查Hadoop端口是否开放到了公网，检测工具可访问：http://tool.chinaz.com/port/

    【修复建议】

    如您为自建Hadoop服务器用户，你可以参照如下方案进行修复：

    1） 如无必要，关闭Hadoop Web管理页面；

    2） 开启服务级别身份验证，如Kerberos认证；

    3） 部署Knox、Nginx之类的反向代理系统，防止未经授权用户访问；

    4） 设置“安全组”访问控制策略，将Hadoop默认开放的多个端口对公网全部禁止或限制可信任的IP地址才能访问包括50070以及WebUI等相关端口，详细端口列表如下：

    a)HDFS
    NameNode 默认端口 50070
    DataNode 默认端口 50075
    httpfs 默认端口14000
    journalnode 默认端口 8480

    b)YARN（JobTracker）
    ResourceManager 默认端口8088
    JobTracker 默认端口 50030
    TaskTracker 默认端口 50060

    c)Hue 默认端口 8080

    d)YARN（JobTracker）
    master 默认端口 60010
    regionserver 默认端口60030

    e)hive-server2 默认端口 10000

    f)spark-jdbcserver 默认端口 10003

    建议按照安全最小化原则，禁止公网对这部分端口访问，如果因业务需要必须对外开放，请配置安全组策略限制指定源IP才能访问这些端口。

    【修复参考】

    1）配置Hadoop服务器在安全模式运行：http://hadoop.apache.org/docs/r2.8.0/hadoop-project-dist/hadoop-common/SecureMode.html
    `

    回复

  7. HDFS Web UI介绍
    https://help.aliyun.com/document_detail/467797.html
    `
    hadoop 3.x http://${namenode_hostname}:9870
    hadoop 2.x http://${namenode_hostname}:50070

    NameNode UI首页介绍
    Overview
    其中，第一行Overview后，为当前NameNode节点的hostname，括号内为active或standby，对应当前节点的高可用状态。

    Summary
    主要信息说明如下：
    Security：表示集群是否开启Kerberos。
    Safemode：表示集群是否是Safemode只读状态。
    文件、目录和数据块的数量，Active NameNode和Standby NameNode的统计有一定差异，属于正常现象，以Active NameNode的数据为准。
    `

    hadoop的几个常用Web UI界面
    https://www.jianshu.com/p/fdc0727d9bab
    `
    hdfs-default.xml dfs.namenode.http-address http://node01:50070 The address and the base port where the dfs namenode web ui will listen on.(HDFS监控服务)
    mapred-default.xml mapreduce.jobhistory.webapp.address http://node01:19888 MapReduce JobHistory Server Web UI host:port.(MapReduce日志监控界面)
    yarn-default.xml yarn.resourcemanager.webapp.address http://node01:8088 The http address of the RM web application.(Yarm集群信息)

    说明：要更改上面参数的内容，可以到${HADOOP_HOME}/etc/hadoop下进行修改：分别对应hdfs-default.xml， mapred-site.xml ，yarn-site.xml新增或修改该参数，重启服务器生效。
    `

    HDFS – Web UI (Namenode UI)
    https://datacadamia.com/db/hadoop/hdfs/ui

    回复

  8. Apache Knox SSO 及在移动云 EMR 中的实践
    https://mp.weixin.qq.com/s/3HTa8o8AoHsFcyWC1qoU0g
    `
    一、KNOX 简介

    Apache Knox网关是一个应用程序网关，用于与Apache Hadoop部署的REST API和UI进行交互。Knox Gateway为与Apache Hadoop集群的所有REST和HTTP交互提供单一的访问点。

    Knox提供三组面向用户的服务：

    1. 代理服务（Proxying Services）：Apache Knox项目的主要目标是通过代理HTTP资源提供对Apache Hadoop的访问。

    2. 认证服务（Authentication Services）：对REST API访问以及UIs的WebSSO流进行身份验证。LDAP/AD，基于头的PreAuth，Kerberos，SAML，OAuth都是可用的选项。

    3. 客户端服务（Client Services）：可以通过DSL编写脚本或直接将Knox Shell类作为SDK来完成客户端开发。

    Apache Knox 代理网关用于保护Hadoop生态体系安全，**为Hadoop集群提供唯一的代理入口。Knox以类似反向代理的形式挡在集群前面，通过内置的过滤器链来处理URL请求，支持使用LADP进行用户身份认证，隐匿部署细节（例如端口号和机器名等），接管所有用户的HTTP请求（例如WEB UI 控制台访问和RESTful 服务调用），以此来保护集群安全**。不仅如此，Knox还能担任认证网关的角色。

    Hadoop大数据平台生态圈中**主要用Knox来保护组件UI，例如HDFS UI、YARN UI、Spark UI、HBase UI等**。

    典型的Knox请求服务资源过程如下：

    1.HDFS中进行Knox proxy代理配置，即Knox用户代理所有客户端用户；
    2.客户端发出Rest请求；
    3.客户端单点登录输入用户名、密码；
    4.LDAP/AD进行用户认证；
    5.使用Knox keytab对客户端用户代理、认证；
    6.使用Knox keytab进行Hadoop资源请求。

    二、KNOX SSO 简介

    Knox Single Sign-on（SSO）提供使用单个用户名和密码访问控制多个Web UIs功能。

    带有默认Knox SSO IDP的Apache Knox允许使用基于表单的身份验证作为SSO的一种解决方案来访问和开发Knox SSO支持的应用程序，包括Ambari、Ranger、Hadoop UIs和通过Knox使用REST APIs定制的应用程序。

    目前，有两种配置Knox SSO的方法：

    1.LDAP/AD：使用Shiro安全框架，默认方法。
    2.SAML：使用pac4j+Okta安全框架。

    三、KNOX SSO 处理 HTTP 请求流程

    以下是通过Knox SSO集成SAML认证的通用时序图：
    …

    流程说明：

    1.SSOCookieProvider检查hadoop-jwt cookie，如果cookie中不存在hadoop-jwt，会重定向请求至sso.authentication.provider.url（将匹配到knoxsso-topology中的Knox SSO服务端点）
    2.Knox SSO配置的IdP向用户发起验证（LDAP/AD，SAML_IdP等）
    3.Knox SSO配置的IdP验证用户提供的凭据/token（例如Basic Auth的username/password）
    4.认证通过，WebSSO服务在cookie中生成hadoop-jwt
    5.WebSSO服务将请求重定向至最初请求的地址，此时cookie中已经存在hadoop-jwt，此后所有操作不再需要认证，直到过期为止

    Knox SSO为集成许多身份验证系统和SSO解决方案提供了一种抽象方法，使参与集成的web应用程序能够更容易地扩展到这种方法中。如果没有Knox SSO提供的token认证功能，每个组件UI都需要单独与各自的解决方案集成。

    # 总结与思考

    为Ambari配置Knox SSO需要注意以下几点：

    •配置Ambari可使用外部用户存储系统（如LDAP）进行身份验证和授权，否则无法通过Knox登录验证页面完成对Ambari的认证
    •保持Ambari与LDAP的用户和组同步，否则会提示单点登录重定向错误
    •Ambari需要开启SSO，并设置相关配置，否则无法通过Knox代理Ambari UI

    使用Knox中遇到的一些问题，供大家参考：

    •由于HBase版本限制，Knox对一些低版本的HBase UIs的代理还不够完善
    •如果Knox进程没有单独配置内存，进程会自动根据系统内存大小按照比例划分可用内存。当频繁触发Knox的访问，会导致Knox进程占用内存高，严重的会直接导致UIs不可访问。因此使用Knox作为代理，建议为Knox单独配置内存
    •使用keytool 生成的证书有默认的有效期，因此需要及时关注证书是否在有效期内
    `

    回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注