今天此文堪比出师表最后一句话

又中断了好几天

事情实在太多，最近里里外外都是事情，没时间写。今天早上有个读者加我，是悉尼的。至此人类常居住的大陆，仅剩下南美和非洲还没有读者了。

估计也很难有，毕竟那里华人少。所以我觉得今天该写点什么。那写点什么呢？先说一下出版社说新书在月底可能来不及了，要8月初了。

上周一次评审经历

我被邀请去一次评审。一上来又是看到一堆技术栈。说实话这些年各种技术栈都或多或少接触过，正因为接触过就觉得很多其实企业用不到。
小结大体分为如下：
1是为了用而用
2不知道为什么这样用，反正别人这样用了（所谓傻子过年看街坊）
3效果可以，但是不知道为什么？反正大家都说应该用它。
4什么流行用什么。必须让它能在我这里落地
5其他等等。

我其实听了业务场景以后我觉得根本用不到Redis、ElasticSearch还有Hadoop全家桶。大家说如果不用这些，那么也就没什么能用的了。就一个MySQL或者Oracle就可以吗？

我说看上去是的！

比如Redis存的计算结果，我看那个结果存RDBMS也可以。

再比如ES的场景，我觉得是当初是为了适配es而去做的设计，而如果在RDBMS中做会简单。

再比如一些使用Hive的场景，我指出了其中大量无效的步骤和无意义的计算。

我这样一顿输出，在场的我方的和对方 做技术的和不做技术的都沉默了。 以至于我讲的过程中时不时的问，我讲的你们听明白了吗？在得到点头的回复后我继续输出。

最后对方技术人员说。其实他们这样做是因为这样的研发成本小。如果精细化实现，的确这些都用不到了。但是这样的研发成本就高了。

对于以上的我是认同的。翻译一下就是，学习刚毕业的没经验的一般都是怎么简单怎么来（关键复杂的也不会）。但凡难度大，或者要巧妙的需要有经验甚至是高水平的人。

所以这就是差距。这让我想到以前一个知名大学在校学生做一个精准推荐系统。

这个系统最后在数据库中的SQL就是 select * from 商品表; 对，你没看错。每次操作都是所有商品。 那你这个还精准个什么？

不出意外的话，那么就出意外的大量无效的推送不说，还增加了系统负荷。访问量多的话，数据库还会因为推荐而宕机。

我们缺的是算力吗？

反正从大数据的经验来看我们不缺。我可以把我事先写好的SQL在任何一个生产库上执行，在1秒内得出要的数据分析结果，甚至我还能带预测。我还能带挖掘。（亲测经历过几个时间）。真的是遥遥领先。Hadoop的
调度分发还没完成，我就已经执行完毕了。

这一切都是设计与实现的差别。好好的利用好有限的资源可以达到很大的收益。impala和Hive等的暴力计算，还不如我设计的SQL在不擅长分析的MySQL的性能。

当然今天的GPU大模型和大数据的算力还是不一样的。只是从大数据的经验来说，很多时候属于无病呻吟的，没有困难制造困难，没有场景制造场景，所以才有了今天的“百模大战”。简直是资源的浪费。

外国的创新是科技和基础的创新。我们是商业模式的创新。一个能单机解决的，绝对来个分布式、中台。最后不能说是闪闪发光，也是一地鸡毛。

有时候出发点就不对了

比如很多时候说大数据的资源消耗高。很多人觉得这是理所应当。但是这从头就不对了。
为什么消耗高是对的？实现方式最优吗？
不是，因为他就是全量计算。
为什么全量计算？
因为没有索引。。。。。
为什么没有索引？
因为设计就是这样，依靠机器抗计算。
那为什么不用有索引的数据库？
因为如果用了，那就没有大数据了。。。。。

很多时候不是说因为这个场景他天生就应该用这些技术栈，而是要考虑他这个场景有没有必要？可能这个场景的存在或者说实现都是错的。那么还谈如何使用？