SPSS中方差分析（F检验）的作用以及使用前提
一、方差分析
方差分析用来检验两组以上的数据，假如有三组数据为什么不能用T检验做三次两两之间检验是否能达到目的，结果是不能的，三次T检验每一次都会犯I类错误（推断错误导致概率过大），所以超过两组数据就要用方差分析（方差分析又叫做F检验）。
1.1 方差分析的作用
方差分析的作用和T检验的作用是一样的，选择不同的取值或者分组时，对结果有无显著的影响，当然前提是超过两组。
1.2 方差分析的前提
1.数据符合正态分布；

2.数据出自随机样本；

不论原来的总体是否服从正态分布，样本均值的抽样分布都将趋于正态分布（中心极限定理）。
1.3 方差分析的结论
从输出结果查看方差分析，是否达到显著水平：是（一般是小于0.05），接受结论一（有差异）；否（一般是大于0.05）， 接受结论二 （无差异），如果符合方差齐性，则选择看符合方差齐性的事后检验，如果不符合方差齐性，则看方差非齐性的事后检验。



方差不齐性可能的原因就是样本量不够大，或者事实就是不齐性，这就要看后面的具体分析。
1.4 常用方差分析分为：单因素设计方差分析、多因素设计方差分析和协方差分析
1.41 单因素设计方差分析

比较超过两组组数据的平均值和一组数据有无差异。

例如：选了4个城市，测试对4个城市的饮料口感评分，这里选用单因素设计方差分析 。
1.411 单因素设计的结果解读



由于显著性<0.05，所以方差同质性检验未通过，之后的事后检验就只能看Tamhane‘s T2的事后检验。



这里Tamhane事后检验的显著性都大于0.05，所以说明城市之间饮料口味并无显著差异 。
1.42 多因素设计方差分析

多因素方差分析的基本思想基本等同于单因素方差分析，不同在于研究的是两个或者两个以上因素对于试验结果的作用和影响，以及这些因素共同作用的影响。

例如：选了22个人，肌肉的恢复度与缝合手法和缝合时间是否相关，这就要用多因素方差分析。
1.421 多因素设计的结果解读



结论：显著性>0.05,说明肌肉的恢复度与缝合时间和缝合时间没有显著差异；
1.43 协方差分析

协方差分析就是在一般方差分析上的基础上还受另一个难以控制的协变量的影响，在分析中剔除其影响，再分析各因素对观测变量的影响。
1.431 协方差分析的前提

1.各组数据来自正态总体，且方差相等。

2.各组系数要通过平行线检验。
1.431 协方差分析的结果解读



显著性大于0.05，所以通过检验。



原工资的显著性为0，所以得出 现工资和原工资有显著关系，教师级别*政策实施显著性0.453>0.05,说明和现工资没有显著关系；

文章目录
绝对中位差Median Absolute Deviation
示例
用途
MAD与标准差的关系
总体MAD
R语言MAD函数

