从技术演变的角度看互联网后台架构

加缓存是为了解决访问速度，减轻数据库压力，但是并不提高推荐精准度。如果我们要提高推荐效果呢?在2015年之前机器学习还没那么普及成熟的时候，我们怎么搞呢?

提高推荐效果，在机器学习之前有两种做法：

- 引入基于lucene的搜索引擎，在搜索的同时通过定制方案实现scoring，比如我可以利用lucene对用户的年龄、性别、地址等进行indexing，但是再返回结果时我再根据用户和查询者两人的具体信息进行关联，自定义返回的score(可以视为推荐相关系数)

- 采用离线批处理。固然可以用hadoop，但是就太杀鸡用牛刀了。常见的是定时批处理任务，按某种规则划分用户群体，对每个群体再做全量计算后把推荐结果写入缓存。这种可以做很繁复准确的计算，虽然慢，但效果往往不错。这种做法也常用在手机游戏的PvP对战列表里面。

这些处理方法对社交网络/手游这类型的其实已经足够了，但是新的业务是不断出现的。随着uber/滴滴/饿了么/美团这些需要实时处理数据的app崛起，作为一个司机，并不想你上线后过几分钟才有客人来吧，你希望你开到一个热点区域，一开机就马上接单。

所以这种对数据进行实时(近实时)处理的需求也带动了后端体系的大发展，kafka/spark等等流处理大行其道。这时候的后端体系就渐渐引入了消息驱动的模式，所谓消息驱动，就是对新的生产数据会有多个消费者，有的是满足实时计算的需求(比如司机信息需要立刻能够被快速检索到，又不能每次都做全量indexing，就需要用到spark)，有的只是为了数据分析，写入类似cassandra这些数据库里，还有的可能是为了生成定时报表，写入到mysql。

大数据的处理一直是业界热点领域。记得2015年硅谷一个朋友就是从一家小公司做php跳去另一家物联网公司做spark相关的工作，之前还很担心玩不转，搞了两年就俨然业界大佬被oracle挖去负责云平台～～～

anyway，这时候对后端体系的要求是一方面能快速满足实时需求，另一方面又能满足各种耗时长的数据分析、data lake存储等等，以及当时渐渐普及的机器学习模型(当时2015年初和几个朋友搞startup，其中一个是walmart lab的机器学习专家，上来就一堆模型，啥数据和用户都还没有就把模型摆上来了，后来搞得非常头痛。当时没有keras/pytorch/tf这些，那堆模型是真心搞不太懂，但是又不敢扔，要靠那东西去包装拿投资的。。。)

但是我们再看上面的图，是不是感觉比较乱呢?各种系统的数据写来写去，是不是有点messy?当公司团队增多，系统复杂度越来越高的时候，我们该怎么梳理?

到了2017之后，前面千奇百怪的后端体系基本上都趋同了。kafka的实时消息队列，spark的流处理(当然现在也可以换成flink，不过大部分应该还是spark)，然后后端的存储，基于hive的数据分析查询，然后根据业务的模型训练平台。各个公司反正都差不多这一套，在具体细节上根据业务有所差异，或者有些实力强大的公司会把中间一些环节替换成自己的实现，不过不管怎么千变万化，整体思路基本都一致了。

这里可以看到机器学习和AI模型的引入。个人认为，machine learning的很大一个好处，是简化业务逻辑，简化后台流程，不然一套业务一套实现，各种数据和业务规则很难用一个整体的技术平台来完成。相比前面一页的后台架构，这一页要清晰许多，而且是一个DAG有向无环图的形式，数据流向很明确。我们在下面再来说这个机器学习对业务数据流程的简化。

在传统后端系统中，业务逻辑其实和数据是客观分离的，逻辑规则和数据之间并不存在客观联系，而是人为主观加入，并没形成闭环，如上图左上所示。而基于机器学习的平台，这个闭环就形成了，从业务数据->AI模型->业务逻辑->影响用户行为->新的业务数据这个流程是自给自足的。这在很多推荐系统中表现得很明显，通过用户行为数据训练模型，模型对页面信息流进行调整，从而影响用户行为，然后用新的用户行为数据再次调整模型。而在机器学习之前，这些观察工作是交给运营人员去手工猜测调整。

（编辑：新余站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!