大数据平台设计哲学的重构

　　面对大数据，在数据和技术都失控的情况下，考虑如何强加对数据的控制和提高驾驭数据的能力都很可能是徒劳的。我们需要重新思考大数据平台的设计哲学，而不是在传统大型软件设计的哲学下做加强和修补。

 

　　拥抱不完美：

 

　　首先，我们必须承认我们的无知和无能，放弃去构建一个全知全能的平台的理想。我们需要思考大数据平台要管什么，更重要的是不管什么。

 

　　我们需要在该放手的地方就放手，我们需要接受甚至是拥抱某种程度的失控。我们很可能就没有办法把所有数据都非常好的管起来，只需要通过平台，新手就很容易把数据情况搞清楚。我们很可能也无法提供完全统一设计风格、交互逻辑的功能界面。我们必须容忍一定的混乱，从而拥抱无限的可能和变化。

 

　　经验与价值的沉淀：

 

　　还是先从数据来看，了解数据最便捷的途径就是找到最了解这个数据的人进行直接沟通。最了解数据的人可能是数据的生产者，也可能是数据的处理者，甚至是消费者。很多情况下完全搞清楚，可能需要与所有相关方都进行沟通后才比较清楚。平台的设计到底是要消除这种直接沟通，还是让这种沟通更有效率呢？

 

　　因为全面文档化是不现实的，那么我们能够考虑的是让目前的方式效率更高。数据平台能够承担的一个功能是更有效的把数据的需求方和了解数据的人连接起来。原来我想找一个了解某个数据的人，都可能需要问好几个人，而要了解清楚一个数据又可能需要找到好几个人，这就需要不断在线下反复的沟通。如果平台能够告诉我哪些人对这些数据最了解，这就可以提升相当多的效率。

 

　　当一个人一位对某个数据最了解，而被人问了很多次问到很烦的时候，他可以把自己对这个数据的总结的文档和FQA放到平台上。对这个数据关心的人也可以写评论谈自己对数据的理解和遇到的坑。当一个数据被使用的越多，那么平台上就可以沉淀出越多关于这个数据的信息，包括最熟悉的人和各种对数据的描述和解读，后来的使用者就越容易掌握这个数据。

 

　　我们可以想象，一个数据平台，经过一段时间的沉淀，有些数据的相关文档会变得十分丰富，而有些数据根本无人问津。当我们不追求全面的控制后，最有价值的信息可能就自动涌现了。当然，当我们要使用一些鲜有人问津的数据时，就需要经历一个比较痛苦的过程。但是只要平台能把这个过程积累到的经验沉淀下来，就是有价值的。

 

　　从标准化到社区化：

 

　　利用大数据是需要探索精神的，大数据平台不应该是一条机械的流水线，把使用者变成一个个没有联系的随时可以替换掉的零部件。因为我们不可能做成真正构建这样有效率的流水线。同时，我们几乎无法用一套客观的量化指标来衡量对数据的利用效率，我们必须寄希望于人的主动精神。

 

　　大数据平台的设计哲学应该以人为中心，尊重人的价值，激励人的探索和创新精神，让对数据有激情的人能够涌现出来，产生更大的声音，同时鼓励和便利人与人之间的沟通，从而提高总体的效率。总之，平台设计思想应该从标准化转为社区化。”

 

　　弹性与开放：

 

　　从技术上来看，我们需要尽可能的适应各种不同的功能和性能需求以及未来可能出现的技术演进。为了解决这个问题，我们需要的不是一个结构复杂包罗万象的技术架构，因为越复杂的系统就越脆弱，就越难以进化。我们也不能绑定核心计算引擎就是Spark或者某几种特定技术，否则这就不是一个能力全面的数据平台。

 

　　很多为自有业务设计的数据平台是可以考虑业务特性来进行特化的。但是我们作为企业服务的提供商，需要考虑的是足够的通用性和灵活性。我们在技术架构的设计哲学上，不应该执着于提供多少强大的功能，而是应该专注于能够提供多少可能性和可扩展性。我们永远无法知道明天客户会有什么新需求，也无法知道会有什么新技术出现。

 

　　因此在技术架构上，应该以容器技术为基础，实现弹性的资源管理，和对技术和功能的开放支持能力。在容器技术的支持下，可以做到不同计算资源的即开即用即回收，可以支持资源的动态智能调整。当一个任务需要Spark时就创建Spark集群，需要TensorFlow就创建TensorFlow集群，任务完成就可以把资源及时回收，任务过程中根据资源使用情况和任务完成要求，动态的增加或者减少资源。

 

　　这种架构下，我们不是将各种技术能力整合封装成各种固定功能提供给使用者将他们的工作傻瓜化，而是向使用者赋能为其开放各种技术能力以及资源能力去创造无限的可能性。这种架构下很难提供统一的界面设计风格、交互逻辑，很多工作也需要使用者开发完成。

 

　　因为我们无法做到对所有的技术进行统一风格的封装，而是把所有的技术直接暴露给了使用者，使用者必须自己使用这些技术来解决问题。当然这并不是说我们不需要做产品设计，只是产品设计的出发点不是创造一套独立完美的体系，而是应该着力于让使用者更容易的将不同的技术方便的组织起来，同时减少在不同技术之间切换的麻烦。

 

　　同时，技术架构也需要考虑不同模块之间如何组织的问题，这个问题遵循服务化的思路应该是已经形成共识，这里就不再过多展开。只是个人觉得在推行服务化之前，我们需要把服务接口的标准、服务总线的技术定下来。有好的服务基础架构，新增、替换、升级不同的模块就变得相对容易。从需求角度确定的功能和模块不可能是百分之百正确的，后续一定会面临着重构和调整的问题。只有做好面对一切变化的准备，才能更好的面对各种不确定性。

 

　　适应而不是约束：

 

　　最后，我想谈谈关于方法论的问题。产品设计方法论先行是对的，但是我们要深入思考什么才是有效的方法论。关于数据挖掘的方法论已经存在十几年了(CRISP-DM)，老实说我们在思考的数据科学的方法论并不会有本质性的改变。但我对这些方法论的感觉就是“如何把大象放进冰箱”，或者5步画马法。原则上都对，但是对实际工作的指导意义非常有限，因为魔鬼都在细节中。

 

　　其实面对大数据，不仅我们对数据和技术是失控的，实际上我们如何处理、应用数据的过程在很大程度上也是失控的。整个过程就像在走迷宫，工作步骤分形似的不断展开。任何大的指导原则对于具体工作的指导意义就变得极为有限。

 

　　正因为如此，产品设计应该考虑的是如何适应这种Ad-hoc的工作状态，而不是用一套流程把使用者束缚起来。我们可以提供一些机制便于使用者来梳理手头的工作，但是尽可能不要去强制使用者遵守某种约束性很强的标准或者规范。

 

　　为什么像NoteBook这样设计如此简单的工具能够流行起来，很重要的一点就是给使用者足够自由的工作界面来做任何想做的事情，而且即写即得，便于随时修改策略，同时文档可以根据需要随时插在代码之中。正是这种无结构的扁平性，使得用户可以按照最合适的路径去完成自己的工作，而不是在被设计好的过程中挣扎。

 

　　我们首先必须承认理性的力量是有限的，我们不是无所不能的。面对着数据失控、技术失控和需求失控的问题，我们到底是要想尽一切办法去控制，还是顺应、包容甚至是欣赏这些失控。这是在我们智能数据平台研发道路的起点上需要思考的问题。