26、实时Hadoop应用的架构与优化

A3B4C5

于 2025-07-17 12:02:13 发布

阅读量37

点赞数

CC 4.0 BY-SA版权

分类专栏： Hadoop迁移：从RDBMS到NoSQL的实践指南文章标签： Hadoop Ampool 实时处理

本文链接：https://blog.youkuaiyun.com/a3b4c5/article/details/149550885

Hadoop迁移：从RDBMS到NoSQL的实践指南专栏收录该内容

31 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

实时Hadoop应用的架构与优化

1. Ampool系统概述

Ampool除了以内存为中心的核心对象存储外，还包含多个优化连接器，能让现有计算引擎高效地从Ampool对象存储中存储和检索数据。目前开箱即用的连接器有Apache Spark、Apache Hive、Apache Trafodion（与Esgyn Corporation合作）、Apache Apex（与Datatorrent, Inc.合作）和CDAP（Cask Data Application Platform，与Cask Data, Inc.合作）。

Ampool本身是一个全分布式存储系统，可维护大量操作持久数据，同时它还提供了多个持久存储连接器，如Hadoop分布式文件系统（HDFS）、Apache Hive和Apache HBase。Ampool可以作为一个独立系统与Hadoop组件一起部署，也可以与现有的Hadoop集群（使用Apache Ambari或Cloudera Manager）一起部署，并且可以使用提供的工具进行监控和管理，也可以将Ampool产生的JMX指标连接到任何兼容JMX的监控系统。

Ampool为（不可变和可变）数据帧、数据集以及事件流扩展提供快速分析存储，为实现Butterfly架构提供了缺失的环节，实现了各种事务和分析工作负载的统一。

2. 案例：广告技术数据管道

以Acme.io公司为例，它是一家热门的内容聚合公司，拥有基于网络的门户和移动应用，有大量用户。公司有众多广告客户，通过独特匹配算法能在毫秒内为用户找到最合适的广告。

Acme.io使用Hadoop集群为用户提供个性化内容推荐，但Hadoop的批处理特性使其无法用于实时广告投放、广告日志流分析以及为客户提供广告活动性能的实时反馈。此外，为满足业务和营销分析师的即席查询需求，公司设置了单独的数据存储库，导致数据基础设施运营成本增加，数据同步困难，浪费了大量数据科学家和大数据基础设施专家的时间。

因此，公司决定逐步升级数据基础设施，从当前的Lambda架构转向Butterfly架构，采用Ampool以内存为中心的存储。

2.1 数据

Acme.io的数据分析管道使用了四个大型数据集：
| 数据集 | 详细信息 |
| ---- | ---- |
| 用户资料 | 包含每个注册用户的详细信息，如UserID、Age、Sex、Location、Registration timestamp、Interests等。 |
| 广告 | 包含所有可在内容中展示的广告的详细信息，如AdID、CampaignID、CustomerID、AdType、AdPlatform、Keywords、PPC、PPM、PPB等。 |
| 内容元数据 | 包含内容的所有元数据，如ContentID、ContentType、Keywords等。 |
| 广告投放日志 | 由广告服务器持续流式传输，每条记录包含TimeStamp、IPAddress、UserID、AdID、ContentID、AdType、AdPlatform、EventType等字段。 |

2.2 计算

在Acme.io的广告分析数据管道中，对数据进行以下计算步骤：
- 摄入和流分析
1. 广告服务器将广告点击、展示和转化事件发送到Kafka代理。
2. Kafka消费者嵌入在Apache Apex（DataTorrent）流分析平台中。
3. 对于每个消费的事件，进行以下计算：
- 解析事件记录。
- 提取时间戳、广告ID、事件类型和广告类型。
- 根据广告ID查找活动ID。
- 对每个广告ID和活动ID的事件类型进行窗口聚合。
- 将这些聚合结果存储在Ampool中。
- 在DataTorrent的流可视化仪表板中可视化这些聚合结果。
- 流分析的输出如下：
- (Ad - ID, Time - Window, Number - Of - Views, Number - Of - Clicks, Number - Of - Conversions, Total - PPV, Total, PPC, Total PPConversion)
- (Campaign - ID, Time Window, Number - Of - Views, Number - Of - Clicks, Number - Of - Conversions, Total - PPV, Total, PPC, Total PPConversion)
4. 第二个流摄入管道用于更新用户表、广告表和内容表。步骤如下：
- 从Kafka代理摄入{用户、活动、广告} {更新、插入}事件。
- 解析事件以确定要更新的表。
- 更新相应的表。
- 跟踪更新的总数。
- 当1%的记录是新记录或已更新时，启动批处理计算并重置更新计数器。

graph LR
    A[广告服务器] --> B[Kafka代理]
    B --> C[Apache Apex流分析平台]
    C --> D[解析事件记录]
    D --> E[提取信息]
    E --> F[查找活动ID]
    F --> G[窗口聚合]
    G --> H[存储到Ampool]
    H --> I[可视化]
    J[Kafka代理] --> K[摄入更新插入事件]
    K --> L[解析事件]
    L --> M[更新表]
    M --> N[跟踪更新总数]
    N --> O{1%记录更新?}
    O -- 是 --> P[启动批处理计算]
    O -- 否 --> M

