大数据技术基础 22 讲（下）

迷南。 2023-01-16 06:20 73阅读 0赞

### 文章目录 ###

# 12 | Spark 与 Flink 的爱恨情仇（上） #

前面我们相对完整地介绍了 Hadoop 架构，并且在上一讲讲解了 Hadoop 中的计算框架 MapReduce 的基本思想。我们已经知道，MapReduce 的主要功能就是并行计算，但是它也不是十全十美的，MapReduce 高成本的硬伤使得它已经不能很好地解决新时代的问题。

这一讲我们所要介绍的 Spark 就是由 MapReduce 思想衍生出来的新的分布式计算框架，但是它又不仅仅是一个 MapReduce 的升级版。接下来就让我们看一下，Spark 到底是一个什么样的工具。

**什么是 Spark**

打开 Spark 的官网，我们看到的第一句话就是对 Spark 的定义：**Spark 是用于大规模数据处理的通用分析引擎**。当然，原文是英文的，这句是我翻译过来的。这句话非常简洁明了地讲解了 Spark 的功能，一个是**针对大规模数据**，一个是**通用分析引擎**。

让我们简单回顾一下 Spark 的发展历程。

在 2009 年，加州大学伯克利分校的 RAD 实验室（AMP 实验室前身）推出了 Spark 框架，并表明 Spark 是一个类似 MapReduce 的通用并行框架，**可用来构建大型的、低延迟的数据分析应用程序**。实验室的研究人员在使用 MapReduce 时发现它在迭代计算和交互计算上效率低下，于是开始设计 Spark。很快，Spark 在一些任务上的效率就已经比 MapReduce 提升了 10 倍以上。

这里需要提到 Spark 的一个特点，那就是**低延迟**。从一开始 Spark 就瞄准了低延迟这样一个目标，这也为它后来能够进入工业界并广泛地应用于生产奠定了基础。

在 2013 年的时候，Spark 项目加入了 Apache，并在 2014 年的 Gray sort Benchmark 比赛上全面超越了 Hadoop 拿下了当年的冠军。这个比赛是对 100TB 的数据进行排序操作：

*  Spark 使用了 206 台 EC2 机器在 23 分钟内完成了操作；
 *  而 Hadoop 的 MapReduce 则使用了 2100 个机器并耗费了 72 分钟。

在后来的一段时间里，Spark 在互联网公司的大数据架构中逐渐成为**主流计算框架**。

**Spark 的特色**

在 Spark 的官网上我们也可以看到，Spark 的特色有五个方面。

（1）**高速**

Spark 使用了最新的 DAG 调度方案，查询、优化和物理执行引擎，在批处理和“流”处理上都表现优异。这里，我给“流”处理加了引号，在后面我们会解释为什么这里会加一个引号。在官方给出的示例中，在 Spark 框架中执行逻辑回归运算要比 MapReduce 快一百多倍。

（2）**易用**

Spark 提供了 80 多种高阶操作，构建应用更加方便。Spark 还提供了多种语言支持，使用 Java、Scala、Python、R 甚至是 SQL 都可以非常容易地编写 Spark 程序。

（3）**通用**

如下图所示，Spark 除了提供计算框架以外还整合了 SQL、流式处理，以及机器学习算法库和图操作算法库。其中 Spark SQL 支持使用 HiveQL 和 Spark 进行交互。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70]  
（4）**多平台支持**

Spark 本身是可以独立运行的，当然，它也可以运行在 Hadoop、Mesos、Kubernetes，甚至是云平台上。它还支持访问各种不同的数据源，比如 HDFS、HBase、Hive、Cassandra 都是可以的。

（5）**内存化**

这点在官网上没有，但是很重要。在运算流程上，Spark 和 MapReduce 基本上是一致的，但是有一个很大的不同就是中间结果的存储：

*  **MapReduce 所有的中间结果都是保存在磁盘上**；
 *  **而 Spark 的中间结果是保存在内存中的**。

这你也就明白了为什么 Spark 的运算速度要快那么多，内存起到了很重要的作用，同样的，由于使用内存存储， Spark 处理的数据规模相对来说就会小一些，但是幸运的是现在内存也不是很贵，公司也都愿意多花点钱从而节约点时间。

**Spark 基础**

**RDD**

RDD 是 Resillient Distributed Dataset（弹性分布式数据集）的简称，它是 Spark 的一个基本数据结构，也是**Spark 最核心的数据结构**。

Spark 在运行时，会将 RDD 分割成不同的 Partition（分区），并把这些分区投放到不同的计算节点下面，进行并行运算。实际上，Spark 程序的整个生命流程，就是对这些数据的处理，创建 RDD、转换 RDD、调用 RDD 操作计算各种结果等。所以，理解了 RDD 的各种操作基本上就了解了 Spark 的核心，对这部分感兴趣的同学可以寻找更多的资料来进行学习。

**两种操作**

在我们的运算中，通常包含两种操作，一个是**Transformation（转换操作）**，一个是**Action（行动操作）**。这两个操作最大的区别是 Spark 对它们的**处理逻辑**是不一样的。

对于转换操作，比如说 Filter（过滤），这些操作是对 RDD 本身的一些操作，其结果是数据的规模发生变化，而数据的类型或者说内容不会发生变化。

对于这种操作 Spark 是进行**惰性运算**，也就是说 Spark 只是记录下这个操作，而不会真的去执行它。只有当 Spark 遇到了行动操作，才会把之前的转换操作进行统一的处理，我们可以认为行动操作是一些产生结果的操作，它的输出是**非 RDD 对象**。这么做的好处是减少了不必要的存储开销，毕竟 Spark 是使用内存来进行中间结果的存储。

这么说可能有点迷茫了，我们写两行代码再来解释一下。

val RDD1 = sc.textFile("data.txt")
    val RDD2 = RDD1.map(x => x+1)
    val RDD3 = RDD2.filter(lambda x: "Python" in x)
    val RDD4 = RDD3.reduceByKey((x,y) => x + y)
    
    val RDD5 = RDD2.filter(lambda x: "Java" in x)
    RDD5.count

根据这几行代码，我们可以得出如下图的一个执行逻辑。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 1]

*  首先，我们从文件中读取数据，这时候形成 RDD1。
 *  后面两步执行了 map、filter 和 reduceByKey 操作，map 操作给所有值加了 1，而 filter 操作过滤出带有 Python 的数据，reduceByKey 对 x 和 y 进行相加。这几个操作都属于 Transformation 操作，输出的结果都仍然是 RDD。
 *  而最后一行执行了 count 操作，count 就是一个 Action 操作，它返回的是 RDD5 中的数据元素个数。

如果 Spark 对每一步都认真执行，那么第一步读取文件后，就已经把全量的数据存储在了内存中，但实际这并没有什么用，当 Spark 根据上面的执行逻辑分析了运算流程之后，会对 Transformation 操作进行整合，直到遇到 Action 操作才真正去进行运算。不知道这样解释，你有没有明白一些。

**两种依赖关系**

由于在 Spark 中流转的数据通常都是**RDD 格式**，从我们的代码可以看出，每一步生成的 RDD 都会依赖于上一步的 RDD，所以，具备上下联系的 RDD 产生的关系被称为依赖关系。

*  根据不同情况又分成**窄依赖关系**和**宽依赖关系**两种：
 *  窄依赖关系指的是生成下级 RDD 不会引起数据在不同的分区（Partition）之间进行迁移（Shuffle）；
 *  宽依赖指的是要生成的 RDD 依赖于多个分区的数据，很明显这会导致处理速度的下降。

接下来，我们再来看一下 Spark 整体的运行架构。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 2]  
如上图，这是一个不太完整的运行架构，但是我们可以借此大概了解一下其中的概念。

当我们编写了一个 Spark 程序，也就是一个 Application 时：

*  这个 Application 以 Action 操作为界限，被划分成多个 Job；
 *  一个 Job 以 Shuffle 为界限被划分成多个 Stage；
 *  而一个 Stage 又会分成多个 Task，Stage 的划分和调度是由 DAGScheduler 来负责的，而 Task 由 TASKScheduler 来进行调度。

这些调度的终极目标就是**根据依赖的关系找出开销最小的调度方法**。最终，这些任务被分派到不同的 Worker 上进行运算。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 3]  
我们再把视野放得稍微高一点，来看看运行架构。如上图所示，这里的 Driver 也就是我们在代码中常说的 main 函数，当它被执行时会创建一个 SparkContext 对象，这个对象会与服务器中的 Cluster Manager 进行通信，从而申请任务所需要的资源。当成功获得资源之后，它的 Task 会被分配到 Worker 的执行器中，从而处理对应的运算。

**开发时需要注意的问题**

正是由于 Spark 所具备的这些特性，在开发的时候也会引起一些问题。

（1）**数据倾斜**

由于 RDD 数据会被分配到不同的分区，存在常见的问题就是**数据倾斜**，某些分区分配了过多的数据，而另外的一些分区则分配了很少的数据，这会导致一些节点的运算过于缓慢。

（2）**过多地使用 Action 操作**

由于 Action 操作会引发真正的运算，并对数据进行缓存，所以，如果 Action 操作太多会造成内存的大量消耗，从而占用过多的资源。

（3）**宽依赖过多**

前面我们讲到，宽依赖会引发 Shuffle，将不同 Partition 的数据迁移到同一个 Partition 中去，所以这个操作也会消耗很多时间。

这几个问题是我们在开发一个 Spark 程序时需要注意的问题。

# 13 | Spark 与 Flink 的爱恨情仇（下） #

在上一讲中，我们着重介绍了 Spark 的概念与架构，在这一讲，我将为你介绍一个新的计算框架——Flink，以及它与 Spark 有着怎样的联系与不同。

在介绍 Flink 之前，我想先介绍两个概念：批处理与流处理。

**批处理与流处理**

**批处理**

所谓的批处理，从字面意思理解，就是把一整块数据切分成一小块一小块，每一个小块称为一批。把一个小块数据分配给一个计算节点进行运算，这种情况称为批处理。

所以说，批处理针对的数据是一个**有限集合**，也就是**有界数据**，这些数据在处理之前就已经存储在我们的源数据地址，当我们要进行处理的时候直接从这个数据集进行读取就可以了。

**流处理**

与批处理相对的，流处理的数据是**无界的**，数据就像一条河里的水源源不断地从上游流到计算框架中，我们不知道数据的总量是多少，也不知道什么时候结束。更发散来考虑，当雨雪天气，水流可能激增，而干旱时节水流可能枯竭，这就是流处理所应对的情况。

我们最开始讲过的 Hadoop MapReduce 就是一个批处理计算框架，而 Spark 和 Flink 是混合计算框架，既可以进行批处理计算，也可以进行流处理计算。带着这两个概念，我们来看一下什么是 Flink。

**什么是 Flink**

我们在 Flink 的官网可以看到对 Flink 的精准描述：

> Apache Flink 是一个框架和分布式处理引擎，用于在无边界和有边界数据流上进行有状态的计算，Flink 能在所有常见集群环境中运行，并能以内存速度和任意规模进行计算。

其实 Flink 的产生时间跟 Spark 差不多，最早出现在 2008 年由柏林理工大学发起的研究项目中，并在 2014 年把代码捐赠给了 Apache 基金会。

同时，Flink 的功能与 Spark 也基本一致，都属于**大数据计算框架**，那么我们来看一下 Flink 有什么特色。

**Flink 的特色**

**1.数据皆流**

在 Flink 的构建思想上，**把所有的数据都看作是流式数据，所有的处理方式都是流处理**。对于事实上的批数据，只不过当成一种特殊的数据流，我们称之为有界流，也就是说这个流数据有开始有结束，我们可以等着这个流获取完全后统一进行计算。

对于在我们公司中真正的流数据，我们将其称为无界流，这个数据只有开始，没有结束。只要我们的业务还在运转，用户还在浏览我们的 App，查看、下单、支付数据就会源源不断地传送过来。处理这种数据，不光是汇总起来就完事了，很多时候还需要注意**数据的顺序**，比如说正常情况下肯定是先点击，再下单，最后支付。如果数据的顺序搞错了，已经有了支付，但是没有点击和下单，那这数据计算起来就乱了套了。

我们说 Flink 就是为了流处理而生，自然而然，Flink 的创建者也为流处理做了很多优化。在数据接收方面，Flink 与 Kafka 有异曲同工之妙，都是基于**事件驱动**的，也就是数据随来随处理，而 Spark 实现的流处理实际上是微批处理，只是把数据块划分的更小。同时，Flink 还有精确的时间控制和状态以保障一致性。

**2.多平台支持**

同 Spark 一样，Flink 可以作为单独的服务进行部署运行，也可以与 Hadoop、Mesos、Kubernetes 集成部署。

**3.高速**

同样的，Flink 也使用了内存作为计算的中间缓存。在前面我们已经知道，批处理由于是已经累积下来的数据，所以需要大吞吐量，而流处理是来即处理，需要的是低延迟。在 Flink 中，使用了一种缓存块机制来保障两种计算的速度。当缓存块的超时时间设置为 0，那么只要有数据就立即处理，适合处理无界数据，而当缓存块超时时间设置为无限大，那么就要等着数据结束才处理，这样更适合有界数据。

当然，在具体的工作中，开发人员可以**根据业务场景对超时时间进行配置，以获取最佳状态**。而这些中间存储，首先是会存在内存中，如果内容不够用再开启磁盘存储。

**Flink 的组件架构**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 4]  
与 Spark 类似，Flink 也实现了用一整套组件来支持整个体系的运转，如上图所示。

*  最底层是部署相关的组件，包括了支持本地单机部署、集群部署，以及云上部署的组件。
 *  Core 核心层，是 Flink 实现的最关键组件，包括支持分布式的流处理运算，各种分配和调度系统都在这一部分实现，为更上层的 API 提供基础服务，这也为用户的方便使用奠定了基础。
 *  API 和 Lib 层，提供了流处理和批处理计算的各种 API，以及针对特定的计算支持库，比如 FlinkML 就是和 SparkMlib 类似的机器学习库，而 Gelly 是和 GraphX 类似的图处理计算库。

看起来，Flink 与 Spark 似乎是没有什么太大的区别，那么下面我们来总结对比下 Spark 和 Flink。

**Spark VS Flink**

**1.核心实现**

在核心实现方面：

*  Spark 主要使用 Scala 语言编写而成；
 *  而 Flink 早期是使用 Java 进行编写的，但是后期的很多更新也使用了 Scala 语言。

