引言

十九世纪英国的著名思想家John Henry Newman曾言“Calculation never made a hero”,calculation本义是计算,这里的意思应该是从慎重考虑、仔细思考这个角度出发,指考虑太多容易错失良机。所以这一句话一般译为“举棋不定永远成不了英雄”。可见,计算还是必要的,只不过不应该过度,正如孔夫子所说:过犹不及。

社会发展,之所以要数字化,其中一个重要的原因是为了可以计算,而计算,在数理科学背景下,则意味着高效,这自然少不了数学的加持—用得好了,至少可以事半功倍;用得不好,尤其是贸然乱用,则会招致不同程度的麻烦,甚至灾难。

如何计算数据

臭名昭著的例子有很多,比如1999年9月23日,美国发射的火星气候轨道侦测器(Mars Climate Orbiter)1号解体,原因是错误的飞行轨迹使它过于接近这颗红色星球,导致承受的大气压力过大。 事后发现,这个错误的根本原因非常可笑:由洛克希德·马丁公司( Lockheed Martin)提供的一个计算推进器发射的软件所用的物理单位是非国际单位—磅力秒(pound-force second),而与其对接的由美国宇航局提供的另一个读取这个结果的软件,其所用的单位是牛顿秒(newton seconds)。一磅力等于4.45牛顿,可见计算误差很大。

这类案例提醒我们,犯错无处不在,而且很容易出现计算错误。很多人承认,这确是人们经常跌落的陷阱。

每当对数据进行数学处理时,都会进行计算。一些常规的例子包括:

  • 对数量进行不同层次的汇总,如对时间分组——每周、每月或每年的数量
  • 将数据中的数量与其他数量分开以产生不同单位或相同单位的比较
  • 使用比例或百分比
  • 从一种度量单位到另一种度量单位的转换

如果你觉得这些计算很简单,肯定不会犯错误的话,那么你太高估自己了。 我在很多情况下都踩过这个坑,也看到其他很多人,包括一些老手,一次又一次掉进去,也挺可悲的。 相信很多数据从业者也都有类似的体会。本系列文章将把更高级的计算留到后面的章节,这里先从最基本的开始。

陷阱:汇总失衡

当对具有相同属性的数据记录进行分组时,就会涉及数据聚合或汇总。在实际生活中,有各种各样的这种分类。有时数据分组会形成层次结构。以下是一些例子:
•时间: 小时、日、周、月、年
•地理: 城市、县、州、国家
•组织: 员工、团队、部门、公司
•运动: 团队、分区、会议、联盟
•产品: SKU,产品类型,品类,品牌

无论我们是在报告不同级别的销售状况,还是为商业活动统计投票,这些汇总计算对我们的报告的完成度都至关重要。让我们来看一个来自航空领域的例子。

美国联邦航空管理局(The U.S. Federal Aviation Administration)鼓励飞行员自愿报告他们的飞机在起飞、飞行、接近或降落时撞击野生动物的情况。 显然,从飞行员、乘客,尤其是那些可怜的小动物的角度来看,挺没劲的。而这个数据向公众开放,为了让大家对此有所感知。

