10 行代码解决漏斗转换计算之性能优化

最新推荐文章于 2022-04-28 10:47:23 发布

Alice_656

最新推荐文章于 2022-04-28 10:47:23 发布

阅读量288

点赞数

分类专栏：集算器大数据文章标签：数据计算

集算器同时被 2 个专栏收录

19 篇文章 0 订阅

订阅专栏

大数据

8 篇文章 0 订阅

订阅专栏

可阅读原文：http://c.raqsoft.com.cn/article/1539156910581?r=alice

大数据分析的性能优化，说道底，就优化一个事情：针对确定的一个计算任务（数据确定，结果确定），以最经济的方案得到结果。

这个最经济的方案主要考量三个成本：时间成本、硬件成本、软件成本。

时间成本：根据计算任务的特点，能容忍的最长时间各不相同。那些 T+0 的计算任务，实时性要求就比较高，T+1 再算出结果就失去了意义。
硬件成本：可以使用的硬件资源，对一个公司来说一般不是经常变化的，机器配置、可集群数量就那么多。即便使用云计算产品，也只是多了扩容的灵活性，成本是少不掉的。
软件成本：编写出这个计算算法的人工费 + 软件环境的成本。这个成本也与前两项相关，程序控制力度粗犷一些，实现逻辑简单一些，程序就容易编写，那软件成本就会低一些，带来的副作用是运行时间超长或者需要昂贵的硬件。

这三个因素里面，一般对于计算任务来说，自然是越快越好，当然只要不慢过能容忍的时长，也就还算是有意义的计算；而硬件因素的弹性就比较小，有多少资源是相对固定的；所以，剩下的可以大做文章的就是软件成本了。软件成本里，程序员的工资是很重要的一项，而有没有顺手的软件环境让程序员能高效的把计算描述出来，就成了关键。最典型的例子就是理论上用汇编程序能写出所有的程序，但它明显不如 SQL 或 JAVA 做个常规计算来的容易。

说到 SQL 和 JAVA，成规模的计算中心的一些维护者估计也会皱眉，使用它们的时间越长，越能体会需求变动或优化算法过程中的痛苦，明明算法过程自己想的很清楚了，但编写成可运行的程序就困难重重。这些困难主要来自两个方面：

首先，一些基础的数据操作方法是自己逐渐积累的，没有经过整体的优化设计，这些个人工具对个人的开发效率有不错的提升，但没法通用，也不全面，这个困难主要表现在用 JAVA 等高级语言实现的一些 UDF 上。
第二，主要是思维方式上的，在生产场景下用习惯了 SQL 查询，在计算场景下遇到的性能问题自然而然就想通过优化 SQL 语句的方式把问题缓解掉。但实际上这可能是个温水煮青蛙的过程。越深入搞，把简单的过程问题越可能搞成庞大不可拆分的逻辑块，到最后只有原创作者或高手才敢碰它。我这个老程序员，十多年前刚入行的时候，八卦中耳闻过 ORACLE 的系统管理员，尤其是有性能优化能力的，比普通程序员贵多了，可见这个难题在数据规模相对较小的十年前已经凸显了。

（注：生产场景和计算场景在初始阶段的软件系统里一般很难截然分开，数据都是从生产场景积累起来的，等积累多了，慢慢会增加计算需求，逐渐独立出计算中心和数据仓库。这个量变引起质变的过程，如果不在思维上转变，不引入新办法，那就将成为被煮的青蛙。）

为了节省读者的时间，我们先把性能优化的常用手段总结一下，方便有需求的用户逐条对比进行实际操作。

1、只加载计算相关数据。

列存方式存储数据；
常用的字段和不常用的分开存储；
用独立的维表存储维的属性，减少事实表的信息冗余；
按照某些常用作查询条件的字段分开存储，如按年份、性别、地区等独立存储；

2、精简计算涉及到的数据

用来分析时，一些冗长的编号，可以序号化处理，用 1、2、……替代 TJ001235-078、 TJ001235-079、……，这样即能加快加载数据的速度，又能加快计算速度。
日期时间，如果用字符串类型按照我们熟悉的格式 (2011-03-08) 存储，那加载和计算都会慢。前面这个日期可以存储成 110308 这样的数值类型，也可以存储成相对于一个开始时间的毫秒数（如相对于最早的数据 2010-01-01 的毫秒数）。

3、算法的优化

计算量小的条件写在前面，如 boolean 类型的判断，要早于字符串查找，这样用较少的计算就能排除掉不符合要求的数据；
减少对大事实表的遍历次数。具体方法有：在一次遍历过程中，同时给多个独立的运算操作提供数据（后面会提到的集算器里的管道概念），而不是每个运算操作遍历一次数据；做 JOIN 时，在内存里的维表里检索事实表数据，而不是用每条维表数据去遍历一次事实表。
查找时借用 HASH 索引、二分法、序号直接对位等方式加快速度。

4、并行计算