---

第3章 总体设计

3.1 系统设计目标和原则

• 本文是在基于营销数据的基础上，根据用户访问、购物数据，可以为营销企业提供更准确、及时、全面的数据支持，帮助企业更好地把握市场动态和用户需求，从而提升企业竞争力和市场份额。
• 因此，针对营销数据的数据特征，实现企业相关业务的实时营销服务，本系统的设计目标和原则主要包括一下方面：
  • 高效性和实时性：营销实时数据处理系统需要实时收集营销数据，以保证高效的数据处理能力，快速响应用户的请求和需求。同时，本系统需要具备高并发、高吞吐量和低延迟等特性，以满足万级用户同时在线的大规模数据处理和分析的需求。
  • 可扩展性和灵活性：营销实时数据处理系统需要具备良好的可扩展性和灵活性，可以根据业务需求和数据规模的变化，动态调整本系统的配置和资源使用。例如，本系统应该支持水平扩展和垂直扩展，可以根据营销实时数据处理需求选择适合的硬件设备和软件方案。
  • 数据安全性和隐私保护：营销实时数据处理系统需要采用多种数据加密和访问控制技术，以保证营销实时数据的机密性、完整性和可靠性。同时，本系统也需要遵守相关法律法规，保护用户的隐私和数据安全。
  • 易用性和友好性：营销实时数据处理系统需要具备良好的易用性和友好性，让用户轻松上手和使用。本系统应该提供简单、直观的界面和操作方式，减小用户的学习成本，提高用户的工作效率。
  • 智能化和自动化：营销实时数据处理系统可以采用人工智能技术和自动化技术，提高数据处理和分析的精度和效率。例如，本系统可以通过机器学习算法实现自动数据分类、自动营销策略优化等功能。
  • 开放性和互通性：营销实时数据处理系统需要具有良好的开放性和互通性，能够与其他系统和平台无缝连接和互操作。本系统应该支持标准化接口和协议，如RESTful接口、SOAP协议等，方便用户定制和扩展系统的功能。
    总之，基于Kafka+Spark的营销实时数据处理系统的系统设计目标和原则应该以满足业务需求、提高数据处理和分析效率为出发点，同时兼顾系统性能、安全性、易用性和可维护性。

3.2 系统架构设计

• 营销实时数据处理系统逻辑架构分为如下几个部分：
  • 登录、系统首页，实时统计页面，访问流量统计页面，交易分析页面，渠道日活柱状图，订单热力图和退出功能。
• 该系统的整体逻辑架构图如图1所示。
  
  图1 系统整体架构图
• 由图可见，该系统可以在保证实时性的同时，完成海量数据的快速处理和分析，提供精准的数据支撑和智能化的决策参考，为企业的营销活动提供了全方位、多角度的数据支持。
• 该系统具有可扩展性、灵活性和高效性等优点，并对相关领域的研究和实践具有一定的参考意义。

3.3 数据采集模块设计

• 在营销实时数据处理系统中，数据采集模块是整个流程中非常重要的一环。
• 它主要负责从数据源采集原始数据并推送到Kafka消息队列中。
• 下面是该模块的设计思路：
  • 数据源的选择：根据项目需求，选择合适的京东销售数据源进行采集。例如，在京东营销行业中，可以从网站、APP、社交媒体等渠道采集用户行为数据和交易数据，此数据中包含了最畅销的手机类型销售数据、其他电器数据和美妆销售数据等。
  • 数据采集工具的选择：在确定了京东销售数据作为数据源后，需要选择相应的数据采集工具。常见的数据采集工具包括Kafka、Flume、Logstash、Filebeat等，本文采用Kafka作为营销实时数据采集的工具。
  • 数据采集参数的设置和管理：在配置京东销售数据的数据采集工具时，需要设置相应的参数。例如，设置采集频率、目标Kafka主题、数据格式、数据编码等。同时，还需要对数据采集程序进行监控和维护，保障其稳定运行。
  • 异常数据处理：在京东销售数据的数据采集过程中，可能会出现一些异常情况，例如网络不稳定、数据格式错误等。需要在数据采集程序中实现相应的异常处理机制，避免因为异常数据导致整个系统崩溃。
  • 数据安全保护：在京东销售数据的日志数据采集模块中，还需要考虑数据安全问题，特别是涉及到用户隐私信息时需要进行加密或脱敏处理，同时也要确保数据传输安全和存储安全。
• 通过以上步骤的设计，可以建立高效可靠的数据采集流程，将各种数据源的原始数据快速准确地推送到Kafka消息队列中，为后续数据处理流程提供可靠的数据基础。
• 数据采集的可靠性非常重要，因此需要采取一些措施来保证数据的可靠性，如数据备份、数据去重、精确一次消费等。

