java中的类是不允许多继承的,而
接口可以多继承,算是一点弥补,然后就是使用接口可以封装具体的实现,不向外部暴露具体的实现细节,只将接口暴露出来,用户也只能够通过接口访问,这样也有一定的安全性。 接口的作用 接口的作用简单一点就是:接口是用来标记类的,不同的类属于不同的接口(通过向上转型),管理接口比管理各种各样的类方便多了,接口体现了抽象的观点,什么是抽象?抽象就是"抽去像的部分"。 使用接口解决问题 问题:现在我们要写个连接
数据库的类给用户使用,有两个函数:一个返回Connection对象,另一个是关闭数据库,close(),一般的解决方法是:给每个数据库写一个类,再根据用户使用的数据库决定使用具体的类。 好的,我们看看这样有什么不好之处: (1).首先每个类都要有重复的代码,造成代码的膨胀; (2).其次最重要的是我们并不知道用户使用什么数据库,可能是Oracle,可能是mysql,也可能是sqlserver等,这个问题很难解决。 解决方案: 首先我们定义接口: public interface DataBase { java.sql.Connection openDB(String url,String user,String password) void close() } 我们定义了两个方法,openDB返回Connection对象,close()关闭数据库 具体的实现在实现DataBase接口的类中 下面看看实现: import java.sql.* public class Mysql implements DataBase { private String url=”jdbc:mysql:localhost:3306/test” private String user=”root” private String password=”” private Connection conn public Connection openDB(url,user,password) { //连接数据库的代码 } public void close() { //关闭数据库 } } 类mysql实现了DataBase接口,下面还有实现了DataBase接口的oraclesql等类; 这些类都归于DataBase接口了,如何在应用程序中使用呢? 我们要定义DataBase对象 myDB,通过myDB来 *** 纵数据库,可以不要分清是哪个类了。 另外的问题:Java中不许我们实例化接口,如DataBase myDB=new DataBase() 我们只能myDB=new Mysql()或者myDB=new Oracle()。这样我们还必须指定实例化哪个对象,好像前面的努力都白费了啊!!那怎么办呢,我们需要一个工厂: public class DBFactory { public static DataBase Connection getConn() { Return(new Mysql()) } } 实例化的代码变成:myDB=DBFactory.getConn(); 整个过程中接口不负责任何具体 *** 作,其他的程序要连接数据库的话,只需要构造一个DB对象就OK,而不管工厂类如何变化。这就是接口的意义----抽象。
满意请采纳
DataSourceAPI就是如何从存储系统进行读写的相关API接口。一般而言,DataSourceAPI应该是比较底层的API,但是这个版本的DataSourceAPI依赖了上层的API,比如SQLContext、DataFrame以及RDD等。在Spark2.0中,SQLContext已经被遗弃了,逐渐被SparkSession替代,同理,DataFrame也被DatasetAPI取代。但是Spark无法更新数据源API以反映这些变化。我们可以看到高层次的API随着时间的推移而发展。较低层次的数据源API依赖于高层次的API不是一个好主意。如果我们想添加其他优化,比如添加limiy优化,那么我们需要添加其他接口:
buildScan(limit)
buildScan(limit,requiredCols)
buildScan(limit,filters)
buildScan(limit,requiredCols,filters)
缺乏对列式存储读取的支持从上面的buildScanAPI可以看出,Spark数据源进支持以行式的形式读取数据。即使Spark内部引擎支持列式数据表示,它也不会暴露给数据源。但是我们知道使用列式数据进行分析会有很多性能提升,所以Spark完全没必要读取列式数据的时候把其转换成行式,然后再再Spark里面转换成列式进行分析。缺乏分区和排序信息物理存储信息(例如,分区和排序)不会从数据源传递到Spark计算引擎,因此不会在Spark优化器中使用。这对于像HBase/Cassandra这些针对分区访问进行了优化的数据库来说并不友好。在DataSourceV1API中,当Spark从这些数据源读取数据时,它不会尝试将处理与分区相关联,这将导致性能不佳。写 *** 作不支持事务当前的写接口非常通用。它的构建主要是为了支持在HDFS等系统中存储数据。但是像数据库这样更复杂的Sink需要更多地控制数据写入。例如,当数据部分写入数据库并且作业出现异常时,Spark数据源接口将不会清理这些行。这个在HDFS写文件不存在这个问题,因为写HDFS文件时,如果写成功将生成一个名为_SUCCESS的文件,但是这种机制在数据库中是不存在的。在这种情况下,会导致数据库里面的数据出现不一致的状态。这种情况通常可以引入事务进行处理,但是DataSourceV1版本不支持这个功能。不支持流处理越来越多的场景需要流式处理,但是DataSourceAPIV1不支持这个功能,这导致想Kafka这样的数据源不得不调用一些专用的内部API或者独自实现。正是因为DataSourceAPIV1的这些缺点和不足,引入DataSourceAPIV2势在必行。DataSourceAPIV2为了解决DataSourceV1的一些问题,从ApacheSpark2.3.0版本开始,社区引入了DataSourceAPIV2,在保留原有的功能之外,还解决了DataSourceAPIV1存在的一些问题,比如不再依赖上层API,扩展能力增强。
评论列表(0条)