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进行操作。