3.4 数据预处理模块设计

• 该系统中数据预处理模块是非常重要的一环。
• 它主要负责对接收到的原始数据进行转化、去重、维度补充、存储，以适应后续流程中的数据处理需求。
• 下面是该模块的设计思路：
  • 数据转换：将原始数据转换成统一的格式，以方便后续处理。例如，将日期时间格式标准化，将字符串类型数据转为数值型数据等。数据转换也可以包括数据结构转换，例如将JSON格式数据转化为表格形式的数据。
  • 数据分流：当原始数据较大时，需要将其分流成多个部分进行处理，以提高数据处理效率。在预处理模块中，可以通过对数据进行分区来实现数据分流功能。主要包括：启动主题（DWD_START_LOG）、页面访问主题（DWD_PAGE_LOG）、页面动作主题（DWD_PAGE_ACTION）、页面曝光主题（DWD_PAGE_DISPLAY）、错误主题（DWD_ERROR_INFO）、事实数据、维度数据。
  • 数据聚合：针对同一个对象的多个属性值进行聚合，以便于后续处理。例如，对于同一用户的多次购买记录，可以将其聚合成一条记录，统计总购买次数、总消费金额等。
  • 数据去重：先进行自我审查，将页面访问数据中last_page_id不为空的数据过滤掉，然后，第三方审查，通过Redis将当日活跃的mid维护起来,自我审查后的每条数据需要到Redis中进行比对去重。
  • 在预处理过程中，可以对数据进行过滤，剔除无用的数据。例如，某些不需要的字段、重复数据、异常数据等
  • 数据维度关联：通过对多个数据源的数据进行维度关联和维度补充，可以获得更加全面和准确的用户行为和交易信息，例如，关联用户维度，关联地区维度。
  • 数据存储：在预处理模块中，可以将清洗和转换后的数据保存到内存、文件系统或数据库中，以便于后续流程使用。
    通过以上步骤的预处理，可以使得基于Kafka+Spark的营销实时数据处理系统能够更快、更高效地处理大量数据，并为后续流程提供高质量且可靠的数据基础。

3.4.1 业务数据预处理模块设计

• 对于业务数据的处理要以类型为单位拆分到不同Kafka的Topic 中。
• 针对维度数据，要单独保存。通常考虑用Redis、MySQL等通过唯一键查询性能较快的数据库中。
• 对数据进行分类、过滤、处理、转化等操作，使得京东营销部门能够更加全面地了解系统和应用程序的运行情况以及用户的行为。具体描述如图2所示
  
  图2 业务数据预处理架构图

3.4.2 日志数据预处理模块设计

• 将采集到京东营销的日志数据，统一存放到Kafka的统一Topic中，通过Spark Streaming进行日志数据消费分流，主要分为五个部分：启动日志、页面访问日志、动作日志、曝光日志和错误日志。具体如图3所示。
  
  图3 日志数据预处理架构图

3.5 数据存储设计

• 该系统的数据存储设计主要是将采集到的京东销售源数据放入到Kafka的Topic中，对于业务数据要使用MySQL数据库，需要在数据库中建相对应的表，Maxwell 会追踪整个数据库的变更，把所有的数据变化都发到一个Topic中，但是为了后续处理方便，应该将事实表的数据分流到不同的Topic中，将维度表的数据写入到 Redis中。
• 对于日志数据只需要将数据放在Topic中即可，将处理后的数据放在Redis中，最终写入到OLAP中。
• 可以提供多种数据访问方式，包括实时查询、OLAP（联机分析处理）、报表和可视化等。

3.6 数据仓库设计

• 本项目的数据仓库设计主要分为ODS、DIM、DWD和DWS四层，其各层详细内容如下：
  • ODS层：用于存储从京东营销数据业务系统中抽取的原始数据，保留了部分历史数据。ODS中的数据不进行清洗、转换和集成操作，主要用于本系统的实时查询和处理等应用场景。
  • DIM层：用于描述京东营销业务数据中的维度和维度间的关系，存储在Redis非关系型数据库。
  • DWD层：存储经过清洗、转换和集成的事实数据。DWD中存储的数据是面向主题的，与特定的业务需求相关联，是数据分析和决策制定的基础。
  • DWS层：为系统的数据分析和应用提供服务。在DWS层中，提供了对数据的访问接口，以便于各个应用程序和查询工具可以通过API、Web服务或JDBC等方式访问和查询数据。利用OLAP技术对多维度数据进行分析和查询，利用报表工具和可视化工具对数据进行展示和分析，以便于用户更好地理解数据中的意义和价值。
