基于大数据实时分析平台研究

2020-06-18黄亦男上海大学

数码世界 2020年4期

黄亦男上海大学

引言

随着互联网的高速发展，用户的很多消费逐渐从线下转移至线上，比如购物、网课、生活缴费等等，在大量的用户数据中，包含着很多运营商感兴趣的内容。从运营的角度看，对于一个app 或者网站，一般都需要统计和汇报每天的登陆量，点击量，消费情况，用户身份，以及每个产品的用户分布情况等，这些数据有些可以通过业务子系统轻易的获取，但更多的需要结合用户行为记录分析才能知道，比如活跃用户变化趋势等。从产品的角度，则会关心用户对某个产品的粘度，大概多少用户登陆后会产生实质的商业行为，体验是否良好，新功能使用情况是否符合预期等。从战略决策角度，数据能够给决策者提供很多参考，哪个地区的潜在用户量最高，则有必要在这个地区开辟业务，哪个渠道转化的新用户数最客观，则应该增加这个渠道的广告投放，比如头条、微信等。数据越准确，越不会造成决策的失误，可以有效的把成本转化为利润。

那这些数据是如何获取的呢？想象在一家互联网公司，产品经理需要知道昨天成功注册后购买某产品并且留下评论的人数、男女比例以便决定下一步的放量计划，首先他需要联系用户系统的负责人获得相关的用户ID，然后通过用户ID 在订单表获取产品ID，最后使用这2 个ID 在社区系统搜索评论。一次普通的查询由于要横跨3 个业务子系统，关联的id 还需要查询日志才能获取，使得查询成本非常高。而产品经理由于职业特殊性，不可避免地会有经常查询这些用户行为的需求，这些工作需要各子系统开发人员的配合才能完成，无形中增加了企业内部大量运营成本。

为了提高数据获取效率，目前互联网公司通过自研大数据实时分析平台来满足各种数据查询的需求，平台通常满足数据统一上传管理，友好的服务界面以及提供了高效的查询接口，平台可以实时提供数据查询，产品经理可以迅速调整策略，比如根据实时运营情况，是否增发红包，或者使用其他营销方式。

1 设计

1.1 数据处理过程

数据处理一般分为数据采集，数据传输，数据建模/存储，数据查询和可视化处理5 个步骤。

1.1.1 数据采集

前端数据采集一般通过埋点的方式，将基本信息比如手机型号、ip、位置等和业务信息打包后，通过特定的端口向服务器发包，通常这类埋点会在app 初始安装时获得用户的允许，基本信息的埋点称为全埋点，覆盖在前端框架中，业务埋点又称为代码埋点，与业务会有耦合。后端数据采集可以直接从日志中获取信息，前提是把需要上报的数据提前打好标签，这类采集传输可靠，信息更加完整。

1.1.2 数据传输

数据传输一般是各公司自研的部分，后端需要处理客户端打点请求，由于网络传输过程会增加额外的数据开销，将数据反序列化后需要对数据做清洗，过滤以及去重，只留下有分析价值的内容，并且还要考虑整体系统的可靠性和可用性，所以一般自研系统会优先定义框架，再设计加工逻辑。

1.1.3 数据建模/存储

区别于传统的关系型数据库存储，大数据的存储按照时间轴分布，采用多维读的列示存储，比如按用户id，浏览过的页面，点击过的按钮等结构存储。本文使用Kudu/Parquet 作为存储引擎，类似于Hbase，MongoDB 等nosql 数据库，可以实现一次导入，多次查询，这样设计的原因是大数据平台主要为了查询统计历史数据，没有修改场景，同时这些加工后存储的数据与正常的业务数据隔绝，即不会影响正常业务的运行。

1.1.4 数据查询和可视化处理

数据查询的输入，一般仍然采取通用的SQL 查询方式，将SQL语句翻译为查询引擎可以识别的查询语言，比如Hive 使用Antrl 实现了对SQL 词法和语法的解析，将SQL 转化为MapReduce 任务。查询输出可以根据公司产品需求，设计为图表、趋势图、油表等表现形式。输入和输出都需要企业做图形界面做可视化支持。

1.2 架构设计

本文针对数据传输，存储和查询，为大数据实时分析平台做了以下的后端架构设计。

1.2.1 数据接入子系统

Nginx 作为可靠的反向代理服务器，可以用来接收客户端的打点请求，通过http 的方式，根据声明不同的RestAPI 调用后方的Extractor。

Extractor 监听Nginx 转发的请求，提供对请求处理的主逻辑，并作为kafka 生产者插入消息队列，数据收集器根据订阅的消息topic 来处理对应的请求消息。

1.2.2 ETL 子系统

ETL 子系统一般会和业务强关联，没有开源软件可用，这一层需要对数据做基本的清洗，过滤以及去重，比如系统间互相调用后留下的中间id 和http 头部多余的报文，路由留下的内网ip，保留的信息除了业务数据外，还有很多用户相关联的信息，比如UserAgent 中保存的端末信息，app 版本号，地域信息等。

1.2.3 存储子引擎

Kudu 是cloudera 开源的运行在hadoop 平台上的列式存储系统，拥有Hadoop 生态系统应用的常见技术特性，与imapla 集成或spark 集成后（dataframe）可通过标准的sql 操作，使用起来很方便。KUDU 同时兼备HDFS 批处理以及HBASE 的实时写入更新的能力，底层使用类似parquet 的列示存储结构，Tablet 是负责Table表的一部分的读写工作，Tablet 是有多个或一个Rowset 组成的，其中一个Rowset 处于内存中，叫做MemRowSet，MemRowSet 主要是负责处理新的数据写入请求。DiskRowSet 是MemRowSet 达到1G 刷新一次或者是时间超过2 分钟后刷新到磁盘后生成的，实际底层存储是是有Base Data（一个CFile 文件）、多个Delta file（Undo data、Redo data 组成）的和Delta MemStore，其中位于磁盘中的Base data、Undo data、Redo data 是不可修改的，Delta Memstore 达到一定程度后会刷新到磁盘中的生成Redo data，其中kudu后台有一个类似HBase 的compaction 线程策略进行合并处理。本文将Kudu 保存当前实时的数据，即1 小时内所有的用户请求数据，Parquet 保存所有的历史数据，定时的数据转储shell 程序每小时运行一次。

1.2.4 查询引擎

Impala 是Cloudera 公司推出提供对HDFS、Hbase 数据的高性能、低延迟的交互式SQL 查询，Impala 对内存的要求很高，和Hive 类似都基于MPP 查询引擎，使用纯内存计算，效率高容错性低，一般Impala会和hdfs同机部署，利用内存计算的特性，避免网络消耗。同时，为了尽量使用内存计算的特性，避免产生不必要的IO，Impala会在源表存储部分冗余数据避开表间的连接。Query Engine 是一个翻译者中间件，将查询的SQL 语句或command 翻译为查询引擎所能识别的查询语言，类似Hive。

2 实验

2.1 实验数据

实验数据采用某电商企业过去2 年的运营数据，其中包括客户端操作、日志、订单数据、注册数据、以及其他业务数据。

2.2 实验任务

本文使用自研的ETL 系统来清洗数据，目的是能够快速通过时间维度和用户维度来获取用户相关的信息，并分别保存在用户行为表和用户表中。尽可能使用少量的表，可以最大化利用Impala 内存计算的特性，减少表连接。用户行为表中会存放用户在什么时间什么地方用什么渠道处理了什么业务，用户表则用来保存用户本身的属性。