基于spark集群的券商个性化推荐系统架构设计最佳实践

一、券商实施个性化推荐项目的必要性

1.1 个性化推荐技术发展背景

目前，随着用户接收到的信息量爆炸般增长，传统的推荐以及服务方式的边际收益正在不断减少，用户个性化的需求变得越来越多。大数据实时个性化服务，主要基于大数据用户画像、产品画像建设成果，结合实时流计算框架，以客户需求为中心进行服务，做内容的主动创新和服务资源的精准配置，在恰当的时间将个性化的服务以合适的方式交付给需要的客户。目前涉猎到的应用包括实时热搜、市场热点、个性化资讯推荐和理财产品推荐，这部分的创新应用尝试主要基于人工智能算法实现。以个性化资讯推荐为例，主要利用在SPARK分布式集群上设计适合于证券金融资讯的协同过滤实时推荐算法，最终实现客户的个性化推荐。人工智能算法有效提升了用户体验和推荐内容的质量、精准度，可以为公司千万用户提供千人千面的全渠道优质服务。通过本行业推荐系统CTR（点击到达率）指标进行评估，个性化推荐可将券商互联网业务客户转化率提高三到五倍；可实现基于互联网的新增开户数、用户规模和用户活跃率的市场领先。

二、证券行业个性化推荐系统方案设计

2.1 设计目标

利用大数据技术的应用，整合公司内外用户服务相关系统和数据，通过基于用户画像的建模方法，运用机器学习和数据建模技术，为用户提供个性化、定制化的金融和资讯产品。

具体表现为：渠道互联网化、产品互联网化、平台互联网化三大体系，建设统一大数据处理平台作为支撑平台，形成一套互联网与大数据综合理论。以技术创新带动业务创新，提升公司差异化竞争力。其中渠道互联网化是本质是将互联网作为金融服务与最终用户之间进行交易的渠道。这种渠道既包括宣传渠道，交易渠道，也包括集成渠道和监管渠道。产品互联网化与渠道最大的区别是企业在互联网，而不是内部交付产品。即企业将产品相关的金融额度、服务、内容全部放到互联网上，并通过互联网和其它服务商进行集成。最终用户在互联网上完成产品和服务选择以及支付。企业内部只保留必要的核心交易记录和结算记录。平台互联网化，或者说互联网平台进入金融领域，是目前互联网金融探讨最热烈的切入点。既有的金融企业，希望通过平台互联网化，直接加载互联网相关的用户群，扩大金融市场，缩减金融成本，再通过个性化推荐等有效触达手段提升用户活跃度。

2.2 负载均衡设计

Netty数据接口服务使用反向代理实现负载均衡，进而达到高可用性。我们在不同服务器上布置了多个Netty数据接口服务，并使用F5制作了一个虚拟IP地址，作为Netty的反向代理地址，实现负载均衡。当某个Netty服务崩溃时，F5会自动屏蔽它的地址，不再将数据请求发送给它，保证数据接口的正常、稳定运行。

2.3 系统架构设计

2.3.1 系统整体架构：

系统的总体架构分为以下几个部分：
1.接入层
接入层基于数据抽取转换存放平台，主要实现功能如下：
（1）抽取：将数据从数据库或者外部文件读取出来，包括关系型数据库、半结构化文件等。
（2）清洗：将一些脏数据和不合规范的数据进行过滤转换使取符合规范。
（3）转换：将数据进行数据类型改变，格式变换，数学计算，逻辑操作等。
（4）过滤：按照特定的列的值进行提取数据。
（5）关联：不同数据流按照特定的列进行合并成新的数据流。
（6）去重：按照特定的列去掉重复数据。
（7）排序：按照特定的列对数据流排序。
（8）加载：把数据装入数据库或者文件中，以供后续使用。

