我要补充的是，impala不是etl工具，它是一个sql查询引擎，允许您在通过etl过程清理数据之后对非常大的数据集执行sql查询。
历史上，pig和hive在spark之前用于etl。如果您更喜欢类似sql的语法，那么hive仍然是相关的，并且有许多变体提供更好的性能，比如tez上的hive和spark上的hive，它们用spark代替mapreduce。
参考文献
Spark上的Hive
泰兹的Hive

过去，很多人要么将a）sql脚本（比如impala）用于unix脚本，要么将b）etl工具用于etl。
然而，问题是1）规模更大，2）技术标准化。
既然正在使用spark，那么为什么不在spark上进行标准化呢？
我已经通过了这个周期和金球dwh处理可以做得很好与Spark。就informatica这样的付费etl工具而言，这意味着成本更低。但也有社区版。
需要注意的几点：
使用Dataframe编写器等，将文件保存为不同的hdfs格式更容易、更直接。
但是带有分支的类似informatica的Map有点不同。
一旦从外部来源获得数据，spark的规模性能将更好。
使用unix脚本比在spark imo中进行文件控制更容易，但如果在spark中进行，则需要习惯这种情况。
sqoop可以省去，你也可以使用spark的jdbc df reader，但是没有理由省去sqoop，虽然我会使用confluent kafka connect来代替更高的延迟，但是后来我们进入禅宗的问题，因为kafka是为了更实时的方面。
我并不完全相信etl工具的好处。
由于需要降低成本，spark是一个不错的选择。但这不是为胆小的人准备的，你需要成为一个好的程序员。我听到很多人都这么说。