一次设计演进之旅

开发 开发工具
今天我给大家讲一讲关于设计演讲的过程。

一、需求背景

[[182446]]

我们需要实现对存储在HDFS中的Parquet文件执行数据查询,并通过REST API暴露给前端以供调用。由于查询的结果可能数量较大,要求API接口能够提供分页查询。在第一阶段,需要支持的报表有5张,需要查询的数据表与字段存在一定差异,查询条件也有一定差异。

每个报表的查询都牵涉到多张表的Join。每张表都被创建为数据集,对应为一个Parquet文件。Parquet文件夹名就是数据集名,名称是系统自动生成的,所以我们需要建立业务数据表名、Join别名以及自动生成的数据集名的映射关系。数据集对应的各个字段信息都存储在Field元数据表中,其中我们需要的三个主要属性为:

  • CodeName:创建数据集时,由系统自动生成
  • FieldName:为客户数据源对应数据表的字段名
  • DisplayName:为报表显示的列名

说明:为了便于理解,我将要实现的五个报表分别按照序号命名。

二、解决方案

1. 前置条件

本需求是围绕着我们已有的BI产品做定制开发。现有产品已经提供了如下功能:

  • 通过Spark SQL读取指定Parquet文件,但不支持同时读取多个Parquet文件,并对获得的DataFrame进行Join
  • 获取存储在MySQL中的DataSet与Field元数据信息
  • 基于AKKA Actor的异步查询

2. 项目目标

交付日期非常紧急,尤其需要尽快提供最紧急的第一张报表:定期账户挂失后办理支取。后续的报表也需要尽快交付,同时也应尽可能考虑到代码的重用,因为报表查询业务的相似度较高。

3. 整体方案

基于各个报表的具体需求,解析并生成查询Parquet(事实上是读取多个)的Spark SQL语句。生成的SQL语句会交给Actor,并由Actor请求Spark的SQLContext执行SQL语句,获得DataFrame。利用take()结合zipWithIndex实现对DataFrame的分页,转换为前端需要的数据。

根据目前对报表的分析,生成的SQL语句包含join、where与order by子句。报表需要查询的数据表是在系统中硬编码的,然后通过数据表名到DataSet中查询元数据信息,获得真实的由系统生成的数据集名。查询的字段名同样通过硬编码方式,并根据对应数据集的ID与字段名获得Field的元数据信息。

三、设计演进

1. 引入模板方法模式

考虑到SQL语句具有一定的通用性(如select的字段、表名与join表名、on关键字、where条件、排序等),差异在于不同报表需要的表名、字段以及查询条件。通过共性与可变性分析,我把相同的实现逻辑放在一个模板方法中,而将差异的内容(也即各个报表特定的部分)交给子类去实现。这是一个典型的模板方法模式:

  1. trait ReportTypeParser extends DataSetFetcher with ParcConfiguration { 
  2.   def sqlFor(criteria: Option[List[Condition]]): String 
  3.   def criteriaFields: Array[Field] 
  4.  
  5.   private[parc] def predefinedTables: List[TableName] 
  6.   private[parc] def predefinedFields: List[TableField] 
  7.  
  8.   def generateHeaders: Array[Field] = { 
  9.     predefinedFields.map(tf => tf.fieldName.field(tf.table.originalName)).toArray 
  10.   }} 
  11.  
  12. class FirstReportTypeParser extends ReportTypeParser { 
  13.   override def sqlFor(criteria: Option[List[Condition]]): String = { 
  14.     s"""       
  15.        select ${generateSelectFields}       
  16.        from ${AccountDetailTable} a       
  17.        left join ${AccountDebtDetailTable} b       
  18.        left join ${AoucherJournalTable} c       
  19.        on a.${AccountDetailTableSchema.Account.toString.codeName(AccountDetailTable)} = b.${AccountDebtDetailTableSchema.Account.toString.codeName(AccountDebtDetailTable)}       
  20.        and a.${AccountDetailTableSchema.CustomerNo.toString.codeName(AccountDetailTable)} = c.${AoucherJournalTableSchema.CustomerNo.toString.codeName(AoucherJournalTable)}       
  21.        where ${generateWhereClause}$       
  22.        ${generateOrderBy}     
  23.     """ 
  24.   } 
  25.  
  26.   override private[parc] def predefinedTables: List[TableName] = ... 
  27.   override private[parc] def predefinedFields: List[TableField] = ... 
  28.  
  29.   private[parc] def generateSelectFields: String = { 
  30.     if (predefinedFields.isEmpty) "*" else predefinedFields.map(field => field.fullName).mkString(",") 
  31.   } 
  32.  
  33.   private[parc] def generateWhereCluase(conditionsOpt: Option[List[Condition]]): String = { 
  34.     def evaluate(condition: Condition): String = { 
  35.       val aliasName = aliasNameFor(condition.originalTableName) 
  36.  
  37.       val codeName = fetchField(condition.fieldId) 
  38.         .map(_.codeName) 
  39.         .getOrElse(throw ResourceNotExistException(s"can't find the field with id ${condition.fieldId}")) 
  40.  
  41.       val values = condition.operator.toLowerCase() match { 
  42.         case "between" => { 
  43.           require(condition.values.size == 2, "the values of condition don't match between operator") 
  44.           s"BETWEEN ${condition.values.head} AND ${condition.values.tail.head}" 
  45.         } 
  46.         case _ => throw BadRequestException(s"can't support operator ${condition.operator}") 
  47.       } 
  48.  
  49.       s"${aliasName}.${codeName} ${values}" 
  50.     } 
  51.  
  52.     conditionsOpt match { 
  53.       case Some(conditions) if !conditions.isEmpty => s"where  ${conditions.map(c => evaluate(c)).mkString(" and ")}" 
  54.       case _ => "" 
  55.     } 
  56.   }} 