2.存储和与处理层
存储和与处理层基于大数据处理和分析平台以及操作性存储和分析平台，其中大数据处理和分析平台主要实现功能如下：
（1）原始数据存储：原始数据存储指从外部数据源获取的结构化和非结构化数据（日志文件、运营数据、业务数据等）的原始备份。
（2）外部数据共享：外部数据共享存储指其他外围系统产生的日志数据或相关
重要业务运营数据的共享存储区。
（3）低密度数据沉淀：低密度数据沉淀类似于数据仓库概念中的数据沉淀层，其数据来源是经过清洗转换后的源数据层，按不同分析角度进行关联、统计、轻度汇总等实现的数据沉淀。
（4）高密度数据汇总：高密度数据汇总类似于数据仓库概念中的数据集市的概念，将低密度沉淀的数据按照不同维度属性进行高密度汇总，比如 按渠道属性、按地域属性、按用户属性等进行统计汇总。
（5）指标分析：KPI指标指关键业绩指标，是分析关键指标或重要指标的方法之一，其特点是考核指标围绕关键成果领域进行选取，通过建立评价指标体系、设定评价指标标准、展现关键指标结果、审核关键指标等来实现KPI指标的考察与跟踪。

3.模型和分析层
模型和分析层基于模型平台，主要实现功能如下：
（1）统计模型：根据选定的数据源，经过统计、归并等数学过程，提取出有用的新数据。
（2）分类模型：选取与待分类对象相关的数据，并基于这些数据，对目标对象进行等级（或者类别）划分。
（3）预测模型：以预测目标对象在未来一定时间内的走势为目标，选取适当的相关数据源和预测方法，对目标对象的未来情况做出估计。
（4）实时推荐架构：针对统计建模和个性化定制的推荐结果，建设实时推送的定制化平台基础构建。

4.展现和应用层
展现和应用层基于指标平台以及业务服务和展现平台，指标平台主要实现功能如下：
（1）指标定义：定义系统使用的指标体系，定义指标的分级、分类，指标类型，指标单元，指标维度、精度，指标版本，指标实例，来源，状态和应用。
（2）指标维护：通过管理流程来维护指标，包括指标申请，审核，录入，修改，生产和消亡。

2.3.2 系统物理架构设计

物理架构由上图中的数据库集群、Hadoop集群、Kylin集群、Elasticsearch集群、对外接口服务器、大屏服务器、ETL服务器、任务调度服务器、Kafka集群、Spark Streaming集群、Redis集群、Netty服务器、报表服务器、界面数据接口服务器等部分组成。
（1）当前部署10台列式数据库服务器集群，其中一台为master，其他为slave。
（2）Hadoop集群由50台服务器组成，其中六台管理节点，其余为数据节点。包含Hadoop、Hbase、Hive、Spark、ZooKeeper等大数据生态环境的组件。
（3）ElasticSearch集群是提供面向客户的在线查询及全文检索引擎，由8台服务器组成，每台服务器上部署有2个ElasticSearch实例，以充分发挥ElasticSearch的性能。集群配置有一个master实例，以及两个可以被选举为master的DataNode，提供高可用性。
（4）任务调度服务器：负责数据工厂内部所有类型的任务调度服务器，包括2台配置数据库服务器，两台应用服务器，双机互备。
（5）ETL服务器：数据采集服务器，一主一备。
（6）Kylin集群：多维应用服务器，两台做负载均衡。
（7）个性化推荐相关服务器集群：Kafka集群、Spark Streaming集群、Redis集群，各三台做分布式集群部署、Netty服务器两台做负载均衡
（8）界面数据接口、对外数据接口服务器：两台做负载均衡

2.3.3个性化资讯推荐模块逻辑架构设计

数据流过程
（1）前端应用向总线发送获取咨讯的请求；
（2）请求信息经总线到F5进行解析；
（3）请求信息经F5到Netty进行解析；
（4）经Netty在Redis中查询相关客户的咨讯ID；
（5）返回这个客户的咨讯ID至Netty；
（6）返回这个客户的咨讯ID至F5；
（7）返回这个客户的咨讯ID至总线；
（8）返回这个客户的咨讯ID至前端；
（9）前端根据推荐ID列表，经总线发起咨讯内容请求；
（10）请求到公共缓存；
（11）公共缓存返回咨讯主题、常规信息、URL至总线；
（12）总线将咨讯主题、常规信息、URL返回至前端；
（13）前端根据URL通过公网访问CDN获取文件；
（14）CDN返回咨讯带的文件，如图片等。

工作流过程
A. 实时数据获取：
（1）将实时资讯内容通过Kafka推送给预处理模块；
（2）将外部语义分析训练数据通过Kafka推送给语义分析模块。语义分析模块用外部训练数据优化其标签系统。

