hadoop - 一个基于大型事件的表或多个表？ Hive 表设计注意事项

Question

我正在解决一个问题，我们有很多来自不同来源的不同事件，这些事件有 60% 的字段是通用的。因此，话虽如此，我最初从为每个事件创建单独的表开始，现在看到可以有很多事件，并且这些事件中几乎 60% 的数据字段是相同的，我正在考虑创建一个包含所有列的事件表事件，我将在此表中添加一个类型列，这将使我的 spark 作业选择与它们相关的事件。该表是一个 Hive 外部表，spark 作业将通过处理一个 staging json 表将数据加载到其中。

我正在寻求专家的意见，看看这种单 table 设计是否可行？

我的分区将类似于分区(日期字符串、客户类型、事件类型字符串)

我可能有一个额外的区域分区，但还没有决定

数据存储为 Parquet 格式

我看到的一个好处是，当引入新事件时，我只需要添加特定于它的列并扩展我的 spark 框架以防止添加新表和东西

我的集群有 6 个 DN，每个 32Gig RAM 和 5TB 磁盘空间。由于 spark 是我们的核心处理框架，我担心所有将要运行的作业的资源消耗？如果分区变得太大怎么办？我也在考虑性能和速度？

任何输入表示赞赏。

Answer 1

在决定如何存储数据之前，需要考虑一些事项。

为什么使用 Parquet 而不是 avro？在 Hive 中使用 parquet 而不是 avro 的进化模式存在一些限制。

你会对你的数据做什么样的操作？如果您将使用几列，我建议使用 parquet 而不是 avro，但如果不是这种情况并且不会进行聚合并且您将主要在行级别工作，我建议使用 avro

您期望合并表格获得什么？您会在不同表之间使用非公共(public)字段进行操作吗？这是常见的情况吗？从可用性的角度来看，保持所有表相互独立并创建一个包含公共(public)字段的表可能是一个好主意，这将允许您在没有这些列的记录需要时使用非公共(public)列，也可以使用“合并”表中的公共(public)字段。 ，这是外部表的好处。

您的数据每天会增长多少？这是非常重要的一点，你会生成很多小文件吗？如果是这种情况，您应该考虑中间过程来创建新文件并使文件更大以至少与 block 大小相匹配，考虑到集群的大小很小，这一点很重要。

请注意如何对数据进行分区，非常细粒度的数据可能会以大量小文件结尾，这会影响您的性能。您真的需要按客户和事件类型进行分区吗？

我不确定您的 spark 框架周围的细节，但直接引入新列似乎很难维护，如果您决定使用 avro

，请考虑使用 genericrecord

我希望它有助于一些决定。

编辑:回答一些问题

当您修改 parquet 表的列结构时，Hive 似乎有一些限制。例如，要修改表定义中的列名，您必须使用标志 parquet.column.index.access 才能使这项工作正常进行，这意味着您需要的所有数据都包含相同的模式。 Hive 中添加全新定义的替换列在 Hive 版本 1.3 中不起作用，由于某种原因，我无法读取新列，不确定这是否在其他版本中得到修复。

此外，spark 中的模式演变已关闭，因为它更昂贵，本质上您必须读取所有文件并整合模式才能以这种方式工作，并且取决于您的文件数量，这可能会影响性能

http://spark.apache.org/docs/latest/sql-programming-guide.html#schema-merging