Scala 语言对大数据处理更加友好，但是做程序员的同学都知道，使用什么样的语言来编写程序其实对整个体系架构的影响并不是很大。

**2.编程接口**

在编程接口方面，Spark 和 Flink 就更加相似了。二者都提供了对各种编程语言的支持，包括 Java、Python、Scala 等，都可以用来编写 Spark 或者 Flink 程序。

**3.计算模型**

计算模型，或者我们也可以叫作**设计理念**，这是引发两者前进方向的最大区别点。

前面我们已经介绍过了，Flink 是把所有数据都看作流来进行处理，所以它本身对**流式数据**有着非常优秀的计算性能，在流计算方面做了大量的优化。

而 Spark 虽然也是混合计算框架，但是 Spark 的设计理念是**批处理**，也就是所有数据都是批数据。在处理流数据的时候使用了模拟的办法，把数据分割成更小的批来进行处理，从而模拟流式处理，所以在 Spark 中的流处理，我们也可以称为**微批处理**。所以，Spark 的迭代和优化只能无限接近真流处理，而无法称为真流处理。但是对于 Flink 则没有这样的情况。

有一种说法很妙——“我们可以认为 Flink 选择了‘batch on streaming’的架构，不同于 Spark 选择的‘streaming on batch’架构”。

当然，早期的 Flink 由于针对流处理进行的优化，也使得它在批处理方面仍然没有 Spark 性能良好，这也就引出了我们下面要介绍的流批一体技术。

**流批一体**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 5]  
在 Flink 早期的时候，虽然说在思想上是把批处理当作流处理的一种特殊形式，但是实际上在处理的时候仍然是分开实现的，不管是 API 层还是 Core 层的 Runtime 都没能够实现完全统一。用户在进行流处理和批处理的时候要分别进行程序的编写，非常麻烦。

但是在 Flink 的 1.9 版本，Flink 开始完善流批一体，Flink SQL 率先实现了流批一体语义，使得用户只需学习、使用一套 SQL 就可以进行流批一体的开发，大幅节省开发成本。

但是只调整 SQL API 并不能解决用户的所有需求。一些定制化程度较高，比如需要精细化的操纵状态存储的作业还是需要继续使用 DataStream API。在常见的业务场景中，用户写了一份**流计算作业**后，一般还会再准备一个**离线作业**进行历史数据的批量回刷。但是 DataStream 虽然能很好地解决流计算场景的各种需求，但却缺乏对批处理的高效支持。

所以，在最近的两年内，Flink 主打流批一体的升级，从上面的架构图变化我们可以看出来，在最新的 1.11 版本，不管是 SQL 还是 DataStream API，都已经可以使用同一套编写规范，而只需要进行简单的选择就可以进行批处理或者流处理。

阿里巴巴在 2019 年初收购了 Flink 创始公司和团队 Ververica，开始投入更多资源在 Flink 生态和社区上。到了 2020 年，国内外主流科技公司几乎都已经选择了 Flink 作为其实时计算解决方案，我们看到 Flink 已经成为大数据业界实时计算的事实标准，在阿里巴巴公布的迭代计划中，Flink 会支持更加智能的流批融合，甚至是自动切换。

随着流批一体技术的实现，使用 Flink 的公司不再需要维护两套架构，部署两套代码，维护成本会进一步降低，我觉得 Flink 会变得更加普及，甚至是取代 Spark 成为新一代主流计算框架。

# 14 | 带你聊一聊标准化数据挖掘全流程 #

在上一个模块，我对大数据架构中最主要的工具进行了介绍，从数据获取，到数据存储，再到数据传输，最后是数据的计算。不知道你是否还记得我们在第一讲中说到的大数据的特点：数量庞大、种类众多、生产速度快以及价值密度低。公司都是追逐利益的，我们的公司兴师动众，耗费大量资源构建这么一套大数据体系，一定是期望这些数据能够给公司带来更大的价值，提升公司的收益。**如果说大数据开发是在搭建戏台，那么接下来的数据挖掘与数据分析就是要开始唱戏了**。从这节课开始，我们就进入大数据挖掘与分析的模块，看看如何充分攫取数据中的价值。

**什么是数据挖掘**

数据挖掘这个词或许我们经常会见到，但是到底什么是数据挖掘？有人觉得数据挖掘就是**各种算法**，有人觉得数据挖掘就是各种**数据的计算**。数据挖掘确实是一个涉及面非常广的词语，在我看来，数据挖掘更**偏向于一种过程**，而不是一种名词或者一个结果，比如说我们要为新闻网站上的新闻标注分类以方便用户查阅，当然可以让编辑或者运营人员人工地进行标注，也可以借助数据挖掘去发现分类与新闻的内在联系，从而为新闻自动标注类别。

所以所谓的**数据挖掘就是以数据作为研究的对象，从数据中寻找价值，获取知识的过程，至于说机器学习算法，或者数据的统计分析，这些都是手段**。

具体到一个公司的业务中，除了上面说的为新闻标注类别，以下这些都可以借助数据挖掘过程来分析和解决：

*  借助历史天气数据预测未来天气变化；
 *  在异常交易行为中发现羊毛党；
 *  为自媒体内容评判好坏；
 *  预测一个商品在未来的流行趋势；
 *  ……

既然数据挖掘是一种过程，那么我们接下来就来看一下在实际的数据挖掘流程中，都分成哪些步骤。

**数据挖掘的流程**

在我刚开始工作的时候，虽然说也是处于数据挖掘的一环，但实际上我对数据挖掘的整体工作并没有什么概念。只是领导告诉我，某个指标需要计算一下，某些数据需要统计一下，我们要训练一个什么模型，我们需要做到多少的准确率等等。

随着工作经验的增长，我渐渐熟悉了这些环节，同时明白了数据挖掘的步骤，开始能够独立处理一个问题。实际上，在数据挖掘领域早已有比较成型的方法论，其中所列出的步骤与我的实际工作不谋而合。在这里，我们就介绍一个被称为 CRISP-DM 的数据挖掘流程方案，并通过一个小例子来实际感受一下，数据挖掘的流程是如何开展的。

CRISP-DM（cross-industry standard process for data mining），翻译过来的意思是**跨行业数据挖掘标准流程**，正如下图所示，在这个数据挖掘标准流程中包含了六个主要步骤，不过这六个步骤在整体上循环往复，但并不是按照单纯的顺序执行，其中还包含了很多关系，接下来我们就分别来介绍一下。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 6]  
**1.理解业务**

以我们在拉勾教育做数据挖掘为例。为了保持内容的独创性，以吸引更多的用户购买，总编希望作者写的东西能够与一些主流网站上的内容存在一些差异，如果说每写一篇稿子，就让运营挨家挨户地去对比，那一定是费时费力，并且对比的效果很差，因为运营也没办法把那么多内容都看一遍，于是总编向我们发起了一个需求：比对作者写的文章与主流网站的文章是否存在一定的独创性。

我们收到了需求，接下来就要摩拳擦掌准备开始工作了。但是不要心急，这里说的工作可不是立马上手分析数据、写代码。作为一个合格的数据挖掘工程师，第一步我们需要理解业务，把业务逻辑搞明白。

需求有了，但是这个需求貌似并不明确。首先怎么定义文章具有独创性，这**并不是通过技术手段可以量化的指标**，我们就需要与总编沟通，确定如果两篇文章的相似度低于 5% 就认为是有独创性的。

之后我们可以把这个问题定义为一种**文本抄袭检测**，但是这个文本抄袭检测与一般的文本抄袭检测是否又有一些区别呢？比如说我们需要检测的是独创性，那么我们对比的粒度是否需要比较细；某些重点的文本是否需要一定不相同；一些引用和概念性介绍是否需要刨除；对于同一个作者的内容该如何处理等等。这些业务独特的需求我们也需要了解清楚，才能方便我们后面的处理。

理解业务看起来很虚，但是却是非常重要的环节，**不要觉得理解业务是浪费时间的事情**，认识清楚我们要完成的业务目标，能够为我们后面的提升效率、优化效果带来非常大的帮助。反之，如果你还没搞清楚业务的细节就上手开发，很可能所做的结果与业务的需求存在偏差，这时候就浪费了更多的时间，严重的还会给公司带来很大损失。

**2.理解数据**

在我们搞清楚业务需求之后，下一步就是要理解我们的数据。针对业务需求，我们需要什么样的数据，而我们公司中又有什么数据？哪些数据是一定要有的，哪些数据可以提升效果，但不是必需的？又有哪些数据是可有可无的？这些问题你需要在这个环节搞清楚。

比如说我们上面的“独创性”需求，至少需要拿到的是拉勾作者写的文本和需要对比的网站上的文本，除此以外，是否可以获得诸如作者名称、发布日期、文章分类等数据，针对细节需求，是否有充足的术语库供我们使用呢？这些数据是否存在一些错误，或者缺失？这些也都是需要考虑的问题。

如果说数据是完美的，那么工作起来自然简单，然而数据挖掘所需要解决的不仅仅是一个算法问题，而是在当前的条件下，在不完善的，甚至有错误的数据条件下，如何更好地输出结果。因此，理解数据也同样重要。如果对于某些需求，现有的数据无法支撑，那么还需要返回到理解业务的步骤，重新讨论业务需求。

**3.准备数据**

弄明白了我们的业务需求，搞清楚了我们手头的数据，接下来我们就要开始准备数据了。

在这个环节，我们需要针对具体的情况，也就是拿我们业务和数据本身的问题去做针对性的准备，把原始的数据经过清洗加工，转变成我们在后面的建模环节所需要的状态。对于我们“独创性”的需求，文本数据自然是不能够直接进行运算的，我们可能需要对文本做一些分词、关键词提取、过滤停用词的工作。如果要使用词向量，还需要训练一个词向量表。对于非文本数据，也需要检查异常值或者缺失值，看是否需要进行丢弃或者补全的操作。

**4.构建模型**

如果说，我们前面的步骤都已经有条不紊地完成了，那么在构建模型这一步将非常顺畅。构建模型所解决的基本上都**属于技术问题**了。面对我们的问题，如何选取对应的技术方案、使用哪种算法来解决我们的问题、如何优化以提升效果是构建模型阶段需要解决的问题。

我们常见的问题通常可以转化成**分类、聚类、回归**和**关联分析**四种问题，进而选择对应的算法构建模型。比如说我们的文本抄袭检测：

*  可以转化成分类问题，把**相似和不相似看作是二分类**，把文本数据转化成数值数据，使用分类算法构建分类模型；
 *  可以把它转化为一个聚类问题，把**文本进行聚类分析**，根据聚类的距离来判定是否抄袭；
 *  可以把多种方法组合起来使用。

很多时候，我们需要根据经验来选择使用何种方案，如果你还不能很好的判断，那么就有必要多做一些试验来对比效果。

**5.模型评估**

模型训练好了，我们还需要对模型进行评估，来确认我们的模型是否确实符合我们的预期、能够满足我们的业务需求、解决我们的业务问题。

从数学原理方面，我们有诸如准确率、召回率、F1 Score 等指标来评判一个模型的效果。同时，在公司中，很多时候我们还需要与业务人员共同进行人工抽样来确认效果。比如说我们构建好了检测文本相似性的模型，只有一个准确率 90% 的概率往往还不能直接使用，我们的效果还需要得到业务方，也就是总编的确认。不仅如此，由于我们训练使用的数据跟线上的数据肯定存在一些区别，在模型上线之后，仍然需要定期花时间来评估线上的效果。如果发现问题，可能需要对问题进行分析，看是否是个例还是大面积的问题。

**6.部署上线**

如果总编检查完了结果，并对我们工作的效果非常满意，那么我们就可以对模型进行部署上线了。

在部署的时候，我们更多地需要考虑一些工程问题。因为有时候我们的模型效果虽然没问题，但是**运算速度可能太慢**，或者**需要太多的资源**，而我们的服务器可能无法支持，或者我们的数据量太大处理不过来，又或者我们需要把服务集成到 App 上面，让用户在无网络时也可以使用等等。

**7.下一次迭代**

我们的抄袭检测服务终于可以上线了，然而数据挖掘流程并没有结束。可能是为了**快速上线**，也可能是由于**当前的某些条件不具备**，我们的第一版服务还存在着很大的优化空间，同时来自线上的日志收集也为我们准备了很多问题案例。在经过了一段时间之后，我们可能需要重新回到构建模型阶段，或者理解数据阶段，甚至是理解业务阶段，对我们的项目进行优化和迭代。

所以说，**数据挖掘流程是一个循环往复的流程**，虽然说按步骤进行了划分，但是这些步骤并不是绝对分隔的，每个步骤之间都有着千丝万缕的关系。

# 15 | 让你一看就懂的数据挖掘四大经典算法 #

上一讲，我们从流程上介绍了数据挖掘，而在整个数据挖掘实施的流程中，数据挖掘算法可能是我们的算法工程师最关注的环节。在常见的数据挖掘过程中，通常会用到什么类型的算法，不同的算法又应对什么样的问题？在实际工作中遇到的问题，该如何转化成算法可解决的问题呢？带着这些疑问，让我们开始这节课吧。

**数据挖掘算法有什么特色**

首先我们来看一下“算法”的定义：

> 算法是为求解一个问题需要遵循的、被清楚指定的简单指令的集合。

如果是没有接触过数据挖掘或者机器学习的同学，说到算法想到的可能是查找、排序、二叉树、动态规划等等。这些算法主要用于我们的数据在存储和运算过程中，通过精巧的设计计算过程达到优化时间复杂度和空间复杂度的目标，而且这些算法的结果是确定的，实施某一个算法，就可以获得对应的效率提升。

单纯从“算法”的定义来看，我们在数据挖掘中所使用的算法与其他的算法也没有什么区别，同样是**为了求解问题而形成的指令集合**。但不同的是，数据挖掘中的算法目标是要寻找存在于数据之中的知识，而且这些知识是不确定的，因此算法的结果也无从而知，可能会获得好的结果，也可能会获得不好的结果，在算法计算完成后我们还需要通过一些辅助方法来评估结果。

**数据挖掘算法四大类**

既然我们知道数据挖掘的算法是为了寻找数据中潜在的知识，那么数据挖掘的算法通常都有哪些类型呢？如果说按照这些算法所解决的问题来进行划分，大致可以分为分类问题、聚类问题、回归问题和关联分析问题。下面我们就来详细看一下。

**1.分类**

