【《基于大数据技术的用户画像系统设计》9400字（论文）】

基于大数据技术的用户画像系统设计目录TOC\o"1-2"\h\u1背景 11.1系统设计背景 11.2系统设计意义 12系统开发技术 32.1Hive技术 32.2Hadoop分布式计算平台 33系统分析 63.1需求分析 63.2功能需求分析 64系统设计 114.1总体设计 114.2数据来源与采集 124.3数据仓库分层设计 154.4标签结果数据存储设计 164.5画像WEB服务设计 175系统实现 195.1标签计算功能实现 195.2人群画像实时查询功能实现 226系统测试 256.1个人用户画像查询功能测试 256.2通过用户标识创建人群功能测试 266.3标签管理功能测试 27参考文献 301背景1.1系统设计背景人类主要是对自身信息进行记录并对世界加以测量从而出现了各种数据，从数据背后可以更好地认识自身和世界。如今，存储技术在迅猛发展，计算机应用更加普遍，人类可以记录以及处理的数据量得到了巨大的增长。互联网技术在问世以来，数据获取以及传递变得更加方便。而且互联网当中无时无刻都在生产出大量的信息。如今，互联网用户的数量在迅速上升，而互联网数量也迎来了蓬勃发展。在近些年，物联网概念变得更加普及，物联网将带来更大幅度的数据增长。据IDC报告，到2025年全球的数据量将达到163ZB。在过去，即使能将数据记录下来，也很难对大量的数据进行处理并挖掘其中价值。在最近十几年间，随着分布式系统的逐渐流行，例如分布式存储技术让存储成本大幅降低，分布式计算实现了大规模数据计算，使得存储以及从海量数据中挖掘有效信息变为可能。同时，伴随着机器学习、深度学习等技术的发展，使得海量数据运算有了更多落地场景，从而帮助业务的发展。在用户产生大量数据以及大数据相关技术把处理海量数据变为可行的前提下，如何发现数据中的价值，提升服务质量是当今很多公司需要考虑的战略问题。然而，提升服务的前提是必需了解产品面对的是用户是谁，用户之间有什么差异，用户的社交网络关系，如何提高用户对产品的粘性。为了解答这一系列的问题，不少公司开始构建用户画像，期望通过用户画像更深入地了解用户。1.2系统设计意义本文主要设计出一个既可以让亿级用户使用的画像系统，同时也包含企业的多个产品，而且也在提供相应的产品服务。这一系统可以进行一定的实时计算，并且得到实时标签便于下游的客户运用。除此以外，这一系统也能利用页面配置的形式对标签的计算准则进行定义，借助于页面配置而生成不同的标签，让开发工作变得更加简答。本文根据用户画像产品的需求，实施了一个基于网络产品技术的用户画像系统，该系统支持从各种来源和结构收集数据。可用于处理TB级数据容量的分布式计算。该系统同时支持独立的实时计算和计算，从而将及时处理大量数据结合起来。在计算标签值时，本条原则上建议使用网页配置来确定标签的值，并将用户组与其他用户组区分开来。通过过滤页面条件。这使得产品和运营者能够按要求创建标签，并区分用户组来分析选定的用户不需要确保数据分析人员每一次都为特定的人口群体编写新的报告。通过搜索引擎，该系统能够为数十亿用户提供每秒的回复，这大大减少了用户要求大量数据的时间。目前，该系统已正式进入网络，为多个指令，如产品，操作，推送，建议，通过页面查询，调用接口，推送信号及其他形式，为商业当事人提供了实用价值。本文比较详细地介绍了用户画像系统在实际业界从设计到实现的过程，希望能给相关从业者构建类似系统时提供一定的参考价值。2系统开发技术2.1Hive技术由于本系统使用了Hadoop技术栈，利用HDFS存储数据。在搭建数据仓库选型时需要考虑到与Hadoop生态兼容，并且能支持SQL查询功能让数据分析师方便使用。考虑到这些特点，本系统最终选定Hive来搭建数据仓库。Hive是一个基于Hadoop的数据仓库工具，提供类SQL查询功能。Hive使用HDFS作为文件系统，在初期通过将SQL转化为MapReduce任务进行计算。由于MapReduce计算过程要落地到磁盘，速度比起内存计算的Spark要慢很多，Hive社区后来推出了HiveonSpark项目，将计算引擎改为Spark，性能得到大幅提升。因此，本系统使用Hive构建数据仓库，利用HiveonSpark通过Spark来进行计算。数据仓库是整个画像系统中最重要的一个部分，本文使用了Hive来搭建数据仓库。大部分离线ETL以及事实类标签计算都由Hive来承担。同时，为了改进MapReduce运行速度慢的缺点，在计算引擎上采用了Spark，通过HiveonSpark实现更高的性能。2.2Hadoop分布式计算平台Hadoop是一个开源的分布式计算框架，设计思想来源于Google实验室的GFs(TheGoogleFilesystem)、MapReduce和BigTable技术，核心组件包括HDFs(HadoopDistributedFilesystem，Hadoop分布式文件系统)、MapReduce计算编程模型和HBase数据仓库等，具有高可用、可靠和可伸缩等优点。通过zooKeePe:管理主备节点实现框架的高可用性，Hadoop计算框架通过将计算任务分配给各个节点达到并行计算的目的，因此可通过增删节点动态调整集群的规模。Hadoop分布式平台架构如图2-1所示:图2.1Hadoop分布式平台架构HDFS是一种分布式文件系统，是-一个主/从结构，适用于大规模数据存储应用，具有高容错性、高吞吐性和高冗余性，可以运行在闲置、廉价的设备上，多个副本备份保证了数据的可靠性。HDFS的结构如图2-2所示:图2-2HDFS结构MapReduce是一种分布式计算框架内的抽象编程模型，它的核心思想是“分治”，在使用MapReduce进行数据处理时将计算任务划分为两个阶段:Map(映射)阶段和Reduce(归一)阶段。整个计算过程会将需要处理的数据划分为Key一value键值对的形式，同时提供丰富的Apl(ApplicationprogrammingInterface，应用程序接口)供开发者使用。HBase是一个分布式、面向列、可扩展、实时读写的Hadoop开源大数据存储组件，底层存储基于HDFS，分布式架构由ZooKeeper群、Master群和RegionServer群组成。由于面向列存储的特性，HBase适用于存储结构未知的海量数据，特别是稀疏数据。HBase在存储数据时采用Rowkey和列簇的方式达到数据的分区、分块存储，同时每一行数据带有时间戳，能够实现高效率的实时读写。HBase结构如图2-3所示:图2-3HBase结构图整个集群的资源分配管理与计算任务的调度、管理则由YARN负责，为数据并行化处理提供了高效的作业管理运行容器。

