带ORC性能的Tez上的Hive真的比用于ETL的Spark SQL更好吗？
我在Hive方面没有什么经验，目前正在学习Scala的Spark。我很想知道Tez上的Hive是否真的比SparkSQL快。我搜索了很多有测试结果的论坛，但他们都比较了旧版本的Spark，而且大多数都是2015年写的。要点摘要如下：
- 兽人将在Spark中执行与parquet相同的操作
- TEZ发动机将像火花发动机一样提供更好的性能
- 连接在配置单元中比Spark更好/更快
最初，我认为Spark会比任何东西都快，因为它们在内存中执行。在阅读了一些文章后，我发现了一些现有的Hive也得到了一些新的概念，如Tez、ORC、LLAP等。
目前使用PL/SQL Oracle运行，并且正在迁移到大数据，因为数量正在增加。我的需求是一种ETL批处理和包含的数据细节涉及到每个星期的批运行。数据很快就会大量增加。
>
输入/查找数据为CSV/文本格式，并更新为表
-
null
-
null
共有1个答案
实现问题解决方案的最佳方法如下。
要将数据加载到表中，我认为spark是一个不错的选项。您可以从hive转移体中读取表，并使用某种窗口函数执行增量更新，然后将它们注册到hive中。当从各种查找表中填充数据时，您可以在Scala中以编程方式编写代码。
但归根结底，需要有一个非常易于使用的查询引擎。当您的spark程序用hive注册表时，您就可以使用hive了。
-
null
在配置单元中创建业务用户。
-
在使用ORC文件格式的Hive中，有没有一种方法可以将列名映射到独立于列顺序的Hive表列？ orc文件的示例架构： 所需配置单元表列顺序： 但是，当我创建具有所需列顺序的表时，数据没有正确对齐。配置单元根据列顺序而不是列名获取数据。这对于拼花格式很好，其中Hive能够根据列名选择正确的顺序。如有任何解决此问题的建议，我们将不胜感激。 我没有选择更改orc文件模式，因为它是由外部进程创建的。也不想
-
这些查询是:select*from t1 where col1='123'[t1由col1 bucketted]select*from t1 where col2='123'[col2不是bucketting列]我的问题是 > 如何确定在查询执行期间正在进行全表扫描还是正在进行相关的部分表扫描？ 我能从DAG或物理计划中得到任何信息吗？我两个都看过，但我看不出有什么不同，就像我在物理计划中看到的那
-
问题内容： 在（尤其是）以下mysql中进行查询时，是否有更好的性能： 过度： 或BETWEEN语法仅被第二个sql替代？ 问题答案： 我记得，没有区别。但是，请自己看看是否： 和： 制定相同的计划。
-
问题内容： 以下是EnumMap的Java文档的 “ 实现注释” 部分的内容： 实施注意事项：所有基本操作均按固定时间执行。它们可能（尽管不能保证）比其HashMap同行更快。 我在java doc中也看到了类似的内容。我想知道为什么它比散列的同行更有可能而且会更快？ 问题答案： 由位数组支持。由于您可以预先输入不同项目的数量，因此我们可以简单地为每个枚举值保留一位。您可以想象对或进行类似的优化，
-
我正在尝试使用ORDER BY查找在Hive中我的表中创建条目的最早时间。声明看起来像这样 这给我一个错误消息，如下所示： https://i.imgur.com/cgIiSKh.png 只是向您展示SELECT语句在没有ORDER BY的情况下是如何工作的： https://i.imgur.com/k6RwAd4.png 我在尝试时也犯了同样的错误 顺便说一句，timeiss是一个字符串。 以下