春天来了，我带着儿子在公园里闲逛，看到花圃里形状各异，五颜六色的小草和花朵，儿子撒开我的手蹲在那里仔细研究起来。儿子指着其中一朵黄色的花问，“爸爸，这个是什么花？”我定睛一看，这个简单，“这是郁金香。”“这个是什么花？”我回答，“这个红色的也是郁金香。”连续问了几个之后，他指着旁边的一朵说“这个也是郁金香。”

我们接着往前走，走到一片玉兰前面，儿子又问我“这树上的是什么花呀？”我说“这是玉兰花。”

上面这个人类幼崽的学习过程就是分类算法所处理的过程。**分类算法就是对已经确定好结果的数据进行学习，从而对未知的新数据进行分类的算法**。在这个例子中，我为部分数据提供确定的结果，儿子通过观察它们的特征和区别来对新的花朵进行判断，从而区分出一朵花是玉兰花还是郁金香花。我们前面说，数据挖掘的算法结果是不确定的，我们怎么知道学得怎么样呢？

再看看我儿子的行为，如果他没有见过其他的花，当我们看到一棵桃树的时候，他可能会指着桃花说“这个长在树上的花是玉兰花。”这就出现了**欠拟合**，他只通过判断是长在地上还是长在树上就决定了花的类别，这个时候我们需要告诉他更多的特征，比如说玉兰的花瓣更宽，更长之类的。

另外一种情况，他可能会指着一朵粉色的郁金香说“这个是粉色的，这个不是郁金香。”这时候就是出现了**过拟合**，他把条件限制得太死，这时候我们应该给他找更多郁金香，让他明白，颜色并不是判断郁金香的主要特征。

**2.聚类**

我们接着往前走，这时候儿子又问我“这个是什么树叶？那个是什么树叶？”我看着这些叶子，虽然它们确实不一样，可是这也超出了我的认知，我也不知道这是什么树呀。我只好跟儿子说，我也不知道这是什么树叶，不如我们把你捡的树叶分一分，然后从每一种里拿一片出来，等我们回家查查这是什么树叶。于是我跟儿子一起蹲在那里，对着之前捡的一兜树叶挑挑拣拣。这些带锯齿边的是一堆，那些小圆片是一堆，还有这种三个尖尖的是一堆，如此种种。

**与分类不同，聚类算法只需要有一些数据，但是事先并不知道数据属于什么类别，通过对这些数据的学习，希望能够通过数据的差别寻找到潜在的类别，从而把已有的数据划分成几个类别，至于说这个类别具体是什么并不清楚**。

**3.回归**

从公园回家，还没进门我就已经闻到了饭菜的香味。我跟儿子说：“我们先吃饭吧，吃完再查树叶。”儿子却不同意，说：“我不饿，我不饿，我不想吃饭。”我媳妇这时候冲了出来，“饭都不爱吃，你都已经比别的小朋友矮了，真不知道你能长多高！”这个问题。我们或许可以使用**回归算法**来分析一下，当然我们首先需要有一些数据，假设孩子的身高可能跟父母身高、孩子的性别，等等有关系，那么我们获取一百组父母的身高和孩子的身高、孩子的性别、孩子吃多少饭、喝多少奶、有多少运动量等等数据，就可以构建一个线性方程，通过已有的数据把系数算出来，然后把我自己的数据输入到这个方程中就可以算出一个数来了。

**回归的计算其实跟分类类似，都是预先已经有了特征数据和结果数据，只不过分类的结果是一个确定的标签，而回归的结果是一个连续型数值。很多时候，我们甚至可以在回归方法和分类方法之间进行转化。**

**4.关联分析**

正当我还在思索孩子能长多高的时候，我媳妇又说：“他不吃饭那就冲点奶粉喝吧，奶粉快喝完了，你去某东上买点。”于是我打开了某东的 App，搜索了奶粉，正当我准备下单的时候，下面弹出了一个优惠信息：买了该奶粉的人还买了 xxx 尿不湿，组合购买可省 xx 元，然后是一个组合链接。于是我问媳妇，“尿不湿还够不够，需不需要买了，这个一起买能便宜一点。”接下来，就是我买了一桶奶粉，两包尿不湿，通过关联分析，某东成功把我本次下单的客单价从 1xx 提升到了 2xx。

**关联分析是从已知数据中寻找相关关系的一类算法，比如说我们这里的奶粉和尿不湿，只是找到这样的销售搭配关系，并把它推荐给正在购物的人，就可以提升业绩了**。在商业分析，推荐系统，以及用户行为分析中，经常会用到关联分析方法。

**不同算法适合的情况**

**1.分类算法**

分类算法对数据的要求比较高，需要一定的**数据量**以及**事先的标注结果**，通常是要根据学习过去已有的数据，对新的数据做出**类别预测**，比如说给新闻分类。

常见的分类算法有最近邻算法 KNN、决策树算法、朴素贝叶斯、人工神经网络、支持向量机等等。

**2.聚类算法**

聚类算法也是要去划分类别，但是聚类算法对数据的要求会低一些，并不需要事先标注好的结果，而是通过**算法模型来判定**。聚类算法通常是针对已经确定的数据集合进行划分，比如说对于用户分群，有一堆用户的基础信息和行为数据，我们不太确定这些用户到底有多少类别，又该如何划分，这时候就可以使用聚类的方式。常见的聚类算法有 k-means 聚类、DBSCAN 聚类、SOM 聚类等等。

**3.回归算法**

如果你有一些数据，其中要去预测的结果并不是一个标签，而是一个连续数值，可以用一个函数近似地模拟特征与结果的关系，那么就考虑使用回归算法。比如说你知道广告投入和产品销量存在着一定的关系，通常是广告投入越大销量越高，你可以用过去几年的广告费用和产品销量构建起一个函数方程，然后把明年的广告预算放进去，就可以得到一个销量的预测值。常见的回归算法有线性回归、Logistic 回归等。

**4.关联分析**

关联分析主要用于寻找两个项之间的关系，并给出关联规则，比如我们提到的尿不湿和奶粉的关系，关联分析可能是需要最少人工调整的方法。常见的关联分析算法有 FP-Growth 算法和 Apriori 算法。

**一个现实问题如何转化**

只是了解了不同的算法适合解决什么问题还不足以很好地完成工作。因为在实际的工作场景下，总是存在着这样或者那样的现实问题。举个例子，比如说我们的电商网站中有很多评论信息，产品经理希望能够从评论中识别到那些不好的评价，并进行深入的分析，从而根据评价来优化商品或者服务。

**第一步，我们需要找到那些“不好的评价”，这可以认为是一种文本的情感识别**，所谓“不好的评价”就是带有负面情绪的评价，他可能会说产品不好，或者服务不好，甚至是破口大骂。面对这样一个问题，自然而然我们想到把这个问题转化为分类问题，把评论分成正面情绪、负面情绪和无情绪三种类别。但是需要注意的是，分类需要有事先标注的结果，那这个标注必须由人来完成，如果没有人来标注怎么办呢？首先考虑自己来标注，这个方法最简单直接，但是耗时很多。如果不想自己标注，那看看在产品形态和数据层面是否有可以利用的信息？比如说有些电商网站除了写评价以外还会让用户进行打分，一般来说不好的评价往往伴随着更低的打分，那么我们可以认为这个分值是一种弱化的标注，虽然没有直接标注来得准确，但是在没有直接标注的情况下也不失为一种方案。

如果没有可以利用的标注信息怎么办呢？那这个时候可能就要考虑用**聚类方法**，我们是否可以先对评论朝着这三个维度进行聚类，在获得了聚类之后再对新数据进行分类呢？当然，这里可能需要对情感相关的特征进行抽取，不然可能聚类到别的维度上面去了。

在实际的工作中，像这种问题可能会经常遇到，除去优化算法本身，还有很多的事情需要去思考、去解决。我们的目的是解决业务中的问题，提升业务指标，如何更好地利用这些算法，需要因地制宜。

**总结**

这一讲是一个基础的数据挖掘算法介绍，可以说数据挖掘中的算法就是在模拟人的决策过程，从而获取数据中的知识。就像我在文中写的小例子，我观察到刚出生的孩子在观察世界时的一举一动其实与这些算法有着类似的过程，或者说这些算法本身也就是从人类认知世界的过程中抽象出来的。

数据挖掘及其算法是大数据版图中一块重要的组成部分，收集来的数据到了这一步才开始真正发挥价值。通过算法，我们可以把原本价值密度低的数据处理成高价值的知识，相当于是一个萃取的过程。

# 16 | 计算机视觉 VS 自然语言处理，你选哪个？ #

在上一讲中，我们有提到一个算法“人工神经网络”，虽然这是一个专业名词，但是近来想必很多不是做技术的同学，甚至不是互联网行业的同学都对这个词有所耳闻，就算没有听过人工神经网络，“深度学习”这个词也一定听说过。

在我们日常的数据中，包含了大量的文本或者说自然语言和图像数据，这些数据最贴近人们的认知，但是**如何让机器理解这种非结构化且非标准的数据**，一直是算法专家想要突破的难题。

其实从很早之前，就有很多人在研究这两个方向，但是主要**局限在制定规则方面**，比如说自然语言处理的乔姆斯基范式，期望通过总结语言规则来进行处理。但是语言没有统一的标准，要想穷尽里面的规则是不可能的。这些年，随着人工神经网络和深度学习的爆发式增长，在自然语言处理和计算机视觉方面有了非常大的突破，这节课，我们就来看一下，如今这些领域可以做些什么事情。

**人工神经网络**

上节课我们说过，机器学习的目标看起来就是**仿照人认知事物的方式**，学习其中的规律并应用到数据当中。那么能不能直接去模仿人的大脑呢？在我们的大脑中充满了无数的神经元，在对神经系统进行研究时，**模仿神经元的生物机理而产生的计算模型就是人工神经网络**。

神经元由**细胞体**、**树突**和**轴突**三部分构成：

*  细胞体主要为神经活动提供能量；
 *  树突接收从其他神经元传来的信号；
 *  轴突将神经元产生的信号传出。

一个神经元和另外一个神经元联系传递信号的结构是**突触**，需要注意的是，在传递信号的时候并不是从一个神经元直接完全地传递到下一个神经元，信号具有强弱，只有当接收的信号累加到足够的强度才会进行下一步传输。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 7]  
据此产生了最简单的人工神经网络，也就是只有一个人造神经元的神经网络，像下图展示的，这个神经网络有一个输入层和将输入单元与输出单元相连的一组连接。假设我们使用这个网络进行图片分类，输入层中的每一个输入可以理解成一部分图像数据（或者说图像特征），输入单元把每个输入和中间连接上的权重相乘，并把乘积总和传递给输出单元。在传输中间使用一个称为激活函数的函数进行运算，它通常是一种阶跃，当输入的值达到某个阈值的时候就会输出 1，而没有达到阈值则都输出 0。每输入一张图片，算法就会对获得的结果与标注的结果进行比较，然后去调整连接权重，因此，只要训练样本够多，总能选到合适的权重，这就是人工神经网络的美妙之处。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 8]  
**深度学习**

关于神经网络的研究在 1960 年代就已经有了，但是像我们上面讲的简单人工神经网络顶多算是模仿了一个神经元，比起我们复杂的大脑可以说还相差十万八千里。很容易想到的就是，能不能把若干个神经元堆叠起来，就像我们的大脑一样，上百亿个神经元组成一个庞大的神经系统呢？想法虽然好，但是那个年代的**硬件性能不足以支撑如此大规模的运算**，而且**样本数据也没有理想的那么多**，随后的很长一段时间，神经网络的研究进入了一个沉寂期。

但是随着互联网的兴起，**大量的数据可以作为神经网络学习的样本，而不断升级的硬件则提供了强大算力支撑**，因而大数据和深度学习的搭配称得上天作之合。关于神经网络的研究也越来越多，神经网络变得越来越复杂，其中的隐藏层越来越多（可以理解为神经元的层数），这个领域也获得了一个新的名字——“深度学习”。在这个后神经网络时代，诸如卷积神经网络、递归神经网络、循环神经网络、生成网络等等分支也快速发展起来，用以解决各种各样的问题。

2016 年，使用深度神经网络学习的 AlphaGo 在围棋比赛中战胜了顶尖职业棋手李世石，可以说是深度学习在大众视角下的一个里程碑。**当然，深度学习的应用并不仅仅在围棋这一个领域之中。**

在计算机视觉方面，原本有一个著名的比赛——ImageNet 比赛。它的举办方收集了大量的图像数据，并构建了一系列的任务，比如说图像分类、物体检测等。

在深度模型进入之前，分类的最好效果是 25% 的错误率。在 2012 年，AlexNet 使用 8 层卷积神经网络，一下把错误率降到 15.4%，超过之前最佳效果差不多 10 个百分点。随后的年份，深度模型大放异彩。在分类任务上，2015 年，有 152 层的 ResNet 错误率已经降到了 3.57%，这个错误率已经超过了人类的视觉识别能力。到了 2016 年，ImageNet 中含有超过 1500 万由人手工注释的图片网址，也就是带标签的图片，标签说明了图片中的内容，超过 2.2 万个类别。其中，至少有 100 万张里面提供了边框（bounding box）。在这么庞大且复杂的数据集上，深度学习已经表现出毋庸置疑的能力，优化项主要集中在堆叠更高层的模型上（增加计算资源），2017 年，分类任务 Top5 的错误率降到 2.25%，同年，ImageNet 比赛宣告终结。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 9]  
**既然深度学习如此强大，很快成为解决非标准数据，也就是我们的自然语言处理和计算机视觉相关问题的有力方式**。接下来我们来看一下，在自然语言处理和计算机视觉方面常见的深度学习应用有哪些。

**自然语言处理**

自然语言也就是我们人类说的语言，我们使用语言进行交流、传递各种信息。在我们常见的应用中，比如今日头条中的新闻文本、淘宝中的商品描述、用户评论文本、喜马拉雅中的有声读物、知乎中的问答等等，自然语言几乎会出现在每一个地方。**伴随着这些应用场景，深度学习基本上介入了所有的方面，并且取得了不错的效果**。

**1.自然语言基础处理**

关于自然语言需要进行的一些基本操作，比如分词、词性标注、句法分析、实体识别等等，**这些大多数是序列标注问题，主要是为了构建一些底层特征而进行的**。

**2.文本分类**

**文本分类可以说是应用最广泛，最容易理解，也最成熟的一项能力**。对于新闻分类、评论的情感分析、广告和标题党的识别，非常多的任务可以使用文本分类的方式解决。

**3.文本生成**