• 通过以上步骤的设计，可以构建高效、灵活的数据服务层，并为后续流程提供丰富的数据分析和查询基础。同时，也可以帮助企业更好地了解用户需求和市场趋势，提高业务效率和竞争力。
• 业务数据仓库主要是ODS、DIM、DWD和DWS四层，从ODS到DWD层主要负责原始数据的整理拆分，形成一个一个的业务事实topic。从 DWD 层到 DWS 层主要负责把单个的业务事实 topic 变为面向统计的事实明细宽表，然后保存到 OLAP中。日志数据仓库主要是ODS、DWD和DWS三层。这四个层次在数据仓库设计中协同工作，在数据仓库中，需要设计相应的查询语句，以便于用户进行数据探索和分析。

3.7 可视化模块设计

• 本项目可视化部分主要分为两部分，一部分是系统的页面可视化展示，另一部分是通过ES服务器来存储数据偏移量，通过KIBANA进行可视化展示。
• 对于系统页面可视化展示，该部分用于展示系统处理后的数据和分析结果，包括实时统计、历史趋势、订单情况，交易分析等内容。其中，实时统计可以通过图表或者仪表盘等方式进行展示，历史趋势可以通过折线图或者柱状图等方式进行展示，交易分析可以使用表格或者饼图等方式进行展示。系统界面具体的模板图如图4所示。
• 对于ES服务器存储数据偏移量及KIBANA可视化展示，该部分用于监控Kafka的消费状态，记录每个分区的消费偏移量，以及分析任务的运行状态等信息。目前我们已经将数据存储到了 OLAP 中，但是数据的存不是最终的目的，数据的查与展示才是最终的目的。例如可以使用 BI 工具进行数据的分析与可视化展示。具体来说，使用Elasticsearch（ES）服务器来存储数据偏移量，使用KIBANA进行可视化展示，可以方便地查看各个分区的消费情况，给予企业决策以数据支撑。
  
  图4 系统界面模板图

第4章 详细设计与实现

4.1 数据采集模块

4.1.1 数据字段

• 用户分析可以通过数据用户的关键词搜索、网页浏览和广告页面浏览模式得到很大帮助。主要字段包括用户行为数据字段、用户属性数据字段、商品属性数据字段和交易属性数据字段等，其中数据的具体内容如表1所示。
  

表1 日志数据

4.1.2 日志数据采集模块

• 对于拿到的京东营销日志数据ODS_BASE_LOG，将数据采集到Kafka的datas目录中。将拿到的源数据放到JSON中进行标准化展示，具体字段展示如图5所示。
  
  图5 日志数据JSON标准化展示

4.1.3 业务数据采集模块

• 对于拿到的京东营销业务数据ODS_BASE_DB，将数据采集到Kafka的datas目录中，具体如图6所示。
  
  图6 业务数据存放路径展示图

4.2 数据预处理模块

4.2.1 业务数据预处理模块

• 对业务数据进行数据消费操作，下面是具体消费到的数据信息，如图7所示。
  
  图7 业务数据消费到数据
• 提取偏移量结束点，转换数据结果为JSON格式，具体效果如8图、图9所示。
  
  图8 转换数据结构后数据展示
  
  图9 业务数据JSON数据展示
• 通过Spark Streaming对业务数据进行分流，将事实数据分流到Kafka具体的Topic中，首先要判断操作类型，明确是什么操作，过滤掉不感兴趣的数据等。

4.2.2 日志数据预处理模块

• 对日志数据进行数据消费操作，下面是具体消费到的数据JSON格式，如图10所示。
  
  图10 日志数据JSON展示
• 通过Spark Streaming首先提取公共字段，然后提取特有字段，对日志数据进行分流到各个主题中，包括：启动主题（DWD_START_LOG）、页面访问主题（DWD_PAGE_LOG）、页面动作主题（DWD_PAGE_ACTION）、页面曝光主题（DWD_PAGE_DISPLAY）、错误主题（DWD_ERROR_INFO）、事实数据、维度数据。启动五个Kafka消费者消费分流后的主题，例如JSON格式错误主题数据如图11所示。
  
  图11 错误数据日志JSON
• IDEA读取到分流之后的数据，在Kafka中分为四个区，提交到offset中。
  
  图12 分流之后的数据

4.2.3 日活宽表数据预处理模块

