从怎样解题到怎样解决问题

  波利亚的《怎样解题》是本很好的解题思路和方法的启蒙书。全书围绕着遇到类似数学题目时如何去解题来教导。并给出一系列的步骤和方法：

  1. 理解题目

   2. 找出已知数据和未知量之间的联系，如果找不到直接联系，考虑辅助题目，最终得到一个解题方案

   3. 执行方案

   4. 检查解答

   咋一看，这些步骤只对解数学题目有用。可稍微一想，其实物理，化学等等题目不都可以如此解决吗。更棒的是，这些步骤可以推广到解决一般问题。

   在工作中，我们碰到大量的问题，其实都可以以一定的方法去解决，而不是束手就擒。

   推广到计算机科学中，算法其实就是将现实生活中的问题映射相应的算法模型，通过映射，将解决现实问题变为解决计算机内部模型问题，从而解决现实问题。无怪乎许多公司在考算法。

   这里就有一个实际项目中的问题让我印象深刻。

   由于项目需要，我们需要对一批用户打标签。已有几十亿的用户行为数据（即记录了用户的各个行为动作，如登录，注册，购物，抽奖等等），目标活跃用户约4000万。在打标签过程中，由于还缺少其他一些明细数据，需要将整批数据放到汇集数据的部门A去与保留的明细数据共同计算得到结果。部门A来人评估，由于每天只能分配给我们几小时计算资源，几十亿行为数据，4000w用户打完标签大致测算下来需要耗时1.5个月。测算方法如下，根据一个类似项目的预估，按照4000w用户维度来跑每一个用户的行为数据，并将每个用户行为记录回该用户表中，每个指标耗时约7小时，而我们有着26个指标，总共需要花费182小时，由于每天最多能分配4个小时给我们的计算，因此需要45天才能算完所有存量数据，而且一旦存量数据开始计算，很难断开，因为一旦断开，则意味着出现部分算完部分没有算完的情况，也就是说，起码也是要7小时一次的跑完一个指标才能释放资源给其他项目，对于他们是不可接受的，于是乎，这个事情不可行。另外，每天的增量数据在指标计算中如果不全量跑计算不出来，比如统计用户登录的设备个数，如果每次记录一个数字表示设备个数，那增量计算时并不知道是否与之前的设备重复，就会出现错误，所以只有每天跑历史上所有全量数据才能计算出来结果。对于跑一次全量都要1.5个月的评估来说，更是毫无可能性。

   这就尴尬了。从领导交代的必须完成到不可行，似乎中间仅仅隔了一个会。

   面对这种现实问题，可能很多人就卡住了。

   我的第一反应是，把26个指标过一遍，看看有什么规律和特点。当我们过指标时，我发现他们可以简单分为几类，第一类，是只需要增量计算即可的指标；比如统计用户注册到现在的时间间隔，只需要计算每天注册的用户数的注册时间记下来（用户不会多次注册），在需要改指标时现用当前时间减注册时间算一遍即可得到该类指标；第二类，可以视为通过增量计算出一堆中间的明细表，然后再根据当天情况将明细计算到用户作为标签；比如统计用户登录的设备个数，可以建一张临时表，每天将当天的所有登录这个行为的设备id及用户id记到该明细表中。然后按照当天活跃用户的维度去增量计算当天的活跃用户的该指标，比如10号当天计算张三的登录设备数为2。

用户id	用户登录设备id	时间戳
张三	ipad1	2017-8-1 00:00:00
张三	ipad2	2017-8-10 00:00:00

   

   按照这种方式，将一个现存的大数据量的存量数据重复计算转变为了一个可以以天为单位的增量计算模式。这个转变有什么意义呢？实际上将原来每天跑全量数据这个不可能完成的任务变为了可以每天跑增量数据这个可能。其次，只计算当天活跃用户的相应标签，则从明细表到结果表的计算也大大减少，实现了整个计算的增量化计算的可行性。最后，对于存量数据，可以按照每天跑n天增量数据的方式，在某个时间节点全部跑完。

   在以上增量化方案的同时，减少行为数据的范围到7亿数据，并且把用户数从全量4000w降低到最近最活跃的用户2000w，于是整个方案已经可行，将方案与部门A同事评估，也认为可行。

   从不可行到可行，似乎又只隔了一个方案。回顾一下整个方案的思想，其实无外乎"分治"，将大问题分解为小问题，将存量分解为增量；"降维"，将数据量降低，将无效计算降低。

   不知道对你是否有启发？