批处理模型构建
- 输入为用户表、广告表和内容表，输出为两个新表：
  - (User - ID, Ad - Id1, weight1, Ad - Id2, weight 2, Ad - Id3, weight3)
  - (Content - ID, Ad - Id1, weight1, Ad - Id2, weight2, Ad - Id3, weight3)
- 构建步骤如下：
  1. 使用MapReduce作业从用户表和广告表中提取相关字段，并根据主题、子主题和关键词进行连接。
  2. 使用Spark作业过滤出前三个匹配的关键词，并使用余弦相似度计算这些关键词对应的广告权重。
  3. 对内容表和广告表重复上述步骤。
交互式和即席SQL查询
使用Apache Trafodion（EsgynDB）对广告活动和广告的聚合数据进行不同窗口的交互式和即席查询，例如：
- 广告或活动的{每分钟、每小时、每天}转化率是多少？
- 每小时广告的点击量占展示量的百分比是多少？
- 广告活动一天欠Acme.io多少钱？
- 每小时最受点击的广告和活动有哪些？
- Acme.io有多少0 - 21岁、21 - 40岁的男性用户？

查询结果可以在屏幕上交互式显示，对于产生时间窗口数据的查询，可以使用Tableau等工具进行可视化。

3. Lambda架构总结

几年前，Nathan Marz首次引入Lambda架构时，大数据社区非常兴奋，因为当时Hadoop无法进行实时流数据处理。Lambda架构的出现改变了这一状况，首次证明了Hadoop可用于实时处理。

然而，随着时间推移，该架构的问题逐渐显现。Lambda架构是一个不错的起点，但需要根据具体环境进行调整，而且在选择Hadoop生态系统组件时存在限制。虽然可以参考相关示例开发Java代码来实现一些系统，但在与关系系统接口以及开发基于事实的模型方面存在困难，其能否在新兴流处理引擎的冲击下生存还有待时间检验。

4. Hadoop集群性能优化

许多组织在使用大数据技术时存在犹豫，主要原因是认为Hadoop性能提升不明显。可以通过在硬件、操作系统、Hadoop配置和数据阶段进行性能调优来提高Hadoop集群的性能。

4.1 硬件配置

不能使用旧的、废弃的商品硬件构建Hadoop集群，生产集群需要更强大的硬件，主节点（NameNode）要比工作节点（DataNodes）更强大。

集群配置
- NameNode需要更多内存，存储应采用RAID，并进行复制以实现故障转移。
- 计算生产使用的集群大小时，可按以下公式计算：
  - HDFS空间/节点 = (每个节点的原始磁盘空间 - 25%非DFS本地存储)/(复制因子)
  - 工作节点数量 = 总HDFS空间/HDFS空间/节点
- 单个工作节点的配置建议：
  - 最新一代处理器，共12 - 16个核心。
  - 每个核心4 - 8 GB内存。
  - 每个核心1 - 3 TB SATA磁盘。
  - 1GbE网卡。
- NameNode的配置建议：
  - 4 - 6个核心。
  - 内存起始配置：(3 GB + 每100 TB原始磁盘空间或100万个文件对象1 GB)。
  - 需要进行复制以实现故障转移。
  - RAID - 1存储。
  - 在64位操作系统上运行以避免JVM堆大小3 GB的限制。
- 如果使用YARN，YARN主节点（资源管理器）的初始配置可以是2 GB RAM和1个核心CPU，但对于繁忙的资源管理器可能需要提升硬件配置。

开发环境的大小取决于应用使用情况。如果使用供应商产品，开发环境的硬件资源可以减半；如果是自主开发的应用，可能需要分配70 - 80%的硬件资源。

4.2 操作系统配置

在对Hadoop集群进行性能调优前，需要参考操作系统文档。以RHEL或CentOS为例，可进行以下调整：

直观调整
- 关闭电源节能选项，在BIOS设置中改为PerfOptimized。
- 关闭磁盘控制器的缓存。
- 使用NOATIME选项挂载磁盘卷，关闭文件访问时间记录以加快访问速度。
非直观调整
- 禁用透明大页面压缩：
  - 对于RHEL，使用命令 echo never > sys/kernel/mm/redhat_transparent_hugepages/defrag 。
  - 为使更改永久生效，在 /etc/rc.local 文件中添加脚本：

if test -f /sys/kernel/mm/redhat_transparent_hugepage/defrag; 
then echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag ;fi

- 减少文件系统保留块空间：使用命令 `tune2fs -m 0 /dev/sdXY`。
- 增加打开文件句柄和文件数量：
    - 使用命令 `ulimit –S 4096` 设置软限制。
    - 使用命令 `ulimit –H 32832` 设置硬限制。
    - 使用命令 `sysctl –w fs.file-max=6544018` 设置系统范围的文件描述符限制。

5. Hadoop配置参数优化

在操作系统调优完成后，需要对Hadoop配置参数进行调整，以在特定环境中获得最佳性能。以下是一些重要的配置参数及其调整建议：