比起文本分类，文本生成则要困难一些。使用文本生成可以给没有标题的内容生成一个新的标题，或者生成对应的摘要。之前 OpenAI 还使用最新的**GPT 模型**来续写哈利·波特，这些都属于文本生成，不过单纯文本生成的效果当前还很难达到工业级别的需求，在实际的工作中，对于这方面的需求往往需要增加很多辅助工作。

**4.语音识别**

语音识别其实分为两个步骤，第一步是要对音频中的音节进行分割然后识别出是什么音，第二步要把这个音转换成对应的文字，这时候就需要语言模型的介入，因为一个音可能对应很多的文字，加入语言模型可以让语音识别的效果更上一层楼，通过上下文关系来决定哪一个字。现在语音识别技术也已经非常成熟，有很多 App 都可以做到几乎实时录音转文字。

**5.机器翻译**

机器翻译就是使用计算机实现**不同语言之间的翻译转换**。语言与语言之间的转换有太多细节的特征，这正适合深度神经网络发挥它可以自行学习深层特征的能力。可以把循环神经网络、编解码器框架和注意力机制很快应用到机器翻译上来。如果你使用过十几年前的谷歌翻译，再看现在的谷歌翻译效果，真的是有天壤之别。

**6.智能问答**

智能问答也是当前非常火热的一个领域，比起前面的几项，智能问答更像是一种应用，其中会用到意图理解、文本分类、文本生成、文本匹配，甚至是知识图谱的相关知识，这里面自然也少不了深度学习的身影。

**计算机视觉**

看完自然语言处理相关的一些应用，别忘了我们的数据中还有很多图像相关的数据。比起语言，图像更加直观，但是图像的信息密度更低。在我们常见的 App 中，新闻会加入图像来还原事发的状况，电商网站也会加入图片和视频来吸引用户购买，更不用说像 B 站、抖音、爱奇艺这种几乎完全是视频构成的应用。深度学习在图像的处理方面，也发挥了强悍的能力。

**1.图像识别**

在图像识别方面，我们前面也讲过，**深度学习模型的效果已经超越了人类的识别效果**。跟图像识别相关的应用非常多，比如人脸识别、图像分类、物体检测。在交通违章上使用的车辆识别，车牌识别；在审核方面使用的图像色情低俗识别、暴力恐怖识别等等，都是图像识别在发挥着作用。

**2.图像生成**

图像生成方面，有很多有意思的应用，比如可以根据对不同的人脸学习，进而自动生成一些新的实际上并不存在的人脸；还可以进行风格的迁移，学习一张图的样式以及另一张图的绘制风格，进而生成一张新的图片；甚至是与自然语言处理结合，根据一段语言描述生成新的图片。

**3.图像变换**

**图像变换主要是对原图像进行一些处理，使得原本不符合某些需求的图片质量提升，能够符合我们的需求**。在这方面，有图像的智能裁剪、图像放缩、图像超分辨（让原本模糊的图片变得清晰）、图像去噪等等。

**4.OCR**

**OCR 技术说的是识别图像中的文字**，目前的 OCR 技术已经比较成熟，对于固定场景下的文本识别效果非常好，尤其是印刷体文本的识别基本上可以达到 100% 的准确率。

**总结**

如果你想动手实践一些深度学习项目，现在有很多框架可以使用，比如说谷歌的 TensorFlow、Facebook 的 PyTorch、百度的 PaddlePaddle，这些框架把很多深度学习所需要的底层建设进行了优化和封装，提供大量更加可用的 API，让深度神经网络的构建更加容易，这些框架中甚至给出了一些非常稳定的神经网络模型。针对很多任务搭建的神经网络或者训练好的模型，你也可以在 GitHub 上面寻找，经过简单的调整即可运行。

# 17 | 如何深入分析电商数据中的价值？ #

从第 14~16 讲，我们沿着算法的路径一步步深入下来，从数据挖掘流程到数据挖掘算法，再讲到当前火热的深度学习在自然语言和图像处理方面的应用。这节课，我们回归到具体的业务上，从产品的视角切入，看看在构建一个电商产品逻辑的时候，该如何一步步进行分析。

在互联网模式中，电商占据着非常大的比重，有做全品类的淘宝京东，也有做垂直领域的，比如卖图书的当当网、多抓鱼，卖服装的唯品会、聚美优品，这样的电商网站不胜枚举。

假设我们现在在一个电商网站公司的增长部门，每天的工作就是绞尽脑汁促进用户增长。有一天，领导找到你说，小明啊，我感觉我们网站上的商品太多了，像我这种高贵的用户很难在我们的网站上找到想要的东西，而且现在不是都在讲消费升级吗，我看我们也应该搞一个“发现好货”的栏目，让那些跟我一样的客户都能够快点找到自己想要的东西。  
![淘宝、京东、拼多多的发现好货栏目][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 10]  
从我自己的认知来看，确实，消费升级的主要逻辑是在对生活质量的提升上，一方面顾客愿意多花一点钱去提升品质，另一方面也是市场上大部分的品牌已经尝试过了，对“新”这件事要求更多。那么，如果我们要在网站上开设这样一个栏目，该做什么样的数据分析呢，首先，我想讲两个分析方法。

**PEST 分析**

PEST 是针对宏观环境的分析，所谓的PEST 指的是政治（Political）、经济（Economic）、社会（Social）和技术（Technological）这四大类主要的外部环境因素。  
![在这里插入图片描述][20210523232127735.png]  
政治环境主要是看我们的国家现在是否鼓励相关的业务，有没有这方面的政策或者法规，比如说国家“十三五”规划指明全面推进互联网应用创新，促进互联网和经济社会融合发展，而且我们的“发现好货”也不会在政府重点监管和整治的范畴。

经济环境又可以分为宏观经济和微观经济。宏观指的是我们整个国家的经济情况，比如说我们国家是疫情期间唯一一个实现正增长的国家，而人口增速放缓、老龄化变得更加严重，家庭规模变小，人们不再喜欢囤积大量货物。而微观主要从一个人的角度出发，例如人们的收入逐步增加，储蓄规模有所下降，消费偏好变得更加多样性，比如这两年逐渐火爆的精酿啤酒就是一个典型的例子。

社会环境则是说跟社会的风俗习惯是否吻合，大家的教育水平是否能够接受我们的产品形态，符不符合大多数人的价值观，我们的产品有没有影响人们的宗教信仰等等。如果说我们的产品有可能挑战人们的价值观，或者说对社会中的风俗习惯有冲突，那估计就得重新考虑了。

技术环境当然就是说的我们的技术实力，首先是我们公司内部的技术水平和基础技术建设能不能支撑我们去做这个事情，在这里当然就是我们的大数据体系，其中的实时流处理、算法研究的能力等等，这些是否能满足“发现好货”这个产品的要求。如果不能，我们的产品是需要做降级方案还是说要去补全我们的技术能力，或者是说完全没有办法做，这就是需要考虑的问题。

PEST 分析从外部环境进行分析，考虑我们的产品在这种大环境下是否可以生存，如果跟大环境存在冲突那可能我们这个产品就没办法去做了。

**SWOT 分析**

在清楚了外部影响因素之后，我们应该再来确认自身的情况，这时候可以使用 SWOT 分析。来自麦肯锡咨询公司的 SWOT 分析，包括分析企业的优势（Strengths）、劣势（Weaknesses）、机会（Opportunities）和威胁（Threats）。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 11]  
**1.机会与威胁分析**

所谓的机会与威胁分析，就是顺着我们上面的环境分析下来，看看在当前环境的情况下，如果要做一个“发现好货”的产品形态，我们的机遇有哪些，受到的环境的不利挑战又有哪些。比如说，当前的经济环境下人们对商品品质的追求有了更大的需求，这就是我们的机遇。把环境分析与我们的产品自身情况结合起来，可以帮助我们判断该采取什么样的产品策略。当然，对环境的分析除了我上面讲到的 PEST 分析，还有一个波特五力分析法，如果你有兴趣可以在课下了解。

**2.优势与劣势分析**

清楚了自身在环境中的情况，接下来我们还需要去看看市面上是否已经有类似的产品形态。因为我们是期望在一个泛品类的电商网站中构建一个“发现好货”的栏目，我们可以去找淘宝、京东等网站是否已经有这样的栏目存在，在一些公开的资料中有没有讲到这方面的东西，这也就是所谓的竞品分析。

优劣势分析就是针对我们要做的产品的整个生命链条与竞品做详细的对比。比如说我们要做一个这样的栏目，我们的优势在哪里，是已经具备了强大的货物筛选能力，还是说我们在价格上更有竞争力，我们的用户更倾向于高质量的商品。

我们的劣势在哪里，是不是物流没有京东的快，货物没有淘宝的齐全，一个产品不可能只有优势没有劣势，但是我们要清楚成功的关键要素是什么，如果我们在这些关键点上存在比较优势，那么我们的产品也许就更强一些，那在后面的运营上也可以趋利避害，强化我们的优势，规避我们的劣势。

当然，在前期分析中，我们的产品还没有上线，所以这些竞品分析也是站在潜在用户的角度去进行比较，与实际的情况可能存在一些差异。所以我们在进行竞品分析的过程中，需要对自身的资源和能力有足够清醒和深入的认识，这样才能更加准确客观。

**人货场指标**

在弄清楚了外部环境与竞品情况之后，我们对大的方向以及策略的制定有了一些想法，接下来我们就要进入具体的场景中来，明确我们要去做“发现好货”的栏目应该从哪些指标入手。

首先我们需要关注的是**核心指标**。任何一个产品的产生都应该有一个核心指标：

*  如果说我们的目标是吸引新用户，那么核心指标就是新用户转化率；
 *  如果说我们的目标是让用户更多使用我们的 App，核心指标就是用户停留时长；
 *  如果我们期望用户更多地了解我们的商品，那么核心指标就是人均浏览商品数。

对于我们“发现好货”的目标，**我们期望能够通过这个栏目获得更高的现金流，那么我们可以把核心指标定为销售额**，而销售额 = 流量 \* 转化率 \* 客单价，对于我们栏目相对固定的位置，流量也是相对固定的，所以我们期望通过把“好”的商品筛选出来放在这个栏目中，以提升转化率和客单价，因此我们的销售额指标是一个有限条件的销售额指标，也就是在流量一定的情况下，销售额更高。

核心指标是我们所追求的目标，要时刻关注，而对于我们在构建产品时，该如何围绕这个目标进行拆解呢，那么就**需要对我们电商网站中的人货场指标进行拆分**。

**人**

**电商网站中所说的“人”，也就是我们的用户**，具体到“发现好货”，我们应该了解：

*  所面向的潜在用户是什么样子的，比如说用户的基本属性、性别、年龄、收入状况等；
 *  用户使用我们 App 的情况，新客、老客、高频用户还是低频用户，喜欢早上下单还是晚上下单；
 *  用户的兴趣点，根据以往下单历史，喜欢健身，喜欢买各种吃的，还是喜欢买儿童玩具等等。

这些都属于用户相关的指标。通过“人”的指标，我们对“发现好货”所面向的人群有了一个基础的判断，了解了我们这个产品潜在的用户量有多少，也方便在后面运营的时候有针对性地引导客户。

**货**

**“货”更加容易理解，那就是我们要售卖的东西**。我们的“发现好货”栏目自然是需要对货相关的指标进行更加详细的盘点，其中包括商品的基础信息，如商品的品类、价格、优惠、库存、介绍、质量、款式、使用寿命等等；商品的历史情况，比如销量、点击率、转化率、退换货率等等。

**场**

**“场”指的是交易发生的场所**，在线下可能是商场、菜市场，而在我们的 App 中，则涉及从用户进来到成交退出的每一个环节。我们的“发现好货”栏目对于用户路径来说，第一个“场”是栏目所处的位置，然后是内页，紧接着是商品详情页，然后是购物车，最后是订单页。

与“场”相关的指标包括流量相关的路径，使用漏斗模型分析从初始进入的流量到最后转化的流量指标；还包括在每一个页面上的停留时长、热力统计、跳失率等等；以及与销售相关的，整体销售额、利润率等等。

经过对人货场指标的细化，我们就可以针对产品构建起人货场模型，也就是说确定针对的是哪一部分用户，对于这些潜在用户我们该选取什么样的商品放在栏目中，对于确定的人和货，在我们的场景中又该如何展示，如何排序能够获取更好的销售额。

**总结**

在算法策略工程师的日常工作中，一般不会独自去承接一个像“发现好货”这么具体的产品形态，但是要构建“发现好货”，必然少不了算法策略同学在背后的身影。比如在这个例子中，算法策略在后面要承担该场景下商品选品策略，承担召回排序策略，甚至是对文案和图片的选取策略，那么我们从一个产品视角出发，对要构建的产品进行全面详细分析，有助于我们在后面针对性地建设算法模型。

这节课，我介绍了在电商场景下进行分析的相关指标，其中 PEST 分析是外部环境分析，接着 SWOT 是分析判断产品的机遇和威胁，优势与劣势。后半节，则是在电商场景下常用的人货场模型，对其中涉及的指标进行了简要的介绍。在具体的生产中，这些指标的统计都要借助大数据体系的工具，比如 Hive 或者 Spark，所以我们首先要掌握这些指标，从整体上对指标有一个了解，到了具体业务再具体分析需要用到哪个环节的哪个指标。

# 18 | 数据可视化：如何直观地“看见”数据？ #

上节课我们从产品思维出发，借助各种数据指标分析产品需求，可以知道数据指标非常多。其实在大数据体系的每一个环节，都有着非常多的数据。这些数据呢，我们写代码去处理没有什么问题，用大数据工具进行运算也没什么问题，但是如果想把数据中的信息表达出来，让人看完能够记住，并且能够记得清楚，明白其中的重点，只靠着一条条的数据恐怕是难以做到。如果我们单纯地把数据列出来，就像下图的表格一样，用在你的展示汇报中，估计没有人能看得下去。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 12]  
数据本身往往是十分枯燥的，而且十分分散，想要简化数据中的信息，给大家留下深刻的印象，**选择使用图表来表达数据情况是一个非常不错的选择**。我想在你的工作和生活中，也一定见过各种各样的图表，对比明显的、优雅的，甚至是炫酷的，让你记忆犹新。我们看下面这张数据大屏的截图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 13]  
图片来自[腾讯云图页面展示][Link 1]

