微盟实时链路构建用户数据平台

• 数据接入：数据接入层通过不同的方式将外部用户全渠道全场景的数据接入到系统中。接入方式有 Kafka 消息推送、MySQL CDC 主动同步、Hive 全量数据同步等。接入的用户数据有用户属性、用户行为、商城订单、商品、渠道、企业微信、导购等。
• 数据实时处理包括：
• 数据预处理：对数据进行适配、清洗、格式校验、字段填充等操作，将数据标准化归一化。然后将标准数据按优先级进行分流。
• 数据建模：按照分析模型对用户数据进行建模分析，提取用户特征。
• 数据存储：对于用户明细数据、聚合分析数据，按照不同场景进行存储，场景分为实时业务高并发点查场景、离线圈人场景、多维检索场景。
• 数据同步：数据同步支撑数据在不同存储、不同系统间的高效流转。
• ID引擎：ID引擎主要识别用户的唯一身份，将不同渠道不同身份标识的用户识别成唯一自然人。同时对于用户身份的合并事件提供数据合并支持。
• 数据应用：业务层核心服务包括标签服务、能力透出服务、数据推送服务、自动化营销服务，为上层应用提供 CDP 核心数据能力。

1.离线处理和实时处理

• 连续性: 数据连续不断的产生，源源不断的流入系统，没有明确的终止时间。
• 无界性：数据没有时间边界和数量边界，数据有可能延迟到达，有可能突然增长。
• 异构性：数据从不同数据源流入系统，不同数据源的数据格式、数据质量会有一定的差异。
• 时效性：数据处理对时间往往是比较敏感的，大部分场景要求在秒级内处理完成。
• 高容量：通常以非常高的速率生成，这使得它们难以被处理。

2.数据接入及清洗

2.1.数据接入

2.2.数据清洗

2.3.突发流量应对

• 数据迁移场景：大量迁移数据均为历史数据，数据迁移的数据量大但由于是历史数据对数据的时效性要求并不高。
• 商户做活动场景：当某个大商户做活动时，会有短时间特点事件的突发流量到来，特点是时间单一、短时间流量大。
• 刷数据场景：目前部分业务数据直接实时同步业务库，当上游有刷数据动作时，会集中收到大批量数据变更。

• 对于历史数据，根据预设的系统吞吐量，优先保证实时数据通行，仅在系统处理有余量的时候适量放行历史数据。
• 对于实时数据，按照优先级（动态可配）将数据划分到不同优先级通道中，下游在消费时可根据优先级通道调整速率。

• Flink 原生开窗只支持表级别同一维度同一窗口大小，每个字段不能有不同的窗口大小。
• Flink 默认的滑动窗口使用重叠窗口重叠状态的方式实现，导致状态膨胀。比如30天的窗口每天滑动一次，状态膨胀30倍，严重浪费资源。
• Flink 默认窗口及聚合逻辑是静态编译的，任务启动时编译生成拓扑，运行时不可更改。修改逻辑需要修改代码重新部署。
• 对于多种不同的聚合窗口，需要多个不同的 Flink 任务，浪费计算和内存资源。

• 支持字段级别细粒度可配的开窗聚合能力，每个字段可以有独立的窗口独立的聚合逻辑，动态可配。
• 滑动窗口状态只存储一份，避免状态膨胀资源浪费
• 基于可重用组件的思想，将通用逻辑下沉到组件库，对外暴露动态参数，实现组件重用、逻辑可配。
• 对于多种不同的聚合窗口，只需要一个 Flink 任务即可，避免原生资源浪费的问题。

4.用户数据合并

• 子用户ID数据是否全部到达？如果没到达不能进行合并
• 子用户ID数据是否全部入库？如果没有入库则获取不到全部子用户ID数据，存在合并时数据丢失的风险
• 数据是否有状态？比如用户首次消费金额统计，用户ID1和用户ID2合并时该如何取值？再如最近一周消费金额，当数据合并时窗口的边界何时被触发？
• 数据合并完后再出现子用户ID数据该如何处理？
• 在分布式环境中，如何保证数据的严格准确地被处理？

• 当收到用户ID合并消息时，向用户数据流 Kafka 中的每个分区发送一个用户ID合并栅栏并标记唯一ID和数量，代表已接收到该子用户ID的所有数据，后续数据流中不会有该子用户ID的数据出现。
• Flink 消费数据的同时收集用户ID合并栅栏，当某个栅栏收集完毕后，意味着该子用户ID数据已经被完全消费，并不一定会完全处理。（数据分区逻辑不同）此时向 Flink 每个分区（并行度）中发送一个入库栅栏并标记唯一ID和数量，代表该子用户ID的数据全部被消费完等待入库，随入库数据流下推。
• 数据在入库的同时同步收集入库栅栏，当某个栅栏收集完毕后，发起正式用户ID合并。
• 用户ID合并时，先从数据库中查出所有子用户ID的数据，然后从状态中查出子用户ID数据所对应的状态，同主用户ID的状态进行合并，合并后同时更新数据库和状态。
• 数据流中出现已合并的子用户ID数据时，为了保证数据的准确性，构造用户ID合并补偿消息，再次发起用户ID合并流程。

5.实时用户打标

• 用户特征为上游实时数据分析产生的分析结果，规则为商户自定义标签规则或系统人群规则。
• 实时标签服务不断接收实时用户特征，不断完善补全用户特征，使用用户特征集去碰撞标签规则，并且为结果创建人和标签关系。
• 实时标签服务不仅支持特征的补全，同时支持特征的撤回。当用户不再持有某个特征时，上游会发送撤回消息，标签服务收到撤回消息后撤回特征并进行规则再次碰撞。

‍