3系统分析3.1需求分析需求分析首要任务是明确该产品的目标用户是谁。本文设计出来的画像系统包含了诸多产品类型，变了便于叙述，主要从短视频应用出发进行研究，最终刻画得到短视频APP用户方面的画像数据。以用户画像系统为基础的定位，这一系统的使用人群主要是短视频产品方面的运营团队与产品团队人员，为其提供出相应的人群分析作用，从而便于他们更好地掌握短视频APP用户群体的整体特点，制定出更加完善的运营策略或者是产品方案。同时，画像系统可以给推荐团队提供APP使用者的兴趣爱好特征，从而提高推荐的成功率。另外，还可以提供人群划分功能给推送团队或者广告团队，让他们通过特定的标签组合便可以圈选出一批人群，从而实现不同人群使用不同的推送策略，提高推送或者广告的点击率。所以，这一系统的目标用户主要是短视频运用方面的运营团队、产品团队、推送团队人员。运营团队与产品团队会借助于页面运用画像系统。但是推送团队会使用程序，通过接口来获取到相关数据。分别按照不同的使用场景，画像系统要提供出各自对应的数据获取手段。3.2功能需求分析该部分把功能需求按外部用户与画像系统内部管理用户分成两部分，分别是对外服务功能与内部管理功能。对外服务部分主要面向画像系统的业务使用方，内部管理功能主要是供画像团队管理相关功能使用。以下将分别介绍这两大部分的需求，并采用UML例图进行描述。3.2.1对外服务对外服务面向的画像系统的使用方，包括产品团队、运营团队、推送团队以及推荐团队。（1）个人用户画像查询该功能面向公司内部所有团队，团队成员通过画像系统页面，利用用户ID、设备ID、邮箱或者手机号等任意一种账号信息，可查询自己的全局画像标签数据。为避免用户数据泄露，所以限定用户只能查看自己的画像数据。该功能一方面提供了公司内部团队查看自己画像的功能，另一重要作用在于收集团队成员的反馈信息，例如某个团队成员发现自己的画像里头某些标签数据不准确，则可以在系统上直接反馈，方便数据分析团队纠正标签计算错误。该功能的用例如图3一1所示。图3一1页面查询用户用例图该功能具体需求用例如表3一1所示。表3-1个人画像查询用例说明（2）人群划分该功能主要面向产品以及运营团队，支持三种方式创建人群。能够利用用户标识，借助于标签筛选或是对粉丝人群进行限定，从而筛选出目标人群，从图3一2当中可以看出。目标群体能够利用数据导出的形式来提供出推送系统便于进行消息推送，也能借助于页面图表方式来展现出这一目标群体各种维度下的标签特点。图3一2三种创建人群的方式（3）通过用户标识创建人群画像系统用户通过指定用户标识例如短视频的用户账号，然后通过文件上传一批使用该标识的用户账号，填写人群名称并提交。画像系统则会根据所上传的账号以及用户标识在系统中转化成对应的画像ID，从而圈定出这批用户。该功能的需求用例如表3一2所示。表3一2通过用户标识创建人群用例说明（4）人群画像用户圈选出了一批用户群体之后，那么就会有相应的用户群体出现。然后点击用户群体名称，就会进入到这一群体的人群画像页面，结果显示在图3一3当中。人群画像主要有部分默认的模板，所有模板当中均有相应的各种维度标签，使用者可以直观地看到该群体的相关标签数据的统计结果。图3一3人群画像基本属性展示页面原型若默认的模板不满足需求，用户可以修改人群画像。通过自定义属性，选择所需的标签用于最终的展示，该功能需求用例如表3一3所示。表3一3人群画像用例说明3.3.2标签管理用户画像团队需要在系统内定义标签如图3一4，包括标签名称、所属层级、数据来源、数据类型、标签区间划分。用户团队可以通过标签管理功能实现对标签的增、删、改、查功能。图3一4标签管理页面原型该功能的需求用例说明如表3一4所示。表3一4用户标签管理用例说明

