作为数据产品经理，你需要知道这些技术知识

在数据分析领域下，总会被提及诸如SQL、Hive，甚至Hardoop、Druid、Spark等这些技术上的词汇。那么作为一名数据领域的产品经理，听着这些不是很常见的产品知识，又应该具备怎样的技术知识呢？本文主要从“用户行为数据“角度介绍一整套的技术架构以及相关的技术要点。

阅读指南

1. 受众人群：数据型产品经理、数据运营等初级岗位；
2. 阅读收获：初步了解用户行为分析数据类产品的大致架构、掌握4大环节的数据技术要点。

一、用户行为分析系统

本文将从数据采集、数据接入、数据分析、数据展示等4个重要地方，分别介绍相关涉及的技术知识。这一节主要介绍整体概念。

1.1 概念

用户行为分析系统其实是指用户使用产品过程中，把产生的 行为数据 通过分析而成的报表工具。此类数据区别于业务数据，大多为公开、有权限获取的，比如一些设备信息、埋点信息等。

目前行业较为人熟知的有百度统计、友盟、神策等，而使用此类产品的主要是数据分析师、数据运营和产品经理等。目的是为了统计埋点、基础指标分析（如PV、UV）等，从而对产品进行体验优化或运营推广。

（样例：数据分析系统图）

1.2 数据系统框架

1.2.1 数据采集

一般用户使用产品的时候，所填写的信息会经由业务系统加密储存。而行为数据是不会经由这些系统收集，而由专门的采集工具进行采集，这就是 SDK 。

1.2.2 数据接入

因为SDK采集的数据是非结构化的，所以数据都是以原始数据的方式按批次定期或实时上传。服务端通过接口对这些数据进行解析、加工处理，初步形成结构化的日志数据，并在数据库按表进行存储。

1.2.3 数据分析

当数据解析并存储之后，即可通过离线和实时两大方式进行分析。部分指标计算量大且实时要求不高，则会采取T+1、T+2（即第二天、第三天出结果）等离线计算方式。

有些指标时效性要求高，如关键指标、日常运营活动（如双十一）等，就需要较高的实时计算方式，以便监测表现。两大方式采用的系统框架会有所差别，后面详解。

1.2.4 数据应用

当使用结构化数据进行分析时，就需要可视化的图表进行展示，不管哪种方式，基本就是通过报表网站平台进行展示。比如折线图、表格、柱状图等，甚至还需要提供更多维的分析指标支持用户自主查询。

二、数据采集层（SDK）

2.1 何为SDK？

2.1.1 定义

SDK是指一种软件开发工具包，是数据采集的必备工具，英文为“Software Development Kit”。

本质上它其实是一些接口API的文件集合，为某个应用程序提供服务。也可以理解为应用开发者通过接入这些文件，并调用里面的相关接口，即可采集相应数据。

因为SDK的大小一定程度上会影响应用程序性能，所以尽量轻量处理，占内存大多在几百K和几兆之间。

2.1.2 作用

不同业务下，SDK的应用性质是不同的。常见的就有数据行为类SDK、功能服务类SDK以及广告营销类SDK等。

其中功能服务类就是指应用通过接入SDK增加一些特殊的产品功能服务，而广告营销类则指专门做消息推送、营销推广等业务的SDK。而本文仅介绍数据行为类SDK。

2.2 SDK类型

主要分为客户端SDK和服务端SDK，客户端SDK是指这类SDK接入在应用的前端，比如iOS、安卓等。而服务端SDK是指接入在后端，更多的在后台底层。

2.2.1 客户端SDK

• iOS SDK：顾名思义，就是以iOS操作系统进行开发的SDK工具包；
• Android SDK：同样是以安卓操作系统进行开发的，可应用在所有安卓类软件中；
• H5 SDK：指以网页操作系统为生的SDK，可应用在web网站、H5网页、公众号（功能实质是H5开发）等；
• 小程序 SDK：小程序是这两年新兴的产品应用，依赖于不同的软件平台。所以需要基于不同的平台进行开发，比如微信小程序、支付宝小程序、百度小程序等，同时还需要分iOS和Android两大系统进行开发。

