案例分析 | 由Decimal操作计算引发的Spark数据丢失问题

一天，金融分析团队的同事报告了一个问题，他们发现在两个生产环境中(为了区分，命名为环境A和B), Spark大版本均为2.3。但是，当运行同样的SQL语句，对结果进行对比后，却发现两个环境中有一列数据并不一致。

由此可见，在环境A中可以查询到该列数据，但是在环境B中却出现了部分数据缺失。

上述两个查询中用的Spark大版本是一致的，团队的同事通过对比两个环境中的配置，发现有一个参数在最近进行了变更。该参数为：spark.sql.decimalOperations.allowPrecisionLoss, 默认为true。

在环境A中未设置此参数，所以为true，而在环境B下Spark client的spark-defaults.conf中，该参数设置为false。

该参数为PR SPARK-22036 引入，是为了控制在两个Decimal类型操作数做计算的时候，是否允许丢失精度。在本文中，我们就针对乘法这种计算类型做具体分析。

在详细介绍该参数之前，先介绍一下Decimal。

Decimal是数据库中的一种数据类型，不属于浮点数类型，可以在定义时划定整数部分以及小数部分的位数。对于一个Decimal类型，scale表示其小数部分的位数，precision表示整数部分位数和小数部分位数之和。

一个Decimal类型表示为Decimal(precision, scale)，在Spark中，precision和scale的上限都是38。

一个double类型可以精确地表示小数点后15位，有效位数为16位。

可见，Decimal类型则可以更加精确地表示，保证数据计算的精度。

例如一个Decimal(38, 24)类型可以精确表示小数点后23位，小数点后有效位数为24位。而其整数部分还剩下14位可以用来表示数据，所以整数部分可以表示的范围是-10^14+1~10^14-1。

关于精度的问题其实我们小学时候就涉及到了，比如求两个小数加减乘除的结果，然后保留小数点后若干有效位，这就是保留精度。

乘法操作我们都很清楚，如果一个n位小数乘以一个m位小数，那么结果一定是一个(n+m)位小数。

举个例子, 1.11 * 1.11精确的结果是 1.2321，如果我们只能保留小数点后两位有效位，那么结果就是1.23。

上面我们提到过，对于Decimal类型，由于其整数部分位数是(precision-scale),因此该类型能表示的范围是有限的，一旦超出这个范围，就会发生Overflow。而在Spark中，如果Decimal计算发生了Overflow，就会默认返回Null值。

举个例子，一个Decimal(3,2)类型代表小数点后用两位表示，整数部分用一位表示，因此该类型可表示的整数部分范围为-9~9。如果我们CAST(12.32 as Decimal(3,2))，那么将会发生Overflow。

下面介绍spark.sql.decimalOperations. allowPrecisionLoss参数。

当该参数为true(默认)时，表示允许Decimal计算丢失精度，并根据Hive行为和SQL ANSI 2011规范来决定结果的类型，即如果无法精确地表示，则舍入结果的小数部分。

当该参数为false时，代表不允许丢失精度，这样数据就会表示得更加精确。eBay的ETL部门在进行数据校验的时候，对数据精度有较高要求，因此我们引入了这个参数，并将其设置为false以满足ETL部门的生产需求。

设置这个参数的初衷是美好的，但是为什么会引发数据损坏呢?

上面的select语句将会返回一个NULL。

执行计划很简单，里面有一个二元操作(乘法)，左边的case when 是一个Decimal(34, 24)类型，右边是一个Literal(1)。

程序员都知道，在编程中，如果两个不同类型的操作数做计算，就会将低级别的类型向高级别的类型进行类型转换，Spark中也是如此。

一条SQL语句进入Spark-sql引擎之后，要经历Analysis->optimization->生成可执行物理计划的过程。而这个过程就是不同的Rule不断作用在Plan上面，然后Plan随之转化的过程。

在Spark-sql中有一系列关于类型转换的Rule，这些Rule作用在Analysis阶段的Resolution子阶段。

用文字解释一下，针对一个二元操作(加减乘除), 如果左边的数据类型和右边不一致，那么会寻找一个左右操作数的通用类型（common type）, 然后将左右操作数都转换为通用类型。针对我们此案例中的 Decimal(34, 24) 和Literal(1), 它们的通用类型就是Decimal(34, 24),所以这里的Literal(1)将被转换为Decimal(34, 24)。

这样该二元操作的两边就都是Decimal类型。接下来这个二元操作会被Rule DecimalPrecision中的decimalAndDecimal方法处理。

（点击可查看大图）

此处我们的操作数都已经是Decimal(34, 24)类型了，所以p1=p2=34, s1=s2=24。

如果不允许精度丢失，那么其结果类型就是 Decimal(p1+p2+1, s1+s2)。由于precision和scale都不能超过上限38，所以这里的结果类型是Decimal(38, 38), 也就是小数部分为38位。于是整数部分就只剩下0位来表示，也就是说如果整数部分非0，那么这个结果就会Overflow。在当前版本中，如果Decimal Operation 计算发生了Overflow，就会返回一个Null的结果。

这也解释了在前面的场景中，为什么使用环境B中Spark客户端跑的结果，非Null的结果中整数部分都是0，而小数部分精度更高(因为不允许精度丢失)。

好了，问题定位到这里结束，下面讲解决方案。

通过观察Spark-sql中Decimal 相关的Rule，发现了Rule DecimalPrecision中的nondecimalAndDecimal方法，这个方法是用来处理非Decimal类型和Decimal类型操作数的二元操作。

此方法代码不多，作用就是前面提到的左右操作数类型转换，将两个操作数转换为一样的类型，如下图所示：

（点击可查看大图）

文字描述如下:

除此之外，默认的DecimalOperation如果发生了Overflow，那么其结果将返回为NULL值，这样的计算结果异常并不容易被用户感知到(此处非常感谢金融分析团队的同事帮我们检查到了这个问题)。

在SQL ANSI 2011标准中，当算术操作发生Overflow时，会抛出一个异常。这也是大多数数据库的做法(例如SQLService, DB2, TeraData)。

PR SPARK-23179 引入了参数spark.sql. decimalOperations.nullOnOverflow 用来控制在Decimal Operation 发生Overflow时候的处理方式。

默认是true，代表在Decimal Operation发生Overflow时返回NULL的结果。

如果设置为false，则会在Decimal Operation发生Overflow时候抛出一个异常。

因此，我们在上面的基础上合入该PR，引入spark.sql.decimalOperations.nullOnOverflow参数，设置为false, 以保证线上计算任务的数据质量。

本文分析了一个Decimal操作计算时发生的数据质量问题。我们不仅修复了其不合适的类型转换问题，减小了其结果Overflow的几率，还引入了一个参数，以便在计算发生Overflow时抛出异常，让用户感知到计算中存在的问题，保证线上计算的数据质量。

在大数据计算场景中，我们不仅关心数据计算得快不快，更关心结果数据的质量高不高。这需要各个团队的密切配合，平台开发人员需要提供可靠稳定的计算平台，业务团队需要写出高质量的SQL，数据服务团队则要提供良好的调度和校验服务。相信在各个团队的共同努力下，eBay在大数据这条路上能走得更远、更宽阔。

您可能还感兴趣：