在ReportTypeParser中,我实现了部分可以重用的逻辑,例如generateHeaders()等方法。但是,还有部分实现逻辑放在了具体的实现类FirtReportTypeParser中,例如最主要的sqlFor方法,以及该方法调用的诸多方法,如generateSelectFields、generateWhereCluase等。

在这其中,TableName提供了表名与数据集名、别名之间的映射关系,而TableField则提供了TableName与Field之间的映射关系:

  1. case class TableName(originalName: String,  
  2.                      metaName: String,  
  3.                      aliasName: String,  
  4.                      generatedName: String = ""
  5.  
  6. case class TableField(table: TableName,  
  7.                       fieldName: String,  
  8.                       orderType: Option[OrderType] = None) 

仔细观察sqlFor方法的实现,发现生成select的字段、生成Join的部分以及生成条件子句、排序子句都是有规律可循的。这个过程是在我不断重构的过程中慢慢浮现出来的。我不断找到了这些相似的方法,例如generateSelectFields、generateWhereClause这些方法。它们之间的差异只在于一些与具体报表有关的元数据上,例如表名、字段名、字段名与表名的映射、表名与别名的映射。

我首先通过pull member up重构,将这两个方法提升到ReportTypeParser中:

  1. trait ReportTypeParser extends ... { 
  2.   private[parc] def generateSelectFields: String = ... 
  3.   private[parc] def generateWhereCluase(conditionsOpt: Option[List[Condition]]): String 

此外,还包括我寻找到共同规律的join部分:

  1. trait ReportTypeParser extends ... { 
  2.   private[parc] def generateJoinKeys: String = { 
  3.     def joinKey(tableField: TableField): String = 
  4.       s"${aliasNameFor(tableField.tableName)}.${tableField.fieldName.codeName(mapping.tableName)}" 
  5.  
  6.     predefinedJoinKeys.map{ 
  7.       case (leftTable, rightTable) => s"${joinKey(leftTable)} = ${joinKey(rightTable)}" 
  8.     }.mkString(" and ") 
  9.   }} 

现在sqlFor()方法就变成一个所有报表都通用的方法了,因此我也将它提升到ReportTypeParser中。

2. 元数据概念的浮现

我在最初定义诸如predefinedTables与predefinedFields等方法时,还没有清晰地认识到所谓元数据(Metadata)的概念,然而这一系列重构后,我发现定义在FirstReportParser子类中的方法,其核心职责就是提供SQL解析所需要的元数据内容:

  1. class FirstReportTypeParser extends ReportTypeParser { 
  2.   private[parc] def predefinedJoinKeys: List[(TableField, TableField)] = ... 
  3.   override private[parc] def predefinedAliasNames: Map[TableName, AliasName] = ... 
  4.   override private[parc] def predefinedCriteriaFields: List[TableField] = ... 
  5.   override private[parc] def predefinedOrderByFields: List[TableField] = ... 
  6.   override private[parc] def predefinedTables: List[TableName] = ... 
  7.   override private[parc] def predefinedFields: List[TableFieldMapping] = ... 

3. 以委派取代继承

元数据的概念给了我启发。针对报表的SQL语句解析,逻辑是完全相同的,不同之处仅在于解析的元数据而已。这就浮现出两个不同的职责:

  • 提供元数据
  • 元数据解析

在变化方向上,引起这两个职责发生变化的原因是完全不同的。不同的报表需要提供的元数据是不同的,而对于元数据的解析,则取决于Spark SQL的访问方式(在后面我们会看到这种变化)。根据单一职责原则,我们需要将这两个具有不同变化方向的职责分离,因此它们之间正确的依赖关系不应该是继承,而应该是委派。

我首先引入了ReportMetadata,并将原来的FirstReportTypeParser更名为FirstReportMetadata,在实现了ReportMetadata的同时,对相关元数据的方法进行了重命名:

  1. trait ReportMetadata extends ParcConfiguration { 
  2.   def joinKeys: List[(TableField, TableField)] 
  3.   def tables: List[TableName] 
  4.   def fields: List[TableField] 
  5.   def criteriaFields: List[TableField] 
  6.   def orderByFields: List[TableField]}trait FirstReportMetadata extends ReportMetadata 

至于原有的ReportTypeParser则被更名为ReportMetadataParser。

4. 引入Cake Pattern

如果仍然沿用之前的继承关系,我们可以根据reportType分别创建不同报表的Parser实例。但是现在,我们需要将具体的ReportMetadata实例传给ReportMetadataParser。至于具体传递什么样的ReportMetadata实例,则取决于reportType。

这事实上是一种依赖注入。在Scala中,实现依赖注入通常是通过self type实现所谓Cake Pattern:

  1. class ReportMetadataParser extends DataSetFetcher with ParcConfiguration { 
  2.   self: ReportMetadata => 
  3.  
  4.   def evaluateSql(criteria: Option[List[Condition]]): String = { 
  5.     s"""       
  6.         select ${evaluateSelectFields}       
  7.         from ${evaluateJoinTables}       
  8.         where ${evaluateJoinKeys}       
  9.         ${evaluateCriteria(criteria)}       
  10.         ${evaluateOrderBy}     
  11.     """ 
  12.   }} 

为了更清晰地表达解析的含义,我将相关方法都更名为以evaluate为前缀。通过self type,ReportMetadataParser可以访问ReportMetadata的方法,至于具体是什么样的实现,则取决于创建ReportMetadataParser对象时传递的具体类型。

通过将Metadata从Parser中分离出来,实际上是差异化编程的体现。这是我们在建立继承体系时需要注意的。我们要学会观察差异的部分,然后仅仅将差异的部分剥离出来,然后为其进行更通用的抽象,由此再针对实现上的差异去建立继承体系,如分离出来的ReportMetadata。当我们要实现其他报表时,其实只需要定义ReportMetadata的实现类,提供不同的元数据,就可以满足要求。这就使得我们能够有效地避免代码的重复,职责也更清晰。

5. 建立测试桩

引入Cake Pattern实现依赖注入还有利于我们编写单元测试。例如在前面的实现中,我们通过Cake Pattern实际上注入了实现了DataSetFetcher的ReportMetadata类型。之所以需要实现DataSetFetcher,是因为我想通过它访问数据库中的数据集相关元数据。但是,在测试时我只想验证sql解析的逻辑是否正确,并不希望真正去访问数据库。这时,我们可以建立一个DataSetFetcher的测试桩。

  1. trait StubDataSetFetcher extends DataSetFetcher { 
  2.     override def fetchField(dataSetId: ID, fieldName: String): Option[Field] = ... 
  3.     override def fetchDataSetByName(dataSetName: String): Option[DataSetFetched] = ... 
  4.     override def fetchDataSet(dataSetId: ID): Option[DataSetFetched] = ... 

StubDataSetFetcher通过继承DataSetFetcher重写了三个本来要访问数据库的方法,直接返回了需要的对象。然后,我再将这个trait定义在测试类中,并将其注入到ReportMetadataParser中:

  1. class ReportMetadataParserSpec extends FlatSpec with ShouldMatchers { 
  2.   it should "evaluate to sql for first report" in { 
  3.     val parser = new ReportMetadataParser() with FirstReportMetadata with StubDataSetFetcher 
  4.     val sql = parser.evaluateSql(None) 
  5.     sql should be(expectedSql) 
  6.   } 

6. 引入表达式树

针对第一个报表,我们还有一个问题没有解决,就是能够支持相对复杂的where子句。例如条件:

  1. extractDate(a.TransactionDate) < extractDate(b.DueDate) and b.LoanFlag = 'D' 

不同的报表,可能会有不同的where子句。其中,extractDate函数是我自己定义的UDF。

前面提到的元数据,主要都牵涉到表名、字段名,而这里的元数据是复杂的表达式。所以,我借鉴表达式树的概念,建立了如下的表达式元数据结构:

  1. object ExpressionMetadata { 
  2.   trait Expression { 
  3.     def accept(parser: ExpressionParser): String = parser.evaluateExpression(this) 
  4.   } 
  5.   case class ConditionField(tableName:String, fieldName: String, funName: Option[String] = None) extends Expression 
  6.   case class IntValue(value: Int) extends Expression 
  7.   abstract class SingleExpression(expr: Expression) extends Expression { 
  8.     override def accept(evaluate: Expression => String): String = 
  9.       s"(${expr.accept(evaluate)} ${operator})" 
  10.     def operator: String 
  11.   } 
  12.  
  13.   case class IsNotNull(expr: Expression) extends SingleExpression(expr) { 
  14.     override def operator: String = "is not null" 
  15.   } 
  16.  
  17.   abstract class BinaryExpression(left: Expression, right: Expression) extends Expression { 
  18.     override def accept(parser: ExpressionParser): String = 
  19.       s"${left.accept(parser)} ${operator} ${right.accept(parser)}" 
  20.     def operator: String 
  21.   } 
  22.   case class Equal(left: Expression, right: Expression) extends BinaryExpression(left, right) { 
  23.     override def operator: String = "=" 
  24.   } 

7. 利用模式匹配实现访问者模式

一开始,我为各个Expression对象定义的其实是evaluate方法,而非现在的accept方法。我认为各个Expression对象都是自我完备的对象,它所拥有的知识(数据或属性)使得它能够自我实现解析,并利用类似合成模式的方式实现递归的解析。

然而在实现时我遇到了一个问题:在解析字段名时,我们不能直接用字段名来组成where子句,因为在我们产品的Parquet数据集中,字段的名字其实是系统自动生成的。我们需要获得:

  • 该字段对应的表的别名
  • 该字段名在数据集中真正存储的名称,即code_name,例如C01。

换言之,真正要生成的条件子句应该形如:

  1. extractDate(a.c1) < extractDate(b.c1) and b.c2 = 'D' 

然而,关于表名与别名的映射则是配置在ReportMetadata中,获得别名与codeName的方法则被定义在ReportMetadataParser的内部。如果将解析的实现逻辑放在Expression中,就需要依赖ReportMetadata与ReportMetadataParser。与之相比,我更倾向于将Expression传给它们,让它们完成对Expression的解析。换言之,Expression树结构只提供数据,真正的解析职责则被委派给另外的对象,我将其定义为ExpressionParser:

  1. trait ExpressionParser { 
  2.   def evaluateExpression(expression: Expression): String} 

这种双重委派与树结构的场景不正是访问者模式最适宜的吗?至于ExpressionParser的实现,则可以交给ReportMetadataParser:

  1. class ReportMetadataParser extends DataSetFetcher with ParcConfiguration with ExpressionParser {override def evaluateExpression(expression: Expression): String = { 
  2.     expression match { 
  3.       case ConditionField(tableName, fieldName, funName) => 
  4.          val fullName = s"${table.aliasName}.${fieldName.codeName(table.originalName)}${orderType.getOrElse("")}" 
  5.          funName match { 
  6.             case Some(fun) => s"${funName}(${fullName})" 
  7.             case None => fullName 
  8.       case IntValue(v) => s"${v}" 
  9.       case StringValue(v) => s"'${v}'" 
  10.     } 
  11.   } 
  12.  
  13.   def evaluateWhereClause: String = { 
  14.     if (whereClause.isEmpty) return "" 
  15.     val clause = whereClause.map(c => c.accept(this)).mkString(" and ") 
  16.     s"where ${clause}" 
  17.   }} 

这里的evaluateExpression方法相当于Visitor模式的visit方法。与传统的Visitor模式不同,我不需要定义多个visit方法的重载,而是直接运用Scala的模式匹配。

evaluateWhereClause方法会对Expression的元数据whereClause进行解析,真正的实现是对每个Expression对象,执行accept(this)方法,在其内部又委派给this即ReportMetadataParser的evaluateExpression方法。

代码中的whereClause是新增加的Metadata,具体的实现放到了FirstReportMetadata中:

  1. override def whereClause: List[Expression] = { 
  2.    List( 
  3.          LessThan( 
  4.                     ConditionField(AccountDetailTable, AccountDetailTableSchema.TransactionDate.toString, Some("extractDate")), 
  5.                     ConditionField(AoucherJournalTable, AoucherJournalTableSchema.DueDate.toString, Some("extractDate")) 
  6.                   ), 
  7.          Equal( 
  8.                 ConditionField(AccountDetailTable, AccountDetailTableSchema.LoanFlag.toString), 
  9.                 StringValue("D") 
  10.               ) 
  11.        ) 
  12.  } 

8. 用函数取代trait定义

在Scala中,我们完全可以用函数来替代trait:

  1. trait Expression { 
  2.   def accept(evaluate: Expression => String): String = evaluate(this) 
  3.  
  4. class ReportMetadataParser extends DataSetFetcher with ParcConfiguration { 
  5.   self: ReportMetadata with DataSetFetcher => 
  6.  
  7.   def evaluateExpr(expression: Expression): String = { 
  8.     expression match { 
  9.       case ConditionField(tableName, fieldName) => 
  10.         s"${aliasNameFor(tableName)}.${fieldName.codeName(tableName)}" 
  11.       case IntValue(v) => s"${v}" 
  12.       case StringValue(v) => s"'${v}'" 
  13.     } 
  14.   } 
  15.  
  16.   def evaluateWhereClause: String = { 
  17.     if (whereClause.isEmpty) return " true " 
  18.     whereClause.map(c => c.accept(evaluateExpr)).mkString(" and ") 
  19.   }} 

9. 演进过程的提交记录

这个设计的过程并非事先明确进行针对性的设计,而是随着功能的逐步实现,伴随着对代码的重构而逐渐浮现出来的。

整个过程的提交记录如下图所示(从上至下由最近到最远):

演进过程的提交记录

四、当变化发生

通过前面一系列的设计演进,代码结构与质量已经得到了相当程度的改进与提高。关键是这样的设计演进是有价值回报的。在走出分离元数据关键步骤之后,设计就向着好的方向在发展。

在实现了第一张报表之后,后面四张报表的开发就变得非常容易了,只需要为这四张报表提供必需的元数据信息即可。

令人欣慰的是,这个设计还经受了解决方案变化与需求变化的考验。

1. 解决方案变化

在前面的实现中,我采用了Spark SQL的SQL方式执行查询。查询时通过join关联了多张表。在生产环境上部署后,发现查询数据集的性能不尽如人意,必须改进性能(关于性能的调优,则是另一个故事了,我会在另外的文章中讲解)。由于join的表有大小表的区别,改进性能的方式是引入broadcast。虽然可以通过设置spark.sql.autoBroadcastJoinThreshold来告知Spark满足条件时启用broadcast,但更容易控制的方法是调用DataFrame提供的API。

于是,实现方案就需要进行调整:解析SQL的过程 ---> 组装DataFrame API的过程

从代码看,从原来的:

  1. def evaluateSql(criteria: Option[List[Condition]]): String = { 
  2.     logging { 
  3.       s""" 
  4.       select ${evaluateSelectFields} 
  5.       from ${evaluateJoinTables} 
  6.       on ${evaluateJoinKeys} 
  7.       where ${evaluateWhereClause}${evaluateCriteria(criteria)} 
  8.       ${evaluateOrderBy} 
  9.       """ 
  10.     } 
  11.   } 

变为解析各个API的参数,然后在加载DataFrame的地方调用API:

  1. val dataFrames = tableNames.map { table => 
  2.       load(table.generatedName).as(table.aliasName) 
  3.     } 
  4.     sqlContext.udf.register("extractDate", new ExtractDate) 
  5.  
  6.     val (joinedDF, _) = dataFrames.zipWithIndex.reduce { 
  7.       (dfToIndex, accumulatorToIndex) => 
  8.         val (df, index) = dfToIndex 
  9.         val (acc, _) = accumulatorToIndex 
  10.         (df.join(broadcast(acc), keyColumnPairs(index)._1 === keyColumnPairs(index)._2), index) 
  11.     } 
  12.  
  13.     joinedDF.where(queryConditions) 
  14.       .orderBy(orderColumns: _*) 
  15.       .select(selectColumns: _*) 

解析方式虽然有变化,但需要的元数据还是基本相似,差别在于需要将之前我自己定义的字段类型转换为Column类型。我们仅仅只需要修改 ReportMetadataParser类,在原有基础上,增加部分独有的元数据解析功能:

  1. class ReportMetadataParser extends ParcConfiguration with MortLogger { 
  2.   def evaluateKeyPairs: List[(Column, Column)] = { 
  3.     joinKeys.map { 
  4.       case (leftKey, rightKey) => (leftKey.toColumn, rightKey.toColumn) 
  5.     } 
  6.   } 
  7.   def evaluateSelectColumns: List[Column] = { 
  8.     fields.map(tf => tf.toColumn) 
  9.   } 
  10.   def evaluateOrderColumns: List[Column] = { 
  11.     orderByFields.map(f => f.toColumn) 
  12.   } 

2. 需求变化

我们的另一个客户同样需要类似的需求,区别在于他们的数据治理更好,我们只需要对已经治理好的视图数据执行查询即可,而无需跨表Join。在对现有代码的包结构做出调整,并定义了更为通用的Spark SQL查询方法后,要做的工作其实就是定义对应报表的元数据罢了。

仅仅花费了1天半的时间,新客户新项目的报表后端开发工作就完成了。要知道在如此短的开发周期内,大部分时间其实还是消耗在重构工作上,包括重新调整现有代码的包结构,提取重用代码。现在,我可以悠闲一点,喝喝茶,看看闲书,然后再重装待发,迎接下一个完全不同的新项目。

【本文为51CTO专栏作者“张逸”原创稿件,转载请联系原作者】

戳这里,看该作者更多好文

责任编辑:赵宁宁 来源: 51CTO专栏
相关推荐

2011-06-30 22:23:21

打印机常见问题

2014-11-12 13:22:34

2016-01-07 12:40:02

机器学习权威定义

2020-11-02 09:48:35

C++泄漏代码

2020-07-08 07:44:35

面试阿里加班

2013-10-22 09:22:07

Hadoop 2大数据

2011-06-28 10:41:50

DBA

2021-12-27 10:08:16

Python编程语言

2020-10-24 13:50:59

Python编程语言

2020-09-03 08:05:34

设计模式编程界

2020-10-18 12:53:29

黑科技网站软件

2020-03-10 07:51:35

面试讽刺标准

2020-03-18 13:07:16

华为

2024-05-31 12:56:06

.NET代码方法

2013-06-03 09:28:49

游戏设计

2017-02-28 11:13:36

华为

2011-07-21 21:01:37

诺基亚塞班苹果

2011-04-07 11:20:21

SQLServer

2020-12-29 10:25:07

漏洞JSONP注入

2020-07-14 15:10:21

Redis架构代码
点赞
收藏

51CTO技术栈公众号