绝对中位差Median Absolute Deviation
参考维基百科中的MAD定义
在统计学中，绝对中位数MAD是对单变量数值型数据的样本偏差的一种鲁棒性测量。同时也可以表示由样本的MAD估计得出的总体参数。
对于单变量数据集X1,X2,...,XnX_1, X_2, ..., X_nX1​,X2​,...,Xn​，MAD定义为数据点到中位数的绝对偏差的中位数：
MAD=median(∣Xi−median(X)∣)MAD = median(|X_i-median(X)|)MAD=median(∣Xi​−median(X)∣)
也就是说，先计算出数据与它们的中位数之间的残差（偏差），MAD就是这些偏差的绝对值的中位数。
示例
考虑数据集(1, 1, 2, 2, 4, 6, 9)，它的中位数为2。数据点到2的绝对偏差为(1, 1, 0, 0, 2, 4, 7)，该偏差列表的中位数为1（因为排序后的绝对偏差为(0, 0, 1, 1, 2, 4, 7)）。所以该数据的绝对中位差为1。
用途
绝对中位差是一种统计离差的测量。而且，MAD是一种鲁棒统计量，比标准差更能适应数据集中的异常值。对于标准差，使用的是数据到均值的距离平方，所以大的偏差权重更大，异常值对结果也会产生重要影响。对于MAD，少量的异常值不会影响最终的结果。
由于MAD是一个比样本方差或者标准差更鲁棒的度量，它对于不存在均值或者方差的分布效果更好，比如柯西分布。
MAD与标准差的关系
为了能将MAD当作标准差$\sigma$估计的一种一致估计量，使用
σ^=k⋅MAD\hat\sigma = k \cdot MADσ^=k⋅MAD
其中 k 为比例因子常量，值取决于分布类型。
对于正态分布数据，k的值为：
k=1/(Φ−1(3/4))≈1.4826k = 1/(\Phi^{-1}(3/4)) \approx 1.4826k=1/(Φ−1(3/4))≈1.4826
也就是标准正态分布$Z=X/\sigma$的分位函数的倒数（也称为逆累积分布函数）。数值3/4是为了$\pm MAD$包含标准正态累积分布函数的50%（从1/4到3/4的范围值），也就是：
12=P(∣X−μ∣≤MAD)=P(∣X−μσ∣≤MADσ)=P(∣Z∣≤MADσ).{1 \over 2} = P(|X-\mu| \le MAD) = P(|{X-\mu \over \sigma}| \le {MAD \over \sigma}) = P(|Z| \le {MAD \over \sigma}).21​=P(∣X−μ∣≤MAD)=P(∣σX−μ​∣≤σMAD​)=P(∣Z∣≤σMAD​).
所以，必须有：
$$\Phi (MAD/\sigma )-\Phi (-MAD/\sigma )=1/2$$
而
$$\Phi (-MAD/\sigma )=1-\Phi (MAD/\sigma )$$
得到MAD/σ=Φ−1(3/4)=0.67449MAD/\sigma = \Phi^{-1}(3/4) = 0.67449MAD/σ=Φ−1(3/4)=0.67449，从而比例因子k=1/Φ−1(3/4)=1.4826k = 1/\Phi^{-1}(3/4) = 1.4826k=1/Φ−1(3/4)=1.4826。
另一种计算方法是MAD等于半正态分布的中位数：
MAD=σ2erf−1(1/2)MAD = \sigma \sqrt 2 erf^{-1}(1/2)MAD=σ2​erf−1(1/2)
这种形式可以用于概然误差的计算。
总体MAD
总体的MAD与样本MAD的定义类似，但是它是基于完全分布而不是样本执行的计算。对于均值为零的对称分布，总体MAD是分布的75%分位点。
均值有可能是无限值，或者不存在的值；然而总体MAD永远都是一个有限值。例如，标准柯西分布的方差不存在，但是它的MAD等于1。
已知最早提出MAD概念的是约翰·卡尔·弗里德里希·高斯。
R语言MAD函数
在R语言中，计算MAD的函数是stats包中的mad()，不同的是它默认乘上了一个比例因子1.4826，为了达到渐进正态一致性。
mad(x, center = median(x), constant = 1.4826, na.rm = FALSE, low = FALSE, high = FALSE)

其中，

x 数值向量。


center 可选，中心点：默认为中位数。


constant 比例因子。


na.rm 如果为TRUE，在计算之前将x中的NA删除。


low 如果为TRUE，计算‘lo-median’，也就是说，对于个数为偶数的样本，在最后计算中位数时不使用两个中间值的均值，而是采用其中较小的值。


high 如果为TRUE，计算‘hi-median’，也就是对于偶数样本，采用两个中间值的较大者作为中位数。

在R语言中，该值的计算方式为constant * cMedian(abs(x - center))，其中center的默认值为median(x)，cMedian为“低”中位数或“高”中位数，参见上面的参数low和high。
默认值constant = 1.4826（近似等于1/Φ−1(3/4)=1/qnorm(3/4)1/ \Phi^{-1}(3/4) = 1/qnorm(3/4)1/Φ−1(3/4)=1/qnorm(3/4)）可以确保对于遵循N(μ,σ2)N(\mu,\sigma^2)N(μ,σ2)分布的XiX_iXi​和大的n 值，存在以下一致性：
E[mad(X1,...,Xn)]=σE[mad(X_1, ... , X_n)] = \sigmaE[mad(X1​,...,Xn​)]=σ
如果na.rm为TRUE，在执行计算之前，将会删除x中的NA值；否则，只要x中存在任何NA值，mad函数将会返回NA。
示例
mad(c(1:9))
print(mad(c(1:9),     constant = 1)) ==
      mad(c(1:8, 100), constant = 1)       # = 2 ; TRUE
x <- c(1,2,3,5,7,8)
sort(abs(x - median(x)))
c(mad(x, constant = 1),
  mad(x, constant = 1, low = TRUE),
  mad(x, constant = 1, high = TRUE))

以上代码输出如下：
> mad(c(1:9))
[1] 2.9652
> print(mad(c(1:9), constant = 1)) == 
+       mad(c(1:8, 100), constant = 1) # = 2 ; TRUE
[1] 2
[1] TRUE
> x <- c(1,2,3,5,7,8)
> sort(abs(x - median(x)))
[1] 1 1 2 3 3 4
> c(mad(x, constant = 1),
+   mad(x, constant = 1, low = TRUE),
+   mad(x, constant = 1, high = TRUE))
[1] 2.5 2.0 3.0