**这里使用柱状图进行数据排行的展示，折线图展示客流量变化，环形图展示数据的分布，中间最大的是一张热力地图**。这样的图表展示让人能够清楚地了解某超市门店的主要指标，对门店的经营状况一目了然，而其背后的数据实际上与我们日常处理的数据并没有什么区别，那么在这里，发挥作用的就是**数据可视化**。

**图表的优点**

数据以图表的形式展示出来，比起干巴巴的数据有很多优点。

**1.简化数据**

第一个是简化数据。在我们的大数据架构中，每天流转的数据动辄上亿条，其中的关联也是纷繁复杂，单纯观察数据恐怕是毫无头绪，使用图表的形式可以帮助我们厘清关系，以简洁的形式展现那些最重要的数据。

**2.加强记忆**

正如我上面所贴的表格和数据大屏的区别，表格的内容你很难记下来，但是转换成图表则会获得非常好的记忆效果。视觉信号的持久性更长，如果说我们还能把数据转换成合适的图表，并能够用色彩变化来展现，则可以进一步强化记忆。

**3.易于理解**

使用图表还可以加快人们对数据信息的理解，“一图胜千言”说的就是这个道理。很多时候需要用语言描述半天的东西，如果画一张图可能你一下子就明白了。

**4.突出重点**

使用图表来展示我们的观点，并通过图表的形式、颜色等信息加强我们所要表达的重点，能够更好地说服其他人。

假设在我们电商网站的某个页面，我说我们每天有 5000 个商品信息被加载出来，有 4000 个被用户看到，有 3000 个被点击，有 1000 个订单，但是最后只有 250 个成交，这样的信息你可能很难一下反应过来，但是我们把它画成一个漏斗图，如下图所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 14]  
你可以很明显地看到每一步流失掉多少用户，差距最大的在下单到支付的环节，所以我们可以针对这个环节再去分析是什么因素导致用户下单之后没有付款，从而优化我们的产品。

**不同场景下的可视化工具**

既然数据可视化有这么多的好处，那么我们该怎么开展数据可视化呢？让我们自己去画图显然是不可能的，也没有那美术功底，当然，现在有很多数据可视化的工具可以使用，我想大家应该都有所了解，比如说使用 Excel 或者 PPT，那么在大数据场景下，我们该如何去选择合适的可视化工具呢。

**1.开发者个人数据可视化**

大数据体系下的开发人员，比如说算法工程师要对算法模型的效果进行对比展示，可以使用 Python 的可视化工具库来进行数据可视化，这类的可视化需求通常是一次性的，Python 中常用的可视化库有**Matplotlib** 和 **Seaborn**，其中包含了常见的静态图表展现形式，像直方图、散点图、箱体图等等，使用这些可视化库基本上可以满足开发者日常的需求。借助 Jupyter 这种开发工具，可以在日常的开发或者算法工作中快速展现数据表现。

当然，使用 Python 开发图表的困难也显而易见，首先是对于不懂 Python 编程语言的同学学习成本比较高，其次是想要做出比较复杂的图需要非常复杂的配置项。

**2.业务分析型数据可视化**

这类可视化需求主要是针对公司的非开发人员。在公司中要借助大数据力量的可不止开发人员，事实上，几乎公司的每一个环节都会见到大数据的身影，每一个决策似乎都与大数据有着千丝万缕的关系。比如说数据分析师、产品、运营等人员，期望借助一些现有的可视化工具来增强对数据的分析过程，通过这种更加显眼的方式辅助分析，并得到分析结果。

**Tableau 就是一款有着这样定位的数据可视化工具**，它提供了一款桌面软件，如下图所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 15]  
其中封装了非常多的图表样式，并且提供简单易用的操作方式，不仅能够监测数据，进行图形化展示，还提供了完整的分析能力。Tableau 的学习成本非常低，只需要拖拽一下就可以完成数据可视化，其中提供的功能基本上可以满足公司大部分数据可视化的需求。除了桌面版本， Tableau 还提供 CRM 版、Online 版等等，对于不会写代码的分析人员非常友好。当然 Tableau 是一款收费的商用软件，在公司使用的话需要注意这一点。

**3.动态数据展示可视化**

如果说你们的可视化需求已经不是出于个人的需要，也不是要做一些汇报和分析，而是**要完全构建起一套属于自己业务的数据可视化平台**，能够自由地掌控其中的每一个元素，并能够实时进行数据展示甚至是互动，就像时下流行的炫酷数据大屏一样，那么你可能就需要用到 Echarts 了。

**它是由百度开源的一个非常专业的数据图表，使用 JavaScript 实现，底层依赖矢量图形库 ZRender，支持几乎所有的浏览器展示**。在 Echarts 的示例页面对 Echarts 中的基本可视化图形进行了展示，如下图所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 16]  
可以看到很多我们想到或者想不到的图表类型都已经位列其中，再加上开发者自己的调整可以变换出各种各样的报表形式，**由于 Echarts 功能强大，而且免费开放，很多公司在开发自己的可视化平台时也都是使用 Echarts 作为其可视化组件**。

在这里呢，我介绍了三种可视化方案，它们分别适用于三种不同的场景。当然，市面上的可视化方案非常多，远不止这里所列举的这几种，但是功能方面大同小异，我这里所写的是最常用的几种情况。如果你有时间，可以再对这部分深入了解一下，看看具体到自己的业务上，使用哪种工具更加顺手。

**当然，数据可视化是一种技术与艺术的结合**，虽然技术方面我有一点认知，但是艺术方面实在是不得要领，因此在做数据可视化的时候该如何去选择合适的图表形式，该如何搭配色彩等等。经过学习和总结，我这里给出一些小的建议，希望在你刚开始做这方面事情的时候也可以用得上。

**可视化的建议**

**1.关于可视化图表的选型**

每种可视化图形都有其适合的场景，或者说适合展示的数据，在这里我大概做了一些总结。

（1）类别比较

**类别比较即是对不同类别的数据放在一起进行对比，突出的是不同数据的规模差异情况**，这种可视化一般会用到柱形图、条形图、雷达图、词云图等等。

（2）数据关系

**数据关系型图表主要是为了展示数据的不同变量之间的联系，比如说层次关系、网络关系、数值关联等等情况**：

*  像数值关联分析需求，可以使用散点图、气泡图、曲面图等等；
 *  当要对比的变量超过三个，可以考虑星形图、平行坐标系、矩阵散点图等等；
 *  而层次关系可以考虑节点链接图、树形图、冰柱图、旭日图等等；
 *  网络关系可以考虑桑基图、蜂箱图之类的图表形式。

（3）数据分布

**数据分布类主要为了展示例如我们的产品在某些维度上出现的规律情况**，这类建议使用直方图、密度曲线图、箱型图等等。

（4）时间序列

**时间序列的数据通常是为了表现随着时间的变化，所展现出来的数据趋势**，这类可选择的图形有折线图、面积图、雷达图、日历图、柱形图等等形式。

（5）局部整体

**局部整体的数据展示通常是为了说明整体下的组成部分所占的比重情况**，这种可以采用饼图、环形图、旭日图、矩形树状图等等。

（6）地理空间

最后一种说的是**期望展示数据在地理空间方面的分布情况**，通常使用地图作为底图，然后辅助以热力图或者散点图进行对比。

除了这里列出的这些，还有很多图表类型我并没有提到，你还需要在实际的应用中去摸索。

**2.关于颜色的搭配**

对于我这样对色彩敏感度较低，自己只能搞出一些奇奇怪怪配色的人来说，**最好使用既定的色彩主题**。好在我上面提到的几种可视化工具中也都提供了若干的色彩主题供大家使用，这些色彩主题都是由专业设计人员精心设计的，本身是有比较好的美观度，同时也省去了自己搭配色彩的苦恼。

其次，如果你觉得工具提供的配色不能满足你的需求，那么可以**去一些配色网站上寻找你想要的配色方案**，并应用到自己的可视化中。

最后一个方案，是**使用公司提供的配色方案**，一般公司的设计部门会有一套常用的公司配色方案。如果没有，你也可以从公司的网站、App 中寻找配色方案，并应用在你的汇报中。关于配色方面，总的原则就是一定要简洁明了，色彩种类不宜太多。当然，如果你非常精通配色可以忽略我说的这部分内容。

**总结**

这节课我介绍了数据可视化的相关知识。**数据可视化是技术和艺术的结合产物，通过把原本冷冰冰的数据通过图形化的手段展示出来，可视化增加了信息的传递和沟通效率，而数据则赋予了图形意义**。

# 19 | 如何快速搭建一个推荐系统？ #

这节课我们进入有关大数据体系的应用方面，来介绍推荐系统相关的知识。

在开篇的时候我们就讲过，随着技术进步和社会发展，各种数据越来越多，各种新的产品形态层出不穷，也正因为如此才有了大数据解决方案，有了各种各样的大数据工具。

我们想要购物，淘宝、京东上面有几十亿的商品供你挑选；你想看新闻，今日头条、微信公众号每天都会有几百万篇的内容产生；你想休息的时候看看视频，抖音、快手、B 站上有数不清的视频资源。如果说把这些东西都放在那里，让你自己去挑选，那估计很难找到自己想要的东西，即便是分门别类的排好，也需要花费大量的时间进行挑选。尤其是在我们的手机上面，屏幕就那么一点点，手指的点击也没有那么精确的情况下。而且很多时候你只是想去看一下，并没有明确要买什么，或者要看什么，面对那么多的可选项，就更加选择困难了。

**推荐系统与这种场景可以说是天作之合，天生就是为了解决“信息过载”的问题，通过分析我们用户的行为，找到有可能感兴趣的东西，并把它们展现出来，供我们选择**。接下来，我们就来看一下，借助大数据体系，如何构建一个推荐系统。

**推荐系统**

要构建推荐系统，我们先来看一下它应该有哪几个组成部分。**推荐系统最基本的功能就是“匹配”，匹配每一个用户和每一个物品，以做到千人千面的效果**。在这里我画了一个最简单的示意图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 17]  
当用户在使用我们的 App 时，产生了大量的行为数据，这些数据通过日志的方式从手机传送到我们的服务器上，在服务器上又通过实时或者离线的方式同步到我们的数据处理平台上面。**使用数据处理工具，比如说 Spark 或者 Flink，我们把这些行为数据加工成为用户画像的一部分**。另一部分，**则是对我们的物品信息进行各种挖掘和计算**。

**这里形成的用户画像和物品画像在召回层进行匹配，确定适合一个用户的物品有哪些，然后在排序层对这些物品的出现次序进行调整，当用户刷新页面的时候，他对应的物品列表就会被展示出来**。这就是推荐系统完成的一个典型的推荐流程，当然，在这里面还有很多的细节和问题需要处理。

**1.用户画像**

**在用户画像方面，基本上可以分成用户的基础属性、行为属性、兴趣属性、价值属性等几个维度**：

*  **基础属性主要是一些相对固定的信息**，比如用户的年龄、性别、手机型号、网络状况等等，这类信息主要依赖用户自行填写或者直接收集；
 *  **行为属性通常是对用户使用行为统计计算得出的结果**，比如说用户的购买行为、互动行为、喜欢什么时间段使用 App、收藏夹或者购物车都有些什么东西等等，通常这类属性使用 Hive 或者一些数据统计工具就可以完成计算；
 *  **兴趣属性通常是针对场景下的物品而言的**，比如说用户有自驾的兴趣、有滑雪的兴趣，或者是亲子兴趣等等，这类属性会以物品属性为基础，其中可能有依赖统计获得的结果，也可能有使用数据挖掘算法获得的结果；
 *  **用户的价值属性，往往是针对我们的平台而言**，对于电商平台，用户价值可能是消费能力、消费周期、消费频率等；对于内容型平台，用户价值则可能是使用时长、互动水平等，这类属性一般也是包含了统计特征和模型特征。

**2.物品画像**

通过对用户行为进行分析，我们对用户有了认知，但是想要去匹配用户与物品，我们还需要在物品方面进行理解。**这里所说的物品，也就是要推荐的东西**：

*  对于电商推荐来说就是商品信息；
 *  对于内容推荐来说就是各种新闻、视频；
 *  对于广告推荐来说就是各种广告信息。

物品本身通常是由文本、图片、视频等构成的，对于这些数据的处理往往就涉及我们的自然语言处理和计算机视觉相关的能力。

关于物品画像特征，**首先也会有基础属性**，通常是数据本身或者经过一些统计就可以得到的特征，比如名称、价格、上线时间、优惠信息这类的数据。

**在基础属性之上，我们会使用算法对这些数据进行加工，以获得基础算法属性**，比如说文本的关键词提取、实体识别、词向量，甚至是预训练模型、图像的美学判定、图像的物体识别、视频的关键帧提取等等。

这两层特征当然可以直接以特征的形式加入推荐召回和排序中，此外，我们会借助这些数据再进行更贴近业务的属性建设，比如说文本图像视频分类、情感分析、人脸检测、质量评级等等。

**3.召回与排序**

有了对用户和物品的描述，我们就可以在同一个空间内对用户和物品进行匹配了。

**匹配的第一步是召回环节**。如果我们要为一个用户匹配他最喜欢的新闻，最粗暴的方式当然是把时下所有的新闻画像都拿出来，然后挨个计算和用户的相似情况。但是新闻如此众多，在实践中这样进行计算会消耗大量的资源，更别提我们还有无数的用户都需要进行计算。**召回环节所要解决的就是从庞大的候选池中快速地找到更可能与用户匹配的物品，缩小候选物品的范围，降低排序时的难度**，如下图所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 18]  
**排序层在召回的结果上进行计算**，因此排序的目标是使用更多的特征，以提升推荐的核心指标为目标，通常使用的是**点击率预估**，通过预测哪一个点击的概率更高，从而给出精准的排序列表。

在工业实践时，为了解决性能等问题，往往还会把这两个环节再进行细分，**召回可以分为粗召回和细召回**，粗召回主要是不关联用户，单纯地以物品特征作为召回特征，在细召回环节再与用户进行匹配。同样，**排序环节也可以细分，分为粗排、精排以及重排**，重排序环节往往是在最后环节做一些规则或者运营进行干预。

**在推荐系统中，用户画像和物品画像通常也会被称为特征工程**，当然这里的用户画像和物品画像**除了应用在推荐系统中，还可以用在各种运营场景**，比如分群和物品圈选，去做场景投放。在经历了特征工程之后，这些从数据中提纯加工后的特征经过召回和排序变成一个列表。对于每一个用户都会有一个自己的列表，当用户在手机 App 上刷新的时候，列表中的内容就会按顺序展示，等待用户的浏览点击，这就完成了一个推荐的流程，从庞大的候选中为用户匹配到最相关的物品。

