工程构建活动在互联网产品研发重要性

软件研发、互联网系统开发到了今天，编程语言和 工具 都变得先进了，但是很多系统由于不稳定、性能差、准确性或者经常出现bug导致软件出现问题，轻则影响用户体验，重则用户直接对软件失去信心。

拿推荐引擎为例，模型算法在整个系统有核心作用，这是通过算法与原有规则比并且与运营推荐比，有严谨数据作为支撑，点击率、浏览、gmv转化每个指标都比运营高很多，而模型算法又比策略形式高很多，一般策略比运营配置固定数据可能要高个100%之多。算法比策略要高个50%甚至100%以上。

但是整个推荐系统，其中比如一个召回数据写错了或者一个上报数据卡住了，甚至一个特征位值不对都会导致数据断崖式下跌，对于整个推荐系统说需要工程上有完备支持，工程分成三大块。

线上推荐引擎服务，推荐引擎逻辑要正确，推荐引擎要保证对每个用户都做到了完备考虑，比如对于超级活跃用户要考虑到他兴趣特别多，这时召回整个逻辑他的耗时会很大，最终可能导致对于整个用户请求超时，无法返回推荐引擎数据，只能下游通过通用补数返回，导致完全浪费一个及其优质用户推荐机会，导致用户体验差，并且影响数据效果。

线上推荐引擎对于频道新用户冷启动时，没有用合适数据，特别优质数据来吸引这就错过了一次将用户转为活跃用户频道用户机会，在有就是推荐引擎存在一些逻辑bug，比如在一定情况下取某个关键数据方式不对，后边会马上发现数据下跌。

再比如线上推荐引擎需要上报数据，上报数据不准确，或者上报数据有缺失，上报数据主要用于模型训练，这会导致训练出模型有问题，模型在用于线上会影响线上效果。模型上线一般会有各种个样指标比如AUC什么的，过了才会上线，但是弄过或了解过的都知道，AUC高不一定推荐效果好，AUC低上线后不一定推荐效果不好。

线上推荐引擎还有许许多多情况会影响推荐效果，让我们先研究暂停线上，我们来看一下近实时，近实时系统一般通过storm或flink系统实现，实现方式是通过接收消息队列用户行为比如用户最近点击、浏览、加购或者频道内行为来形成准实时推荐数据，准实时准确性实效性都明显影响线上效果。

准实时计算，经常会发生这种情况，我在其他频道点击了很多新的品类下商品，回到这个推荐频道下，并没有将我的实时偏好、兴趣推荐出来，这时就要一顿查找，是不是消息队列堵塞了，是不是storm消费处理变慢了导致数据挤压，数据挤压导致消费持续消费不到新的，导致线上推荐获取不到用户最近兴趣导致用户在app内其他行为，不能及时反馈给用户。

准实时还有特征相关，准实时生成特征不正确，或者实时特征不及时导致影响线上效果。让我们在放下准实时来看看离线计算，离线计算主要基于hive MapReduce或spark等，离线计算经常需要依赖上一个任务或者表，而前一个任务或表没有按时出来，导致这个任务延误，导致数据没有及时更新导致影响线上推荐效果。

离线任务在有就是逻辑有问题，导致计算数据过多或者过少，过多导致数据没法拉取出来，或者拉取出来在线上计算过于耗时，导致影响线上效果。

上边说了只是实际遇到问题的一小部分，实际问题更多，其实问题看着多，但我们总体去看其实都是一类问题就是工程问题，软件研发工程始终是构建活动核心，无论是苹果的iOS还是微信，因为再好创意以及产品也要落地为产品，那么他都是一个构建活动，没有一个系统例外。

要解决工程问题需要我们对软件首先意识到他就是一个工程过程，重视工程价值，通过监控、完善构建能力、提升团队技术能力来达到提升构建能力过程。重要的是要对这件事情有正确认知，有正确认知才能推动这件事情向正确方向发展。工程是软件、互联网产品关键一环，欢迎大家可以分享讨论下，在开发推荐系统或其他任何软件、app、互联网产品，构建过程中遇到的那些工程问题。