2.2.2 服务端SDK

• 定义：服务端的sdk具体通过后端上报数据，即业务应用采集到数据后，通过自身的服务端传到大数据系统的服务端，即“业务服务端-数据服务端”，而非客户端SDK的“业务服务端-客户端SDK-数据服务端“。
• 类型：由于每个业务的状况不同，开发语言都不是唯一的，所以针对服务端类型的SDK都会基于不同的语言提供相应的开发版本，包括Java SDK、Pyhon SDK、PHP SDK、C SDK等等。

2.2.3 小结

不同的用户有不同的业务诉求，客户端和服务端各有优缺点，主要取决于业务诉求。整体而言，大多数产品应用使用客户端SDK居多。

2.3 作用

SDK最大的任务就在于采集数据、识别数据和上报数据。

2.3.1 采集数据

由于SDK采集的数据较广，涉及种类较多，主要分几类：

1. 设备数据：具体指终端硬件设备，如电脑设备、手机设备等，如果是手机可以具体到手机类型、品牌、网络环境等。如果是电脑，则是电脑型号、浏览器类型等；
2. 程序数据：具体指应用程序的数据，比如是APP，则是此APP应用程序内的基础数据，包括APP版本、渠道、安装时间等等；
3. 埋点数据：具体指用户在某应用程序触发产生的行为数据，比如点击哪个页面、停留时长、页面曝光、启动时间等等。主要是基于业务考虑进行埋点设计。

2.3.2 识别数据

由于采集的数据属于原始数据，且SDK层基于原始数据的真实性和唯一性，基本是不会做结构化的逻辑处理，即不会做数据加工。所以SDK在这里最多会进行识别数据的处理。

• 识别用户ID：不管数据如何原始、混乱，有一个关键的就是需要识别产生这个数据的“用户”是谁，所以就有用户ID的说法。但这个用户ID不同的产品和业务，各家不尽相同，生成ID的算法也不同，有人用操作系统的IDFA和IMEI生成设备口径的算法，也有人直接用软件的账户ID作为唯一用户ID,这个是没有规定的。 例子：“userid”：321990ddwsadnkiouf78hjh”；
• 识别程序ID：因为SDK是支持多个程序独立使用的，但是数据最终是在同一个服务端和数据库，那么就需要做应用程序之间的区分。这个时候就有应用ID，每个独立应用分配一个ID，且是唯一的。至于如何分配生成，也是看各家的业务诉求，并没有唯一标准。例子：“productid”：“12321321321dasdasdas33213”

2.3.3 上报数据

由于SDK在嵌入应用程序前，就已经打通与服务端的接口并进行上报。所以此时SDK是已经界定了一系列的上报逻辑，以及需要传什么数据。

• 原始数据：其实就是一条条原始数据记录，每条数据附带那一刻采集的诸多信息，包括用户ID、设备数据、埋点数据等，但这些数据并不是每条都必带的，取决于当时的环境是否有提供这些信息.
• Session：指某一次节会话信息，主要为了记录用户行为习惯。因为每个用户操作习惯、时长都不同，有可能突然不再操作，又可能隔几分钟在操作，对于这样的情况需要基于业务场景的诉求，定义这些session逻辑，并分别创建不同的sessionid去分割。比如停止操作几分钟后、程序退出或切换至后台等是否需要定义。
• Cookie：主要是网站使用的一种识别用户的数据集，一般存储在用户本地终端上，以便于用户在不同时间操作时都可以快速调用且识别为同一个设备用户。与session区别在于，Cookie存储在浏览器内，数据量有限且相对没那么安全。

三、数据接入存储层

从这一环节开始，就进入服务端运作的流程。这个环境涉及数据接入、解析和存储等3方面。

