Spark SQL运行 过程 抄的别人的，记录 学习

抄的别人的，觉得写的特别好


val FILESOURCE_TABLE_RELATION_CACHE_SIZE =
buildStaticConf("spark.sql.filesourceTableRelationCacheSize")


org.apache.spark.sql.catalyst.catalog.SessionCatalog#tableRelationCache

private val tableRelationCache: Cache[QualifiedTableName, LogicalPlan] = {
val cacheSize = conf.tableRelationCacheSize
CacheBuilder.newBuilder().maximumSize(cacheSize).build[QualifiedTableName, LogicalPlan]()
}

这里记录的是 QualifiedTableName 和 LogicalPlan 的对应关系。

每个表 和这个表的关系


这里是处理了刷新表 ，这里有好几个 Map 都存了什么
tableRelationCache
tempTables
globalTempViewManager


def refreshTable(name: TableIdentifier): Unit = synchronized {
val dbName = formatDatabaseName(name.database.getOrElse(currentDb))
val tableName = formatTableName(name.table)

// Go through temporary tables and invalidate them.
// If the database is defined, this may be a global temporary view.
// If the database is not defined, there is a good chance this is a temp table.
if (name.database.isEmpty) {
tempTables.get(tableName).foreach(_.refresh())
} else if (dbName == globalTempViewManager.database) {
globalTempViewManager.get(tableName).foreach(_.refresh())
}

// Also invalidate the table relation cache.
val qualifiedTableName = QualifiedTableName(dbName, tableName)
tableRelationCache.invalidate(qualifiedTableName)
}


https://blog.csdn.net/junerli/article/details/78607708

meta 这一块
org.apache.spark.sql.catalyst.catalog.SessionCatalog

org.apache.spark.sql.hive.HiveSessionCatalog

