目录：
1、何为事件驱动，与实时分析的区别是什么
2、支持什么样的需求场景、背景是什么
3、平台架构
4、功能介绍
5、未来规划
1、何为事件驱动，与实时分析的区别是什么
以前实时大多处理的是数据分析类型的场景，随着业务的不断增长，特别是行为日志采集后进行实时的预测、推广的场景广泛应用，事件驱动型的类型场景越来越多。
行为日志的数据特别大，叠加实时的场景应用，对于性能、稳定性、实时的要求特别高。
事件驱动的技术恰好可以解决这类场景人诉求，通过事件流与外部系统的交互的技术支撑非事件驱动莫属。
简单总结下事件驱动和数据分析的区别：
事件驱动：根据事件流中的事件触发计算、更新状态或进行外部系统的交互操作；关键词为事件、状态、外部系统；业务本质是每条数据（事件）触发业务变化。
数据分析：从原始数据中提取有价值的信息和指标；关键词为原始数据和提取过滤分析；业务本质是对数据集进行操作、重要分析。
2、支持什么样的需求场景、背景是什么
背景，其实就是现在的问题和痛点，有以下几个方面
1）事件管理：用户行为事件缺乏统一抽象和管理；开发效率低、周期长、存在重复建设问题；
2）规则引擎：规则处理逻辑与业务系统耦合，难以灵活应对规则变化；
3）动作触发：缺乏触发下游动作的统一灵活的管理和配置；
基于3个痛点，构建基于事件流的处理平台，即基于事件流（用户行为日志流），通过事件管理、规则引擎、动作触发完成对以下场景的支撑，同时将行为日志与业务数据库和用户特征库中的业务数据进行计算处理，提供更加完善的消息事件信息。
支撑的场景如下：
1）风控：通过规则设置、报警设置、实时大盘，对于业务管理过程中的风险进行预警并分析，提供实时、准确的数据支撑；
2）实时推荐：通过行为模式定义、用户特征关联计算、实时A/B测试，给不同级别的客户推荐需要的产品和信息，提升业务过程的转化率，降低获客和转化成本；
3）自动化运营：通过业务行业对接、活动编辑、效果分析，为运营插上自动化的翅膀，提升运营的效率和效果；
4）监控报警：对于业务的支撑，通过普通规则、CEP、同环比，提供实时的数据，并基于基准线，提供实时的监控报警信息；
3、事件处理平台架构
首先是需要有一个管理模块，相当于完成整个事件处理的元数据管理，包括事件管理、事件流管理、任务配置、任务管理4个部分。具体的功能在下节功能介绍中详细描述。
其次是行为日志的采集，基于事件管理的格式定义，通过行为日志采集组件，将各类行为日志采集到Kafka的消息MQ中，为事件处理引擎提供事件流的数据。
又次是规则引擎，通过规则引擎过滤、加工、输出更加完整有用的事件流信息。包括以下几个部分：
1）Filter：即过滤器，针对原始上报的事件信息，需要进行基本规则的校验，将不符合规则的业务数据进行简单过滤处理，避免无效数据流入规则引擎，造成大量负载，占用资源影响性能；
2）Cep：规则处理器，原始事件可能不符合实际的业务处理，需要补充一些属性字段，需要通过计算进行事件流的加工处理，以确保事件消息的可用，能用；比如一个客户点击后，在一天内有没有到访事件的规则处理。
3）Sink：输出管理，对于处理好的事件流信息，输出给下游，便于具体业务场景的应用，比如报警或风控等。
再次是动作触发引擎，这个是一个关键的点，前面的采集、加工都是事件消息的准备，真正发挥作用是动作触发引擎的核心职责，他是一个出口，一个有价值的出口，也是另一个业务的入口。作为信息的中转站和发起者，是整个事件驱动平台的核心。在这里，一个事件流可能通过多轮的处理才会流出到真正的使用方。
最后是场景服务应用层，即最终的使用方。对于内部的系统，直接通过服务端赋能，对于外部的第三方系统，需要进行适配，处理好安全、性能、稳定性相关的问题后，再统一标准方式与第三方系统进行集成，完成整个业务场景闭环。
4、功能介绍
首先是定义事件及事件数据源：包括数据库的类别，比如Kafka，数据源连接信息，主题信息即Topic，具体的事件属性信息，确保采集的数据可以上报，按照标准上报，并定义接入的字段标准规范，比如必填，长度等
其次是创建事件流：创建事件流就是将原始事件通过一系列的加工，然后形成最终事件消息的过程，包括定义事件处理的流程；针对流程中每个节点的内容进行定义，比如过滤、加解密、Union合并操作；需要提供一些基本的算子，常用的算子供其使用，让使用过程方便、灵活、快捷。类似一个低代码平台。在没有低代码平台的时候，也可以针对每个事件进行简单定义的处理，并与代码进行结合形成事件流。
然后是创建事件组：在事件流的基础上可以定义单个的事件，之后可以创建事件组，以对接我们的业务含义，即明确具体的业务是做什么的，如用户的点击、浏览、分享、关注等事件。创建事件组有两种方式：
一是本地方式，即可以根据事件的各个字段和维度设定条件；
二是远程方式，这与我们的埋点系统（用户行为日志）直接连通，可以直接得到用户事件的定义。
然后是任务配置：针对事件流中的节点，进行任务的配置。在此过程中，主要是要抽象各种算子，灵活组合和配置，同时采取基于json定义任务配置的标准DSL。
最后是事件输出：事件信息加工处理完成后，需要配置输出方式，一般包括3类，写入下游Kafka、调用Http接口（包括与第三方集成、存储、内部系统间的调用）、发预警或消息通知等。在实时的处理过程中，技术上需要注意高并发的场景和Exactly-once的处理机制，并考虑缓存、异步、二级线程池以提供并发度和性能；
5、未来规划
首先在架构上，数据的采集、任务管理、SQL引擎、Cep引擎都需要不断地优化改进，特别是在高可用方面，需要提升。同时，目前只是在事件处理过程领域，对于行业日志的分析进而到整个的客户数据平台方面考虑较少，接下来应该是落盘，价值分析，做更多的数据价值赋能。
整体来看，以实时事件处理平台基本具备了事件处理的所有部分，功能是比较完善的，对于规则引擎及关联计算介绍得比较简单，特别是对于复杂场景的支撑，对于关联数据的获取顺序及来源说明，对于事件处理的性能指标是比较模糊的。这也是架构上最核心的最需要关注涉及到系统是否能高可用的核心指标。