前面提到，SDK只会采集原始数据（就好比绿色无污染的食品），而这些非结构化数据其实不利于管理和使用的。这时候就需要在接入后进行数据解析、清洗加工再扔进数据库。

3.1 接入层

这一层是服务端与SDK端之间联系的一层，所有的日志数据就是通过这个接入层进行获取，但获取成功后是需要返回“成功”的信号给到SDK，证明是畅通的没有报错。

但大多数情况下，由于上报的数据较多，尽管是按批次上报，也是会出现类似“排队”的情况，一个一个去等完成再返回数据效率十分之低。所以这时候就会借用“redis”手段。

redis：Remote Dictionary Server 远程字典服务，实质是一个key-value存储系统，一门开源的数据库技术。简单来说它就好像一个副服务器，当主服务器接收到诸多数据后，都可以扔到这里来，让它慢慢接收，并且无需等待返回“结果”信息，主服务就可以告知SDK我这边“ok”了，请放心。

3.2 逻辑层

这一层的作用实际是指对数据进行解析、清洗加工处理，即日志数据，因为数据的存储是要按照明确的数据库和表的结构来存储。

日志数据例子：{“userid”:”3213213hdhdhasjoiewq3321″,”productid”:”dadsadsad2321321″,”mobile”:”samsung:SM-G9008V”,”country”:”CN”}

3.3 数据存储

提到数据存储，就必须接触到数据库，那么对于这样的用户行为数据，又会使用什么样的数据库呢？目前关于数据库，主要分为关系型和非关系型数据库。

3.3.1 关系型数据库

平常所接触到诸如Oracle、Hive、PG等，其实这些都属于关系型数据库，本质上都是建立在SQL（结构化查询语言）的基础上，所以最大的特征就是结构化。这些适合大量的数据查询，统一提供增、删、改、查、排序等多种查询。

数据库类型有很多，以下仅列举常遇见的3种：

3.3.2 非关系型数据库（NoSQL）

此类数据库的存在是出于性能、速度等方面考虑，主要是因为关系型数据库涉及数据较大、结构复杂，一些简单、体量小的存储和查询不适合在这样的数据库进行运作，所以才有这样的数据库。

上面也提到，其中redis就是这么一种，以及MongoD、Memcache。

• 优点：这类数据库优点在于足够快、结构单一、数据集中等；
• 缺点：结构相对没那么规范清晰、会有重复冗余；

3.3.3 数据库表

在使用SQL查询的时候，一个关键地方就是需要知道表结构。所谓的表结构就是数据表与表之间的关系，以及具体表字段的含义。所以数据库表的设计十分重要，对后续SQL查询计算、机器运行性能、任务执行等方面有很大的影响。

（样例：usertable_01）

存在在数据库中的就是一张张这样的表，通过SQL语句查询可以快速获取所要的数据结果。所有原始数据经过解析清洗之后，就会像这样以结构化的形式进行存储，以便于管理和使用。

表设计：系统有诸多数据指标，而对于产品或运营而言，就是定义各个指标的统计逻辑和场景。那么对于技术者来说，除了输出固定的查询语句之外，还需要进行合理的表设计。

所谓的表设计，就是根据指标体系把结构化的数据分拆成多张数据表，并进行有机关联，从而提供合理的统计输出。

比喻需要固定了解每天使用程序的用户的某些设备信息（手机型号、品牌、网络环境等），就可以放在同一张表，而无需跨表关联影响效率，同时这样的设计有利于性能。但具体如何设计，主要是基于业务的指标体系考虑。

四、数据分析层

在大数据分析开发当中，有诸如Spark、Hive、Hbase这些数据库或计算引擎，但这些都基于一套核心的系统，就是 Hadoop 。要开发一套完整的大数据开发系统，大多数技术都是从Hadoop中获取能力。

4.1 核心框架Hadoop

4.1.1 定义

Hadoop是大数据开发所使用的一个核心框架，是一个允许使用简单编程模型跨计算机集群分布式处理大型数据集的系统。很多关于大数据开发的技术模块都基于此基础上，覆盖了数据传输、数据存储管理、数据计算等诸多方面。

