神策数据是国内专业的大数据分析和营销科技服务提供商，目前已为众多商家提供了数据服务。画像平台功能只是神策所有服务模块中的一部分，本节根据神策对外提供的技术资料，按照个人理解描述一个类似神策平台的构建过程。
神策产品介绍
神策数据定位是国内专业的大数据分析和营销科技服务提供商，公司致力于提供如下能力帮助企业实现全流程营销数字化。
神策数据目前提供的产品方案是“两云一台”。神策分析云可以整合广告投放、用户行为、业务经营等多种数据源，覆盖全场景的业务分析与用户洞察，为企业中的不同角色提供实时、多维度的数据分析和智能决策方案。神策营销云是覆盖公域私域、线上线下的全场景的数字化营销平台。神策数据根基平台是面向业务的全端数据基础平台，可以实时采集、治理、存储、查询、展示数据，并搭载数据智能引擎，高效积累数据资产，赋能业务应用场景，助力企业构建扎实的数据根基，实现数字化经营。
除了使用完整的产品方案，神策还提供可以单独购买使用的服务，表9-4中简要介绍了各服务的主要应用场景。
表9-4 神策数据相关产品及适用场景
产品名称 | 主要功能点 | 应用场景 |
|---|---|---|
神策分析 | 报表（配置数据形成报表）概览（数据看板）分析（事件、留存、漏洞）书签智能预警分析 | 基于全渠道采集的数据，可以实现各类分析功能，构建分析报表并设置预警信息等。 |
神策用户画像 | 用户标签管理用户分群用户群画像 | 自定义生产标签、基于标签和行为明细圈选人群、人群画像分析。 |
神策智能运营 | 运营计划流程画布微信运营内容管理 | 制定运营计划，实现精准运营 |
神策智能推荐 | 物品库栏位（推荐规则） | 配置推荐物料和策略，借助算法能力实现智能推荐。 |
神策AB测试 | AB实验 | 配置AB实验，实验效果分析 |
神策广告分析 | 渠道分析渠道追踪 | 智能广告投放，投后效果分析 |
神策客景 | 客户全生命周期分析与运营工具 | 客户全生命周期管理 |
主要技术模块
神策的核心功能都直接或者间接依赖从业务侧收集到的各类数据，不同数据的来源不同，但是需要有统一的数据接入层，为了满足不同量级的数据接入需求，接入层需要支持横向扩展；收集到的数据需要按照业务要求经过清洗和整理之后存储起来；为了提供高效的分析功能，数据要配合性能要求写入到合适的查询引擎中；所有功能最终都经由前端展示系统提供给用户使用，用户在页面上的操作转换为查询和分析命令后经由查询引擎执行。综上可知，为了实现一个类似神策的平台，从技术角度主要包含如图9-17所示的五个技术模块：数据采集与接入、ETL处理、存储系统、查询引擎和前端展示系统。本节会分别介绍各模块的主要实现思路以及可以使用的开源技术方案。
图9-24 系统关键技术模块1. 数据采集与接入
数据采集负责汇总各类渠道的业务数据，其中渠道种类可以分为客户端和服务端。客户端主要包括Android、IOS、小程序、HTML5等，数据主要来源客户端埋点，可以通过埋点SDK上报业务数据。服务端主要指服务端数据导入，导入的数据主要包含服务端业务日志，也可以是服务端已存在的业务数据，比如存储在业务数据库MySQL中的数据。
为了统一数据采集的接入方式，可以全部采用HTTP协议写入数据；为了减少数据传输的网络带宽消耗，可以对上传的数据进行压缩。数据最终通过负载均衡器进入服务端，采用负载均衡可以支持横向拓展来适应不同量级的接入数据。收集到的数据最终路由到不同的后端服务器上实现数据落盘，服务器可以使用Nginx，其作为七层负载均衡器适用于解析HTTP协议的数据；数据可以先直接写入本地文件中，一方面可以快速实现数据写入及保存，另一方面可以实现与后续ETL环节的解耦，方便ETL阶段按需处理数据。图9-25展示了数据采集和接入模块的主要流程。
图9-25 数据采集及接入模块神策已经开源客户端数据采集SDK，在项目中可以直接使用。服务端日志收集也有一些开源工具，如Logstash、FileBeat，其两者都支持HTTP协议传输数据。Logstash基于Java实现，运行于JVM之上，但是运行过程中对于资源的消耗较大；FileBeat基于Go语言实现，占用资源较少。如果需要将业务数据库中已有的数据上传到数据收集服务，可以借助Logstash或者syncer实现。负载均衡已经发展比较成熟，四层负载均衡可以考虑使用LVS，七层负载均衡可以使用Nginx或者HAProxy，也可以使用负载均衡云服务来实现，比如阿里云SLB、腾讯云CLB以及AWS ELB。
2. ETL处理
采集到的数据经由Nginx写入本地文件之后，需要对数据进行解析与加工。数据解析首先要将数据解压为原始的业务数据，然后校验数据内容是否合法、丢弃异常数据等。数据解析过程中可以监控数据质量，当出现大量异常数据时可以及时报警并进行处理。为了支持用户二次开发，数据解析与加工模块可以提供用户自定义插件功能，当用户对数据加工有特殊需求时可以通过插件进行干预。ID-Mapping也可以在本环节实现，用户传入的每一条数据中都包含UserId或者DeviceId等，为了实现全局ID唯一，可以将原始ID转换为统一的ID后传递到后续环节。
经由数据解析和加工后的数据可以写入消息队列供后续环节进行消费。为什么不能直接进行数据写入？主要有两点考虑：一是数据写入消息队列后，所有相关方都可以消费消息来满足不同业务需求；二是实现了业务解耦和数据流量削峰，后续数据写入模块可以自行扩缩容满足写入性能要求。图9-26展示了ETL数据处理模块的主要流程。
图9-26 ETL处理模块为了能够感知本地文件的变更，可以基于JNotify和WatchDog实现，其中JNotify基于Java语言实现，WatchDog基于Python语言实现，两者在业界使用都比较广泛。图9-26中显示的消息队列是Kafka，其比较适用于大规模数据处理，其他开源消息队列还包括RabbitMQ、RocketMQ等。
3. 存储系统
经由数据解析与加工后的数据最终通过数据写入模块被写入存储系统中，最常见的大数据存储方式为HDFS文件或者Hive表；部分业务场景下为了加速查询及分析速度，可以借助一些高效的分析引擎实现，比如本书提到的ClickHouse。数据写入模块可以借助Flink来实现，首先需要消费上游处理好的数据，然后使用Hadoop提供的接口实现数据写入（ClickHouse也支持通过接口的形式写入数据）。目前业界各类存储引擎也比较多，需要根据数据特点和业务需求进行选择。图9-27展示了存储系统模块的主要流程。
图9-27 存储系统4. 查询引擎
如图9-28所示，所有功能请求最终都会转化为数据执行任务，数据执行任务通过SQL语句的形式进行表达，最终借助查询引擎从Hive或者ClickHouse中找到满足条件的数据。为了提高计算速度，可以优先使用ClickHouse计算，计算失败或者异常后可以通过Hive进行兜底计算。由于Hive和ClickHouse的优劣势和所支持的业务场景不同，查询引擎需要支持按任务类型路由到不同执行引擎的功能。
查询引擎需要高度抽象，其暴露的功能接口与具体引擎无关，对外隐藏具体的执行细节。对于查询结果，经由查询引擎封装后返回调用方，比如将查询结果组装为图表格式数据后返回前端页面展示。
图9-28 查询引擎5. 前端展示系统与其他模块
前端展示系统是用户可以直接感知和使用的功能系统。前端展示系统有哪些功能与业务需求相关，各类功能需精心设计来提高用户使用的便捷性。前端开源框架也有很多，比如React和Vue，本书第7章中也介绍了基于Vue搭建前端框架的步骤。前端应该关注功能的可用性与结果的有用性，用户可以简便高效地使用平台功能并满足自身诉求，页面展示出的各类结果需要明确且易理解。
为了保证系统的可靠性与稳定性，需要提供完善的系统监控能力。从数据接入到各类平台功能的使用，涉及的基础组件和功能模块比较多，当某个环节出现问题时需要被及时感知并进行处理。如果提供商业化产品，需要监控当前License是否合法，保证商业利益。
为了监控系统中的软硬件运行状况，需要提供全面和完善的运维工具。商业化产品还需要支持自动化的版本升级，降低人工干预成本、提高部署效率。
本文节选自《用户画像：平台构建与业务实践》，转载请注明出处。
