29、大数据处理中的索引、NoSQL 选择与 Lambda 架构案例

最新推荐文章于 2025-08-19 02:59:57 发布

A3B4C5

最新推荐文章于 2025-08-19 02:59:57 发布

阅读量49

点赞数

CC 4.0 BY-SA版权

分类专栏： Hadoop迁移：从RDBMS到NoSQL的实践指南文章标签：大数据处理索引优化 NoSQL选择

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

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

31 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

大数据处理中的索引、NoSQL 选择与 Lambda 架构案例

1. 索引对性能的影响及类型

索引对于查询性能至关重要，虽然 Hadoop 不像关系型数据库管理系统（RDBMS）那样提供高级索引功能，但仍有一些通用准则可供遵循。

1.1 通用索引准则

合理使用索引，过多索引会影响插入性能，索引应与频繁的查询模式相匹配。
对于 Hive，索引分区应与表分区在分区列使用上保持一致。可参考 Hive 索引文档进行全面了解。

1.2 常见索引类型

1.2.1 紧凑索引（Compact Indexes）

适用场景 ：适用于包含大量不同或唯一值的列，如员工 ID，尤其适用于包含数值的列。
存储方式 ：在 Hive 中，紧凑索引内部存储为一个排序表，包含要索引的列值以及存储这些值的块。
存储格式 ：需使用与表格式匹配的最佳格式（如 ORC、Parquet、Avro）存储，并在需要时进行压缩。若表进行了分区，索引也会分区，可按需更改索引的分区结构。
配置参数 ：设置属性 IDXPROPERTIES 'hive.index.compact.binary.search'='true' ，确保索引可用于紧凑二进制搜索。
索引更新 ：创建索引后，若源表数据发生变化，需刷新或更新索引，使用以下命令：

ALTER INDEX <Index name> ON <Table name> REBUILD;

由于 Hadoop 处理的数据量较大，建议在系统空闲时手动安排索引更新。

1.2.2 位图索引（Bitmap Indexes）

适用场景 ：适用于只有少数不同值的列，如性别、逻辑值（是/否）、类别或类型。这些列的不同值数量与表中行数的比率较小，该比率称为基数度。
优势：传统索引对大表进行全索引会占用大量磁盘空间，而位图索引仅使用索引数据大小的一小部分。它为每个键值使用位图而非行 ID 列表，位图中的每个位对应一个行 ID，若位被设置，则表示对应行包含该键值，通过映射函数将位位置转换为实际行 ID。此外，位图索引会压缩位图，对于少量不同的键值，提供更好的压缩效果。
使用建议 ：建议使用单列位图索引，因为多个位图索引的位图可轻松组合。为使位图索引有效，需对要索引的列中的数据进行排序，设置属性 hive.enforce.sorting 为 true ，并在 create table 语句中描述应排序的列。同时，需指定有效的存储格式，并在索引较大时进行压缩。

1.3 其他索引类型

存储索引（Storage Index） ：适用于 ORCFile 和 Parquet 格式，是一种最小/最大索引，若值不在数据块中，可跳过该数据块，适用于使用 < 、 > 、 = 运算符的数值和查询。
聚合索引（Aggregate Index） ：类似于具有预定义聚合的表，如按特定列分组的计数、求和、平均值。

综上所述，为实现有效索引，需了解和评估数据，并根据源表数据的变化定期更新索引。

2. 选择 NoSQL 解决方案并优化数据模型

选择适合环境和数据的 NoSQL 解决方案非常重要，但这一点常被忽视。

2.1 NoSQL 解决方案选择

若数据大多是非结构化且数据量较小（约 2 - 5 TB），列式数据库可能不是合适的解决方案。
需了解主要类型的 NoSQL 数据库、其特点、优缺点，以及它们在所需处理类型（基于业务需求）中的表现。决策将对环境的性能和支持功能产生重大影响。

2.2 NoSQL 数据迁移与模型优化

数据迁移准备 ：选择合适的 NoSQL 解决方案后，需将数据迁移到 NoSQL 环境。大多数情况下，是将联机事务处理（OLTP）或联机分析处理（OLAP）系统迁移到 NoSQL。
数据模型转换 ：关系型 OLTP 环境中的数据具有引用完整性，需执行连接操作来检索所需数据。关系型数据库在连接操作方面表现良好，具有索引、定义统计信息、缓存数据和查询计划等增强性能的功能。但将关系型数据迁移到 NoSQL 环境后，大多数 RDBMS 功能不可用，且 NoSQL 数据库在连接操作方面表现不佳。因此，需重新设计数据模型，消除连接操作，可能需要对数据进行非规范化处理，并合并一些数据表以形成更大的表。

