易观OLAP比赛的反思
这场比赛我们输了。我们向来说自己的产品性能很好，但这次却是输在性能上。
先说具体的技术原因
周六去了解了优胜者的做法，算法和我们基本一样的，这方面并没有特别的优势。影响我们程序性能的因素主要是三点：
1. 存储压缩率
我们采用的存储方式压缩率太低，最终数据量比优胜者大出了10倍还多，只算读取时间就会被远远落在后面了。集算器目前可商用的文件格式更象是一种缓存，列存和强压缩方案都不够成熟。我们在今年之前也没有特别关注存储，一方面是要优先解决计算问题，另一方面由于用户现场如何存储数据常常不由我们说了算，关注了也意义不大。而今年新开发的更高效的数据仓库式存储方案在比赛时还没有测试正常，暂时还无法采用。
2. Java
为了更好的集成性和可移植性，集算器现在使用Java开发。而Java本身运行性能就低于C++，而且对于这种复杂计算中又会大量产生对象，以及JVM为了安全性增加了许多检查，这些动作都会消耗很多运算时间。
3. 解释程序
这次比赛的运算较为复杂，没办法只用几个库函数拼，需要用集算器脚本写循环分支实现。而集算器脚本是解释执行的，解释执行能获得热切换等灵活性的好处，但运算效率远低于直接Java代码。
如果是开脱解释，这些原因都没有问题。事实上，在上述这些限定条件下，我们能做到这个性能已经很强了，甚至比主办方硬写的UDF还要快不少。而且我们还有很堂皇的优势：完全用集算器脚本写出来，只用了10行代码就搞定核心聚合算法，我们可能是比赛中唯一没写UDF的选手。代码的通用性也很强，可以随意改变过滤条件。相比之下，主办方的UDF有效内容就超过100行，而且算法较简单，其它人代码未全公布，要实现和我们类似算法的代码量还会再超出。我们其实完全可以说自己擅长的是简化代码，而不是性能。
然而，在一个比拼性能的场景下，说这些并没什么卵用。用户不会关心你有什么原因以及你在其它方面的优势，用户只关心在复杂度可容忍的前提下能不能更快。
所以，更重要的是反思非技术原因
第一个问题，在这个比赛条件下，我们还能做到更快吗？
当然能！
即使采用集算器现有的存储格式，也还有办法减少存储量，但预处理会麻烦许多；对于取数和计算环节也还有优化空间，可以少产生很多Java对象；解释程序的细节应当也有潜力可挖。
而且，我们也可以写个UDF来试，虽然我们要推广集算器，但也可以看看UDF和解释程序的差距，提交两个版本反而会更有说服力。毕竟集算器脚本很短，用不了多少时间去写，可以腾出时间写UDF。我们甚至也可以写个C++程序来比对，公司里并不缺C++高手。
那么，第二个问题来了，为什么没去做呢？
我觉得是有些松懈了，说严重些，是有点自满了。这主要是我本人的原因。
我们在历史上的POC验证中常常能大幅度胜出，超越数据库和Hadoop的案例颇多，除了少数几种特定的应用场景外，集算器在性能上碰到对手的情况并不多，即使有些慢的情况也不会有太大差距，而且还可能是售前人员没写对代码导致。这些都使我们醉心于集算器的高性能。
在测试阶段我们把性能做到主办方程序的2.5倍时，我自己就感觉已经可以了。我当然知道用C++或硬写UDF有可能更快，但并不觉得差距会很大，毕竟主办方也是硬写的UDF。所以就到此为止了，懒得再继续深入琢磨优化手段了。
现在想起来，我们以前之所以能大概率地赢，那是因为对标语法常常是同样也要解释执行的SQL，而不是程序员硬写的代码。即使是硬写的UDF，编写者们也是行业集成商的应用程序员（他们会且应当更关注业务而非技术），而不是数据库厂商或互联网公司的系统级程序员。
比赛输了，但也有积极的效果
对于研发部和我自己来讲，这都是一次强烈的刺激。它让我们知道，在性能优化的征途上，我们还有很长的路要走。
以往在优化时想到一些可能不见得一定有效的手段，有可能就懒得去试了，反正已经够快了，毕竟还有许多其它问题也要解决。现在，我欣喜地看到，当知道比赛成绩的差距后，算法研发的同学开始主动去寻找和尝试进一步的优化手段。我想，我们没有人会就此服输，我们还有很多潜力：
解决存储问题，实现高性能可选的列存和压缩机制，这也是集算器数据仓库功能的主要任务；
重构Java底层数据结构，绕过JVM的安全检查，大幅提升Java程序的运算性能；
服务器的C++版本将提上日程，我们以前只是说，并没有付诸行动，现在要开始了；
......
最后，借用乔布斯同学的话与大家共勉：Stay Hungry! Stay Foolish!
补记：周末录了一首吉他曲，正好与此刻心境相符
金戈铁马的战场上奋勇厮杀，寂寞空灵的旷野中凝神沉思。