4.1.2 作用

使用Hadoop可以方便地管理分布式集群，将海量数据分布式地存储在集群中，并使用分布式并行程序来处理这些数据。

4.1.3 架构

一套完整的Hadoop框架涉及数据传输、存储到计算等环节，并在这些基础上提供种类较多的组件，为快速搭建大数据分析平台提供成熟的基础能力。

• HDFS ：能够提供高吞吐量的分布式文件系统。
• YARN ：用于任务调度和集群资源管理。就好比是一个项目的PMO，产品提需求，根据现有的资源、时间、成本等快速分配任务，调动机器资源来支持。
• MapReduce ：基于YARN之上，用于大型数据集并行处理的系统。也是初代的计算引擎。Hive就是基于这个系统之上。
• Flume ：一个日志收集系统，作用在于将大量日志数据从各数据源进行收集、聚合，并最终存储。
• Sqoop ：用于底层数据传输的工具。
• Kafka ：一种高吞肚量的分布式消息队列系统。
• Hbase ：一个可伸缩的分布式数据库，支持大型表的结构化数据存储，底层使用HDFS存储数据。
• Hive ：基于Hadoop的数据仓库工具，可以将结构化的数据文件映射为一张张数据库表，并提供简单的SQL查询功能，可以将SQL语句转换为MapReduce任务运行。更多支持离线任务。
• Spark ：一个快速通用的Hadoop数据计算引擎，适用于实时任务。同时也应用于机器学习、流处理等。

4.2 计算类型

4.2.1 离线计算

离线计算就是在计算开始前已知所有输入数据，输入数据不会产生变化，且在解决一个问题后就要立即得出结果的前提下进行的计算。时间上按天来算，就是T+1、T+2甚至T+7等，主要看指标的时效性优先级要求。

4.2.2 实时计算

实时计算是相对离线而言，就是指查询条件不固定、目标不明确，但又对数据需求的时效有较大要求，所以需要实时查询进行分析。

优点是自定义条件多，能满足多维分析的数据需求，缺点是考验查询引擎，由于处理数据量大短时间输出结果会有所偏差，且等待时间长。

4.3 计算引擎

按照目前行业的发展，关于计算引擎已经发展到了第4代，第1代是MapReduce，而在这里重点介绍5种。

1. Hive ：前面介绍到这种查询引擎，其实它属于第2代流行的引擎，目前仍有大量企业使用这个，主要是十分成熟，能满足大部分的基础需求场景。但由于数据量大，依赖不少组件，导致数据量一大查询速度就相对较慢。
2. Spark ：目前十分流行的第3代查询引擎，能够承担批数据处理，和Hive兼容，相比它查询速度更快一些，扩展性高。
3. Flink ：是最近流行的第4代查询引擎，主要是同时支持流数据和批量式数据处理，相较于Spark有较大得提升。但目前技术相对新一些，应用得还不算多。
4. Druid ：一种高效实时、迅速的分布式数据查询系统，它采用不是前3者依赖得hadoop框架。主要支持聚合查询、实时查询，且灵活。但有些数据分析指标不一定能支持。
5. Impala ：一种数据查询引擎，优点在于高性能、低延迟（准实时）。相比hive绕过底层MapReduce,所以更快。同时也支持复杂的交互式查询。

整体来说，不同的业务场景采用不同的计算架构，没有优劣之分，只有合不合适。

五、数据应用层

很多时候，大家常接触的都是数据可视化平台，比如常见的BI报表平台、数据大屏等，都是充分使用了数据可视化技术进行呈现。

那么实现这些效果，又用到了哪些技术手段？

5.1 数据平台

在介绍可视化技术前，不得不先说数据报表平台，因为这是大多人常接触的，如那些图表、网络图谱、3D城市模型等。抛开单个而言，它是一个平台化的产品。