B. 资讯预处理模块的数据交互：
（1）资讯预处理模块对资讯内容进行清洗和预处理，调用语义分析模块的HTTP服务获取资讯内容的标签；预处理模块接收到资讯标签结果后，将结果结构化，其中需要的维度信息从对内Redis中获取；
（2）将原始资讯信息存入ES；
（3）将结构化的资讯标签结果存入Redis、Kafka和HBase，如下所示，
i）Redis：更新Redis中资讯状态表，
ii）Kafka：供Spark Streaming计算Item CF等资讯相关指标，
iii）HBase：供推荐引擎离线训练推荐规则。

C. 日志预处理模块的交互
（1） Java批量的解析日志存入Hadoop，供推荐引擎离线训练推荐规则；
（2） LogStash实时解析日志存入Redis和Kafka，如下所示，
i）Redis：更新对内Redis中客户状态表，
ii）Kafka：供Spark Streaming计算User CF等客户相关指标，以及统计热点资讯等信息。

D. 推荐引擎中批量获取训练数据：
（1）从Hadoop中获取用户点击行为历史数据；
（2）从Hbase中获取资讯结构化标签历史数据。

E. 推荐引擎与Spark Streaming交互：
（1）推荐引擎根据用户行为历史数据、资讯标签历史数据以及CTR等评估指标，测试、调整、优化自定义推荐规则和基于机器学习的自动化推荐规则；
（2）推荐引擎生成的推荐规则提供给Spark Streaming使用，推荐引擎与Spark Streaming无直接的数据交互。

F. Spark Streaming根据实时数据流、缓存、规则（E）计算推荐列表：
（1）资讯状态缓存，F3-用户状态缓存，两者保存在对内Redis中；
（2）实时资讯流，F4-前端实时日志流，两者保存在Kafka中。

G. Spark Streaming将推荐结果列表保存在对外Redis中。

2.4 设备需求

本项目所需要用到的设备层面的需求如下表所示：

2.5 个性化推荐系统模块设计

2.5.1 外部接口设计

（1）资讯看了又看

（2）热点资讯

（3）个性化资讯推荐

2.5.2 内部接口设计

（1）更新客户相关信息

（2）更新个股相关信息

（3）更新板块相关信息

（4）更新资讯相关信息

（5）资讯点击次数统计

（6）APP客户端点击资讯记录

（7）更新客户持仓相关信息

（8）更新用户自选股相关信息

（9）资讯相似度计算

三、项目实施经验

3.1 项目周期

根据项目整体规划和预期目标，项目整体建设周期分成以下几个阶段：
（1）项目调研和规划设计：一个月；
（2）项目的总体分析和设计，包括技术架构选型、软硬件部署：一个月；
（3）主要技术平台搭建和测试：四个月；
（4）主要功能开发；针对公司内部进行金融产品、资讯和服务的个性化定制开发工作：三个月
（5）试运行，验收：一个月

3.2 执行实施标准

本次项目的开发始终就严格按照标准化要求，遵循公司信息系统采购、建设和质量评估标准。力求最终按照规范化的工作方法管理项目循环过程，始终把最终用户放在项目产品供应优化和质量控制的中心。针对项目建设过程中每个阶段的标准化管理情况，具体分析如下。
（1）实施需求调研
需求调研阶段的目的是：对现有业务和IT现状进行调查和初歩诊断，明确咨询与实施的目标与范围.根据现状制定具体的行动方案。
（2）项目准备
对项目实施范围内的业务进行深入全面的分析，澄清需求，评估各业务大致工作范围和工作量，并结合产品拟定项目应用方案，建立一套系统运行的良好制度。根据现状设计项目总体规划，让项目有章可循，总体控制。
（3）项目建设
项目建设主要包括两个阶段，一个是项目开发、一个是项目实施。
项目开发阶段主是产品的生产，主要包括项目的开发、测试，使用手册，产品审核等。
项目现场实施阶段主要是产品应用的建立，主要包括项目实施计划，硬件及支持平台采购、运行环境配备，项目产品现场安装、调试、系统权限分配、客户培训，项目试运行、项目的变更，问题的跟踪解决、产品完善等。
（4）项目交付
项目交付阶段主要是在保证项目良好运行的同时，支持辅助系统使用和对接方能够流畅正确和理解系统使用方式，并完成项目验收，生成相关验收报告和项目总结。
（5）运行支持
项目支持主要是对完成项目后续维护服务体系建立，以保证项目的持续性和完整性。

3.3 人员配备

