Database Hadoop与数据库

我目前正在研究一个问题，我试图将hadoop与数据库集成，因为hadoop提供并行性，但不提供性能。我指的是hadoopDB的论文。Hadoop通常会将一个文件拆分成块，并将这些块放在不同的数据节点中。在处理过程中，namenode告诉可能找到块的位置，并在该节点上运行映射。我正在研究一种可能性，即用户告诉namenode在哪个datanode上运行映射，namenode运行映射从文件或数据库获取数据。您能告诉我告诉namenode运行映射的datanode是否可行吗

---

谢谢

不确定为什么要将map/reduce任务绑定到特定节点。如果某个节点发生故障，会发生什么情况？在Hadoop中，map/reduce操作不能绑定到集群中使Hadoop更具可伸缩性的特定节点

---

您可能需要查看“Hadoop与数据库之间的导入/导出”。

如果您正在寻找从分布式数据存储区查询数据，那么为什么不考虑将数据存储到Hadoop和HDFS之上构建的分布式数据库中。它在后台将数据存储到HDFS中，并像大型数据库一样提供查询语义。在这种情况下，您不必担心向正确的数据节点发出查询。HBase（也称为hadoop数据库）的查询语义也会处理同样的问题

为了方便查询和存储数据到HbASE，如果您的数据是时间序列数据，那么您也可以考虑使用它是Hbase周围的包装器，并提供简单的基于标签的查询语义，以及与GNUPlot很好的集成，以便给您图形化的数据可视化。 Hbase非常适合对非常大的分布式数据存储进行随机读/写。但是，如果您的查询是在大容量写/读操作上进行的，那么对于您的情况，Hbase可能是一个非常适合的解决方案。与Hbase类似，它也构建在Hadoop Map Reduce和HDFS之上，并将每个查询转换为底层Map Reduce作业。Hive最好的地方在于它提供了类似SQL的语义，并且您可以像查询关系数据库一样进行查询。 就数据组织和Hive功能的基本介绍而言，您可能希望了解以下几点：

Hive将结构添加到存储在HDFS上的数据中。表的架构存储在单独的元数据存储中。它将类似SQL的语义转换为在后端HDFS上运行的多个map reduce作业

传统数据库遵循写模式策略，一旦为表设计了模式，在写入数据时，将检查要写入的数据是否符合预定义的模式。否则，将拒绝写入。 在蜂巢的情况下，情况正好相反。它使用模式对读策略。这两种政策都有各自的权衡。在写模式的情况下，加载时间较长，加载速度较慢，因为在加载数据时会验证模式的一致性。但是，它提供了更快的查询时间，因为它可以根据模式中预定义的列对数据进行索引，但是，在某些情况下，在最初填充数据时可能无法指定索引，而这正是读取模式方便的地方。它提供了一个选项，根据所需的分析类型，在相同的基础数据上存在两个不同的模式

配置单元非常适合批量访问，因为新的更新需要构造一个全新的表来更新数据。此外，由于没有索引，查询时间比传统数据库慢

配置单元将元数据存储到一个称为“元存储”的关系数据库中

配置单元中有两种表：

托管表—其中表的数据文件是预定义的，通常会移动到HDFS上的配置单元仓库目录或任何其他hadoop文件系统中。删除表时，在这种情况下，元数据和数据都将从文件系统中删除

外部表-在这里，您可以惰性地将数据创建到表中。在这种情况下，没有数据移动到配置单元仓库目录，架构/元数据与实际数据松散耦合。删除表时，只有元数据被删除，实际数据保持不变。如果您希望数据被多个数据库使用，这将非常有用。使用相同模式的另一个原因可能是在同一基础数据上需要多个模式

---

谢谢@praveen我有一个场景，其中数据分布在不同的数据库中，因此当查询到达时，查询的相关部分应该从不同的数据库中获取数据。因此，我需要访问特定节点并查询这些节点。我可以在以后向其添加复制功能，这样即使某个节点出现故障，我也可以进行sti 我们将从节点检索数据。