**常见推荐方法**

根据对推荐系统使用特征的区别，我们大致可以把推荐分成下面几种情况。

**1.基于协同过滤的推荐（Collaborative Filtering，CF）**

**这种方法最简单有效，协同过滤的基本思想就是相似用户所喜爱的东西也是相似的**。协同过滤可以只根据用户行为来分析，**根据用户浏览的内容来决定用户的相似度**，然后为一个用户推荐与之相似的用户看过或者买过的东西。协同过滤虽然简单，但是对于用户行为较少的情况，协同过滤的效果也非常不稳定，如果是完全没有用户行为，那就更加束手无策。

**2.基于内容的推荐（Content-Based，CB）**

**基于内容的推荐更多地依赖物品画像**，比如我们为商品都标注上标签，如果你点过一个带有“自驾”标签的商品，那么基于内容的推荐会给你推送其他带有“自驾”标签的商品。这种方案不再需要大量的用户行为，但是需要好好对物品进行处理，能够完整、细粒度地刻画物品特征才能有较好的效果。

**3.基于知识的推荐（Knowledge-Based，KB）**

前面两种方法都是基于用户行为的推测，**基于知识的推荐则是在明确需求与结果的情况下进行的**。首先需要有明确的知识体系，比如说“下雨要打伞”这样的知识，然后用户告诉推荐系统“下雨了”，那么就可以给用户推荐雨伞。这种推荐不需要有之前的用户行为，但是要想**总结这种知识则是非常困难的**。当然，随着近些年知识图谱的发展，基于知识的推荐应用也变得越来越多。

**4.混合型推荐**

顾名思义，**混合推荐就是结合上面几种不同的方案同时应用在一套推荐系统框架中**。实际上，公司中所使用的推荐系统通常都是混合推荐系统，借助上面每一种推荐方案来解决不同场景下的问题。

**冷启动问题**

推荐系统虽然很美好，但是有一个问题始终绕不过去，这就是推荐系统的冷启动问题。由于我们上面讲的推荐系统是依赖用户行为计算的，那么对于没有行为的用户，或者刚刚产出的新闻或者商品没有对应的行为数据，没办法按照上面所讲的步骤进行用户与物品的匹配，这就是**推荐冷启动问题**。从冷启动对象来分，可以分成三种情况。

**1.用户冷启动**

**这是指对于一个新用户，我们没有他的历史行为，也就很难去计算他的兴趣偏好、他的价值**。对于新用户的解决方案，你可能见到过，比如当你刚注册一个应用的时候让你自己选择兴趣点；或者是利用一些边缘信息，比如用户的注册信息、手机型号、用户的网络制式；再者可以给用户推荐一些热门内容或者优质内容。

**2.物品冷启动**

物品的冷启动比起用户的来说可能会好一点，因为我们自己会掌握物品本身的信息，即便是这个物品还没有行为数据，我们可以根据基础属性以及算法结果给出一些匹配用户。如果在流量比较充足的情况下，给每一个新物品一定的基础曝光，让它产生一些用户行为，利用这部分行为数据再进行下一步计算。

**3.系统冷启动**

**系统冷启动是说在一个全新的推荐场景，没有任何用户数据，只有部分物品数据**。这种情况下，可以借助运营知识，先制定一些公认的规则，逐步累积数据，并随着用户的增长进行调整，直到系统相对稳定的状态。

**总结**

这一讲我们大体介绍了推荐系统的整体框架，结合大数据体系，推荐系统已经越来越成熟。在如今的生活中，推荐系统已经覆盖了我们所使用应用的大多数场景，并且还在不断应用于新的场景中，推荐系统逐渐由一个高端技术变成了标准配件，没有推荐系统的应用反而不那么常见。

如果你想实现一个简单的推荐系统，可以**使用规则来进行召回排序；使用简单的 KNN 算法或者决策树算法也可以实现推荐系统**；当然，现在**基于深度模型的召回排序算法**也非常流行。在大数据工具中，像**Mahout**也提供了推荐引擎可以方便使用。在 GitHub 上，推荐系统的开源项目也非常多，比如说[SparrowRecSys][]就提供了一套完整的基于深度学习的推荐系统，还包括数据部分。不妨借助这些开源项目练练手吧。

# 20 | 如何从零开始做数据化运营？ #

上一节课我们讲了大数据体系下的第一个重要应用：推荐系统。**推荐系统借助大数据完善了自身的能力，而大数据则凭借推荐系统直接触及用户**。这节课，我们再来看大数据体系在公司中带来的第二个大应用：数据化运营。

**如果是早些年，提起运营可能还停留在依靠人工经验来制定运营策略、拉新用户、搞促销活动、在渠道投放广告等等**。这些工作可能更多地依靠运营人员的主观判断，会很大地受到运营人员的认知水平和相关经验的影响，而且这些运营策略一经制定，直到最后也很难回收明确的效果。比如说，把广告投放出去了，到底拉来多少新用户？我们加入了一个新的功能，用户到底喜不喜欢？最近用户的复购率降低了，是什么原因？

**如果说没有一个统一的大数据体系在运转，单纯依靠运营人员去回收这些数据的情况，相信很难给出一个准确的答复**，但是，近年来，**随着大数据逐步成为一种标准配置，数据化运营逐渐成为运营的主流思想，借助数据驱动，为运营的决策提供了良好的数据支撑，辅助了运营决策的效果检验，也为精细化运营提供了各种便利的能力**。这节课，我们就来看一下，如何做数据化运营。

**如何做数据化运营**

**对于数据运营来说，最核心的工作就是制定人货场的匹配策略，所要解决的就是在什么样的“场景”下给什么样的“用户”展示什么样的“货物”以达到什么目标。**

**1.理解业务**

运营动作往往都有一个明确的目标，比如说要拉新，或者要促活，或者要提升转化等等，因此**数据化运营首先也需要对业务有深入的理解，清楚业务的目标与业务流程**。

**2.制定目标**

**在对业务的整体认知下，针对一次运营动作设定目标**，比如说在暑期提高亲子类目商品的新客转化，以及本次的核心指标，比如新客转化的人数提升 10%。

**3.细分拆解**

有了目标和核心指标，接下来就需要对其进行细分拆解了，**这也是数据化运营的一项核心能力**。

针对上述目标我们来看一下，**针对的用户群体为有亲子倾向的用户，同时是亲子商品的新用户**，继续细分，这些新用户的消费区间是什么样子的，用户年龄是怎么分布的，除了亲子还有没有其他兴趣。

**对于商品，则是亲子类目商品**，继续细化，这些商品是益智类的卖得好还是娱乐类的卖得好，是品质高的卖得好还是便宜货卖得好。

**对于场景，我们需要关注亲子类目商品可能出现的场景**，比如说推荐场景、搜索场景、运营位场景等等。

对人货场三方面拆解完，还需要对**其中的指标进行细化，清楚其中的哪些指标会与我们的核心指标相关**。比如说，亲子用户在推荐场景下单的比例比搜索场景高，但是搜索场景的亲子用户复购率高。**通过剥洋葱式的方法一层层拆分，将原本庞大的目标拆分成可操作的动作，进而确定我们的试验策略**。

**4.推进执行**

根据既定的方案，下一步就是推动方案的落地实施。**数据化运营项目往往是跨多个部门**，涉及流程中的产品、运营、数仓、分析师、数据挖掘与算法工程师、后端研发，甚至是前端与设计人员，在执行环节仍然需要在以下两方面保持高度的关注：

*  进度的控制
 *  实施效果的控制

**5.检验结果**

数据运营方案如期上线，但数据运营的工作还没有结束，还需要跟踪核心指标是否会随着我们的策略上线，朝着我们想要的方向变化。随着时间的流逝，如果确实朝着目标改变，那么说明策略有了效果，但是是否跟预期的目标一样多，或者这个变化是否稳定，以及还有没有其他可能的因素影响了结果？这些东西需要在回收结果的时候再次进行分析。

反过来，如果策略上线了，数据没有变化，或者甚至效果反而下降了，同样也需要去分析原因。有了这些分析的结果，我们即将进入下一个循环，调整策略，或者制定下一个目标。所以，**上线并不是一个结束，而是下一个开始**。

**辅助运营的指标模型**

上面提到的核心环节就是细分和拆解，尤其是对于指标的拆解。在《17 | 如何深入分析电商数据中的价值？》中，我们讲到了电商体系中人货场的模型，对其中涉及的指标进行了简单的介绍。**指标在数据化运营体系中是承上启下的润滑油，它由原始数据加工而来，反过来又驱动其他产品**。因此，要做好数据运营工作，也需要有指标体系来进行指导，在这里我们来看一下数据化运营中常用的指标模型。

**1.RFM 模型**

第一个指标体系是 RFM 模型，**RFM 主要是针对用户的分析，一般对于用户价值的衡量和分析都可以以 RFM 模型为基础，不断地进行拆分和细化**。

*  **R（Recency）：指的是最近一次交易的时间间隔**。
 *  **F（Frequency）：指的是用户的消费频率**，一般是在一个时间范围内的消费频率。
 *  **M（Monetary）：指的是消费的金额**，同样，也是在一个时间范围内进行计算的。

根据 RFM 模型，我们首先可以对用户做出一层区分，**这个用户是高价值用户还是低价值用户，是处在用户生命周期的头部还是尾部**。对用户方面的理解通常可以以 RFM 模型为根基，做进一步的细化，最后筛选出我们运行需求的用户群。

**2.AARRR 模型**

第二个我要介绍的模型是 AARRR 模型。在 **AARRR 模型对应着运营的五个环节，即获取（Acquisition）、激活（Activation）、留存（Retention）、收入（Revenue）、推荐（Referral）。**

对于我们的 App，或者说每个产品功能，其实都具备这样的生命周期：

*  首先是通**过各个渠道获得曝光**，让用户知道这款产品，并能够吸引到我们的产品上来；
 *  然后是**去激活这些新用户**，让他们开始使用我们的产品；
 *  在对产品体验过以后，我们期望**用户能够留存下来**，而不是用完就流失了，我们希望用户能经常来使用我们的产品；
 *  对于留下来的用户，还要**引导他去付费，给我们带来收入**；
 *  最后，我们还期望用户能够**主动去宣传我们的产品**，把产品推荐给他的朋友使用。

这就是 AARRR 模型的全路径。在数据运营的目标中，基本上都可以拆分到这其中的一个或者多个环节里，围绕着这些环节去拓展你的指标，并制定相应的提升策略，便于我们全面地分析问题。

**辅助运营的系统**

**作为数据驱动的重点应用，数据化运营在各个公司中也变得越来越重要**。随着公司规模的不断扩大，数据化运营需求每天每时每刻都在不断地扩充，这不仅仅是运营人员的工作，也是产品、研发、算法、市场的共同追求。自然而然，大量的数据运营需求存在着很多的共性，为了让数据化运营更加精细，更加迅速，也产生了很多辅助运营的工具与系统。

**我们前面所讲过的 Hive 当然可以直接拿来使用，数据分析、数据挖掘和数据可视化中的工具也可以用于数据化运营**，但是这些工具相对于触达用户的运营策略有点过于底层，并且对于非研发人员的使用并不友好，所以，需要有更加面向运营的工具。这里我要讲的是**圈人系统和选品系统**。

在《19 | 如何快速搭建一个推荐系统？》中，我们提到了可以用用户画像和物品画像来辅助运营。这里我们所讲的工具，也是**从用户画像和物品画像所衍生出来的**。在推荐系统或者某些研发算法场景，**我们所使用的用户画像和物品画像往往以特征数据的形式呈现，尤其是在现在深度模型流行的情况下，只需要把这些特征数据压缩成向量表示即可**。这种形式的用户画像和物品画像对于神经网络来说是可以接受的，但是对于运营人员则没有任何意义。

**在圈人和选品系统，主要使用的是用户画像和物品画像标签化的结果，而且标签通常都是有限个的，以方便运营人员查看**。

**圈人系统往往包含个体画像、群体画像的展示，包含用户分群功能，以及数据透视功能**：

*  **个体画像是对于单个用户的总体情况进行展示**，主要用于运营抽样分析和检验圈人的实际情况；
 *  **群体画像则是对已有的标签所包含的人群分布进行展示**，以方便运营人员圈选人群前进行观察和思考，比如说用户年龄段的分布情况，用户在兴趣维度上的分布等等。

**圈人功能则是这个系统的主要功能，通过运营人员可以理解的标签，对用户进行圈选，以用于某个运营策略**，比如我们上面要对亲子用户进行运营，这里就是用兴趣标签【亲子】即可筛选出对应的用户群。

最后的数据透视，则是对于圈出的用户群进行初步的分析，以确保圈出的结果和运营想要的一致，比如展示圈出人群的总数、性别比例、消费能力等等。在筛选完人群之后，通常可以把人群列表自动化对接到后续的功能上，比如说小场景的推荐，或者是定向 Push。

下图即是某圈人系统的界面，可以看到，所有用户画像都已经标签化，运营人员可以针对自己需要的人群标签进行选择，**在右侧可以配置不同标签条件的与或非关系**，从而生成所需要的人群列表。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 19]  
**与圈人系统相对应的选品系统，亦是同样的逻辑**。基于我们对物品的数据挖掘和分析，并把结果标签化为运营人员可理解的有限个标签，在同样的一个系统上进行单物品展示、属性总览，以及物品圈选和数据透视，通过运营人员对所需要物品的筛选，生成一个物品列表，等待使用。

**通过对用户和物品筛选的平台化，辅助运营加速了对“人”和“货”的挑选过程，对已经筛选好的用户和物品，接下来就是投放到某个“场”，完成运营的执行动作**。当然，**对于投放环节也可以建设相应的平台来辅助运营**，常见的有触达平台或者营销平台，有兴趣的同学可以在课下进行了解。

**总结**

**数据化运营是数据驱动的典型产物，大数据体系给数据化运营带来了更加便捷的施展空间**。在未来的时间，存量竞争更加激烈，谁更擅长使用运营手段提升用户体验，谁就更能获得长远的发展。通过数据化，可以使运营更加精细化，甚至精益求精。而**大数据辅助运营，则可以通过历史决策现在，通过现在预测未来**。