（1）项目管理办公室PMO
负责整个项目的协调工作，主要负责与上级主管部门、其它子平台进行协调，并负责本项目各子系统工程组和软件开发组的相互协调，确保工程按时、有序地进行。负责组织安排好各种例会，协调会并形成文档等记录。
（2）项目经理
项目经理是项目团队的领导者，他所肩负的责任就是领导团队准时、优质地完成全部工作。作为项目的指挥者，项目经理要担任的职责是对项目的计划、组织和控制。我公司将为本项目的实施配备具有IT项目管理工作资质和经历，具有完成类似项目的经验，主持过多项大型软件开发、系统集成项目的管理和实施，具备与上级领导、客户及属下进行交流的技巧，并具有丰富专题知识的项目经历，该人将在联合领导组的直接领导下，作为具体承担人和联络人与联合领导组保持联系。
（3）系统开发人员
应用软件系统开发组在组长的组织下，对服务系统的各个子系统进行详细需求分析及设计，确定业务流程，各子系统功能，应用软件系统总体结构以及模块之间的关系，定义各功能模块的借口、控制接口、反馈接口，确定系统数据结构，分析各子系统之间的关系，确定技术实现路线。设计工作完成后，软件开发人员负责设计各模块的内部细节，并制定测试计划，对集成测试和性能测试等工作作出规定与安排。
针对本项目软件开发的复杂性，应用软件系统开发组应详细划分项目队伍组织结构，并合理的分配人员，同时明确每人的分工，制定进度安排，确保开发任务的可控性。
（4）测试人员
测试组负责软件、硬件的测试工作，负责制定测试计划、测试内容。负责对应用软件的模块测试、功能测试、性能测试、内存测试、稳定性测试、综合测试，整个系统安装、调试完毕后对系统进行总体测试，在项目进行中及时发现软、硬件设备出现的问题、故障，帮助开发、集成人员快速、准确地解决问题，确保软、硬件设备能够按时投入正常运行。
（5）文档管理人员
文档组负责管理由各组在实施和服务过程中所填写的各种记录文档和其它技术资料，包括电子文档和文字材料。如项目管理文档、实施计划、实施进度、系统应用设计文档、系统配置情况、系统运行和维护手册、测试文档、初步验收报告、用户意见反馈表、系统测试报告、试运行情况、反馈技术手册、验收报告、系统维护日志项目会议纪要、项目进度报告和分包商提交的各种文档等等。在项目进行的各个阶段督促相关人员按时完成各种文档，工程交付后负责所有技术、质量文件的整理归档。

 四、运维管理经验

运营监控部分分为服务器状态监控、服务监控两个部分，以便于掌握服务器、服务、数据总线的实时状态，及时发现、解决潜在的问题。

（1）服务器状态监控
编写python脚本实时采集服务器的cpu、内存、磁盘io、网络io等信息，并发送给OpenTSDB时间序列数据库，OpenTSDB负责接收、存储、查询、分析接收到的数据。OpenTSDB是基于Hbase的时间序列数据库，可以用于存储海量的时间序列明细数据，同时，它还提供了一个功能强大的GUI，可以轻松定制监控图表，只需选择参数即可分析、对比监控数据。

当发现CPU、内存等服务器容量达到预警值的时候(不同系统的服务器有不同的预警值)，即可根据系统的特点添加服务器资源，以提高系统的容量。

（2）服务监控
服务监控方面，使用Ambari监控Hadoop、Spark、Hbase、Hive等Hadoop生态圈的组件。Ambari是应用最为广泛的Hadoop生态部署、管理、监控工具。监控内容包括这些服务的状态，以及HDFS的空间使用情况、Block的健康状态，YARN的资源使用、MapReduce Job历史及运行状态，Spark应用的状态等。

ElasticSearch集群的监控由Marvel负责。Marvel是elastic官方的ElasticSearch监控工具，可以查看集群中各个节点的状态及cpu、磁盘、JVM Memory的使用情况，各个Index的shard在集群中各节点上的分布情况与状态。此外，还可以查看Elasticsearch的查询、写入速度及延时，以及Shard的活动情况。

对于Kafka、Redis、Netty，列式数据库、ETL系统、调度平台等服务来说来说，我们自主开发了一个集数据采集、数据传输、数据展示于一体的监控系统，监控这些服务的运行状态、所在的服务器状况等信息。