POC

三字经家家有，大S特别多，曾经见过一位老兄的演讲，整张PPT只用来解释ERP，CRM，BPM，ERM，GRC，HCM……后面的几页PPT也是用来解释这些三字经之间的关系，讲得老师神情亢奋（众多价值啊），听众一头雾水。很多刚刚进入公司的人恐怕都有一段不短的时间是用来熟悉这些三字经、四字箴言的吧。最让你崩溃的三字经是什么？

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

一般来说，POC是为了解决一些理解上的障碍，和买车、买电器一样，你说你这款车用了一个新一代的引擎，不仅噪音小、加速快，同时还省油了。听起来很好，我也被说服了，但是口说无凭，开出来跑10公里看看，到了你说的标准，我就买。买软件也一样，你说SybaseIQ有压缩，查询速度快，数据加载能够做到每秒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)))

  FROMTable_M

GROUP BYsubstr(convert(char,S_DATE), 1, 5);

 

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