我们这节课，介绍了数据化运营的基本思路，以及在做细化拆分时常用到的两个指标模型，当然**关于数据化运营的指标体系远不止这些**，不过我觉得这两个对于初学者已经足够。最后的部分，我介绍了借助大数据体系中的能力所形成的辅助运营系统，辅助运营也是大数据体系的能力之一。当然，我这里所讲的都比较简单，在实际的工作中更加复杂多样。希望你也不要受限于这里所讲的内容，在工作中结合自己的环境多挖掘新的玩法，创造更大的价值。

# 21 | 大数据环境下如何保护隐私? #

上节课我讲到数据化运营针对部分用户和物品做出了精细化的运营动作，说到用户圈选那必然会涉及大量的用户信息，如果作为一个用户你可能很担心，我的信息会不会被泄露，会不会被用来干一些不好的事情？尤其是在当前大数据盛行的时期，一个公司可能掌握了全国甚至世界上很多人的私密信息，包括你的基本资料，也包括你的言语甚至是你的行动轨迹。如果说公司做不好数据安全的工作，把这些信息泄露到一些不法分子的手中，那么会产生非常危险的后果。**不仅仅是自身企业的信誉受损，用户的权益受到损害，这些数据被人利用还可能危害社会甚至是国家的安全。因此要做好数据安全工作不仅仅是技术上的，更是公司管理上的重点，需要一系列的制度流程和技术手段共同来保障数据安全**。这节课，我们就来讨论一下关于数据安全的一些事情。

**数据安全问题**

我们的大数据体系之下囊括了各种各样的数据，从数据的生产开始，大量数据源源不断地进入我们的大数据平台中，被加以处理和利用。自然，大数据给很多公司带来了大量的收益，也给用户提供了很多便利的服务，为社会创造了很多价值，但是，**与之伴随而来的，是各种各样的数据安全问题**。在这里，我们先来看一下在大数据体系之下，或者说我们的公司中都会存在着什么样的数据安全问题。

**1.硬件安全**

首先是硬件方面的安全问题。比如说我们的**硬盘、内存、CPU 等，虽然硬件的使用周期很长，但是这些设施长时间使用仍然会有故障出现**，尤其是在大数据下，服务器数量众多，大公司或者云服务供应商动辄就有成千上万的服务器。除了本身的故障问题，还可能受到自然灾害、人为破坏的影响，**如果硬件发生大面积的问题可能导致我们的服务出现问题**。

**2.平台安全**

平台安全主要是指我们的大数据平台，其中用到很多工具，这些内部使用的平台工具虽然经过很多经验丰富的开发人员开发和使用，但是仍然难免存在着一些缺陷或者漏洞，以及在遇到一些攻击时，可能在某些环节产生数据泄露。

**3.服务安全**

第三个是提供服务时的安全问题。**大数据平台当然不是只放在那里就可以了，我们使用大数据平台来建设公司内部的能力，从而能利用这些数据对外提供服务**，包括我们对用户提供的服务和我们内部的服务，比如上节课讲到的圈人系统。对于这些服务，面临的安全风险就更多了，因为这些服务有很多对外暴露的地址、端口等访问方式，如果其中存在一些高风险漏洞就可能被不法分子利用。

**4.流程安全**

上面三种可以说都是基于数据的容纳场所的安全，不管是服务器还是大数据平台，数据在上面存储和流转，如果它们本身存在安全问题数据当然是不能幸免的。

但是在我们日常的工作中，数据并不只是在这里面存放，而是会有很多的人在使用这些数据。不管是数据分析师通过大数据平台进行分析，还是数据挖掘同学把数据转移到 GPU 机器上进行运算，都是使用数据的正常流程，但是在这些流程中，数据安全问题也非常值得关注，不然在数据经过几次复制转移之后，到底有多少数据流出去，到底有没有重要数据被泄露，已经没有人说得清楚了。

**数据安全的技术方案**

可以看到，在我们的公司中，面临的数据安全问题很多，所以要严加防范，那么在一般情况下都有什么样的技术方案来解决数据安全问题呢？

**1.安全分级**

**首先我们可以对数据的安全等级进行划分**，比如说：

*  用户的真实信息为最高密级；
 *  用户的相关信息为次高密级；
 *  用户的行为信息为一般密级；
 *  公开信息为最低密级。

依照制定好的数据安全等级，在不同的环节给予不同的处理方案，比如说在数据的存储方面，给高安全等级的数据增加更多安全硬件设施；在权限审核上更加严格等等。

**有了比较明确的安全等级，也方便对数据安全问题进行监控，一旦发生数据不合规的数据传输，方便确认风险大小**。如果没有明确的安全等级，对我们的大数据中所有数据一致管理，要浪费很多资源不说，同时在发生问题时也很难确认该如何处理。

**2.权限认证**

在大数据体系中，会有很多环节和工具涉及数据的存储和应用，同时，在公司中还有很多的系统会涉及这些数据的使用。在公司层面统一一套权限认证的标准，对于不同安全等级的数据，对使用方采取统一的权限管理，不管是个人使用还是系统使用，都可以接入这个权限认证体系，这样**既可以节省数据流转时各种烦琐的申请和审批手续，又可以对数据的应用情况了如指掌**。在大数据工具中，有一个通用权限认证解决方案：Kerberos，可以为我们前面提到的很多大数据工具提供权限认证服务。

**3.资源隔离**

资源隔离方面，通常采用的是**多租户方案**，也就是在**一套硬件上，为不同安全等级的数据建设多套架构服务**，比如说对于大数据中的存储 HBase，对高安全等级的数据使用一套单独的 HBase存储，对低等级的数据采用另外一套Hbase存储。这样在操作的时候都是分隔开的，也方便对数据的监控。

**4.数据加密**

数据加密很容易理解，也是很早就有的技术了。简单来说，**加密技术就是通过一些变换算法，把原本的数据处理成不可读或者没有意义的数据，只有加密人本身知道如何将加密后的数据还原**。

之前去平遥古城，那里的日升昌票号是中国第一家银行，他们的汇票就已经在采用加密技术，比如把 1 到 12 个月用文字“谨防假票冒取，勿忘细视书章”进行替代。

对于不同安全等级的数据，我们可以采用不同等级的加密技术，同时在数据的传输和存储环节也有不同的加密方案。加密技术是一门涉及很广的课程，**现代密码技术一般分为对称加密和非对称加密**，如果对这方面感兴趣的同学可以去学习一下密码学。

**5.数据备份**

**数据备份主要是防止发生大面积的网络问题、数据丢失情况，以及人为破坏或者自然灾害等不可以预料的问题。针对不同安全等级的数据，我们也可以采取不同的备份策略**，比如对于安全级别高的数据采取实时的多存储方案，对于低安全级别的数据定期进行备份等。

**6.数据脱敏**

**数据脱敏一般是对数据监控环节进行的**。对于安全级别较高的数据可以认为是敏感数据，比如说用户的姓名、手机号等，但是在数据传输或者使用过程中，往往会跟其他部分混杂在一起。在对数据的流转进行监控的过程中，如果发现涉及敏感数据，可以对数据进行替换、隐藏等等操作，以防止敏感数据泄露。这种方案一般是针对数据对外开放的时候采取的措施。

**7.分享水印**

**针对数据分享时候的安全问题，除了脱敏还可以采用水印技术**。不管是内部的可视化平台，还是对于可分享的文件、图片或者 PPT 等资源，统一加入水印来标记。在一些公司分享的资料中，你经常会看到一些可见的水印标记，当然，对于数据也可以加入一些隐藏水印，达到安全防护的作用。水印技术虽然不能防止数据泄露，但是能够通过水印追踪负责人，**属于一种事后手段**。

**除了这里所讲到的技术手段，公司在面对数据安全问题的时候，还需要配合管理手段来建立一套比较完善的数据安全管理机制**，对公司内的人员进行宣传教育，提高大家的防范意识，并且在数据生产、数据存储、数据传输、数据应用等环节进行**事前的保障、事中的监控、事后的追踪**。

**个人如何注意隐私保护**

**虽然说公司在内部通常都会注意数据安全的问题，但是仍然免不了存在这样那样的问题，导致数据泄露到不法分子的手中**。正如我们经常在新闻中看到的那样，2014 年 12306 网站旅客信息泄露；2016 年 12 GB 用户信息泄露；2018 年华住酒店 5 亿条数据被出售。类似的新闻层出不穷，我想在未来的一段时间里，仍然无法完全避免这种事情的发生。对于个人来说，完全不使用大数据相关的产物在这个时代几乎是不可能的，那么该如何注意保护自己的隐私呢？

**1.不使用一些来路不明的 App**

对于正规公司生产的 App，因为其受到比较严格的监管，一般都会注意数据安全的问题，他们至少不会主动去出卖你的信息，而且一旦你因为他们的问题造成损失，他们需要承担相应的赔偿。但是有很多 App 和一些分享链接的目的就是套取你的信息用于出卖，这类 App 一般都通过个人的方式发布，没有明确的公司名称，平时在下载的时候应该注意区分。

**2.对不同等级的 App 使用不同的密码**

譬如我可能会把 App 区分成**金融类**，像支付宝、微信以及银行 App 都属于这一类，直接跟自己的资金账户相关，对这类 App 设置足够复杂且不同的密码，同时使用指纹开锁等加密措施。

对于一些我可能要支付，或者发布信息的 App，比如知乎、豆瓣，则密码可以相对弱一些。

最后一级是**纯浏览型的 App**，比如抖音、爱奇艺，我只是看上面的东西，对于这类 App 基本上都是使用相同的密码，即便是被盗了也不会对我有什么损失。

**3.发布信息注意避免隐私**

大数据时代，用户自己发布各种信息变得十分方便，但是你发的这些东西如果不注意，很可能对你造成损失。比如说你彩票中奖了，把彩票发到网上被别人冒领了；或者你把带有身份信息的东西，比如身份证照片发到网上，被人用来注册 App 或者拿来贷款，都是有可能的。所以，**发布信息一定要注意区分，如果里面的信息会通过某些联系关联到你，那么就要谨慎了**。

**4.不贪小便宜**

最后一点，也是最重要的一点，不要贪小便宜。**一切盗取数据行为的目的都是为了从你这里谋取利益**，比如通过你的下单信息给你发短信说要赠送东西，或者告诉你中奖了等等来吸引你的注意力，从而让你落入他的圈套之中。现在很多使用大数据的公司都有比较严格的校验系统，如果你不主动配合，只是使用你的信息，不法分子也很难利用你的信息来牟利，因此一定要注意不贪小便宜，对于各种送上门的东西保持警惕。

**总结**

这节课我们主要讨论了有关数据安全的问题以及应对数据安全问题都有一些什么样的技术方案。大数据体系虽然很好，给我们的生活带来了很多便利，但是它带来的安全威胁同样十分巨大，不管是在建设大数据体系的公司，还是接受大数据福利的个人，都需要对数据安全问题有清醒的认识，做好防范准备和应对措施。最后，我也基于自己的经验讲了一些个人该如何注意隐私保护的方法，虽然说个人在大数据的数据安全方面处于被动的地位，但是采取一些必要的措施，以及注意不要贪小便宜，还是可以把风险降到比较低的状态，希望可以对你有一些帮助。

# 22 | 数据中台：用大数据赋能业务 #

上节课我们介绍了数据安全相关的问题和解决方案，在我们的大数据体系中，有那么多的数据、无数的流程和纷繁复杂的工具和应用，似乎每一个环节都会受到数据安全的威胁。随着业务的不断扩张，部门越来越多，项目越来越大，每一个部门每一个项目都需要各自不同的数据，也会产出各自不同的数据，如果没有很好的统一协调管理，那么处在大数据之下的每一个人都像盲人摸象一样，各自看到的只是大数据的一部分而不是一个整体。这样我们在工作中就不能充分利用内部的数据，部门间的沟通和配合变得越发困难。

假设我们是在一个做内容的公司，**有着图片、视频、文本多种内容形式**，每一个形式的内容由一个部门负责，并有一个单独的 App。如果说每一个大的部门都有一套自己的数据挖掘小组，他们分别为各自部门的内容进行标签挖掘：

*  图片部门的人产出了一套标签，里面有一个叫“汽车”的标签；
 *  而负责视频的团队产出的标签里有“试驾”“自驾”“房车”几个标签；
 *  负责文本的团队产出的标签里有“汽车测评”“开车去哪玩”的标签。

他们在做着十分类似的事情，所产出的标签虽然含义雷同但是名称和 id 也都不一样，如果有一天我们需要不同部门的业务共同去构建一个包含了图片、文本、视频等不同形式的与“车”有关的 App 项目，要把这些内容对齐是多么困难。不仅如此，他们还可能在使用着不同的数据源，使用着不同的大数据工具，一个把数据放在 MySQL，一个把数据放在 HBase，一个把数据放在MongoDB，有着不同的更新时间、字段名称，可想而知，没有个半年甚至一年的时间，很难把这些东西理清楚。

**什么是数据中台**

很多公司饱受这些问题的困扰，想要改进却不知从何入手。这个时候，数据中台概念横空出世。说起数据中台的提出还有一个小插曲，据说早在 14 年，马云去参观芬兰的游戏公司 supercell，这个只有不到 500 人的公司通过一个中台组织负责开发游戏引擎、素材、算法等等，而具体的游戏业务都可以复用这些东西，创造了诸如《部落冲突》《海岛奇兵》《皇室战争》等多款策略游戏。回来之后马云受其启发，在阿里推出中台战略，推动 **“大中台，小前台”** 的组织调整。

说了这么多，到底什么是数据中台呢？有一个公开的定义是**通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径**。这个定义乍看似乎并没有什么特别的地方，感觉跟一个统一的数仓并没有什么区别，但是实际上这句话只是对于数据中台中技术方面的解读，从《阿里巴巴数据中台实践》的资料中我们可以看到，**数据中台所承载的功能是数据业务化，链接所有数据，赋能业务，数据中台距离业务更近，能更快速地响应业务和应用开发的需求，可追溯，更精准**。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 20]  
所以，除了技术方面的采集、计算、存储、加工等能力，数据中台更多的是要有业务能力，考虑业务的需求，而不是单纯做技术方面改进，**如何通过对数据的统一管理进而提升业务目标是数据中台最需要考虑的事情**。

**数据中台解决的问题**

**1.统一数据汇集**

要做数据中台，首先就需要有数据汇集的能力。如果说每一个业务都是一条高速公路，那么数据中台就是交通枢纽站。**各个业务所需要的数据，所产生的数据都流入数据中台，由数据中台对这些数据进行统一管理，这样一旦有项目需求即可从数据中台获取，而不需要再一个业务一个业务去了解沟通。数据汇集可能涉及大数据中的数据采集、计算、存储等各种工具**。