4系统设计4.1总体设计4.1.1概念设计目前接入画像系统的产品每日新增数据量己经达到TB级别，因此该系统从一开始就是基于大数据架构来设计的。本文实现的画像系统整体架构如图4一1。本系统架构设计时也参考了著名的Labmda架构，将离线批处理与实时流计算相结合，形成相互补充。图4-1整体架构图4.1.2逻辑设计一方面，根据数据计算时效性，可将系统分为离线计算与实时计算。离线批处理主要用于数据量较大、要求精度高的标签计算上，而实时流计算则用于对时效要求高，允许存在一定误差的标签。尽管计算有所分离，但是实时计算值也会纳入到标签存储层的数据库当中，也即是和离线计算使用相同的数据库，从而就能确保标签存储层的数据始终相一致。另一方面，根据数据流方向，可将系统分成六层，分别是数据来源层、数据采集与存储、标签计算层、标签存储层、画像应用层。下文将对各层进行详细介绍，确定每层涉及的技术平台选型，并结合使用场景解释对应选型的原因。4.2数据来源与采集4.2.1数据采源画像的数据来源包括用户数据、服务端的业务数据、以及外部系统产生的补充数据。其中，用户数据是指用户在使用客户端的时候产生的行为数据，这里的客户端包括了移动APP、PC客户端和WEB端。这部分数据是构成用户画像的基础，通过对这部分数据可以挖掘出用户的设备属性、位置属性、用户触发的各种行为事件。服务端的业务数据是指用户在使用客户端的过程中在服务器端生成的数据或者是一些和业务相关的定义数据。这类数据包括用户注册信息、消费订单类信息、关注关系、社交关系等数据。这类数据往往需要验证其真实性，因此不适合直接采用客户端数据，而是利用业务服务端的数据，尽可能保证数据的真实性。客户端产生的用户行为数据与服务端的业务数据，基本上覆盖了画像系统的原始数据来源，这两部分是画像系统里头最重要的数据。除此之外，还可以从外部系统获取数据，例如本系统中的视频类别标签是从识别系统接入，由内容识别系统对视频内容进行分类所产生。4.2.2采集数据采集是指从业务方数据源获取原始数据的过程。这阶段获取的数据包含了结构化数据，例如通过业务协议上报的业务数据，业务方数据库的数据，也包括了非结构化的数据，例如来自业务方的日志。本文实现的画像系统，数据采集阶段包括移动端SDK数据上报，业务方数据库数据同步，内容识别系统推送的实时流数据。（1）客户端上报客户端上报是指用户所使用的客户端程序主动按照约定的协议向服务端上报数据。其中，客户端包括App端，PC端和WEB端。由于目前移动端的占据了大部分流量，因此这里主要介绍移动端的数据上报方式。移动端上报主要通过埋点实现，埋点方式可分为全埋点与代码埋点。两种常见埋点方式比较，见表4一1。表4-1埋点方式对比本系统中使用了代码埋点的方式，由数据分析师与产品运营团队确定业务事件埋点。相比全埋点，针对特定业务事件埋点可以大幅减少无用数据，可有效减轻后续数据运算的压力，另外，因为针对特定事件，可以突出用户在关键业务上的行为轨迹，使得后期数据分析比全埋点简单。这种方式的缺点是客户端开放工作量增多，新增需求需要版本更新才能实现。除了以上两种方式，目前还有可视化埋点与服务端埋点。对于可视化埋点，一些较为复杂的业务场景，很难通过页面圈选的方式实现，因此本系统没有使用可视化埋点。服务端埋点则是指将埋点配置放在服务端，客户端通过读取服务端配置来上报数据。这种方式更新埋点事件不需要客户端发版，灵活性更高。服务端埋点与代码埋点将是本系统将来改进的一个方向。在本系统中，客户端根据埋点通过HTTP协议上报数据，在服务端部署带负载均衡的接收服务用于数据接收，如图4一2。图4一2SDK上报数据流程接收服务会直接往Kafka消息队列里头写入数据。然后实时计算将直接消费该队列进行运算，而离线服务则消费队列然后写HDFS文件。Kafka队列将会在下一节进行介绍。此处利用了Kafka作为消息中间件，保证实时计算与离线处理读取到的数据源是一致的。（2）服务端同步服务端同步是指从业务方数据库同步数据到画像系统的数据仓库。正如前文所述，服务端数据跟业务密切相关，而且经过服务端验证，数据质量和可靠性都比客户端高，是构建画像系统非常重要的数据来源。本系统中的服务端数据来自业务方数据库，使用Apache下的开源数据传输工具sqoop来同步数据库到画像的数据仓库。Sqoop是Apache下一款用来在Hadoop与关系型数据库RDBMs之间传输数据的工具。其使用场景如图4一3所示，sqoop可以从RDBMs导入数据到HDFS，数据经过清洗、计算后将一些汇总的报表数据再导出到RDBMS。图4一3Sqoop传输数据数据传输是10密集型操作，为减轻数据同步对业务方数据库的影响，同步时间放在业务低谷时段进行，例如每日凌晨。业务方数据库如果是主从结构，则可利用从库进行数据同步。上述的sqoop主要用于离线数据同步，画像系统中包含了部分实时计算标签，例如近10分钟内用户观看的短视频类型，这类实时数据对于推荐系统做实时推荐非常重要。而这类数据来源也主要来自业务方，但利用sqoop同步数据的方式显然不能满足时效性。因此，本系统针对实时数据采用了Apache下另一款开源消息系统Kafka。4.3数据仓库分层设计在本系统中，将数据仓库模型分成了三层，分别是ODS层、DW层、画像应用层，见图4一4。图4一4数据仓库分层示意图ODS层：该层是原始数据层，将不同来源的原始数据，本系统中则是SDK上报的文件数据以及从业务方同步过来的业务数据，经过一些初步的ETL流程进入ODS层，作为原始数据保存。例如ODS通过采集SDK上报的数据，存储了某个用户一天下来，在APP内的各类点击事件。DW层：DW层主要存储从ODS经过ETL和进一步运算的汇总数据。其中DW又可分为DWD与DWS。DWD是指经过计算，提炼出来的业务明细数据。而DWS则是经过业务计算，按一定维度聚合的汇总数据。例如DWD层存储了某个用户观看短视频的明细记录，即将ODS层的点击事件转化为观看记录明细。然后DWS层则保存了该用户这一天下来观看短视频的总时长。画像应用层：该层主要存储了数据产品的结果数据。在本系统中，通过DW层的用户观看记录，可以提炼出该用户喜欢的短视频类型，例如搞笑类视频，则可以提炼出用户偏好的画像标签，该标签则可以存于画像应用层。应用服务例如WEB段则可以直接读取该层的数据用于展示。4.4标签结果数据存储设计用户数据经过计算层之后得到标签结果数据，这些数据将会存入标签结果存储层。该层存储了来自离线与实时运算后的最终结果，为上游服务提供查询数据。该层在整个系统的位置如图4一5。图4一5标签存储层画像应用层又分为计算结果存储以及标签结果存储。计算结果是指计算层直接输出的结果数据，而标签结果则是根据标签定义转化为区间的结果。例如“近7天日均在线时长”标签，计算结果是40分钟，而标签结果则是“30分钟到1小时”。画像应用层对外提供数据时，会根据业务的需要来提供两种不同的结果。例如使用方是推荐系统，他们需要的更可能是40分钟这个确切的数据，由他们再次进行加工。而如果使用方是产品或者运营，他们的在分析用户群体时，往往只需要知道一个大致的区间范围就足够。因此本系统的画像应用层同时存储了计算结果和标签结果。4.5画像WEB服务设计画像层WEB服务主要承担画像相关功能查询以及系统内部管理的功能。在技术上，采用微服务架构，使用docker进行容器化管理，技术实现上主要使用了Java技术栈，架构如图4一6所示：图4一6画像应用服务架构用户请求首先经由Nginx集群分流，到达webserver应用，webserver不承担真正的业务服务，而是类似网关，将请求通过rest转发到具体的服务模块，由具体模块处理业务细节并最终返回结果给Webserver。

