上周跟组里同学说，想写一篇《数据的路该往哪走？》的文章，论述一下我们的思考和看法，面向不懂大数据的高层和业务方，也把我们一到两年的发展方向确定下来。只是现在写作障碍越来越严重，怎么也连贯不起来，对着一闪一闪的光标长久的挣扎和发呆，先流水账记录一些偏技术的内容吧。
这一年多数据处理方面的进展，应该说每一步进展都在预料之内，都是在理论层面论证清楚后进行的。执行更像是验证。有趣的是，单纯看落地出来的结果，并不显得多么复杂和高明，方案简单粗暴到极点。对外分享，每每让我有种在下象棋，思考了几十分钟，最后走了一步“拱卒”的感觉。不过同是简单，是否是“有理有据，有意为之”，差别是根本性的——艺术是不是也是这样？
回顾整个思考过程，核心是三篇：
- Google: 《Shasta: Interactive Reporting At Scale》
- Palantir: 《Friction in Human-Computer Symbiosis: Kasparov on Chess》
- Google: 《Analyza: Exploring Data with Conversation》
当然要理解这三篇的内容，需要大量知识储备，许多references要提前熟悉。
第一阶段的目标是解决我们自身的问题。当时面临的问题是研发效率低，组里同学工作机械重复，难度不大却费时费力，实实在在是在“搬砖”。错误在于不该按做业务需求的思路做数据需求 ，应该从数据方案出发，挑战Shasta中说得很清楚：
- First, user query latencies must be low.
- Second, underlying transactional data stores have complex “read-unfriendly” schemas, placing significant transformation logic between stored data and the read-only views that Shasta exposes to its clients.
- Finally, Shasta targets applications with strong data freshness requirements.
解决的核心思路，就是变pre-processing优先为post-processing优先，利用硬件和引擎强大的在线计算能力（主要是在线join），把预处理工作消除。仅这一点，做惯了传统数仓建模的人至今也很难接受，相比之下，平台的接受度反而更高一些。
这一阶段还主要是从纯技术角度来说。当前除了类似头条这种纯信息化的业务，“互联网+”型业务对于数据应用面临的困境是，所有人都知道数据有价值，但不知道应该如何利用。加之现在DL和AI概念火得一塌糊涂，造成一个很滑稽的局面，人们拿着DL这个锤子，却找不到合适的钉子。各方能做的，就是“先收集数据”，然后依然做些初级的洞察分析。于是引出第二阶段的思考，也即文章的标题，数据技术方案的发展方向是什么？数据如何发挥价值？终态是什么？
前段时间一直在调研WolframAlpha和Palantir这两家传奇公司的方案，资料很少，只是判断大方向应该如此。经过一段时间的广泛阅读，从这个slides中了解到Palantir的核心策略竟是IA，后来经Quora指点在archive.is里挖出一篇Palantir官博里已经不存在的那篇重要文章，整理思路，发觉一直以来忽视了“人”的重要性，也忽视了“人”造成混乱的能力。
IA（Intelligence amplification）是一个很老的概念，可以直译为“智能增强”，与AI对应。这个场景下的AI指的是AI的终极形态，而非简单的算法应用。AI以机器为中心，IA以人为中心。现阶段除某些纯信息类的封闭场景（如围棋），绝大部分是无法做到完全AI自主工作的，IA的思路更为贴近现实：以领域专家为核心，系统作为其大脑的扩展，提供数据支持，快速响应他提出的各类问题，步步逼近答案，逻辑思考和决策仍在人脑中进行。
Palantir文章中的数学模型很好的解释了这个思路：a(h,c) = h*c。其中a表示系统发挥的效用，h表示人的能力，c表示系统能力。效用等于人乘机器的能力，这是理想情况，现实中是不可能的，比如分析师向Hive发出一个数据查询请求，可能要两个小时才能返回结果，效用大打折扣。所以需要修正一下公式，增加一个参数f，friction，表示人机交互成本：a(h,c,f) = h*c/(1+f)。
更进一步，可以认为人的能力是个常量，于是公式可以简化为：a(c,f) = H*c/(1+f) 。
我们目前的现状是，H不止一个（很多数据产品）且绝对值很低（能力不够），f值非常大（数据问题作为需求来处理，每个N天）。所以数据不太能发挥出来很大价值。这是根本原因。
根据公式可以很容易看到三个优化方向：
- 提升h：找个对数据敏锐的业务领域专家，带着明确目标利用系统
- 提升c：提升系统计算能力
- 降低f：降低人机交互成本
初看起来H是比较难搞定的，但实际上未必会构成瓶颈。如果f够低，普通的H也可以发挥很大价值，而且人是会成长的。这个问题有点“鸡生蛋蛋生鸡”的意味，重点还是系统要够强大，人机交互成本要足够低。然后在人机互动的过程中，双方都会有持续提升的动力，飞轮就转起来了。
按这个模型可以回答前面的问题：
- 技术发展方向？降低f
- 发挥价值的方法？以人为中心，通过低成本、高频率的人机交互
- 终态？f等于0
所以，第三个阶段核心是如何降低f。理想情况不难想象，就是Elon Musk的公司Neuralink想要干的事情，把电脑和人脑无缝连接起来。这个进程需要多少年我们无法预测。姑且先退一步，现阶段能做到通过自然语言交互，做到秒级响应就已经非常理想了。目前比较成熟的系统，能了解到的，只有WolframAlpha、Palantir、IBM Watson以及前些日子看到的Google Analyza，Siri和各种优秀的智能音箱产品也算，不过Siri是基于WolframAlpha的，另外百度阿拉丁（在我看来）算是一个生硬的失败版本。
从我们面临的实际问题出发，降低f其实是在解决“需求预处理”的问题。这是一个做得越多负担越大、效率越低、错得越多的事情。造成当前格局的表象原因是，多个团队按照自己的粗浅理解设想数据需求，不系统、不深入、不专业，一段时间下去，必然趋于同质化，边界模糊，互相扯皮，在一个非常初级的层次内耗。这其中，人的能力和组织架构合理性是主因。但若论本质，却与第一阶段技术方案的问题相同，我们不应该按”需求预处理“的方式做事。
怎么理解“需求预处理”，说得理论化一点，若以整个数据服务能力作为核心，当前的做事方式就是一种对Query（需求）的穷举（预处理）。不可能穷尽，事情也就不可能做完，做不到对未来查询需求的提前满足，也就不可能提效并降低friction。当需求垂直进行的时候，甚至在不同团队进行的时候，期望做到系统复用、保证指标一致性根本是天方夜谭。可惜这个道理，在团队外很难给人讲明白，给不懂技术的产品和业务团队讲清楚就更难了。
技术的发展方向是搭建一个框架，使得随着数据需求的不断迭代，系统能力持续增强，数据、指标、算法、可视化持续集成进去，产生累积效应，变加为乘。这个框架一个很好的例子就是Analyza，回到我们自身，配合第一阶段形成的在线计算能力，预期可以做到提高c的同时极大的降低f。还在紧张论证当中。
最后说点题外话，近期因为各种原因被动思考了一下“画饼”的问题。当然这个能力还是要有，即所谓的愿景，所谓的Vision。马云天天挂在嘴边“使命、愿景、价值观”，当然很重要，但我越来越觉得，根基应该还是技术突破，否则会陷入一群人反复拿一坨固定大小的事情不断重新切饼分饼的滑稽局面。我们应该做的，是将马车工业的饼升级为汽车工业的饼，螺旋攀升，而不是在马车工业里内耗——全部马车产业也比不上如今一个汽车轮胎产业体量大。