**2.统一数据管理**

数据只是单纯汇集起来并不能够说是数据中台，在数据中台需要有良好的数据管理能力。数据管理就是需要对现有的数据有很好的理解能力，现在有多少数据、不同业务所汇集的数据是否存在联系、数据的分布、数据的趋势如何等等，在这个环节，对统一数据进行整理分析以及可视化，除了前面的存储、计算还会涉及可视化、数据分析等。

**3.统一数据研发**

**数据研发是面向业务所进行的数据加工**。我们大数据的课程就是建立在数据有价值的基础上，所有的环节也都是为了从数据中获取价值而构建。从业务需求的角度考虑，对数据进行加工，从大数据中萃取业务价值，比如说提供统一的标签体系解决我们开头讲的小故事中的问题，就是数据研发所需要处理的事情。在这个环节，会涉及数据挖掘相关的技术。

**4.统一数据服务**

基于对数据的汇集、管理以及研发，数据中台是对全局数据最为了解的部门。同时，为了赋能业务，数据中台同时也要清楚地知道业务所需要的，并提供统一的数据服务以方便业务应用。对于一些通用的数据能力，比如说推荐系统、搜索系统也可以建设成统一数据服务，只需要为业务方提供自由的配置即可在需要的位置上线。

经过了上面几个步骤，数据中台自然而然解决了我们在工作中经常遇到的几个问题。

*  **部门协作**：一个项目往往涉及多个部门的数据，甚至是由多个部门合作共同完成，每一个项目都需要一次沟通协调，需要对当前各部门的现状和数据进行一番梳理，项目需求其实都比较类似，只不过有时候是这个部门主导，有时候是那个部门主导。在数据中台的支持下，项目主导者都可以在数据中台完成对各部门所需数据的了解，减少沟通成本，加强部门协作。
 *  **重复造轮子**：对于一个公司内部的应用，往往都存在着很大的关联性，比如说字节跳动的抖音、火山视频、西瓜视频都是以视频型内容为主的 App，里面关于数据的采集、存储、计算、搜索、推荐、用户画像及内容画像必然极为相似，数据中台则可以为其提供统一的数据服务，只需要一套开发人员，如果每个应用都单独建设将浪费很多人力，且生产出来的东西都是重复的东西。通过数据中台的功能复用，业务部门也可以更加聚焦在精细化运营上，专注于自己的业务特色。
 *  **效率问题**：在公司中一个项目的数据链路很长，比如在我之前的工作中，发现推荐出来的内容缺少了电视节目，首先从推荐查到自己的推荐池数据，然后又找到内容生产平台，最后发现是数据源头所取的数据表字段发生了变化，耗费了大量的时间。数据中台对数据统一采集和管理，使得此类经常出现的问题得以抽象出统一的解决方案，并在数据中台即可完成整个流程，大大增加了工作效率。

**避免落入中台战略坑**

自从阿里巴巴推出了数据中台的概念，并将数据中台在公司内部进行大力推广和应用，无数的 CTO、CEO 开始纷纷效仿。数据中台既然这么香，那是不是每一个公司都需要有一个数据中台呢？答案是否定的。数据中台的理想虽然很好，但不是每一个公司都有需要，而且也不是每一个公司都可以做成，我觉得在做数据中台的时候至少要考虑以下三个问题。

**1.是否有明确的业务需求**

**业务需求是搞数据中台的基础，如果说你的业务很单一，或者只有两三个重复业务，数据流程不复杂，业务部门不会交叉折叠，那么大概率你是不需要搞什么数据中台**，如果硬生生搞出来一个没有业务使用的中台，那只是徒增公司负担。

**2.是否有强有力的推动者**

只有需求还不足以支撑我们启动数据中台计划。由于数据中台是贯穿公司全部业务的，且工程量巨大，首先是需要投入大量的人力和资金，同时还需要各个部门共同配合来完成。如果说这样的项目没有自上而下的强力推动者，往往会半途而废，即便是勉强完成，也一定是缺斤少两，只是有一个数据中台的样子，而其可用性则会大打折扣。

**3.是否有明确的组织和制度**

强有力的推动者可以保障数据中台项目的启动和落成，但是后续的使用和规范则需要有明确的组织和制度进行保障。**数据中台不是一个一次性的项目，需要不断地进行迭代和升级**。随着业务的扩充、技术的发展，负责数据中台的组织也需要不断地提升自己的能力。在使用方面，如果没有良好的制度，随着时间的流逝，数据中台可能又会变成一个废弃的项目。

因此，**数据中台对于公司的问题是一个很好的解决方案，但不是所有的公司问题都可以通过数据中台来解决**。不要让数据中台成为 KPI 或者 OKR 的产物；也不要说公司业务缺乏发展动力，搞一个数据中台缓解老板的焦虑。数据中台不仅仅是一个技术型的项目，更多关系到公司文化、制度、组织多方面的协调，这些方面的能力都要具备才有可能完成数据中台的建设，否则可能就是一个消耗公司资金的累赘。

**总结**

这节课，我们介绍了如今非常流行的数据中台。数据中台的建设几乎可以囊括我们大数据课程中所介绍的方方面面，并在一个公司内部将这些能力、方法及应用进行统一，以达到一份付出，多份收获的效果。数据中台的概念如此庞大，它所产生的价值也必定是很巨大的，但是要建设数据中台，其开销和难度也不是一般的项目可以比拟的。因此，我们在后面还讲了数据中台避坑指南，对于缺乏需求、缺乏推动者、缺乏组织和制度的公司最好不要考虑数据中台的建设，因为这可能不会让你的公司变得更好，相反的，它可能把你的公司拖向深渊。

# 彩蛋 | 大数据时代，未来将去向何方 #

这一讲是在最后补加的彩蛋，我们的正课实际上已经结束了，但是关于大数据的学习还远没有结束。专栏中涉及的内容繁多且复杂，虽然我们在开篇词里已经整体介绍了大数据的内容，以及就业相关的注意事项，但是我想过了这么久可能你已经有所遗忘。这一讲，我们再来梳理一下大数据发展的脉络，并给你提供一些学习建议，希望能够帮助你进一步巩固已学习的知识，为未来发展打下坚实的基础。

**大数据的发展时间轴**

首先我们按时间顺序回顾一下大数据的发展脉络。大数据技术并不是凭空出现的，数据本身就存在，只不过随着软/硬设施的发展，突然进入了一个爆发时代，由量变引发了质变。当数据量发生暴涨时，很多原有技术无法充分满足现有的需求，因此才出现了大数据技术。

大数据的发展可以追溯到数据库时代，数据库的出现解决了数据存储的问题；后来数据的运算工具——Hadoop 的诞生，使得大数据的价值能够以更低的成本展示在世人面前。随后，大数据展现了百花齐放的景象，各种工具、技术、概念层出不穷。

在 2010 年的 Hadoop 世界大会上，著名的 BI 软件供应商 Pentaho 公司提出了**数据湖**的概念，数据湖把各种类型的数据不加处理地汇聚到一起，利用数据湖强大的大数据查询、处理、分析等组件对数据进行处理和应用。

后来，**大数据平台**出现，能够一站式解决大数据开发的问题，大数据的发展开始向业务倾斜，从技术逐步走向业务层面。

时至今日，阿里提出“**数据中台**”的概念：大数据不仅仅是一个技术问题，更多的是一个业务问题。在阿里的数据中台中，已经把数据和业务紧紧捆绑在了一起。数据中台更强调应用，离业务更近，强调服务于前台的能力，能更快速地响应业务和应用开发的需求。

**常见的大数据核心技术**

大数据的发展不仅是概念的变更，对于我们研发人员来说，更多的是核心技术的更迭。我们的专栏中也讲了很多核心技术相关的内容。

作为当前大数据技术的基石，**Hadoop 体系及其衍生工具**是一定要掌握的，其中的核心技术有两个，一个是用于存储的**HDFS**，一个是用于计算的**MapReduce**。在此基础上，扩展了数据库 Hbase 和 SQL 化工具 HIVE，与其搭配的还有用于数据传输的 Kafka、收集日志的 Flume，还出现了替代 MapReduce 的产品 Spark 和 Flink。

当然，不只有 MapReduce 存在替代产品，我们讲到的每一个工具在不同的生产环境都有若干替换产品。上面提到的都属于大数据的底层工具，负责提供数据传输、存储、计算，此外还有各式各样的数据挖掘工具、数据分析工具、数据可视化工具等，用于提炼数据价值，为我们的业务提供支持。

搭建这样一套庞大的核心技术层，业务目标当然不只是做一个数据报表这么简单。当前互联网公司大数据应用最广泛的就是**推荐系统和数据化运营**。

绝大多数互联网公司担任着平台的角色，通过平台向用户展示内容、商品或广告，吸引用户阅览、购买等。围绕着这些场景化需求，可以通过自动化的技术方案，利用机器自行学习用户特征和物品特征匹配，完成业务目标，这就是我们说的推荐系统；另一个常用的就是数据化运营，即按照用户的主观意愿进行定制化。当然，大数据的应用相当广泛，我们专栏并没有全部介绍，随着你工作的深入可以遇到更多应用场景。

**大数据相关工作的能力需求**

通过我们梳理的大数据发展时间轴，你可以发现大数据流行时间不算久，并且正处于一个高速发展的时期。可能你正在从事或是想要成为其中的一员，那么你应该具备什么样的能力呢？具体的技术能力我们在正文部分已经介绍过了，这里就不再赘述。下面我们来聊一聊应对未来的情况，你所需要的能力。

**专业基础技能**

首先还是专业基础技能，这也是最重要的能力。比如说你想成为一个大数据开发技术人员，你的专业基础技能就是掌握代码的编写；成为一个商业分析师，你的专业基础技能就是数据分析能力。

专业基础技能很容易考察，只需让你动手实践就可以判断你掌握的程度，当然所有职业最重要的能力都是专业基础技能，这也是你工作的基本职业要求。

**学习能力**

在这个快速发展的时代，大数据工具和核心技术发展也是日新月异。作为专业技术人员，首先你要学习的就是不同工具的使用。如果公司也处于快速发展时期，技术框架的迭代会非常迅速，你需要持续学习新技术并能快速运用到工作中。

当然，如果你有跳槽的打算，不同公司可能采用的不同技术框架，对内部系统的封装上面也存在着很大的差异，学习能力此刻会成为你适应环境的重要技能。

**业务理解力**

最后一项通用能力是业务理解力。大数据时代对技术人员的要求不再是单纯掌握技术，而是把技术应用在业务上面，产生业务价值。有关业务的理解，我们在数据挖掘、数据分析和可视化、数据化运营、数据中台的课程中都提到过，你可以参考学习。

大数据本身就是为了挖掘数据中的业务价值而存在的，所以你需要有很强的业务理解力，能够明白你所做的事情的前因后果，才能发挥最大价值，避免“技术自嗨”。当然，业务理解力比基础技能和学习能力培养更困难，需要你在工作中多观察、多思考、多提问。

往后的路还很长，或许你已经在这个行业里摸爬滚打多年，或许你正准备进入这个行业，又或许你只是在观望这里的情况，但是不管怎样，大数据的发展进程不会慢下来，反而会越来越快。之前是互联网行业，以后也会逐步过渡到传统行业，越来越多的公司将会利用大数据赋能自己的业务，从大数据中发掘业务价值，所以对大数据人才的需求也会越来越旺盛。

大数据的工具和技术千变万化，但是掌握上述三个能力，可以帮你在未来的工作中以不变应万变，不管你未来去向何方，都能成为一个合格的“掌舵人”。

**学习书单**

最后，我整理了一份书单，列出了与我们课程中一些重点部分相关的学习书目，帮助你加深理解。当然，不是说只看这些书就可以了，大数据相关的内容过于庞杂，只介绍书单都可以单独写一本书了。

我列举书单的目的是希望帮助你在某一点深入学习 ，一本书中可能引用到另外一本，或者另外若干本。如果你对某一个方向感兴趣，你可以从其中一本书出发，我相信很快你也能找到更多学习资料。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 21]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70]: /images/20221022/3133667d0e7442be94fefb475f90ad79.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 1]: /images/20221022/e63744386c93458d94263e20b6349f8d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 2]: /images/20221022/14230c8d9b5d401b898528189ada9419.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 3]: /images/20221022/90c83b3fc60342ff83e97783a555e862.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 4]: /images/20221022/a9a62b672aa548d08d2a1d58679577ea.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 5]: /images/20221022/249d776815174914a52b32d4471caee1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 6]: /images/20221022/5540fbc2450244f69a5f9745db16cfd7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 7]: /images/20221022/434b2ae28b7e49fc85b179ac0a449f32.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 8]: /images/20221022/8634370ffd5c45a78967a177ab590fa2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 9]: /images/20221022/02fbecbfe53545b180033889982d554a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 10]: /images/20221022/0e6319a91c9a4de18bd08869e8a36c33.png
[20210523232127735.png]: /images/20221022/6a6595d2da2a4fb7a32203c56eafa1ff.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 11]: /images/20221022/f78ac9d5aca24c2b9a1ca11035bc9342.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 12]: /images/20221022/7c5934dff61943c6b6589a526bbce14e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 13]: /images/20221022/364b29fbbd754b3283326352b8a67cc8.png
[Link 1]: https://cloud.tencent.com/act/pro/yuntuad?fromSource=gwzcw.3778317.3778317.3778317&utm_medium=cpc&utm_id=gwzcw.3778317.3778317.3778317&fileGuid=xxQTRXtVcqtHK6j8
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 14]: /images/20221022/5b8cc35cd2054fc6be44ba594491f251.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 15]: /images/20221022/44d1e566e04a457e9b1ede50d59b7042.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 16]: /images/20221022/b8ba3a6dab2b491ab190bdc26bf05d12.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 17]: /images/20221022/9634084e02a54591b749fb33df59235b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 18]: /images/20221022/d81ceab852fb4db19f5d7964c11de8a7.png
[SparrowRecSys]: https://github.com/wzhe06/SparrowRecSys?fileGuid=xxQTRXtVcqtHK6j8
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 19]: /images/20221022/1478a043c2bb424abf1a79fa6828d4ed.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 20]: /images/20221022/9d121a056869401f8d06755b2ac34ef8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MDk1MDU1_size_16_color_FFFFFF_t_70 21]: /images/20221022/9e49b9c75fc24d8f818fee8231004283.png