5系统实现5.1标签计算功能实现标签计算是整个画像系统运算量最大的部分，目前每日新增的ODS层数据量达到TB级别。因此离线标签计算每天累计要处理过百TB的数据。离线运算主要采用了HivesQL与spark相关的技术栈。利用spark分布式计算，在集群中分发计算程序而不是移动数据，然后再将结果聚合，实现海量的数据计算。标签计算里包括了标签的原始值计算以及区间值计算，其流程如图5一1。图5一1标签计算流程图标签原始值计算是指数据从ODS到DW层以及从DW输出到HBase的过程。这阶段将计算结果保存起来，作为标签区间值计算的原始数据。例如，业务定义了‘旧均观看时长”标签，“10分钟到20分钟”是其中一个区间。原始值计算的则是用户日均观看时长，例如巧分钟，其对应的就是“10分钟到20分钟”这一区间。标签区间值转换是指将指标的数值结果转化为特定的标签区间。该功能允许业务方自己设定不同的区间取值生成标签，流程如图5一2所示。这样一份原始值就可供多个业务方复用，而不需要重复计算。图5一2标签区间值计算例如年龄标签定义了如图5一3的标签，区间范围：“19到25岁”，那某个用户年龄是23，符合该区间，则在标签转换时会将原来的数值转换为“19到25岁”这一标签区间值。从数值到区间的转换是通过编写Spark程序实现的。图5一3定义年龄标签区间标签开发者首先在画像WEB服务中定义标签的数据源、名称、数据类型、标签区间以及标签转换的规则。当Dw层计算完成后，计算结果会输出到HBase，spark程序通过读取HBase的标签结果与标签定义中配置的区间规则进行匹配，最终将转换后的标签区间值输出到Elasticsearch，供WEB页面查询使用。5.2人群画像实时查询功能实现目前整个画像系统收录的用户量在数亿级别，使用传统的RDBMS查询压力很大，而选用NO一SQL类数据库则很难实现维度的聚合。因此如4.6.2节所述，画像系统选用了Elasticsearch作为搜索引擎实现人群画像实时查询功能。该查询功能流程如图5一4：图5一4人群画像查询由页面发起请求，WEB服务器根据请求路由到ES查询服务，ES查询服务根据人群画像的筛选条件拼装Elasticsearch的查询请求，查询画像的Elastiesearch集群，最终得到结果后原路返回。页面展示效果如图5一5、5一6所示：图5一5人群画像结果展示1图5一6人群画像结果展示2人群画像中展示的维度可由用户自行选择定义，结果是由查询引擎实时按各种维度聚合，这给用户带来了很高的自由度，用户可以根据业务需要进行定制化的人群分析。Elasticsearch使倒排索引提供了近实时的查询，画像的Elasticsearch集群目前有20多个节点，使用别名关联多个索引实现查询。使用别名关联多个索引的好处是可以控制每个索引的数据量，有利于后续的扩展。

