背景

当前团队内有多个围绕着“特征”建立的系统，有特征系统、用户画像系统、分析门户等。在业务发展初期，这些产品都是紧贴业务的发展而建设的，系统功能模块和沉淀下来的特征也是基于运营活动、业务单元而垂直开发的，给后期带来了巨大的维护和开发成本。

整体架构

在上篇文章中主要是叙述了特征管理系统的顶层设计，从业务的角度对其进行了产品定位，根据它的定位将其划分为元数据管理、特征加工、特征服务三个功能模块，并简要的描述了实时特征计算的大致实现流程。本文再细化特征管理系统的实现。

背景

实时特征对运营活动是必不可少的，特征的质量也会对业务产生直接的影响。但是由于当前没有一个统一的实时特征接入和生产平台，导致特征的产出过程过于混乱，实时特征的质量也是不可控的。当前现象及主要问题有：

背景

近来在优化一个java项目的性能，在服务架构、gc、代码实现方式都做了基本的优化后，思考如何对其进行更进一步的优化。进一步的优化有两个方向：

1. 使工程本身（架构、gc、代码）再进一步。
2. 验证类似nginx一样的多进程网络服务是否可行。较容易实现，且很容易应用到其它线上服务上。

序言

数据工程师（ DE ）和数据产品经理（DPM）日常的一部分工作是和运营、PM对接，根据需求产出APP层数据和可视化报表。 DE分别通过Tableau和数易来产出报表，但这两个产品都有局限性：

• Tableau价格昂贵，使用人数有限制
• 数易的可视化图表类型过少，不能满足需求
• 且DE有个性化的需求，Tableau和数易均不能给出及时的响应