【数据蒋堂】第 44 期:谈谈临时性计算
临时性计算,顾名思义,是指临时发生的一些计算需求。这种计算在日常数据处理中很常见,我们举一些例子:
- 应对业务部门的取数需求:比如销售部门想获得进行了某项促销活动前后的销售情况变化信息;
- 数据挖掘算法前的清理准备:将来自各个业务系统的数据(甚至一些企业外部的数据)整理成规则一致的二维表,这些动作常常比挖掘本身耗时还长得多;
- 有业务规则的测试数据生成:测试数据不能完全随机生成,必须满足一定的业务规则以及分布比例;
- 大数据计算的优化方案实验:性能优化是个迭代的过程,需要不断尝试各种计算方案;
- 非日常(外部)数据的清洗和入库:比如有些下级部门提供的 Excel 表格要写入数据库再进行统计分析;
- …
可以看出,临时性计算具体相当的普遍性。那么,我们是用什么方法来处理这种具有普遍性的计算需求呢?
其实也就是编程序了,常用来对付临时性计算的编程方案有三种:以 Java 为代表的高级语言、以 SQL 为代表的数据库语言、以 Python 为代表的脚本语言。
然后,第二个问题,我们怎么评估这些方法的优劣和适应性呢?
为了回答这个问题,我们先要先分析临时性计算的需求特征:
- 需求随意,不可预测:这是临时性计算的基本特征,计算需求时临时产生的,不能事先预测到而做进数据分析系统中,只能临时面对;
- 经常只做一次,缺乏直接可复用性:这也是临时性的特征,做完就完了,没有必要刻意地反复优化,也没必要也不可能事先为计算做准备工作;
- 大量涉及多样性的原始外部数据:很多计算的涉及数据并不在数据库中,比如收集上来的 Excel 表格,从网上爬下来的文本等,这些数据还常常以原始形式出现;
- 常常涉及多步骤的过程计算:本来分析处理类的运算就会步骤比较多,而数据源的杂乱更会加剧这一现象;
- 必要时可能转变成日常计算:也有些临时性计算可能重复发生,这时就有必要转化成日常计算放进数据分析系统中;
- 以结构化数据计算为主:这一点并非临时性计算特有的,其实数据分析和处理类的计算都是主要面对结构化或即将被结构化的数据。
从需求的特征出发,我们就可以提出应对临时性计算的方案的技术要求了:
- 开发快捷:临时性计算随时发生,需要快速解决,所以要注重开发效率,相对来讲,对于运算性能要求会低一些;
- 人员要求低:临时性计算发生场景很普遍,那么应当尽量降低实施开发人员的要求,而不是总是需要专业的程序员才能做;
- 环境简单:经常只做一次的事情,要让环境搭建足够简单,如果准备计算环境花费时间超过实施计算本身了,那就得不偿失了;
- 数据适应面广:计算方案要能方便地面对各种各样的数据源,不要总是需要专门的接口和技术体系,特别地要能处理较大的数据量;
- 易于集成:要转变成日常计算时,临时写出来的代码最好能够只要简单修改甚至不加修改就能集成到数据分析系统中去。
现在我们按这套技术要求来考查前面提到的三种技术方案,并给评个分(前四项满分 10,第五项重要程度低满分 5)
1. 以 Java 为代表的高级语言
开发快捷 | 3 分 | 用于处理结构化数据的语法和类库都不够丰富,代码会写很长,不方便,但处理过程性运算较容易,调试方便度尚可 |
人员要求低 | 1 分 | 需要很专业的程序员才能掌握 |
环境简单 | 1 分 | 开发环境一点也不简单 |
数据适应面广 | 3 分 | 理论上什么都能做,但做起来都很难 |
易于集成 | 5 分 | 这方面没有任何问题 |
总分:13 分
2. 以 SQL 为代表的数据库语言
开发快捷 | 5 分 | 有完整的结构化数据计算能力,简单运算容易写,但复杂 SQL 很难写,而且存储过程调试很不方便 |
人员要求低 | 6 分 | 简单运算易于掌握,复杂多步运算要转换思维习惯,很费劲 |
环境简单 | 7 分 | 数据库安装不太简单,但常常已经安装好了 |
数据适应面广 | 1 分 | 基本上不能计算数据库外的数据,对外样性数据源和原始数据无能为力;大数据计算能力尚可 |
易于集成 | 5 分 | 这方面没有任何问题 |
总分:24 分
3. 以 Python 为代表的脚本语言
开发快捷 | 8 分 | 开发环境较简单,调试也容易,对过程计算支持较好;不过语法体系不是专为结构化数据计算设计,有些复杂运算还是不好写 |
人员要求低 | 7 分 | 经常一些简单培训后基本上都能掌握,不过有些语法规则比较绕 |
环境简单 | 7 分 | 环境安装较为方便,但版本兼容上有些问题 /td> |
数据适应面广 | 7 分 | 外部数据接口丰富,但开源包安装很麻烦,缺省自有的大数据方案,再配合其它访问显得很麻烦; |
易于集成 | 1 分 | 一般业务系统都是 J2EE 的,集成脚本语言的难度很大 |
总分:30 分
算下来还是脚本语言相对最好。