通过代码第2行的输出可以看出MAD对于异常值的鲁棒性。

目录

技术中台的作用是什么？

技术前台

技术中台

在什么情况下，才有必要做技术中台？

| 前提1：技术组织结构垂直化

| 前提2：业务线又多又复杂

有了技术中台，是不是就能上天？

总结

 


就在刚过去的半年里，「中台」成了技术圈内讨论的热门词汇，就连一些名不见经传的小公司，也都纷纷喊出了「要向中台转型！」的口号，甚至有人说「不做中台，那就等着死吧！」

如果我没有记错，「中台」思想源自于2015年，马云参观一个著名的游戏公司Supercell之后提出了，简言之就是“小前台、大中台”，随即阿里就成立中台事业群，并取得了很好的成效。

随后，美团点评也开始走中台策略，腾讯在去年的组织架构调整中，也提出建设具有 “腾讯特色的技术中台”。


技术中台的作用是什么？

要搞明白这点，你需要先搞清楚「技术前台」、「技术中台」与 「技术后台」 之间的关系，以及他们各自扮演的角色与作用。

先来说说我们的「技术前台」。

技术前台

「技术前台」，说白了就是为业务部门开发功能的技术团队。

如果是ToC的业务，交付物必须贴近终端用户，如果是ToB的业务，交付物需要满足商家的需求。

脑海中必须时刻牢记 “小步快跑，快速试错” 的理念，业务说啥，就是啥，业务要怎么做，你就怎么做。

另外，研发资源的投入基本和业务对等，业务需求多，人数增加，业务需求少，人数相应减少，而且团队组织也基本按功能线来划分。



运用的技术栈也相对单一，以Java语言为例，通常 “1个NG + 1个War/N个Jar + 1个数据库” 就搞定了，而其余的技术服务都将由「技术中台」提供。



「技术前台」的核心价值体现在对业务逻辑的理解与实现上，是技术向业务传递价值的阶梯。

我觉得在这点上，与线下销售团队的前台营销有一些类似。

技术中台

再来说说我们的「技术中台」。

「技术中台」，说白了就是强调资源整合、能力沉淀的平台体系，当「技术前台」实现业务功能时，为他们提供底层的技术、数据等资源和能力的支持。

这怎么理解？



从这张图中可以看到，「技术中台」有点像编程时的适配层，起到承上启下的作用，将整个公司的技术能力与业务能力分离，并以产品化方式向前台提供技术赋能，形成强力支撑。

在什么情况下，才有必要做技术中台？

俗话说 “知己知彼，百战不殆”，在我看来，面对技术问题时，“知己” 比 “知彼” 更为重要。

在实施「技术中台」之前，我们是否要静下心来对自己进行 “灵魂拷问”？比如说，当前的时机是否已经成熟？或者怎么才叫成熟？

在我看来，要想做「技术中台」，客观环境需先满足两个前提：技术组织结构垂直化、业务线又多又复杂。

否则，「技术中台」的结果只会是两种：一场闹剧 或者 一笔赔钱的买卖。

| 前提1：技术组织结构垂直化

曾经有朋友说过，每家公司的组织结构演进都是一部心酸血泪史。我很费解，问为什么？

他说，因为这中间掺杂着太多的主观判断与情感纠葛。

比如，某员工认为公司管理混乱，组织架构来回调整，今天拆这个团队，明天合那个团队，纯属病急乱投医，高管都是些横行霸道，滥用资源的傻逼货，借机搞人，这公司，没救了。

但高管们大呼冤枉，觉得组织架构调整的目的是为了提高产出和人效，如果你干得不爽可以离开，这种事情，本来就不可能让每个人都满意，既得利益者肯定大加赞赏，而失去利益者肯定狂喷不止，不用理会。

的确，这种 “自我革命式” 的调整，基本不可能一步到位，需要一个过程慢慢演化，而在这个过程里，自然会遭遇很多的阻力或质疑。



瞧瞧这结构，经典的职能分工模式，有什么问题吗？

我不但说不出问题，甚至能找出一万个理由说明这种模式的好处。开发按业务线分开，测试与运维形成上下层关系，谁也不想管对方，两边的老大也是评级的，相安无事。

那什么情况下才会觉得这种模式有问题呢？

客观的说，职能分工模式更适合瀑布式开发模式。先谈需求，再谈工期，随后按部就班地往下做