3. 性能调优的综合考虑

性能调优是一个广泛的主题，涉及多个子主题。以下是一些性能调优的建议：
- 参数调优 ：MapReduce 或 HDFS 参数列表并非详尽无遗，可参考 Apache 文档获取完整参数列表，并调整与自身环境更相关的参数。
- 索引选择 ：仔细审查查询需求，添加合适的索引类型。
- 硬件优化 ：虽然像 Teradata 这样的大公司专注于设计处理 PB 级数据的硬件，Intel 也推出了不牺牲性能的硬件加密和解密解决方案，但可根据自身情况参考硬件优化的通用准则，优化计划使用的硬件。
- 规划与测试 ：不同组织采用不同的性能调优方法。一些组织从通用准则开始，在遇到特定问题时再考虑性能调优，这种方法能快速解决当前问题，但不能保证该区域或其他区域不再出现问题。因此，需进行良好的规划，进行压力测试，考虑数据增长和使用增加情况，以及边界条件（最小和最大可能值），包括硬件资源、NoSQL 解决方案、网络容量或技术支持资源等方面。对增长和边界条件有深入了解，有助于有效规划近期可能出现的性能问题。

4. Lambda 架构案例：Yourtown 保险公司欺诈检测

4.1 业务问题与解决方案

Yourtown 保险公司近期面临大量欺诈索赔问题，为应对此问题，公司增加了严格的准则和额外的处理流程，但这导致处理时间增加了两倍，使得有真实索赔的客户不满并将业务转移到其他保险公司。

公司聘请了业务处理和软件性能专家，他们通过统计模型分析过去的索赔数据，创建了一个预测模型来判断索赔是否可能欺诈。若索赔被判定为可能欺诈，则将其引导至特殊队列进行额外处理，必要时启动调查；其余被判定为非欺诈的索赔则像之前一样快速处理。

该策略减少了真实索赔的处理时间，并能以约 80% 的准确率识别欺诈索赔。顾问向 IT 部门保证，随着时间推移，该预测模型将变得更加准确，提供更高的准确率。该模型基于多个因素判断欺诈索赔，如客户去年提交的索赔数量、索赔提交时间、索赔提交时的天气条件、客户年龄、客户驾驶历史等。

由于索赔数据量非常大（30 TB，每月增长 1%），决定使用 Hadoop 进行数据处理，又因为需要实时处理，所以选择了 Lambda 架构。根据数据量，商定每周周末重建批处理层，速度层保留过去六天的数据，欺诈判定将基于批处理层的历史数据和速度层的最新数据。

4.2 解决方案设计

4.2.1 硬件设计

数据系统当前数据大小为 30 TB，每月增长 1%，未来四年总增长约 50%，即 15 TB。由于批处理层对数据进行非规范化处理，需额外约 30% 的存储空间，总空间需求达到 60 TB。假设在重建批处理层时系统不可用，最终空间需求为 60 TB。

综上所述，需要一个 95 节点的集群，包括 92 个数据节点、处于故障转移配置的两个名称节点和一个 YARN 资源管理器节点。开发环境的大小可根据相关准则计算。为获得良好性能，数据节点可使用提供 7,200 RPM 的 SSHD 存储或提供 10,000 RPM 的 SATA III 驱动器，网络接近或处于同一子网有助于减少网络流量并提供良好性能。

4.2.2 软件设计

数据录入 ：客户通过基于浏览器的应用程序输入索赔数据，索赔数据使用 VoltDB 存储，并每小时推送到 HDFS/Hive。
批处理层 ：使用 HDFS/Hive 构建批处理层视图。
服务层 ：使用只读数据库 Splout SQL。
速度层 ：使用 Spark 及其 SQL 功能。

4.2.3 数据库设计

索赔系统有大量表和列以捕获所有详细信息，但大部分数据对于欺诈检测并非必需。为演示欺诈检测概念，将使用以下存储在 HDFS 中的表（主数据）来构建批处理视图：
- Claim
- Claim_status_type
- Policy
- Policy_owner
- Claim_line_item

需注意，欺诈检测是一个复杂的过程，实际需要比此处提供的更多信息。

5. Lambda 架构各层功能及数据流转

5.1 各层功能概述

Lambda 架构主要由批处理层、速度层和服务层组成，各层在数据处理和欺诈检测中发挥着不同的作用。

