我正在处理一个问题，在这个问题中，我们有很多来自不同来源的事件，而这些事件具有60％的字段。因此，话虽如此，我最初是从每个事件创建的单个表开始的，现在看到可以有很多事件，并且在这些事件中几乎有60％的数据字段相同，我想创建一个事件表，该事件表将为所有人提供列事件，我将在此表中添加一个类型的列，这将使我的Spark作业选择与他们相关的事件。该表是一个蜂巢外部表，Spark作业将通过处理登台JSON表加载数据。
我正在寻求专家的意见，以查看该桌子设计是否可行？
- 我的分区将就像分区（日期字符串，客户类型，EventType字符串）
- 我可能对地区有一个格格的分区，但尚未决定
- 数据存储为镶木格式
- 我看到的一个好处是，当引入一个新事件时，我只需要添加特定的列，并扩展我的火花框架，而不是添加新的表格和东西
我的群集在每个群集上有6个DNS，每个DNS都有32Gig RAM，每个磁盘空间为5TB。由于Spark是我们的核心处理框架，因此我担心所有将运行的工作的资源消耗？如果分区变得太大怎么办？我也在考虑性能和速度？
任何输入都将受到赞赏。
在决定如何存储数据之前，需要考虑一些事情。
- 为什么要使用parquet代替avro？使用镶木而不是Avro围绕进化模式存在一些局限性。
- 您将对数据进行哪种操作？如果您使用几列，我建议使用parquet而不是AVRO，但是如果不是这种情况，并且不会进行聚合，并且您将主要在行级上工作，我建议Avro
- 您期望获得什么合并表？您会使用不同表之间的非共同字段进行操作吗？这是常见的情况吗？从可用性的角度来看，也许是一个好主意，使所有桌子彼此独立，并使用公共字段创建一个表格，这将使您可以使用非common列工作，如果需要这些记录，没有这些列，也可以"合并"表中的常见字段。，这是外部表的好处。
-
您的数据每天都会增长多少？这是一个非常重要的一点，您会生成很多小文件吗？如果是这种情况，则应考虑中间流程以创建新文件，并使您的文件更大至至少与块大小匹配，考虑到群集的大小很小，这是一个重要的一点。
-
注意如何对数据进行分区，非常细粒度可能会在许多小文件中结束，这会影响您的性能。您真的需要客户和EventType的分区吗？
- 我不确定您的火花框架周围的细节，但直接引入新列似乎很难维护，如果您决定使用avro ，请考虑使用GenericRecord
我希望它对一些决定有所帮助。
编辑：回答一些问题
当您修改木板表的列结构时，Hive似乎有一些局限性。例如，要修改表定义中的列的名称，您必须使用flag parquet.column.index.access进行此工作，这意味着您所有的数据都需要相同的架构。Hive中的替换列以添加一个全新的定义在Hive 1.3版中不起作用，出于某种原因，我无法阅读新列，不确定这是否在其他版本中进行了修复。
此外，Spark中的架构演变被关闭，因为它更昂贵，从本质上，您必须读取所有文件并巩固以这种方式工作并根据您的文件数量来工作，这可能会影响性能
http://spark.apache.org/docs/latest/sql-programming-guide.html#schema-merging