从这些记录中摘录了一个特定的部分(数据源来自https://wildlife.faa.gov/),我们看下上报的野生动物袭击的数量是如何随着时间变化的,当然前提是如果有的话。这里做了张撞击记录的时间线图,按年计算,如下所示:

从这个时间轴上可以看到,该数据记录可追溯到2000年。这图这似乎表明,上报的撞击事件呈上升趋势, 然后在有数据显示的最近一年(相对于当时写这个分析报告的时间),即2017年,出现了急剧下降。为什么撞击数量突然减少了? 是否有一些高新技术在全美各地的机场实施?鸟类和动物的大规模南迁?负责管理数据的美国联邦航空局员工罢工了?

其实答案不难找到,将数据集的粒度级别精确到月或周, 可以看到2017年的数据只有半年的,如下所示:

确切地说,当时做这个分析报告时,该数据集中最新记录的野生动物撞击发生在2017年7月31日晚上11点55分。 有记录的最早的撞击发生在2000年1月1日上午9点43分。 这是上报撞击事件的日期方面的范围,也是一个简单但重要的陷阱预警:将层次不同的数据按同一层次汇总。

这提醒我们,在得出任何关于数据的结论之前,一定要花一点时间找出正在分析的数据的边界 ,至少先找出数据集中每个定量维度的最小值和最大值。

可以想象,处理新数据集类似来到一个未知的岛屿,比如波利尼西亚人在700年前首次发现并定居新西兰,后来成为毛利人。 或者类似于探险家詹姆斯·库克(James Cook),他在1769年末至1770年初来到那里,是第一个完成了环绕毛利人家乡对面那个岛屿的欧洲人。

有趣的是,库克并不是第一个发现新西兰的欧洲人。在他之前的一个世纪,1642年,荷兰航海家亚伯·塔斯曼(Abel Tasman)驾驶着Zeehaen号船已经发现了,但他没有像库克那样彻底地绕过,也没有彻底地探索其海岸。 这就是为什么库克的探险队能够正确地将新西兰南部和北部岛屿之间的区域识别为一个海峡,因而这是一个可航行的航道,而不是一个海湾;可是当时那个荷兰人错误地认为这是仅仅是一个没有通道的弯曲的海岸线。这就是为什么新西兰南岛和北岛之间的那片区域被称为库克海峡, 而不是塔斯曼最初命名的齐海恩湾。这是一个很好的实例,因为它展示了:当我们不能彻底地探索航海目标的轮廓时,很可能会得出关于地形的错误结论,做数据工作也是如此。

这段历史典故讲罢,回到刚才提及的野生动物撞击飞机的数据集。如果已经看到了2017年撞击数据的陡降,不作多想,还是认定这是2017年的全年数据,就太不应该了。 每次给一些新受众展示这个报告时,对于2017年的这个突然下降的撞击数,很多人都会狐疑不决,脑洞大开,即使已经事先提醒这个是已上报的数据。相信一直跟着看这个系列的朋友, 应该看出来了,这里面又涉及了认知方面的陷阱,即数据与现实的差距,也就是错误的认定标识为2017的数据包含了2017年的全部数据。

期待大家在汇总多层次数据集时,对此保持谨慎。

如果我们想探究野生动物撞击的季节性会怎样?例如,撞击是否经常发生在冬季还是夏季? 如果没有首先探索轮廓数据而去寻求这个问题的答案,一般会先看下按月汇总的数据,作图如下:

首先观察到的可能是,撞击次数最多的月份是7月,在冬季12月达到了最低水平,
1月、2月,然后在春季缓慢增加,5月至6月略有下降,然后在7月飙升至峰值。在这个高峰之后,计数逐月稳步下降。

通过之前对数据轮廓的研究,我们已经知道,这些记录在2017年7月31日结束, 所以1月到7月的数据比8月到12月多了一个月。如果我们在每个月的条形图上加上年度的部分—— 每年一个带有数据的部分——并且只把2017年的部分涂成红色,就会发现,每个月的比较并不是严格意义上的一对一比较。如下图:

1月,2月,3月,4月,5月,6月和7月都包括18种不同年份的数据,和其他月份包括17个不同的年, 因为2017年只有部分数据。如果过滤掉2017的数据, 在上图中意味着去掉红色部分从,而每个月度包含数据相同年数。 如此看来,7月份实际上并不是上报撞击次数最多的月份,而是8月份,如下图所示

如果我们贸然作一个快速和粗略的分析,认定7月是高峰月份,就会像亚伯塔斯曼航行离开库克海峡, 认定前方无路可走是一样的。说来可悲,已不知有多少次,数据从业者因为忽略了数据集的边界,而在基本事实上犯了错误。

陷阱:失落的数据—缺失值

上一部分谈的是对数据集的外部边界没有清晰认识在汇总和组间比较时出现的问题, 这里把目光转向数据内部,谈一下缺失值。与以往不同的是,我们看一个相对文艺一点的例子。

这个例子与Avoiding data pitfalls的作者Ben Jones的个人兴趣有很大关系。Ben很喜欢美国文学家埃德加·爱伦·坡(Edgar Allan Poe)的作品,想分析一下其全集,目的在于看下在他的一生中,作为一个多产的作家:总共写了多少作品或发表了多少作品, 他在什么年龄开始和停止写作,以及是否有某段时间他的创作渐显乏力。

Ben在维基百科上无意中发现了这位文学家的全部参考书目(数据来源:https://en.wikipedia.org/wiki/Edgar_Allan_Poe_bibliography.), 其中包含了已知的每一部作品的表格, 这些表格按文学类型和写作日期进行排列。总共大约有150件作品,但其中有一些是有争议的,Ben猜测会有几十个。

维基百科页面上的表格有的提供特定作品的完整日期,有的只列出月份和年份,有的只列出年份。 把这些表格稍微整理一下,按年创建一个埃德加·爱伦·坡作品总数的时间轴,如下图所示

可以看到,他在1824年开始写作,那一年将满15岁,一直写作到他去世,1849年。 看起来他最多产的一年,包含很多不同作品,是1845年,一共写了13篇。现在,看一下他职业生涯中哪一年创作的作品最少。

看下时间轴上的最低点,也就是值为1的1824和1825年间,只写了一部文学作品。 那时候他还是个青少年,似乎答案就是这个了。然而,那并不是他创作文学作品最少的年代。我们还是要更仔细的观察一下,就像福尔摩斯检查犯罪现场一样。

顺着x轴的年份检查一下,会注意到这个时间序列中少了三年。在x轴上没有1826、1828和1830的值。 在那些年里,显然什么也没发表。还有个数据处理的问题:做这张图时,年份的格式并没有转化成时间格式, 因此就更难注意到这些年份从时间线中消失了,即使线图的偏度很明显。

为了显示出那些失落的年代,设置一下数据的格式或者根据各自的可视化工具进行相应调整, 这里用tableau作图如下所示。

为了更进一步的清晰显示失落的年代,再做一张柱形图,如下图所示:

可见这里主要涉及如何处理缺失值,而不同情况,方式也不同。比如,类似奥运会或其他每隔几年一次的事件,就没必要把缺失的年代调整为0了。

缺失值是数据集中的隐藏杀手,一直是极其危险的存在,无论如何对其保持谨慎都不为过。

陷阱:不一致的单位

这也是一常见陷阱,与我们测量事物的方式有关。 当我们对数据中的不同度量进行数学运算时,需要确保知道所涉及的度量单位都是什么。 如果不小心,就可能碰到单位不一致的情况,然后得到非常错位的结果。

在前面,已经提到了火星气候轨道器解体(如下图4.26)这个的例子。当时的情况是,轨道飞行器飞得离火星表面太近了,承受压力过大,即将被烧成灰烬。 造成这一错误轨迹的原因是,洛克希德·马丁公司在提供的一个软件系统中,所输出推力器的发射脉冲是以磅力秒(pound-force second)计算的, 而美国宇航局创建的另一个系统,则根据每个系统的规格以牛顿秒(newton seconds)计算。一磅力等于4.45牛顿, 所以计算得出的推力比轨道飞行器保持在安全高度所需的推力要小得多。这次任务的总成本为3.274亿美元自然全部损失,而更大的损失则是失去了许多关于火星的宝贵信息。

Ben Jones,上世纪90年代末在加州大学洛杉矶分校(University of California at Los Angeles)就读工程学院时,度量单位是一件很重要的事情。 作为学生,他们经常被要求在作业、实验和考试中从国际单位制(IS,法语国际单位制的缩写)转换为英语工程单位,反之亦然。忘记转换单位是新手常犯的错误,而这种现象或问题在实际工作中也以不同程度存在着。

目前世界上只有三个国家没有使用国际单位制:利比里亚、缅甸和美国。 试想一下,如果你生活在古代,当你去邻近的城镇旅行时,你会遇到完全不一样的长度、质量和时间的测量系统, 这通常是根据当地封建领主的拇指大小或足长之类的东西确定的。

所以要感谢法国大革命,因为它促成了绝大部分国家采用一套共同计量单位。现在美国要达到这一目标,每更换一个路标,一部法律, 一个监管要求,一个包装标签的成本都将是巨大的,而且这些成本将持续几年甚至几十年。 但从长远来看,减少错误、简化跨境贸易和国际交流能够节省很多成本, 还能让数据陷阱变得不那么危险。

对于那些不是工程师或科学家的朋友,可能正坐在哪里自言自语: “我真庆幸不用担心这个问题!”毕竟,我又不用去设计火星轨道器或漫游者或类似的复杂东西。”

首先,让我们承认设计火星轨道飞行器,漫游者之类的,复杂是复杂,但还是挺酷的。第二,即使不做这些,你还是会涉及各种单位的事情。 比如,你是否曾在盘子里放一汤匙盐,而不是食谱中要求的一茶匙?这里面的容量差别到底是多少?

以下是Ben Jones列举他自己在这些情况下,包括商业在内,曾经陷入这种糟糕陷阱的10种不同方式,还是颇具一定代表性的:
•用不同货币计算成本或收入:美元、欧元、人民币,日元
•用不同的度量单位计算库存
•温度比较:摄氏温度、华氏温度(开尔文温度)
•用各种数量做数学运算,比如使用K(数千)、M(百万)和B(数十亿)
•使用纬度和经度以度数分秒(DMS)和十进制度数(dd)处理位置数据
•使用笛卡尔坐标(x,y)与极坐标(r,线性)处理二维空间位置
•处理角度与弧度
•用十六进制、十进制或二进制计算或做数学
•确定发货日期时,涉及日历日和工作日

上面列出的这些项目中有一些是相当棘手的,也并不少见。 以最后一个为例——运输时间。我的包裹什么时候到?把周末和假期也考虑进去了吗?是中国的假期,还是需要考虑美国,加拿大或英国的假期? 从技术上讲,测量的基本单位无论如何都是一天,但我们是以特定类型的天为单位来测量时间的。 这可能看起来像一个技术细节,但可能决定着在我们的旅行途中,能否按时收到需要的包裹。

跌入这个陷阱的根本原因是盲目深入数据集,而不花时间去先查阅元数据表。 元数据很重要,可以帮助我们理解到底在处理什么,以及严格记录所创建数据集的重要性。 数据字段可能名为shipping time,但该字段的操作定义是什么?另一个数据字段可能名为quantity, 但它是以单位、容器或其他形式度量的吗?还有一个数据字段叫price,但是货币单位是什么呢?

查询元数据是必要的。 标准的数据集都要经过严格的文档化,每个领域都有详细的描述, 以回应度量单位问题,而花些时间去下定义是值得的。

需要注意的一个细节是,有时数据集会有一个包含不同单位记录的字段,一个混合数据字段。 在这些情况下,通常会有第二个伴随列或数据字段,为每个字段指定度量单位。 这些是特别复杂的情况,我们可能需要编写基于度量单位(通常是UoM)字段的IF/THEN计算, 以便在执行简单的聚合计算(如Sum和Average)之前将所有值转换为公共单位。

想获取更多内容,请关注海数据实验室公众号。

本期分享到这里,我们会每天更新内容,咱们下期再见,期待您的再次光临。有什么建议,比如想了解的知识、内容中的问题、想要的资料、下次分享的内容、学习遇到的问题等,请在下方留言。如果喜欢请关注。

社群推荐:

更多有关数据分析的精彩内容欢迎加入海数据在线数据分析交流群,有什么想法或者疑问都可在里面提出,与同行零距离交流,共同成长进步,请识别下面二维码加火星小海马微信,邀你进群。

七大数据陷阱之技术过失之数学失误-如何计算数据(上)相关推荐

  1. 七大数据陷阱之技术过失(上):数据整理中的问题

    引言 许多著名运动员都曾坦言:我所做的不过是令自己精力充沛,技巧娴熟.同样的,虽然之前谈论了不少与数据科学相关的理论和思想, 但实际的数据工作也不外乎基础设施的性能优化,以及到各种到位的技术性操作,如 ...

  2. 七大数据陷阱之油腻的统计学:千夫所指

    开场白 时下已经是所谓的数字化和大数据时代很多年了,统计学的地位愈发显赫,用途愈发深广,而对之的批评或负面情绪也日益高涨. 对于如此现象,用一句电视剧里常说的话---此事牵涉甚广,那么本文就来理上一理 ...

  3. Dws同步mysql数据_数据库技术丨GaussDB(DWS)数据同步状态查看方法

    摘要:针对数据同步状态查看方法,GaussDB(DWS)提供了丰富的系统函数.视图.工具等可以直观地对同步进度进行跟踪,尤其是为方便定位人员使用,gs_ctl工具已集合了大部分相关系统函数的调用,可做 ...

  4. Halliburton首席数据科学家兼技术研究员谈能源行业AI应用现状

    能源行业属于高技术驱动性行业.由于需要在严苛的条件下处理大型设备中的各类自然资源数据,石油与天然气行业长期使用数据及分析技术提高流程效率.近年来,能源行业企业开始加大对各类AI这既的应用,通过多种方式 ...

  5. 独家 | 大数据与AI技术在金融科技的应用

    独家 | 大数据与AI技术在金融科技的应用 [导读]本文选自百融金服CEO张韶峰和CRO季元于2017年9月14日晚在清华大数据"技术·前沿"系列讲座--大数据与AI技术在金融科技 ...

  6. 《大数据》2015年第2期“前沿”——大数据技术发展的十个前沿方向(上)

    大数据技术发展的十个前沿方向(上) 吴甘沙 英特尔中国研究院 doi:10.11959/j.issn.2096-0271.2015023 Ten Fronties for Big Data Techn ...

  7. 发展大数据还有啥问题:数据孤岛、技术差距、人才短缺

    近日,在有关部门的调解之下,菜鸟和顺丰的"数据断交"事件总算告一段落,双方经过紧急会谈后,再次恢复了数据传输合作,算是和平解决.这次事件暴露出了大数据发展中的数据共享难题,但只是大 ...

  8. 大数据和云计算技术周报(第101期)

    导语 "大数据" 三个字其实是个marketing语言,从技术角度看,包含范围很广,计算.存储.网络都涉及,知识点广.学习难度高. 本期会给大家奉献上精彩的:Spring熔断降级方 ...

  9. 【开赛啦!邀你来战 】2022年“桂林银行杯”数据建模大赛暨全国大学生数学建模竞赛广西赛区热身赛

    2022年"桂林银行杯"数据建模大赛 大赛背景 桂林银行股份有限公司(以下称"桂林银行"),以金融成就美好生活为使命,以承接国家和地方发展战略为己任,服务地方经 ...

最新文章

  1. c语言写的跳转心理测试,求各位大神赐教!我做了一个“心理测试的答题卷”编程,总共有1...
  2. 释疑の舍入参数文件介绍
  3. 向DataGridView中添加新的一行数据,可以添加到最后一行或作为第一行
  4. Readhat中作安全基线
  5. Intel Hyperscan简介
  6. ES terms多值搜索及范围过滤深入剖析-搜索系统线上实战
  7. JavaScript语法详解:运算符和表达式
  8. MATLAB xlswrite 写数据 到 Excel文件
  9. .net session超时设置 sessionState的相关属性
  10. Spring Cloud构建微服务架构(四)分布式配置中心(续)
  11. 20190912每日一句
  12. echarts地图map下钻到镇街、KMZ文件转GeoJson、合成自定义区域
  13. 使电动机反转的matlab仿真图,基于MATLAB的电机仿真研究
  14. 金蝶凭证序时簿在哪_金蝶KIS旗舰版外购入库单序时簿界面没有凭证的按钮
  15. 配色表 色卡 前段色彩
  16. cordova环境配置步骤
  17. 华为交换机关闭网口_华为交换机监控口配置命令图文教程
  18. 一个简单的学籍信息管理系统,基于PHP和Bootstrap的实现
  19. 计算机存储的发展(块存储,文件存储,对象存储)
  20. Luogu_P3258 松鼠的新家

热门文章

  1. React Native 的未来与React Hooks
  2. 快速玩转Yolov5目标检测—没有好的显卡也能玩(一)
  3. KDD99数据集+tensorflow
  4. 采购管理系统(Java+SSH+mysql)
  5. 大专男学计算机还是护理好,男生大专学什么
  6. PPT制作流程图、添加复杂公式?
  7. Elasticsearch8.0版本中Elasticsearch Java API Client客户端的基本使用方法
  8. NC65 查询模板参照字段启用参照是否包含下级
  9. 计算机音乐数字乐谱勇气,梁静茹《勇气》简谱
  10. office2019