private[sql] class HiveSessionCatalog(
externalCatalog: HiveExternalCatalog,
globalTempViewManager: GlobalTempViewManager,
val metastoreCatalog: HiveMetastoreCatalog,
functionRegistry: FunctionRegistry,
conf: SQLConf,
hadoopConf: Configuration,
parser: ParserInterface,
functionResourceLoader: FunctionResourceLoader)
extends SessionCatalog(
externalCatalog,
globalTempViewManager,
functionRegistry,
conf,
hadoopConf,
parser,
functionResourceLoader) {


Spark SQL运行流程

将SQL语句通过词法和语法解析生成未绑定的逻辑执行计划（Unresolved LogicalPlan），包含Unresolved Relation、Unresolved Function和Unresolved Attribute，然后在后续步骤中使用不同的Rule应用到该逻辑计划上
Analyzer使用Analysis Rules，配合元数据（如SessionCatalog 或是 Hive Metastore等）完善未绑定的逻辑计划的属性而转换成绑定的逻辑计划。具体流程是县实例化一个Simple Analyzer，然后遍历预定义好的Batch，通过父类Rule Executor的执行方法运行Batch里的Rules，每个Rule会对未绑定的逻辑计划进行处理，有些可以通过一次解析处理，有些需要多次迭代，迭代直到达到FixedPoint次数或前后两次的树结构没变化才停止操作。
Optimizer使用Optimization Rules，将绑定的逻辑计划进行合并、列裁剪和过滤器下推等优化工作后生成优化的逻辑计划。
Planner使用Planning Strategies，对优化的逻辑计划进行转换（Transform）生成可以执行的物理计划。根据过去的性能统计数据，选择最佳的物理执行计划CostModel，最后生成可以执行的物理执行计划树，得到SparkPlan。
在最终真正执行物理执行计划之前，还要进行preparations规则处理，最后调用SparkPlan的execute执行计算RDD。
三、SparkContext运行原理分析
前面我们队Spark SQL运行架构进行分析，知道从输入SQL语句到生成Dataset分为5个步骤，但实际运行过程中在输入SQL语句之前，Spark还有加载SessionCatalog步骤。
3.1 使用SessionCatalog保存元数据
在解析SQL语句之前需要初始化SQLContext，它定义了Spark SQL执行的上下文，并把元数据保存在SessionCatalog中，这些元数据包括表名称、表字段名称和字段类型等。
SessionCatalog中保存的是表名和逻辑执行计划对应的哈希列表，这些数据将在解析未绑定的逻辑计划上使用。（SessionCatalog中的表名对应的逻辑执行计划是什么？是这个Dataset对应的逻辑执行计划）
3.2 使用Antlr生成未绑定的逻辑计划
Spark 2.0版本起使用Antlr进行词法和语法解析。使用Antlr生成未绑定的逻辑计划分为两个阶段：第一阶段的过程为词法分析（Lexical Analysis），负责将符号（Token）分组成符号类(Token class or Token type)，第二阶段就是真正的Parser，默认Antlr会构建出一颗分析树（Parser Tree）或者叫语法树（Syntax Tree）。
SQLContext类中定义了SQL的解析方法parseSql。具体的SQL解析在AbastrctSqlParser抽象类中的parse方法进行，解析完毕后生成语法树，语法树会根据系统初始化的AstBuilder解析生成表达式、逻辑计划或表标识对象。
在AbstractSqlParse的parse方法中，先实例化词法解析器SqlBaseLexer和语法解析器SqlBaseParser，然后尝试用Antlr较快的解析模式SLL，如果解析失败，则会再尝试使用普通解析模型LL，解析完毕后返回解析结果。
3.3 使用Analyzer绑定逻辑执行计划
该阶段Analyzer使用Analysis Rules，结合SessionCatalog元数据，对未绑定的逻辑计划进行解析，生成了已绑定的逻辑计划。在该处理过程中，先实例化一个Analyzer，在Analyzer中定义了FiexedPoint和Seq[Batch]两个变量，其中FixedPoint为迭代次数的上线，而Seq[Batch]为所定义需要执行批处理的序列，每个批处理由一系列Rule和策略所组成，策略一般分为Once和FixedPoint（可理解为迭代次数）
3.4 使用Optimizer优化逻辑计划
Optimizer的实现和处理方式同Analyzer类似，在该类中定义一系列Rule并同样继承于RuleExecutor。利用这些Rule对逻辑计划和Expression进行迭代处理，从而达到对树的节点进行合并和优化。其中主要的优化策略总结起来是合并、列裁剪和过滤器下推等几大类。
Optimizer的优化策略不仅对已绑定的逻辑计划进行优化，而且对逻辑计划中的Expression也进行了优化，其原理就是遍历树，然后应用优化Rule，但是注意一点，对逻辑计划处理时先序遍历，而对Expression的处理是后续遍历（根据树节点类型来判断是逻辑计划还是Expression吗？）
3.5 使用SparkPlanner生成可执行物理计划
SparkPlanner使用Planning Strategies对优化的逻辑计划进行转换(Transform)，生成可以执行的物理计划。在QueryExecution类代码中，调用SparkPlanner.plan方法对优化的逻辑计划进行处理，而SparkPlanner并未定义plan方法，实际是调用SparkPlanner的祖父类QueyrPlanner的plan方法，然后会返回一个Iterator[Physicalplan]。
SparkPlanner继承于SparkStrategies，而SparkStrategies继承了QueryPlanner。其中SparkStrategies包含了一系列特定的Strategies，这些Strategies是继承自QueryPlanner中定义的GenericStrategy。在SparkPlanner通过改写祖父类QueryPlanner中strategies策略变量，在该变量中定义了转换成物理计划所执行的策略。
3.6 使用QueryExecution执行物理计划
在该步骤中先调用SparkPlanner.preparations对物理计划进行准备工作，规范返回数据行的格式等，然后调用SparkPlan.execute执行物理计划，从数据库中查询数据并生成RDD。
SparkPlan的preparations其实是一个RuleExecutor[SparkPlan]，它会调用RuleExecutor的execut方法对前面生成的物理计划应用Rule进行匹配，最终生成一个SparkPlan。
SparkPlan继承于QueryPlan，SparkPlan中定义了SQL语句执行的execute方法，执行完execute方法返回的是一个RDD，之后可以运行Spark作业对该RDD进行操作。