但当用户的需求开始变的多种多样，业务方时不时的就要上一个新功能，做一个新系统的时候，你会发现开发出来的系统很难变更，至少很难快速变更。

于是，你把开发按系统功能进行重组，每个团队都围绕 “交付速度” 开展工作，但这样又遇到了两个新的问题：


	
多种多样的中间件，每个团队独立选型中间件，没有统一的维护，没有统一的知识积累，无法统一保障SLA。
	
	

	
开发与测试、运维之间目标不一致（比如测试A君，开发要求你只做功能测试，快上线，但测试老大却要求你做非功能测试，保障质量，避免背锅……到底听谁的？），陷入永无休止的扯皮与争吵。
	
面对这两个新的问题，我们做出了调整：


	
成立平台架构组，负责中间件、自动化测试/运维、数据库等技术工具或服务的开发、维护。
	
	

	
把质量管理部中的测试团队，与系统运维部中的应用运维团队，按照系统功能拆分至各开发团队，由原开发经理负责，形成各自独立的Feature Team。
	


到这个时候，虽然整个组织结构还未完全实现垂直化分工，但已基本能够达到 “快速试错，小步快跑” 的目标。

另外，这更像平台化的另一种雏形，就是逐渐把一些公共、底层的技术能力抽象出来，与业务逻辑分离，并形成各种接入式基础服务，同时可以为多个业务线提供服务。

也就是说，打造「技术中台」的前提是平台化，而平台化的先决条件是「组织结构垂直化，技术工具公共化」。

如果没有这样的前提，就失去了打造「技术中台」的立身之基。

| 前提2：业务线又多又复杂

曾经有朋友问我，技术的核心价值是什么？我的答案是 “改变世界”。

他说，别扯淡，好好说话。

他说，对业务驱动型的公司来说，技术的核心价值是 “降低成本，提升效率”，而单从架构设计的角度来看，想达成这项目标的两个手段是「通用性」与「复用性」。

现在想想，这句话可以完美的衔接到「技术中台」上去。

回顾几年前，我们的业务逻辑也曾非常单一，要么用你的银行卡买卖基金，要么用你的电子钱包买卖基金，方便，快捷。



渐渐地，随着业务创新业务增多，需要前后台系统定制开发，逻辑兼容难度增加。



在这样的局势下，为满足企业规模扩大和多样化经营对组织机构的要求，公司开始转向事业部制，按产品、地区或市场(顾客) 划分经营单位。



为了应对业务方的这次调整，我们开始将业务开发中的一些共享服务分离出来，成立了业务中台组（由于本文以技术中台为主，业务中台的内容将不进行展开说明）

将可以复用的服务和代码，交由这几个组开发出服务来，给业务组使用，这样数据模型会统一，业务开发的时候，首先先看看有哪些现成的服务可以使用，不用全部从零开发，也会提高开发效率。

与「业务中台」相呼应，「技术中台」就像一个工具大仓库，里面放满了各式各样的技术工具，无论是哪个团队，哪个人，快速找到自己的工具，拿来就用就行了。

而维护工具的这群人，不用贴近业务开发，每天的任务就是研究如何使用这些工具，如何调优，遇到问题如何Debug，形成知识积累。

有了这么一群专职的人，就可以根据自身的情况，选择有限几个技术栈集中研究，限定业务组只使用这些工具，可保证选型的一致性。

如果你只有一条业务线，那就别搞「技术中台」了，把人凑在一堆，又省钱，又省力。

有了技术中台，是不是就能上天？

理论上讲，当业务线变多且越来越复杂，前台与后台之间的“技术债”会随之变多，重复造轮子与沟通成本太高的现象会增多，通过技术中台可以一定程度上来解决这个问题。

这种理论看似完美，但在实际执行上却困难重重。

设想下，如果「技术中台」做得太多，资源投入就会很大，无法形成正向的利益传导；

如果「技术中台」做得太少，又无法深入理解业务，导致适配方案落地性变差，渐渐失去价值。

这句话怎么理解？

十年前，我在某金融软件公司工作，随着客户数的增多，成本与效率/质量的矛盾日益凸显。

设想下，从一波人维护一套代码，渐渐变成一波人维护几套代码，这样一来，Bug增多，效率下降，抱怨也随之变多，再加上甲方挖人，最后人员离职，团队土崩瓦解，Game Over……