目前第三方应用较多的就有百度统计、阿里、友盟、神策等。

（样例：报表平台）

（样例：可视化屏）

5.2 可视化技术

实现数据可视化，除采用前端的基本技术外，还包括相关的图形技术组件

5.2.1 web前端基础技术

大多数情况下，前端使用的技术框架离不开这关键的3种语言，即CSS、HTML、JavaScript。

1. CSS ：英文全称Cascading Style Sheets，是一种文本样式的语言，主要针对文本的位置、色值、字体、字号等方面的控制。
2. HTML ：英文全称 Hypertext Marked Language，即超文本标记语言。主要是通过指令控制文字、图形、动画、声音、表格、链接等形式的文本。
3. JavaScript ：对于前端而言，不管是文字、还是视频，还是其他图形，都是一种文本。都可以通过以上2点实现。而JavaScript的作用就是在这些“文本”基础上增加动效功能，也就是我们产品常说的“交互”，这方面的功底体现了这个产品能给用户提供多好的体验效果。

5.2.2 可视化技术应用

可视化技术主要是针对数据层面而言的一些技术手段。因为这方面的技术已经十分成熟，且大部分场景下的需求样式是比较固定的，所以这样的技术大多开发成为组件，并普遍开源。而这里则主要介绍前端常见的3种。

组件：英文名Component。所谓组件其实就是指一种可用“复用”的功能模块。因为产品开发到了一定程度，很多时候设计较为接近的，那么开发往往会基于效率开发成一套可复用的组件，这样每次遇到同类型的需求，即可快速调用。

比如一个柱状图，可以定义相关的位置、图形形状及布局。通过复用组件化之后，就可以任意改变里面的参数，比如色值、大小、字号等，比较灵活，也省事。

1. Echarts ：一个基于 JavaScript 实现的开源可视化库，能够应用在PC、移动终端等设备上，分别提供常规的图表（折线图、柱状图之类），地理数据的地图，社交关系型的图谱、旭日图，以及一些特殊的图形。Echarts提供了大量丰富的数据可视化图表，并支持较高定制化，是前端在进行可视化开发中使用较为普遍的工具库；（网址：https://www.echartsjs.com/zh/index.html）
2. D3.js ：全称为Data Driven Documents，本质是一个 JavaScript 的函数库，通过它来实现数据可视化的，所以它实际是一个通过函数操作数据的文档。与JavaScript不同的是，D3把一些复杂流程进行精简成几个的函数样式，能够够快实现更酷炫的图形可视化，在原有常规的图形可以做得更多元化。（网址：https://d3js.org）
3. three.js ：简单来说，three其实就是指3D的意思，听到3D就知道是做立体模型的，同时它同样基于JavaScript而建立的，所以就有three.js。通过它可实现三维图形的需求，比如一些城市建筑模型、人体模型等。但是由于目前还不算十分成熟，国内相关资料较少，英文文档的学习成本较高。（网址：https://threejs.org/）

5.3 应用产品

1. 数据分析型：百度统计、友盟、神策、Growing IO等
2. BI报表类：Tableau、Quick Bi等
3. 可视化类：阿里云Data V、百度Sugar等

总结

1. 一整套完整的数据系统，涉及方方面面。参与其中的PM，承担责任也不同。每个人应该基于核心工作，做相关的延伸，不一定都需要掌握。
2. 一名合格的数据分析型产品，数据指标设计、数据库、SQL查询、计算引擎，都是必须掌握了解。
3. 其实各大厂都有一套自身的数据技术体系，多关注CSDN、腾讯云或阿里云等社区，会有所裨益。

推荐阅读：《大数据平台演进之路 | 淘宝 & 滴滴 & 美团》https://cloud.tencent.com/developer/article/1506317

注：本期的文章涉及较多技术术语，建议反复阅读。以上的系统框架图仅帮助阅读理解，并不是完整的架构图。

 

作者：A.D，世界TOP50强公司产品一枚；公众号：吾某

本文由 @A.D. 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。