面对着数据失控、技术失控和需求失控的问题，我们到底是要想尽一切办法去控制，还是顺应、包容甚至是欣赏这些失控，这是在我们智能数据平台研发道路的起点上需要思考的问题。

目前我们正在规划我们新一代的智能数据平台。这几年以来，我们也一直在尝试做一个足够强大的数据平台来高效支持内外部的应用；我们也在不断调研全球最新的数据技术和产品。

最近一年来，我也对到底要什么样的数据平台、到底需要什么样的功能、我们要根据什么原则去设计，有一些不太成熟的、碎片化的思考。上周五跟老阎、松柏、老何和学波一起沟通规划时，讨论了很多问题，也使得我对这些问题的思考更加深入了一些。这里做一下简要总结。

在大数据行业干了这么些年，我相信大家都有一种在泥潭中挣扎的感觉。要搞清楚到底有哪些数据、数据的结构、数据的来源、数据的意义、数据的上下文、数据的质量、数据可能有哪些局限性等等，都是非常麻烦的事情。在大多数情况下我们会发现数据的元数据缺失，数据的说明文档不存在或者文档有用的内容很少。

为了某一个新任务要把数据搞清楚，我们可能需要咨询很多不同的人，每个人对数据的说法都不完全一致，当所有相关方都沟通了几次后，我们才大致把数据的概貌搞清楚。而这仅仅是完成了第一步，后面的数据处理、数据探索、特征工程、分析建模、生产应用还有无数的迷宫的需要探索。

自然，面对这些问题，我们会想能不能有一个平台把数据以及数据利用的各个环节都有效管起来，让我们可以很轻松的把数据的来龙去脉搞清楚，借助各种强大的功能非常方便的让我们把数据处理、数据探索、特征工程、分析建模乃至生产应用都轻松的解决。

总之，我们希望这个平台能把一切都管起来，把一切关于数据、项目和工程的信息都管起来。使用者只需要在这个平台上就能获得关于数据的一切信息，并能够获得各种运用数据的能力。这可以说是数据平台的终极理想。

但是最近半年来，我对这个终极理想产生了比较大的疑惑，感觉追求这一目标可能是“理性的自负”。

复杂与失控的现实

复杂的大数据：

首先，大数据本身就是极其复杂的，不仅在于规模、维度、类型，也在于其各种变化和各种不完美。而且大数据还在日复一日的变得更大、更复杂、更快，要把所有数据以及所有数据的所有方面全部都搞清楚，恐怕是非常困难的，很可能已经是人力不可及的事情。

可能必须得承认，我们对大数据的控制能力是有限的，大数据很大程度上对于人类来说就是失控的。很直接的一个例子就是“数据湖”，显然“数据湖”失去了传统数据库和数据仓库那种井井有条的规范美。“数据湖”基本上就是把所有可以收集到的数据堆放在一起，并没有非常规范的管理。并不是人们不想管理，而是事实上是做不到的，只能向现实妥协。当然，这种妥协很大程度上是可能是自发的而不是自觉的。

可能很多人也认为“数据湖”只是一种过渡，我们还在等待更强大的数据管理和数据治理的技术、工具、平台和方法论的出现。

但是，人的智力和精力终归是有限的，如果我们期望能为所有数据都建立非常良好的文档和谱系来进行管理，并且能够得到及时的维护更新，需要投入的人力可能是无法承受的。而且如何保证这些管理的质量?只做形式审查是比较容易的，但是无法正真保证管理文档的内容质量，但是实质审查实际上又是不可能做到的。因此，很可能我们根本没有办法对大数据建立起传统意义中的管理体系。

复杂的技术：

其次，技术上的问题也是非常复杂的。技术问题的复杂性主要来自于各种技术本身的不完备性，任何技术都只能解决某一类型的问题。但是一个通用的数据平台，至少需要考虑能解决大部分的常见需求，这就意味着必须要将不同的技术整合到一起。多种技术的整合是非常考验系统工程能力的，这是要过的第一关。

但更大困难在于技术的快速发展，新技术、新开源项目不断涌现，既有技术和项目有些持续发展、不断更新，有的逐步衰退。这种情况下，如何能够保证平台本身在技术上能跟上时代是个非常困难的问题。一个系统的结构一旦确定，就会形成路径依赖，随着时间的推移，会变得越来越难以变动，越来越难以将新技术整合进来。

另外，即使技术本身不变化、功能不变化，但是处理的数据规模不同、质量不同、具体的资源规模和配置都会有很大的不同。处理大数据难点在于如何用有限的资源和能力来处理规模巨大的问题。同样的处理逻辑，但是数据规模的不同，有效的处理方法可能就有很不同。而这是预设功能难以全面考虑清楚的。

综上，大数据平台面对的技术问题也是开放性的，或者说也是失控的，我们执着于技术和功能层面的大一统也很可能是“理性的自负”。

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

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

拥抱不完美：

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

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

经验与价值的沉淀：

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

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

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

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

从标准化到社区化：

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

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

弹性与开放：

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

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

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

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

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

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

适应而不是约束：

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

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

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

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

总结

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

来源：http://www.36dsj.com/archives/103500

本文来源于人人都是产品经理合作媒体@36大数据

题图来自unsplash，基于CC0协议