在这种情况下，一般公司会采取三种应对措施：


	
一对一服务 - 项目制：多个团队，多套代码，多套标准，服务多家客户，但这样一来成本又难以承受，时间一长，肯定资不抵债。
	
	

	
一对多服务 - 标准化：一个团队，一套代码，一套标准，服务多家客户，但客户不买账，客户说我的需求都是个性化的，你别来某某标准来引导我，叫你咋做，你就咋做，不愿意？那您走，我找别人家做。
	
	

	
一对多服务 - 产品化：一个团队，一套代码，多套标准，服务多家客户，通过技术与配置化的手段，利用SOA思想，打造自己的产品化平台，但对技术投入要求较高，尤其是核心人才的依赖较大，中小型企业一般都很难留住这些人，只要他们一走，公司基本完蛋。
	
回想下，当年那些叱诧风云的软件公司，又有几家活下来了？以金融业为例，恒生算是在第二条路上走的比较成功的，而我们当年却死在了第三条路上。

在我看来，我们的「技术中台」就是一家 “乙方服务公司”，而我们的「技术前台」更像是一家 “甲方电商公司”。

不可否认，有了这家 “乙方服务公司” 之后，在面对大型项目及快速多变的业务时，技术的投入与主动权更强了，但由于理念、职责、节奏与使命不同，外加 “屁股决定脑袋” 的立场，前台与中台之间很容易引发矛盾。

从职责角度来说，前台是 “快速应对业务变化”，中台是 “稳定高效提供服务”。

一个追求效率，一个追求质量，这矛盾是天然存在的。

怎么理解？我来举个小例子说明下。

前台部门的A团队和B团队，由于业务需要同时向「技术中台」提出要接入缓存服务的需求

「技术中台」的中间件产品线中有一套基于Proxy的自研分布式缓存系统，已在其他业务线运行多年，但由于A团队与B团队的技术债都各不相同，必须通过增加适配器才能完成接入

而此时人手又不够，按重要程度排序，只能先接A团队，但B团队也有需求，又等不及，怎么办呢？就先给他来个Redis接着玩玩吧，等A团队接好了再来接你的。

一个月后，等A团队接完了，找到B团队，这时痛点已不存在，团队的激情自然不高，毕竟没有收益，就不了了之了。

几个月后，安全团队提出要对Redis集群进行改密，由于A团队接入的是「技术中台」的缓存中间件产品，采用代理模式，并通过控制台操作，既方便，又快捷，找个晚上，5分钟内，全部搞定。

但B团队用的是直连Redis的模式，密码嵌入在SDK中，不仅在改密过程中需要前台与中台联动，而且还需要在改密后重启应用服务，这样一来，只有配合应用发布的周期才能干这件事。

最终，原本五分钟可以搞定的事，整整搞了三周才搞定，「技术中台」的运维同学更是陪熬了多次通宵，还因为人为疏忽引发了一次事故。

就在这件事过去的一年时间里，由于B团队系统的业务规模逐渐增大，Redis数量也逐渐增多，「技术中台」的运维成本与风险也随之上涨。

这期间，中台曾多次与前台交涉，希望能够通过适配的方式将A团队接入缓存中间件，但始终未能达成。

在「技术中台」看来，“你们只顾自己，不管别人，功劳你们拿，黑锅我们背？”

在「技术前台」看来，“你TM懂个屁！我们都快被业务逼疯了，你们不就多费点人工吗？多加点班会死吗？总扯一些理念干嘛？对你没收益的事，你干嘛？”

因为这样的分工模式，导致这种矛盾在工作中很多，而且似乎并没有更好的方法彻底解决。

有人说，要解决很简单，要么强压，要么加大投入，下下狠心就得了。

先来说说强压，似乎能够在短时间内达到目的，但纯属 “杀敌一千自损八百” 的招数，难道要业务研发团队停下手上的活，倾巢而出一起搞技术改造吗？更何况，前台承受的压力，是中后台团队无法想象的。

退一步说，抛开 “互相理解” 这个话题，强压的套路等同于 “攻城为上，攻心为下”，对今后的管理与团队氛围都会带来诸多的麻烦。

再来说说加大投入，看看我上面提到的 “死在路上的软件公司们”，还想加大中后台的投入吗？

如果你不是大厂，还是算了吧。

那句话怎么说来着？最悲惨的结局是，你的技术中后台越发强大，但你的业务规模却在逐渐萎缩。

可悲，可叹。

总结

在互联网时代，技术圈似乎从来不缺少热议话题，但有质量，有深度，且能解决实际问题的却少之又少。

现在人人都在讨论「中台」，今天「产品中台」，明天「数据中台」，这个说能提高效率，那个说能排除万难，聊得不亦乐乎。

对于企业来说，话题热不热并不重点，方案牛不牛逼也不重要，关键是能帮助用户找到效率、质量与成本的平衡点，或许才算是一个合格的「技术中台」。