• 日活的统计我们只需要考虑用户的首次访问行为，不同企业判断用户活跃的方式不同，可以通过启动数据或者页面数据来分析，我们采用页面数据来统计日活，页面数据中包含用户所有的访问行为，而我们只需要首次访问行为。
• 首先是转换数据结构和去重，在每批次的数据中先将包含有 last_page_id 的数据过滤掉，剩下的数据再与第三方（Redis）中所记录的今日访问用户进行比对。具体实现结果如图13所示。
  
  图13 自我审查后数据展示
• 通过Redis维护今日访问的mid，自我审查后的数据再与Redis中维护的今日访问mid进行对比，进行第三方审查。具体实现结果如图14所示。
  
  图14 第三方审查后数据展示
• 维度关联，由于要针对各种对于不同角度的“日活”分析，而 OLAP 数据库中尽量减少 join 操作，所以在实时计算中要考虑其会被分析的维度，补充相应的维度数据，形成宽表。由于维度数据已经保存在固定容器中了，所以在实时计算中，维度与事实数据关联并不是通过 join 算子完成。而是在流中查询固定容器（Redis/MySQL/HBase）来实现维度补充。
  
  图15 用户信息维度关联表
  
  图16 日活宽表补充维度

4.2.4 订单业务宽表数据预处理模块

• 订单宽表消费到数据，基于order_detail和order_info两个表，具体如图17所示。
  
  图17 订单宽表消费到数据图
• 订单宽表补充维度，由于要针对各种对于不同角度的“订单”分析，而 OLAP 数据库中尽量减少 join 操作，所以在实时计算中要考虑其会被分析的维度，补充相应的维度数据，形成宽表。
  
  图18 订单宽表补充维度运行结果图
• 事实表与维度表之间的关联，由于在很多OLAP 数据库对聚合过滤都是非常强大，但是大表间的关联都不是长项。所以在数据进入 OLAP 前，尽量提前把数据关联组合好，具体流程如图19所示，不要在查询的时候临时进行 Join操作。所谓提前关联好，在实时计算中进行流 Join把数据存入缓存，关联时进行 join 后，再去查询缓存中的数据，来弥补不同批次的问题，运行结果如图20所示。
  
  图19 维度关联表流程图
  
  图20 两表关联结果展示
• 事实表与维度表之间的关联在数据库中查询到结果如图21所示。
  
  图21 两表关联后MySQL展示

4.3 数据存储模块

4.3.1 业务数据存储模块

• 将采集到的业务数据存储到Kafka的Topic中，同步存储到MySQL数据库（gmall）中便于展示，在MySQL中创建业务离线数仓gmall，导入相关的数据表。具体如图22、图23所示。
  
  图22 Kafka中业务数据展示
  
  图23 MySQL数据表的展示
• 列举两个MySQL数据库中的数据表order_detail、order_info进行展示，具体如图24、图25所示。
  
  图24 MySQL中order_detail数据信息的展示
  
  图25 MySQL中order_info数据信息的展示
• 将处理后的事实数据存储到Kafka中，维度数据存储到Redis中，包括用户维度数据和订单省份维度数据。具体如图26、图27所示。
  
  图26 事实数据在Kafka展示
  
  图27 维度数据在Redis展示

4.3.2 日志数据存储模块

• 将采集到的日志数据存储到Kafka的Topic中，具体如图28所示。
  
  图28 日志数据在Kafka中的存储
• 对于分流后的数据存储到不同的Kafka分区中，便于以后操作，避免不需要的数据，提高数据利用率，具体如图29所示。
  
  图29 日志数据分流后在Kafka中的存储

4.3.3 日活宽表数据存储模块

• 先建一个日活宽表模板，将待写入ES的数据准备好，这里是一个JSON格式的gmall_dau_info_1018，其中包含了需要存储的各个字段及其对应的值。ES有着高效的数据读写性能和强大的搜索功能，支持实时地对存储的文档进行查询和分析，还可以实现全文搜索、聚合分析、地理位置搜索等复杂功能。
• 主程序调用工具类批量写入 ES，其实我们前面已经使用 Redis 进行了去重操作，基本上是可以保证幂等性的。如果更严格的保证幂等性，那我们在批量向 ES 写数据的时候，指定 Index 的 id 即可。
  
  图30 ES中日活宽表

4.3.4 订单宽表数据存储模块

• 先建一个订单宽表模板，将待写入ES的数据准备好，这里是一个JSON格式的gmall_order_wide_1018，其中包含了需要存储的各个字段及其对应的值。
  
  图31 ES中订单宽表

4.4 数据仓库模块

4.4.1 ODS层

• ODS层主要是将日志文件和业务数据采集到Kafka中的统一 Topic中，业务数据库的采集主要是通过Maxwell基于对数据库的变化的实时监控。要利用这些工具实时采集数据到 Kafka，以备后续处理。
  
  图32 ODS层Kafka中数据展示