层名称	功能描述
批处理层	存储历史数据，使用 HDFS/Hive 构建批处理视图，对数据进行非规范化处理，为欺诈检测提供历史数据支持。
速度层	处理近实时数据，使用 Spark（连同 Spark SQL），保留过去六天的数据，为欺诈检测提供最新数据。
服务层	使用只读数据库 Splout SQL，为用户提供查询服务，将批处理层和速度层的数据整合并呈现给用户。

5.2 数据流转过程

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(客户输入索赔数据):::process --> B(VoltDB 存储):::process
    B --> C(每小时推送到 HDFS/Hive):::process
    C --> D(批处理层构建视图):::process
    C --> E(速度层处理近实时数据):::process
    D --> F(服务层 Splout SQL):::process
    E --> F
    F --> G(用户查询):::process

客户通过基于浏览器的应用程序输入索赔数据，数据首先存储在 VoltDB 中，然后每小时推送到 HDFS/Hive。在 HDFS/Hive 中，数据分别流入批处理层和速度层。批处理层对历史数据进行处理和构建视图，速度层处理近实时数据。最后，服务层的 Splout SQL 将批处理层和速度层的数据整合，为用户提供查询服务。

6. 数据存储与处理的优势分析

6.1 数据存储优势

批处理层 ：使用 HDFS/Hive 存储历史数据，HDFS 具有高容错性和可扩展性，能够存储大规模数据。Hive 提供了类 SQL 的查询接口，方便对数据进行分析和处理。同时，批处理层对数据进行非规范化处理，减少了数据查询时的连接操作，提高了查询性能。
速度层 ：使用 Spark 处理近实时数据，Spark 具有内存计算的特点，能够快速处理大量数据。Spark SQL 提供了 SQL 查询功能，方便对数据进行分析和处理。速度层保留过去六天的数据，能够及时反映数据的最新变化。
服务层 ：使用只读数据库 Splout SQL，提供了高效的查询服务。只读数据库减少了数据更新的开销，提高了查询性能。

6.2 数据处理优势

数据不变性 ：Lambda 架构采用数据不变性的设计思想，将数据分为多个“事实”，并在时间空间中捕获这些事实的变化。任何对事实的更改都作为一个新的事实记录存储，并带有时间戳，这不仅保留了数据的历史信息，还避免了数据更新和删除操作可能导致的数据损坏问题。
分离存储与查询 ：Lambda 架构将主数据（以第三范式存储）与查询层（以非规范化视图存储）分离，解决了传统数据库系统在数据存储和查询处理之间的权衡问题。主数据的规范化存储保证了数据的一致性和完整性，查询层的非规范化视图提高了查询性能。

7. 其他架构设计变化探讨

7.1 Kappa 架构

Kappa 架构是对 Lambda 架构的简化，它只使用一个流处理引擎来处理所有数据，而不需要批处理层。在 Yourtown 保险公司的案例中，如果采用 Kappa 架构，可直接使用 Spark 处理所有索赔数据，避免了批处理层和速度层之间的数据同步问题。但 Kappa 架构对实时处理能力要求较高，需要确保流处理引擎能够处理大规模数据。

7.2 Fast Data 架构

Fast Data 架构强调数据的实时性和快速处理能力，它采用事件驱动的方式处理数据。在 Yourtown 保险公司的案例中，Fast Data 架构可更快地响应索赔数据的变化，实时进行欺诈检测。但 Fast Data 架构需要更强大的实时处理技术和基础设施支持。

8. 总结与建议

8.1 总结

本文介绍了大数据处理中的索引选择、NoSQL 解决方案选择、性能调优等方面的知识，并通过 Yourtown 保险公司的案例详细阐述了 Lambda 架构在欺诈检测中的应用。索引的合理使用能够提高查询性能，NoSQL 解决方案的选择需要根据数据特点和业务需求进行评估，性能调优需要综合考虑参数、索引、硬件等多个方面。Lambda 架构通过批处理层、速度层和服务层的协同工作，能够有效处理大规模数据，实现近实时的欺诈检测。

8.2 建议

索引优化 ：根据数据特点和查询需求，选择合适的索引类型，如紧凑索引、位图索引等，并定期更新索引，以保证查询性能。
NoSQL 选择 ：在选择 NoSQL 解决方案时，充分了解不同类型 NoSQL 数据库的特点和优缺点，结合自身数据和业务需求进行选择。
性能调优 ：进行全面的性能调优，包括参数调优、索引选择、硬件优化等方面。同时，进行良好的规划和压力测试，考虑数据增长和边界条件，以应对未来可能出现的性能问题。
架构选择 ：根据业务需求和数据特点，选择合适的架构，如 Lambda 架构、Kappa 架构或 Fast Data 架构。在选择架构时，充分考虑架构的优缺点和实施难度。