五年总结:过往记忆大数据原创精选,欢迎收藏转发。
Data Source API 定义如何从存储系统进行读写的相关 API 接口,比如 Hadoop 的 InputFormat/OutputFormat,Hive 的 Serde 等。 这些 API 非常适合用在 Spark 中使用 RDD 编程的时候使用。 使用这些 API 进行编程虽然能够解决我们的问题,但是对用户来说使用成本还是挺高的,而且 Spark 也不能对其进行优化。 为了解决这些问题,Spark 1.3 版本开始引入了 Data Source API V1,通过这个 API 我们可以很方便的读取各种来源的数据,而且 Spark 使用 SQL 组件的一些优化引擎对数据源的读取进行优化,比如列裁剪、过滤下推 等等。如果想及时了解Spark、Hadoop或者HBase相关的文章,欢迎关注微信公众号:iteblog_hadoop
Data Source API V1 为我们抽象了一系列的接口,使用这些接口可以实现大部分的场景,这些接口如下(参见 org.apache.spark.sql.sources.interfaces.scala 文件):
常见的读取 JSON、CSV、JDBC、Kafka 以及最近开源的 Detla Lake 等都是通过 Data Source API V1 实现的。这个版本的 Data Source API 有以下几个优点:
接口实现非常简单
- 能够满足大部分的使用场景
但是随着 Spark 的不断发展,以及使用的用户越来越多,这个版本的 Data Source API 开始暴露出一些问题。
Data Source API V1 不足
部分接口依赖 SQLContext 和 DataFrame
一般而言,Data Source API 应该是比较底层的 API,但是这个版本的 Data Source API 依赖了上层的 API,比如 SQLContext、DataFrame 以及 RDD 等。在 Spark 2.0 中,SQLContext 已经被遗弃了,逐渐被 SparkSession 替代,同理,DataFrame 也被 Dataset API 取代。但是 Spark 无法更新数据源 API 以反映这些变化。 我们可以看到高层次的 API 随着时间的推移而发展。较低层次的数据源 API 依赖于高层次的 API 不是一个好主意。 扩展能力有限,难以下推其他算子 当前数据源 API 仅支持 filter 下推和列修剪(参见上面的 PrunedFilteredScan 接口的 buildScan 方法)。如果我们想添加其他优化, 比如添加 limiy 优化,那么我们需要添加其他接口: buildScan(limit)buildScan(limit, requiredCols)
buildScan(limit, filters)
buildScan(limit, requiredCols, filters)
这样下去对我们来说是一个噩梦!