但是POC这个词恐怕所有IT行业的人，从厂商到用户；从销售到售前都应该知道，全称是“Proof Of Concept”,直译是“概念证明”，其实就是“验证测试”，比如我要卖给你Sybase IQ，我说这是列式数据库，可能通过解释原理就可以解释清楚了；但是我说Sybase IQ比你现在的数据库要快10倍，恐怕大多数用户都会说“听起来不错，但是是骡子是马拉出来遛遛，咱们做个POC吧”。

一般来说，POC是为了解决一些理解上的障碍，和买车、买电器一样，你说你这款车用了一个新一代的引擎，不仅噪音小、加速快，同时还省油了。听起来很好，我也被说服了，但是口说无凭，开出来跑10公里看看，到了你说的标准，我就买。买软件也一样，你说Sybase IQ有压缩，查询速度快，数据加载能够做到每秒1G以上，我给你一些我现在的场景，建几个空表，几个TB裸数据，做个加载，看看花多少时间，索引维护是在加载前还是在加载后，索引维护的开销是多大，能不能做并行加载，监视一下磁盘，看看IO的状况是否如你所说，CPU的使用率如何等等。

查询效率怎么测？我现在有200个报表，其中90%的运行时间从15秒到45分钟不等，但是也有十几个报表非常头疼，每次跑都要几个小时，有个别要跑超过一天……（听起来有点儿耳熟？，请找SAP工程师咨询关于列式数据库IQ，HANA如何能够帮你），我挑几个最头疼的、最有代表性的、最经常用的，你跑跑看，如果真的能从20个小时提高10倍，一般来说对企业的意义是巨大的，通常带来的会是业务流程和管理流程上的改变，例如，很多企业到季度末的季结、或者月末的月结期间都会有特殊的流程，限制一些所谓的“非关键业务”给财务报表让路；或者很多重要的库存分析或者风险评估的算法因为计算量大，运算时间长，也会被强行削减运算频率，导致企业无法对随时发生的业务变化进行合理而实时的反应，而在竞争中吃亏。

但是有一点，特别值得广大企业，特别是CIO们选择软件时注意，很多软件带来的是改革、革命（Revolution)，而不仅仅是改进、进步(Evolution），引进这样的软件通常也会在一些使用原理、组织结构、实现机理上有变化，而不能简单、生硬地以原来的场景、流程、方法来强硬地衡量软件的好坏。

举一个不一定贴切的例子（以前演讲的时候用过）：一个山村，盛产山核桃，原来都是村民用上山用背篓或者手推车把山核桃运下来，从山上下来的路只有一条又窄又粗糙的沙石路，由于城里人对野生山核桃的需求越来越大，为了能将山核桃多快好省地开发出来，村里决定公开招标，特别设定了一些看似非常贴切，非常合理考核标准，如：背篓的大小，容积，容器的重量，手推车的大小，轮子的直径，平地上能够每小时跑几公里，山路上能够每小时跑几公里等等。然而，一个企业推荐了一套效率非常高的滑索系统，可以让村民们集中精力打核桃，在山上装筐后几十秒就可以运下山，空筐又可以几十秒运上去，但是就是因为没有轮子（或者只有滑索用的小轮子），虽然筐可以很大，但是平地背着跑的速度不比以前快，就被这个村子否决了！

当然，继续上纲上线一点，这和我们国家的教育体制不无关系，很多企业很习惯指定硬指标，硬考题，硬分数，人也是这样教育上来的，在体制内很适应，但是对革命性技术很少有感觉，或者不知所措，下对上听命的思想根深蒂固，对新鲜事物接受起来必然阻力重重。

举一个例子，最近的一次POC里面，客户提出了大量的查询场景，其中一个查询是这样的（有修改，去除了敏感性）：

SELECT substr(convert(char,S_DATE), 1, 5),

       avg(convert(bigint,DURATION1)),

       avg(convert(bigint,DURATION2)),

       avg(convert(bigint,DURATION3)),

       sum(convert(bigint,DURATION1)),

       sum(convert(bigint,DURATION2)),

       sum(convert(bigint,DURATION3)),

       max(convert(int,PRICE1)),

       min(PRICE2),

       avg(convert(int,PRICE1)),

       avg(convert(int,PRICE2)),

       avg(convert(int,PRICE3)),

       avg(convert(bigint,SIZE)),

       sum(PRICE2),

       sum(convert(bigint,SIZE)),

       count(distinct(convert(bigint,NUMBER)))

  FROM Table_M

GROUP BY substr(convert(char,S_DATE), 1, 5);

 

显然这样的SQL语句如果经常性出现在应用中，反映了数据库设计中的一些根本性问题。然而在实操中，对我们提出的更优策略不以接受。我真心希望这个用户只是为了测试一个Convert函数而设计的考题，而不是我说的固步自封。

——————————————————————————————————————————

感谢您关注“明说大数据”微信公共帐号，我在这里不定期和您交流大数据的概念，大数据的技术，和大数据的应用。如果您喜欢我的内容，欢迎持续关注，转发请注明以下出处。

http://mmsns.qpic.cn/mmsns/J1ls5REKIzO2ZbEB09KeDdP1k6URV2aVicetHLCDSoIzy6tic1ziccicjA/0