原创 奇思易想 奇思易想 2020-09-02 20:07

如何解决超规模的复杂问题？

停更了1个月，一方面有工作的原因，有个新产品的设计工作安排得非常紧张，另一方面，我认为主要是因为选题库枯竭，说白了，不知道写什么好。我一直希望自己输出一些更有深度的内容，那如何做到更有深度呢？关于写作这件事，有个公式我非常认可：

写作=输入（40%）+思考（30%）+输出（30%）

「写作」这件事情由三部分组成：

• 输入：阅读、他人的观点、自己的经历都是输入的一部分，这是写作这件事情的根基，没有素材，就陷入了「巧妇难为无米之炊」的困境。
• 思考：我们对书籍的思考，对经历的感悟，构成了作品的意义，这是写作的灵魂部分。
• 输出：把我们看到的书和观点，历经的事情通过文字技巧编排出来，很重要，但是没那么重要，这就是我为什么不太喜欢那些只强调技巧的写作课程的原因。

对于写作内核的构成，其实这里隐喻了一个超规模的复杂问题：

要想持续的写作，首先就要有足够丰富的输入。粥左罗在他的书中算过这样一笔账：一年读500万字，算是一个较为可观的输入量了。

那么，这个超规模的复杂问题来了：

如何在一年之内完成500万字的阅读？

Books, Pages, Story, Stories, Notes, Reminder, Remember

「一年完成500W字的阅读」，我的第一反应是，这太难了，哪有那么多时间，除非专职写字儿了。

但是其实拆解一下，问题并没有这么复杂：

一年365天，算下来，每天只要读1.37万字，是不是觉得没那么可怕了呢？

接着拆分，一篇文章3000字，你只需要读5篇，就达到了这个要求。想必我们每天上下班路上读的文章也不止5篇吧。

所以，单单从完成「500W阅读」这个量化指标来看，拆解到每一天，其实只需要完成5篇3000字文章的阅读，无论是时间上，还是心智压力上，都没有任何挑战。

所以，如何解决超规模的复杂问题？

就我目前的认知，我认为只有一种方法：拆解。

将大规模打散为多个小规模，将大问题拆解成多个小问题，逐一解决这些小问题，那个复杂的大问题就解决了。

在程序设计中，我们经常会用到一个思维模型：分治思想，其实本质上就是「拆解」。

例如，现在有一份跨度10年的订单数据要做汇总统计，这个数据规模很庞大，每年有超过1亿条记录，数据库中共有10亿+数据，这个怎么做？

超大规模数据运算

我们都知道，在关系型数据库中，对亿级别的数据体量进行操作，速度和效率都会比较低下，一方面数据的计算量很大，另一方面数据访问本身速度就会偏慢，那如何解决这种超规模的复杂计算问题呢？

对于这种问题，有经验的工程师，一般就会引入多线程的处理手法，通过多线程调度的方式同时进行数据统计运算。其实核心思路也是通过拆解任务来做的。

对于「10年订单数据的计算任务」这个超规模问题，首先可以拆解为10个「1年订单数据的子计算任务」，而这个年度计算子任务，又可以进一步拆解为12个月度计算子任务。

这样，这个问题就可以最终拆解为：

120个「月度订单数据计算子任务」，这些子任务可以同时进行，相互不干扰，各自处理自己那部分数据，最后执行完毕以后将每个任务的子结果进行汇总即可。

这样做的好处显而易见，一方面多个任务并发进行，可以极大的节省计算时间；另一方面每个任务只需要处理1个月的数据，平均下来1000W左右的数据量，这个跟10亿数据相比，已经极大的缩小了数据范围，提升了从数据库读取数据的速度和效率。

在计算机领域，「分治思想」的应用非常广泛，现在流行的分布式系统数据库、以HDFS为代表的分布式文件存储系统，无一不是为了应对超规模的存储需求。单机存储的容量总有一天会达到极限，不可能无限往上堆硬件，又贵又解决不了根本问题。所以将「集中式的大容量存储」这个问题拆解为分布式存储，引入多台小机器共同承担部分存储职责，每个机器只存储部分数据而非全量数据，这样应对起来还是绰绰有余的，这就是分治思想的有效应用。

拆解，在我们日常的生活和工作中也是蛮多，只是很多时候我们并没有意识到自己正在使用这种思维。

我们进行产品规划的时候，一般会进行迭代安排。迭代划分的过程，其实就是拆解的过程。

产品迭代，造车之路

第一个迭代要实现mvp，保证核心完整即可，有两个可以代替步行，给他的是一个滑板车。

第二个迭代，给用户能控制方向了，产品变成了手扶滑板车。

第三个迭代，让用户两只脚都能用上，给他一台自行车。

第四个迭代，用户不需要用脚来提供动力了，只需要控制方向即可，给他一台摩托车。

最后，给用户一个更舒适的通勤环境，给他一台小汽车。

产品设计的同学看到这个图应该都会会心一笑，但是如果让他一上来就给用户一台"小汽车"，估计他就要抓狂了。

真正厉害的操盘者，会将「小汽车」这个超规模复杂问题，拆解为多个阶段性问题：

1. 动力问题，先把轮子造出来
2. 方向控制问题，提供手持控制方向
3. 动力问题的升级，让双脚都参与到动力控制中来
4. 动力问题的再升级，主动提供动力输出，解放双脚
5. 舒适和安全问题，为用户提供舒适空间和安全

这个产品迭代中的拆解，不再是简单的问题平铺切块，而是阶段的递进，是一种更高级别的拆解。

至此，我们会发现，拆解 这件事情本身也是存在不同的手法的。问题不一样，拆解手法自然也不一样。

这里需要对「超规模的复杂问题」进行分类，不同的问题有不同的复杂度，从上面的例子中，其实我们大概可以做出如下分类：

1. 时间型拆解。通过时间来分解具体任务，逐步消化，例如「一年完成500W字的阅读量」，「背诵唐诗300首」等本身就有时间属性描述的大任务，都可以通过自然时间进行拆解。
2. 空间型拆解。本质上通过并行处理来进行任务拆解，计算机领域的通用叫法是「用空间来换时间」，压缩执行时间，提升执行效率。这个在现实世界中也经常看到，例如武汉的火神山医院，项目赶工期，短短15天要建成一间医院，那办法就是加人，加大量的人同时干活，这其实就是典型的空间型拆解。
3. 功能型拆解。先提供部分核心功能，满足部分需求，然后逐步叠加其他功能，甚至升级颠覆原来已有的功能，在这个过程中，虽然不是一步到位给你最完美的体验，但是可以应急，满足你的测试验证目标，根据清晰的实施路径规划，你也知道下一步能提供什么出来。

当然，「拆解」只是解决复杂问题的第一步，如何拆解，拆到是什么样的程度才是合适的，拆解之后如何调度汇总，这些也对解决问题至关重要。

我认为「拆解」带来的分治思想，其作用不仅仅在于解决问题本身，更在于帮助我们分析问题，将问题的关键部分梳理出来，逐步让复杂的问题清晰化，去掉非必要的复杂度和噪音，既简化了信息，也极大的增强人们解决问题的信心，这个过程就是将压力和焦虑分解的过程，是非常有效的一种解决问题的思路。

最后，留一个超复杂的问题：如何将大象装进冰箱呢？