在线特征系统最核心的目标是将离线的特征数据通过在线服务的方式，提供给策略系统使用。在线特征系统的出现是为了实现如下的系统目标：
从整体系统功能上来划分，在线特征系统需要做两件事情：第一，每日将离线更新的特征数据写入到存储引擎，这里我们选用分布式KV（Key-Value）存储引擎Tair作为线上存储引擎，利用公司的ETL工具定期将离线数据写入到Tair；第二，提供接口服务，我们搭建了一个基于Thrift接口协议的RPC服务来对外提供特征读取服务。
由于不同特征集查询方式都相同，只是数据不同，因此在Service层我们把一组特征集合以及它的查询维度抽象成Domain。举个例子，Domain=ABC表示用户基础画像特征，包含性别、年龄、星座等特征，同时它又定义了查询维度为用户ID。这样对于不同的特征集，只需要调用同一个接口，传入不同的Domain即可。
在这一阶段，系统的重点是搭建一套特征导入、存储、读取的流程。我们利用公司提供的工具和组件迅速完成了任务。当有新的特征表需要接入时，开发一个导入ETL，在服务端做相应的配置即可生效。同时，结构上的松散也带来很大的灵活性。在业务发展初期，团队组织结构单一，需求量少，变化快，种类多，系统保持简单、松耦合，有助于灵活应对不断变化的需求。
随着每日接入Domain数量的增加，接入新Domain工作显得繁琐而效率低下：每接入一个新的特征表，需要开发ETL，而且ETL需要测试、上线、配置调度。因此，我们重新设计了数据导入的方案。
ETL工具需要开发数据导入脚本，它的灵活性相对较高，写出错的可能性也很大，测试和审核流程难以避免，新入职同学更是需要较大的学习成本。而对于特征导入这个需求，它的模式固化，可以抽取出以下元数据：
根据这些元数据，将导入流程都固化下来，可以进行平台化的统一调度。用户通过填写或选择少量的表单信息注册任务，出错的可能性大大降低，流程也可以从原来的写ETL代码、测试作业、配置调度、上线审核，简化成了填写表单和审核。接入流程从原来的几个小时，缩短到几分钟。同时，存储引擎从原来的仅支持Tair，到现在Squirrel（美团点评基于Redis的KV分布式存储中间件）等多引擎加入，系统调度架构如下。
阶段二的完成大大简化了离线特征的上线流程，使接入工作从几个小时缩短到几分钟，也降低了出错的可能性。导入平台化的实现，也为通用性优化功能提供了土壤：数据压缩功能使得内存、带宽资源得到了更充分的利用；多引擎存储功能满足了需求方对性能的不同要求；导入调度功能解决了更新流量峰值的问题，提高了系统的整体可用性。
迄今为止，原始特征数据都是离线的，且更新周期都是一天，这跟离线数据仓库的T+1模式有关。而很多关键的业务指标希望做到实时化，特征工程也是如此。用户近几分钟、近几秒的行为信息往往比很多离线特征更具有价值，实时特征必然会在策略系统中发挥越来越重要的作用。
参考离线特征的计算过程，离线大部分是利用了数据平台的ETL工具，它的输入输出都相对固定，只能落地到Hive，用户大部分的精力只需要关心计算逻辑。因此从离线Hive导入到线上存储引擎，成为了特征系统的主要工作，无需操心特征计算。而目前公司没有很完备的、类似HiveSQL的计算框架支持实时特征计算，生产计算实时特征需要自己写流式处理作业。因此我们有必要提供一个专用、便捷的特征计算工具来支持常见特征的计算工作，利用简单配置完成实时特征计算。
实时部分的系统架构如上图所示，与离线类似，Console部分接受用户的表单配置并将元数据写入Settings持久化。Scheduler会负责读取Settings的元数据信息调度实时特征生产任务。我们采用Storm流式服务计算实时特征，从实时数据仓库的KafkaTopic接收流式数据，并按照预先配置好的特征计算逻辑生产、计算实时特征，然后写入到线上存储引擎。
下面详细讨论一下我们对于实时特征计算的平台化以及优化方案。
算法使用的特征有繁有简，复杂多变，设计一个自动化的实时特征计算系统难度很大。回到业务需求，我们的目的是通过特征生产系统来简化开发工作量，而非完全取代特征开发；因此我们选择一部分常见的实时特征类型，实现自动化生产和导入。对于更复杂的实时特征，提供了更新接口来支持第三方特征生产程序对接。
销售额这个指标其实是对订单金额做求和（SUM）操作，总结常见的计算类型有如下几种：
上述24个特征是常见的一些实时统计类特征，开发者只需要填写表单，选择需要的特征类型即可完成特征开发工作。对于现阶段不支持配置实现的个性化、计算逻辑复杂的特征，开发者可以自己开发Storm拓扑实现计算逻辑（对应实时特征生产调度图中灰色的ThirdParty模块），并通过更新接口写入到线上存储引擎。
从上述支持的特征列表中可以看出，实时计算框架目前只支持聚合、明细列表这样的简单特征。即便如此，实时特征计算还是面临很大的挑战。离线特征只需要计算出更新周期内特征的最终值即可，而实时特征需要把每次特征变化都要实时计算出来，它既要计算的快，又要计算的多，因此它无法支持很大量的数据。
在生产调度演进过程中，会不断遇到各种系统问题，如可靠性、一致性、性能等等。在这一章节我们把特征生产调度中一些常见的技术手段，以及常见问题的解决方案汇总起来呈现给大家。
抽象存储层Storage有很多好处：
对于每日的离线特征更新，我们发现有些虽然总数据量庞大，但每天的变化比较少。比如用户画像，有很多沉睡的用户他的特征基本不发生变化。如果每天将全量数据刷到线上，其实做了很多无谓的更新操作，对系统资源是一个巨大的浪费。尤其是更新线上存储引擎，写入压力将导致在线服务稳定性的波动。因此考虑在更新前计算出特征的增量变化数据，只更新变化的部分。而计算增量数据需要有线上特征集合的完整离线数据备份——数据镜像。
数据镜像（SNAPSHOT）是对线上存储引擎数据的离线备份。由于KV存储的特点适用于随机访问，而对顺序访问（如遍历）的支持并不是其强项，因此通过构造离线数据镜像，可以一定程度上帮助我们更为方便的操作线上KV存储引擎中的数据。这里主要是为了支持增量更新和数据恢复功能。
如下图所示同一个更新周期（Period）内需要做两次数据处理流程：归档（Archive）和同步（Sync）。Archive会将上一个更新周期的SNAPSHOT和这个更新周期的特征数据表做差集和并集。差集的结果是增量数据（Diff），并集的结果是该更新周期内的SNAPSHOT。对于数据量大而Diff又少的特征集合来说，增量更新会极大的节约线上的资源。
随着离线特征表增多，同一时刻进行数据导入的作业相互抢占资源，未加控制的写入速度影响了KV存储引擎的正常读取，甚至引起雪崩。实时特征也面临类似问题，实时数据流容易随着集群的状况、业务的特点出现流量峰谷，如果没有消费速度的限制，很容易导致存储引擎压力突增突减，甚至将其打垮。
离线与实时通过不同手段控制并发写入线上存储速度。离线更新的特点是：
我们的目标是尽快将这些数据同步到线上存储引擎，同时兼顾写入速度（影响更新延迟）和集群资源（线上存储压力）。鉴于离线更新的特点，且Sync作业本来就由调度器管理，因此很容易将并发控制实现在调度器内部。调度器会控制每个存储引擎的最大Sync作业并发数量，同时每个Sync作业内部并发的写入速度也是固定的。负载限制的关系如下：
同步中的作业数*作业内部并发度≤线上存储引擎的最大写入压力
而实时特征更新的特点是：
由于写入方可能来自特征系统外部，难以统一控制写入方速度，因此我们没有像离线一样让写入方直接操作线上存储，而是在两者之间增加了一个Updater服务（参考图5.实时特征生产调度），由它控制每个写入方的速度。实时特征流量波动大，且对更新延迟要求高，新接入的实时特征需要预估流量峰值并配置到Updater服务中。对于超过预设流量的请求予以拒绝或延迟。
离线特征与实时特征面临的原子更新问题各有不同。离线更新的粒度为天级别，所有特征一天只更新一次，有的特征集合希望保证天级别的更新是原子的。即不希望任意时刻出现一部分特征是昨天的值，一部分特征是今天的值。这个问题利用上文提到的逻辑存储层可以很好的解决，这里不再赘述。
然而实时特征生产更新却面临另一种问题。很多时候需要先读取特征当前值，然后基于当前值做计算得到新值写入KV存储引擎，一次更新过程涉及到读取，计算、写入三步。因此如果要保证数据更新的一致性，必须要保证一次更新的读、算、写操作的原子性或者事务性。对于原子更新的需求主要有两类解决方案：
如果说实时数据是离线数据的延伸，那么离线数据可以说是实时数据的备份，二者是相辅相成的。理论上，利用实时数据可以计算出所有想要的特征，但离线数据可以从不同方面解决实时特征计算中诸多棘手问题：
上图为离线实时特征生产的整体架构。离线与实时的数据融合，需要一个更强大的调度器，它负责协调离线任务与实时任务的关系，高效、可靠的完成数据导入工作。离线作业与实时作业的调度关系分为两种：
数据恢复功能是离线与实时架构融合的产物，只不过它的离线数据不是业务上产出的某张离线表，而是离线镜像数据SNAPSHOT。
能力所限，难免管中窥豹，挂一漏万。欢迎感兴趣同学一起交流。
伟彬，美团平台及酒旅事业群数据挖掘系统工程师，2015年毕业于大连理工大学，同年加入美团点评，专注于大数据处理技术与高并发服务。