4.4.2 DIM层

• DIM层包括维度设计，在DIM层中，需要定义出各个维度以及它们之间的关系，可以定义出用户、地区、时间等多个维度，并且将它们按照一定的关系进行组合。对于每个维度，需要从ODS层中提取相应的数据，并且进行加工和转换。对于用户维度，可以从ODS层中提取用户的基本信息，并将其转换为符合规范的格式；对于时间维度，可以生成一张包含所有日期的日历表等。将经过加工和转换的维度数据存储到DIM层中。这里主要是将业务数据的地区和用户维度数据存储到Redis中。
  
  图33 DIM层维度数据存储

4.4.3 DWD层

• 从ODS层中抽取需要进行分析的数据，通过Spark Streaming对数据进行清洗和加工。例如过滤无效数据、去重、补全缺失数据等，最终将数据要进行以表为单位拆分到不同 Kafka 的 Topic 中。
  
  图34 DWD层数据分流存储

4.4.4 DWS层

• 从 DWD 层到 DWS 层主要负责把单个的业务事实 topic 变为面向统计的事实明细宽表，日活宽表和订单宽表，然后保存到 OLAP 中。
  
  图35 日活宽表DWS层展示
  
  图36 订单宽表DWS层展示

4.5 可视化模块

• 目前我们已经将数据存储到了 OLAP 中，但是数据的存储不是最终的目的，数据的查与展示才是最终的目的。本项目使用 BI 工具进行数据的分析与可视化展示。我们的数据保存在 Elasticsearch，那么利用 KIBANA 进行可视化展示是一种非常高效的可视化解决方案。系统可视化页面展示主要通过Spring Boot框架实现前后端分离，用于展示系统的实时数据和历史趋势。该系统包方式、实时监控、查询界面、可视化工具和地图显示等组件。

4.5.1 BI可视化模块

• 渠道日活柱状图是一种用于展示不同渠道（手机类型）每日活跃用户量的图表。通常情况下，该图表以柱子的形式表示每个渠道在特定日期内的活跃用户总数，从而使人们能够直观地比较各个渠道的表现。渠道日活柱状图对于业务人员来说非常有用，因为它们提供了关键的数据和见解，以支持他们在制定策略和决策时做出明智的选择，具体可视化结果如图37所示。
  
  图37 渠道日活柱状图
• 订单业务宽表地图热力图是一种数据可视化方式，用于显示订单业务在不同地理区域内的数据分布情况。
  
  图38 订单业务热力图
• 在这个热力图中，每个地区的颜色和深浅表示该地区内订单业务指标的大小或频率。订单业务宽表地图热力图可以使业务人员更好地了解订单业务的地理分布情况和趋势，优化营销策略，发现潜在的商机等等，从而帮助企业更好地把握业务发展态势，做出更明智的决策，具体展示如图38所示。

4.5.2 系统页面可视化模块

• 如下是一个简单的登录页面，登录页面应该是一个友好、安全且易于使用的界面，以便用户可以轻松地访问京东营销实时统计管理平台。
  
  图39 系统登录页面
• 首页主要展示系统的总体概况，包括统计管理的内容，实时统计、访问流量统计、订单统计、交易分析、欢迎页面等。
  
  图40 系统首页
• 实时统计部分，日活实时监控，用户可以选择某一天的日期，首先，会有一个今日访问总数的统计，实时显示当天的日活用户数，以便监控和调整营销策略。其次可以查看今日和昨日的日活访问情况，具体内容会有一个折线图展示，总之，该页面可以帮助用户轻松地监控和管理系统运行情况。
  
  图41 实时统计页面
• 访问流量统计是对昨日和近七日的PV总数、UV总数和新增用户数进行一个统计，PV指的是页面浏览量，也就是用户在网站上访问页面的次数。UV指的是独立访客数量，也就是访问网站的唯一不同的用户数量。
  
  图42 访问流量统计页面
• 会员统计页面，包括累计注册用户数，累计消费用户数，新增用户数，新增消费用户数和客单价。通过以上统计信息，会员统计页面可以为业务人员提供全面的会员数据分析支持，并且能够帮助业务人员更好地了解会员的特征和行为习惯，从而更加精细化地进行营销策略的制定和执行。
  
  图43 会员统计页面
• 交易分析页面包括性别、年龄分布饼状图和具体商品信息搜索的表格信息展示，根据时间维度（例如日、周、月等），分别展示不同时间段内的性别、年龄分布等统计信息占比，帮助业务人员更好地了解交易的趋势和变化。
  
  
  图44 交易分析页面