今日头条抽奖推荐机制
当前新一代架构还在字节推荐场景中快速演进，目前已较好解决了实时窗口特征的生产问题。
出于实现统一推荐场景下特征生产的目的，我们后续会继续基于 Flink SQL 流批一体能力，在批式特征生产发力。此外也会基于 Hudi 数据湖技术，完成特征的实时入湖，高效支持模型训练场景离线特征回溯痛点。规则引擎方向，计划继续探索 CEP，推动在电商场景有更多落地实践。在实时窗口计算方向，将继续深入调研 Flink 原生窗口机制，以期解决目前方案面临的窗口特征数据退场问题。
郭文飞，字节跳动推荐系统基础服务方向负责人。2015 年初加入字节，主要负责推荐系统基础服务方向，例如消重、计数、特征等。
字节跳动推荐架构团队实时计算方向，负责抖音、今日头条、西瓜视频等超 10 亿用户产品推荐系统架构实时计算系统的设计和开发，保障系统稳定和高可用。抽象通用实时计算系统、构建统一的推荐特征中台，实现灵活可扩展的高性能存储系统和计算模型，为推荐业务实现先进的消重、计数、特征服务等实时推荐数据流系统。目前非常缺人，欢迎对技术有追求的同学加入，一起构建世界级先进的实时推荐数据流系统，联系方式：guowenfei@。
今日头条抽奖推荐机制
在字节内部的实时特征离线生成链路当中，我们主要依赖的数据流是 Kafka。这些 Kafka 都是通过 PB 定义的数据，字段繁多。公司级别的大 Topic 一般会有 100+的字段，但大部分的特征生产任务只使用了其中的部分字段。对于 Protobuf 格式的数据源，我们可以完全通过裁剪数据流，mask 一些非必要的字段来节省反序列化的开销。PB 类型的日志，可以直接裁剪 idl，保持必要字段的序号不变，在反序列化的时候会跳过 unknown field 的解析，这对于 CPU 来说是更节省的，但是网络带宽不会有收益，预计裁剪后能节省非常多的 CPU 资源。在上线了 PB IDL 裁剪之后，大部分任务的 CPU 收益在 30%左右。
今日头条抽奖推荐机制
特征计算层完成特征计算聚合逻辑，有状态特征计算输入的数据是状态存储层存储的带有切片的 FeaturePayload 对象。简单的 ETL 特征没有状态存储层，输入直接是 SQL 抽取层的数据 RawFeature 对象，具体的接口如下：
复制代码
有状态特征聚合接口
复制代码
无状态特征计算接口
另外通过触发机制来触发特征计算层的执行，目前支持的触发机制主要有：
策略
解释
OnTimerTrigger
周期性定时触发特征的计算逻辑
OnUpdateTrigger
上游状态层每次更新即触发特征计算
CustomTrigger
自定义特征计算的触发时机
今日头条抽奖推荐机制
1. 我的内容没有命中发文规范里的情况，就一定可以发表么？
不一定。发文规范是平台审核的基础，具体的内容是需要审核的，请以审核结果为准。
2. 为什么推荐流量“不稳定”？
头条的推荐系统是从上百万篇文章里面，把你的文章选取出来。如果那个时候其他的文章表现得特别好，你的文章就不会得到很好的推荐。也就是说，每一篇文章的推荐量，既取决于当时具体的环境，也取决于以及当时整个内容池里面其他文章的表现。
可能是这些原因导致的：
今日头条抽奖推荐机制
在字节业务爆发式增长的过程中，为了满足各式各样的业务特征的需求，推荐场景衍生出了众多特征服务。这些服务在特定的业务场景和历史条件下较好支持了业务快速发展，大体的历程如下：
推荐场景特征服务演进历程
在这其中 2020 年初是一个重要节点，我们开始在特征生产中引入 Flink SQL、Flink State 技术体系，逐步在计数特征系统、模型训练的样本拼接、窗口特征等场景进行落地，探索出新一代特征生产方案的思路。