6系统测试6.1个人用户画像查询功能测试6.1.1当前用户画像展示测试用例测试目的：用户登录画像系统首页，默认展示该用户的个人用户画像标签数据。测试步骤：（l）在浏览器中打开用户画像网站。（2）输入帐号及密码，登录画像系统。测试输入：输入个人帐号及密码。测试结果：如图6一1所示，登录画像系统后，页面自动展示该登录用户的画像标签数据。图6一1个人用户画像标签展示图6.1.2单个用户画像查询测试用例测试目的：通过指定帐号查询单个用户的个人用户画像标签数据。测试步骤：（l）登录用户画像系统。（2）进入查看用户标签菜单（3）输入用户ID查询该用户标签。测试输入：输入测试用户ID。测试结果：如图6一2所示，页面展示该用户的画像标签数据。图6一2个人用户画像标签展示图6.2通过用户标识创建人群功能测试测试目的：通过上传一批用户ID，创建这批用户的人群画像。测试步骤：（l）登录用户画像系统。（2）进入“通过一方ID创建”菜单。（3）填写人群名称，选择标签库，用户标识。（4）上传用户ID文件并提交。（5）选择该人群名称查看该人群的画像。测试输入：人群名称、标签库、用户标识、用户ID测试结果：如图6一3所示，填写人群画像相关信息并上传用户ID文件并提交。图6一3通过用户标识创建人群展示图如图6一4所示，人群创建成功后通过点击该人群名称进入查看该人群的画像数据。图6一4人群画像数据展示图6.3标签管理功能测试测试目的：通过页面创建标签，定义标签的运算规则。测试步骤：（l）登录用户画像系统。（2）进入“标签体系”菜单。（3）点击“新增标签”按钮，填写标签名称创建新标签（4）选择标签，点击“编辑计算规则”按