参数	说明	调整建议
`dfs.blocksize`	HDFS中数据块的大小	根据数据量和应用需求调整，较大的数据块可减少NameNode的负载，但可能影响小文件的存储效率。
`mapred.child.java.opts`	Map和Reduce任务的Java虚拟机参数	根据任务的内存需求调整，避免内存不足或浪费。
`yarn.scheduler.maximum-allocation-mb`	YARN调度器允许分配的最大内存	根据集群的总内存和应用需求设置，确保资源合理分配。

调整这些参数时，需要根据实际的集群环境和应用场景进行测试和优化，以找到最适合的配置。

6. 数据存储格式和压缩

Hadoop以文件形式存储数据，因此选择合适的存储格式和进行数据压缩非常重要。

6.1 存储格式

常见的Hadoop存储格式有Text、SequenceFile、Avro、Parquet等，选择时需要考虑以下因素：
- 数据访问模式 ：如果需要随机访问，Parquet等列式存储格式更合适；如果是顺序访问，Text或SequenceFile可能足够。
- 数据类型 ：不同的存储格式对不同的数据类型支持不同，需要根据数据的特点选择。
- 数据分析工具 ：某些分析工具对特定的存储格式有更好的支持。

6.2 数据压缩

由于Hadoop处理的数据量通常很大，数据压缩可以节省存储空间和提高数据传输效率。常见的压缩编解码器有Gzip、Snappy、LZO等，它们各有优缺点：

压缩编解码器	压缩比	压缩速度	解压缩速度	支持随机访问
Gzip	高	慢	慢	否
Snappy	中	快	快	否
LZO	中	快	快	是

选择压缩编解码器时，需要根据数据的使用场景和性能需求进行权衡。例如，如果需要快速处理数据，Snappy可能是一个好选择；如果对存储空间要求较高，Gzip可能更合适。

7. 特殊索引和缓存技术

为了进一步提高性能，可以使用特殊的索引和缓存技术。

7.1 索引技术

索引可以加快数据的查找速度，常见的索引技术有B树索引、哈希索引等。在Hadoop中，可以使用第三方索引工具如Apache Accumulo或Apache Solr来实现索引功能。

索引的创建步骤如下：
1. 选择合适的索引工具和索引策略。
2. 对需要索引的数据进行预处理，确保数据格式符合索引工具的要求。
3. 使用索引工具创建索引，并将索引与数据关联起来。
4. 在查询数据时，利用索引快速定位所需数据。

7.2 缓存技术

缓存可以减少数据的访问延迟，提高数据的处理速度。常见的缓存技术有内存缓存和磁盘缓存。在Hadoop中，可以使用分布式缓存如Apache Ignite或Ehcache来实现缓存功能。

缓存的使用步骤如下：
1. 选择合适的缓存工具和缓存策略。
2. 确定需要缓存的数据，通常是经常访问的数据。
3. 将数据加载到缓存中，可以在数据处理过程中动态更新缓存。
4. 在查询数据时，首先检查缓存中是否存在所需数据，如果存在则直接从缓存中获取，否则从数据源获取并更新缓存。

8. 性能测试和问题排查

在完成上述优化步骤后，需要进行性能测试以验证优化效果，并及时排查和解决出现的问题。

8.1 性能测试

可以使用基准测试工具如Terasort、WordCount等对Hadoop集群进行性能测试，记录各项性能指标，如处理时间、吞吐量等。通过对比优化前后的性能指标，评估优化效果。

性能测试的步骤如下：
1. 选择合适的基准测试工具和测试数据集。
2. 在优化前运行基准测试，记录性能指标。
3. 进行优化操作，如调整硬件配置、修改Hadoop配置参数等。
4. 在优化后再次运行基准测试，记录性能指标。
5. 对比优化前后的性能指标，分析优化效果。

8.2 问题排查

如果在性能测试或实际使用过程中发现问题，需要及时进行排查。常见的问题包括内存不足、磁盘I/O瓶颈、网络延迟等。可以使用监控工具如Nagios、Ganglia等对集群的各项指标进行监控，定位问题所在。

问题排查的步骤如下：
1. 收集问题的详细信息，如错误日志、性能指标等。
2. 使用监控工具对集群进行实时监控，观察各项指标的变化。
3. 根据问题的表现和监控数据，分析可能的原因。
4. 针对可能的原因进行排查和修复，如调整配置参数、增加硬件资源等。
5. 验证修复效果，确保问题得到解决。

graph LR
    A[性能测试] --> B[选择测试工具和数据集]
    B --> C[优化前测试]
    C --> D[记录性能指标]
    D --> E[进行优化操作]
    E --> F[优化后测试]
    F --> G[记录性能指标]
    G --> H[对比分析]
    I[问题排查] --> J[收集问题信息]
    J --> K[使用监控工具]
    K --> L[分析可能原因]
    L --> M[排查修复]
    M --> N[验证效果]

通过以上对Hadoop集群在硬件、操作系统、配置参数、数据存储和处理等方面的优化，可以显著提高Hadoop集群的性能，满足不同应用场景的需求。同时，持续的性能测试和问题排查能够确保集群的稳定运行，为企业的大数据应用提供有力支持。