首页  思维导图  详情

【读书笔记】数据中台-手把手教你搭建数据中台

2021-06-17 14:17:20   5  举报





AI智能生成

为你推荐

查看更多



数据中台

数据中台与数据治理流程

数据中台

手把手教你搭建数据中台

作者其他创作

大纲/内容

数据中台-手把手教你搭建数据中台

第一章：数据中台入门攻略

章节介绍

让你快速了解中台基础知识

什么是中台

什么是业务中台

什么是数据中台

为什么要搭建数据中台

什么企业适合搭建数据中台

业务中台

是中心化的能力复用平台

数据中台

数据中台可以承担公司所有产品线的数据分析工作，通过数据化的手段为各条产品线赋能

数据中台主要承担四个方面的工作

采集

指采集各条产品线的数据（如业务数据、日志数据、行为数据），并将这些数据集中处理，存放在数据中心

存储

是用更加科学的方式存储数据，业内一般使用分层建模的方式，让采集上来的数据变成公司的数据资产

打通

一方面要打通用户的行为数据和用户的业务数据，从而构建更加丰富的用户画像

另一方面要打通产品线之间的数据

使用

是用打通后的数据赋能业务人员，帮助领导层进行决策，用数据来反哺业务

最终目标是要帮助企业实现数据智能

业务中台与数据中台有什么关系

业务中台的目的是让一切业务数据化

数据中台的目的是让一切数据业务化

公司内部是否存在业务中台有何影响

如果公司已有业务中台，则搭建数据中台会相对容易，因为业务中台已经整合了公司内所有产品线的业务模块，使通用的业务数据都被统一存储到业务中台，这样就不用再对每条数据线单独进行调研，沟通成本会大大降低

如果没有业务中台，也可以搭建数据中台，只不过工作量要大一些，要从各条产品线分别采集数据

什么企业适合搭建中台

从短期来看，中台的建设成本比较高

业务中台要具备支撑公司所有产品线的核心业务能力

数据中台要支撑公司所有产品线的数据分析相关工作

影响

短期：一旦开发相关系统，则前期投入比较大

长期：公司在搭建好中台并具备核心的业务能力和数据能力之后，再去扩展产品线时，新建产品线所需的成本就没那么高了，新产品线只需接入中台即可，所以长远来看，中台还是能降低企业研发成本

如何判断企业是否适合搭建中台

判断的依据是看该公司的产品线数量

如果该公司有多条产品线（至少三条产品线以上），各条产品线之间有很多可复用的功能，则该公司适合搭建中台

初创公司不适合搭建中台，因为搭建中台需要投入大量的人力，物力成本，且初创公司在前期产品线单一

实战案例

产品线图例

案例背景

一家服装批发业务的互联网公司，有三条业务线，公司的角色就是搭建一个产品互联网平台，从服装的生产到销售，再到运输都无缝的连接起来，从而打通服装产业的上下游

打版服务

给原创设计师提供服装打版/生产的平台-对接打版厂家

电商服务

快递/物流服务

案例说明

每条业务线都会用到用户、支付、营销活动等模块，业务中台把这些功能进行模块化封装，使各条产品线都能更快的搭建自己的基础功能，做到一切业务数据化

数据中台对每条产品线的核心数据进行回收，通过销售数据反哺生产和供应链，做到一切数据业务化

业务中台架构

架构图例

架构说明

业务中台的底层是数据存储层

可以根据公司业务量的大小，选择合适的数据库存储

再往上一层就是业务中台的核心部分

业务中台的特点是作为中心化的能力复用平台

常见通用模块

用户中心

用户中心是每个互联网产品都会用到的，只是每个互联网产品的用户类型不一样

比如注册、登录、账号的管理、用户基础信息的管理等这些通用功能的数据会被存储于业务中台中，但是那些偏业务的十分个性化的数据则不会，还是会被分散存储在各个应用中

商品中心

商品中心汇集了商品生命周期的所有信息

商品的数据都汇聚在一起，十分有利于数据中台的商品数据分析工作

交易中心

交易中心主要与订单的生成和状态管理相关

对于不同的产品线，状态管理是不一样的

支付中心

支付中心需要处理各个支付渠道的对接（如支持支付宝、微信、银联等支付方式），还要处理支付后的对账，需要一套十分严谨的对账逻辑保证各条产品线的账目是平的

营销中心

如公司要做优惠券活动等的营销功能模块

与数据中心紧密关联，如选择什么用户参与活动，可以通过数据中台基于规则推算出来，而且在活动完成后，数据中台可以基于活动产生的数据做自动化的活动效果分析

数据中台架构

第一层是数据采集层

无论是业务数据库的数据还是日志文件的数据，都需要把他们抽取到数据中台中做统一的存放

一般数据工程师会用一些比较成熟的数据同步工具，将业务数据库的数据实时同步到数据中台，同时将离线日志数据以T-1的形式抽取出来整合到一起

第二层是数据计算层

海量的数据采用传统的存储方式是不合理的，业界一般采用分层建模的方式来存储

操作数据层（ODS）

维度数据层（DIM）

明细数据层（DWD）

汇总数据层（DWS）

应用数据层（ADS）

通过分层建模可以令数据获得更高效，更科学的组织和存储

为了保证数据指标的准确性和无歧义性，企业内部的数据指标需要通过一套阉割的数据指标规范来管理

指标的定义

指标的业务口径

指标的技术口径

指标的计算周期和计算方式

第三层是数据服务层

数据经过整合计算后，如何被调取和使用呢？

数据中台一般以借口的形式对外提供服务，开发人员将计算好的数据根据需求封装成一个个的接口，提供给数据产品和各条产品线调用

第四层是数据应用层

数据产品类型

针对内部的数据产品

一般用于服务公司的产品/运营人员/领导层

针对用户的数据产品

可以基于数据中台整合后的数据开发一些创新应用，比如个性化商品推荐

针对商家的数据产品

可以基于数据中台为上架提供数据服务，比如商品的数据依据和分析

开发流程

流程图例

第二章：数据采集

介绍数据中台的数据采集模块

如何通过数据埋点采集用户行为数据

如何采集产品线业务数据

为什么要进行数据采集

要采集哪些内容

怎么进行数据采集

数据采集的分类

用户行为数据

这类数据不会存储在产品线的数据库中，而是通过异步传输的方式传输并存储到数据采集服务器中

浏览数据

点击数据

业务数据

业务数据一般存储在业务数据库或业务中台中

业务数据库一般存放产品线的个性化的业务数据

业务中台一般存放通用的业务逻辑数据

数据行为数据采集

数据采集方式

与第三方移动应用统计公司合作完成采集

说明

前端开发工程师需要按照第三方公司的对接要求，集成第三方公司提供的数据采集SDK（即软件开发工具包）

一般来说，第三方公司会提供H5端、安卓端、IOS端、小程序端的SDK

前端开发工程师完成了SDK的集成，就能在他们的后台查看自己的应用的数据

优点

开发工作量少，一般每个客户端花费1-2天的开发时间就可以完成集成

而且数据分析相关功能都不需要开发，第三方公司回直接提供相关功能

采集到的数据相对来说比较准确，因为这些产品都是比较成熟的

缺点

产品线的流量相关数据比较丰富，但是因为只做了最基础的页面和按钮埋点，很难采集到产品线的业务数据

比如对于电商产品来说，我们不但要看坑位的流量，更要看坑位的转化率，而转化率这个指标就涉及交易额，但是第三方公司应用统计产品是无法获取我们产品的交易额的

能看到的数据有限

标准化的产品提供的都是标准化的数据

提供的数据很难同步到数据中台的数据中心

第三方公司一般不会提供这些数据同步的接口

采用前后端埋点结合的方式完成数据采集

针对各应用客户端做全面的埋点，后端开发相关埋点数据报表

为减少手动埋点的工作量，可从市面上选择一些开源的SDK做嵌入

选择好SDK后，可以进行下一步工作“定义埋点的接口文档”

采集的数据很全面，前端埋点已经有了一些通用的封装，前端工程师只需要做少量的开发

后端埋点解决了数据流失的问题，保证了关键指标数据的准确性

依赖前后端开发工程师开发埋点模块，每新增一个页面就需要增加埋点开发的工作量

埋点测的是也比较麻烦，测试工程师需要测试每个客户端并点击所有的页面和按钮，并在控制台查看参数是否设置正确

工作量比较大，需要依赖多个角色配合才能完成，整个开发过程比较繁琐

埋点公共字段定义

浏览页面事件的接口定义

商品详情页特殊字段信息定义

点击事件的接口定义

采用可视化埋点与后端埋点结合的方式完成数据采集

可视化埋点的主要特点是可以让产品/运营人员通过可视化的界面自行完成页面和按钮埋点配置

可视化埋点只能针对普通的页面和按钮等使用，这些页面和按钮只能用于采集公共的信息

这种方式统一了数据标准，进一步降低了埋点的开发成本

数据中台在和其他产品线进行埋点合作时，只需提供可视化埋点的SDK给各条产品线，并且定义好那些页面和按钮是必须进行埋点的，接下来让产品线自行完成埋点即可

由于产品的大部分页面和按钮属于普通的页面和按钮，不需要十分个性化的参数，故可视化埋点可以解决产品的大部分页面和按钮的埋点数据的手机

将埋点工作都交给各条产品线完成，就必须定义好合作的机制，讲清楚哪些页面和按钮在上线前是必须完成埋点的

可视化埋点没有解决重要按钮，重要页面的埋点问题，也没有解决后端埋点的问题，这个工作还是依赖产品线前端和后端开发一起完成

数据采集流程

用户行为数据采集流程图例

流程说明

第一步：前端工程师同步异步HTTP接口的形式将埋点数据发送到Ngnix服务器，通过Ngnix做负载均衡将日志文件采集并存储起来

第二步：通过如Flume之类的日志采集工具将埋点日志文件以消息的形式发送到Kafka集群

第三步：数据中台通过订阅Kafka集群的日志消息将日志文件存在在数据中台

业务数据采集流程图例

业务数据库产生的业务数据一般存储在关系型数据库（如MySQL、Oracle）中，存储的过程会产生Binlog日志文件，Binlog是一种二进制格式的文件，用于记录用户对数据库更新的SQL语句信息

Kafka MySQL CDC Connect读取了业务数据的Binlog文件后，通过CDC（Change Data Capture，意为“变动数据捕获”，是增量抽取数据解决方案之一，能够帮助识别从上次提取之后发生变化的数据）的方式将业务库变动数据记录到Kafka等下游来消费。

可以通过Python语言在Kafka消费基础上做一个调用，将生产者产生的数据消费到Hbase。这样当MySQL中有相应操作时，Hbase便会同步

数据埋点实战案例

采集通用信息，包括设备及浏览器信息、当前SDK信息、网络信息、经纬度、时间信息等。只要集成了数据采集SDK，数据采集SDK就会自动收集这些通用信息

通用信息字段定义

采集应用的公共信息，主要包含平台信息和页面信息

应用公共信息字段

制作埋点的页面列表，这里只列举商品详情页涉及的相关业务参数。当用户进入商品详情页时，系统要记录两个关键信息：第一个信息是当前商品ID（COMMODITYID），有了商品ID，就可以通过数据库查询商品的所有信息；第二个信息是用户从哪个位置进入商品详情页，可以通过坑位ID（SPMID）来记录流量的来源，有了流量的来源，我们就可以更加清楚用户访问的来龙去脉

埋点页面列表字段

制作当前页面需要埋点的按钮列表

第三章：数据存储与计算

介绍数据中台的数据存储与计算模块

如何打造一套高效、没有歧义的指标管理体系

介绍数据中台的分层建模体系

什么样的数据能成为数据资产

数据能成为数据资产就说明它一定是有价值的数据，没有价值的数据不能成为数据资产

如何定义数据指标

解决这个问题的核心方法就是拆解：将一个数据指标拆解到不能再继续拆解为止，这样就能够最大限度地保证大家的理解无误

图例

图解

首先定义出这个指标所属的业务板块和数据域，接下来定义这个指标的业务过程（如电商领域的加购、下单、支付等）。接着要判断这个指标是一个原子指标还是一个派生指标？如果是一个派生指标，这个指标的时间周期、修饰词分别是什么，通过什么衡量这个指标？最后要定义这个指标的统计维度是什么，这些维度的属性有哪些？经过这样一层一层的拆解，每个指标会归入不同的类别，因为每个指标都有各个维度清晰的定义，只要公司内所有人都以这份定义为准，歧义就不会产生

名词解释

数据域

数据所属的领域。例如，电商产品中的用户、商品、交易等大的功能模块都属于数据域

修饰类型

对修饰词的描述。如电商中的支付方式、终端类型等

修饰词

除了维度以外的限定词，如电商支付中的微信支付、支付宝支付、网银支付等

原子指标

即不可再拆分的指标，比如支付金额、支付件数等指标

维度

是指度量单位，用来反映业务的一类属性。常见的维度有地理维度（国家、地区等）、时间维度（年、月、周、日等）、订单的维度等

属性

隶属于维度。如地理维度中的国家名称、省份名称等都属于属性

派生指标

一组对应的原子指标、修饰词、时间周期就组成了一个派生指标

如何识别虚荣指标

那些和公司的增长无关且从中很难看出公司问题的指标一般都是虚荣指标，而那些能直接促进交易额的指标（比如上文提到的各个转换率）一般都是增长指标。区分两者的关键，就是看该指标能不能让我们采取相应的行动来促进公司的增长

数据模型设计

什么是数据库和数据仓库

数据库

用来存储业务数据

数据仓库

用来存储汇总后的报表数据

数据仓库的分层建模体系

ODS层（Operate Data Store，操作数据层）

ODS层数据是数据仓库的第一层数据，是业务数据库的原始数据的复制

例如，每条产品线的用户信息、订单信息等数据一般都是原封不动地同步到数据中台的ODS层中的。

作用是在业务系统和数据仓库之间形成一个隔离层，在数据中台进行计算任务时，可以以ODS层的数据为基础进行计算，从而不给业务数据库增加负担

DIM层（Dimension，维度数据层）

DIM层存储的是维度数据，如城市、省份、客户端等维度的数据

DWD层（Data Warehouse Detail，明细数据层）

DWD层数据是数据仓库的第二层数据，一般基于ODS层和DIM层的数据做轻度汇总

DWD层存储经过处理后的标准数据，需要对ODS层数据进行再次清洗（如去空/脏数据、去超过极限的数据等操作）

DWS层（Data Warehouse Service，汇总数据层）

DWS层数据是数据仓库的第三层数据，是以DWD层的数据为基础进行汇总计算的数据

DWS层数据都是各个维度的汇总数据，比如某日某产品线的访问用户数、收藏用户数、加购用户数、下单用户数、支付用户数等。

ADS层（Application Data Store，应用数据层）

ADS层数据是数据仓库的最后一层数据，以DWS层数据为基础进行数据处理

设计ADS层的最主要目的就是给数据可视化应用提供最终的数据。后端开发工程师基于ADS层的数据将最终数据结果以接口的形式展示给数据中台的应用层

图示

数据仓库为什么要建模

假设还是要统计某条产品线A当月的交易额，如果没有采用分层建模，那么数据统计就是以结果为导向的，直接提取业务数据库中的产品线A的订单时间、订单金额，然后筛选时间为当月的订单，并基于订单金额做汇总计算，最后通过接口的方式将数据输出到应用层

如果采用分层建模，第一步是将业务数据库的数据同步到ODS层中，将维度数据存储在DIM层中，第二步是通过DWD层丰富统计指标的维度，目前案例中的需求是时间维度，可以预先增加其他常用的维度如产品线、客户端的维度，第三步是在DWD层中汇总各个维度的交易额，第四步是基于现在的需求，计算出产品线A的当月交易额，在ADS层提供要显示的数据

建模前

数据模型设计的第一步就是要了解产品功能涉及的业务流程及数据存储情况。本案例中的这个功能的业务流程比较简单，大家都比较熟悉：新用户一般会先进入首页，发现了首页中感兴趣的坑位后就会点击并进入商品列表页，接下来用户会进入商品详情页然后“加购”商品，如果用户真对商品感兴趣，就会进行提交订单和支付的操作。用户行为数据（如用户浏览了商品详情页）一般存储在埋点日志采集服务器中，而下单和支付数据存储在业务数据库或者业务中台中。

ODS层模型设计

ODS层一般都是把业务数据原封不动地同步到数据中台的。我们先看一下案例中各个数据指标和数据源的分布情况。访问首页用户数、访问商品列表页用户数、访问商品详情页用户数这几个指标属于用户行为数据范畴，要统计这几个指标，我们需要记录哪个用户在什么时间在什么端浏览了哪个页面。在前面第2章笔者已经讲过，用户浏览和点击的行为数据，可以通过数据埋点收集起来，我们只需从埋点采集日志文件中抽取用户的行为数据到数据中台即可。

DWD层/DWS层模型设计

DWD层数据的粒度和ODS层数据是一样的，都属于明细数据。不过DWD层会结合DIM层的数据做一次轻度汇总。DIM层中存放的是一个一个的维度数据

ADS层模型设计

ADS层是面向应用的，其基于DWS层的汇总数据做最终的计算。ADS层会基于功能需求汇总数据，后端开发工程师只要通过接口的形式提取相应的数据进行展示即可

如哦公司只有一条产品线，那么完全没有必要搭建数据仓库，基于数据库已经足够做统计分析了，但是当公司有多条产品线，而且要做大量的数据分析工作时，那就适合搭建数仓

第四章：数据打通

介绍数据中台的智能化标签平台

标签平台是用户画像和推荐系统的基础，从宽表的定义，标签体系的搭建，标签的生成，用户的全选开始

如何打通用户的行为数据和用户的业务数据

如何打通公司内部各条产品线的数据，消除数据孤岛，释放数据的最大化价值

标签平台主流程介绍

目标

数据中台的标签平台需要能够为多条产品线、多种角色打标签

一个用户如果在多条产品线中产生了行为数据，都要通过标签记录下来，且标签可以被看到

公司内每条产品线都可以定义自己产品线的个性化标签，但产品线之间互不受影响

标签平台不但能给注册用户打标签，还能给潜客打标签

功能规划

数据宽表功能

用来存储用户、商品等所有的指标

用户宽表

商品宽表

标签体系功能

将各条产品线共用的标签和非共用的标签，按照统一的层级结构组织起来

为什么要建立标签体系呢？

一方面是让公司所有的产品线都用一个标签体系，这样采用统一的标准，可以大大降低沟通成本

另一方面是通过这个标签体系可以全局查看公司都用哪些标签、哪些用户用了哪些服务、某个用户都有哪些角色，这个也是数据中台打通公司数据的一个体现

标签体系一般是多层结构的，一般来说四层结构就可以基本满足一个公司的标签体系的搭建

标签工厂功能

可以基于规则选择指标生成标签

标签是怎样生成的

示例图

步骤

选择平台

平台给标签划分了一个大类，同时也可以解决权限问题。因为在这里提前选择了平台，当产品线A的运营人员查看自己产品线的标签时，就不能看见产品线B的标签

选择维度

标签是属于用户维度还是属于商品维度？维度进一步对标签做了分类，同时也决定生成标签时的数据源的选择，也就是上文讲到的宽表的选择

选择一级标签和二级标签

把新的标签归入标签体系，这样所有的标签都可以在我们标签体系中看到

定义标签

比如我们要给产品线A的新用户打上标签，新用户是根据他的注册天数这个指标来定义的，我们就可以用这条规则来选择应该给哪些用户打上新用户的标签

设定标签的计算规则

可以选择用户宽表或者商品宽表的指标进行等于、大于、小于等简单的运算

人群圈选功能

通过不同标签组合形成人群。该功能一般与推送、营销系统对接

RFM模型

R（Recency），即用户最近一次交易时间的间隔，R值越高，表示客户交易发生的日期越久，反之则交易发生的日期越近

F（Frequency），即用户在一段时间内交易的次数，F值越高，表示客户交易越频繁，反之则表示客户交易不够活跃

M（Monetary），即用户在一段时间内交易的金额，M值越高，表示客户价值越高，反之则表示客户价值越低

基于RFM的用户分群图例

第五章：用户分析

用户分析思路

用户模块的功能设计可以参考AARRR这个理论

拉新

活跃

留存

转化

裂变

用户拉新渠道注册码管理

用户拉新相关指标

用户拉新页面转化率

用户拉新ROI模型

用户活跃分析

用户留存分析

用户转化分析

用户转化模块要用一切合理的策略让用户下单。这里关注的指标有：首单人数、复购人数、首单率、复购率

用户裂变分析

裂变是现在互联网产品比较火热的拉新手段。裂变涉及增长相关的知识，而增长的本质就是把产品核心的价值传递给更多用户。一个产品有价值，它自然而然就会带有传播属性，所以要想实现裂变，那就必须先保证产品的价值

用户生命周期分析

逻辑关系图例

新用户如果长时间没有下单就变成了未激活用户，新用户如果有下单就变成了活跃用户，活跃用户如果隔一段时间没有下单就变成了沉默用户，沉默用户如果近期有下单也会重新变为活跃用户，沉默用户如果很久都没下单就有可能流失，变成流失用户，如果流失用户近期又有下单就会重新变成活跃用户

第六章：商品分析

商品数量规划

选品最终目的

其一，要满足平台用户的需求，针对这一点我们要思考我们的用户有什么特点、他们想要哪些商品、我们能提供哪些商品给他们；其二，对于电商运营平台来说，在提供用户需要的商品后，要思考如何使收入最大化

商品类型

引流款

跑量款

四季常青款

高利润款

商品售中分析

品类分析

针对品类价格段的划分工作，可以引入K-Means聚类算法，能够自动化的将每个品类划分出最合适的价格段

原理：通过K-Means聚类算法可以找到每个品类价格段的几个中心点，再通过中心点划分出价格段

商品售后分析

如何降低商品的售后成本、如何通过用户的反馈进一步优化商品，是这个阶段我们要关注的核心工作。商品售后分析应该重点关注商品的几个指标，包括次品率、48小时发货率、退货率

第七章：流量分析

核心问题

每天有多少个用户进入公司运营的平台，这些用户都是谁，他们都去了哪里，在哪个位置产生了消费，哪个位置的消费金额比较高，哪个位置的消费金额比较低

必备功能

网页分析

可以监测每个网页的流量数据。网页分析的指标包括PV、UV、浏览时长、跳出率

解决了“有多少用户来”“这些用户都是谁”的问题

要做网页分析这个功能，首先就要和各个业务产品线的产品经理沟通每个产品都有哪些网页、网页的地址是什么、网页名称是什么、网页有没有在数据库中被管理起来

可以协调产品线的产品经理输出一份现有产品所有的网页名称和地址，然后将这份网页表格导入数据库，并给网页定义统一的英文名称和中文名称，目的就是方便运营人员理解数据

路径分析

可以看到用户来了我们平台后主要的路径是什么，从哪个网页进来，又从哪个网页离开

解决了用户去了哪里的问题

坑位流量分析

可以看到产品的每个坑位每天产生多少流量、产生多少交易额

要实现交易额的统计，就要进行后端埋点。用户从坑位到商品详情页，再到加购页和下单页，整个操作链条都要上传坑位的ID。特别是在加购环节和下单环节之间有一个断层，用户今天加购，可能明天才下单，因此在用户加购时，必须把坑位的ID带入购物车，当用户从购物车取出商品并下单时，再将坑位ID带入订单。订单中要有一个字段用于记录商品的来源，即商品来源于哪个坑位。这样通过解析订单中的坑位ID就知道商品是从哪个坑位卖出去的

第八章：交易分析

自动化短信推送

业务系统一般会对接短信平台，短信平台可以设置短信的模板，在设置好短信模板后，由数据中台完成数据指标的计算并且完成定时器的设置，然后调用业务系统的接口完成短信的定时推送

交易来源分析

问题：用户在加购后并不一定下单，可能在一段时间后才下单，这样就给交易来源分析带来一定难度。因为当加购环节和下单环节之间有时间间隔时，用前端埋点的方式统计订单来源就会有一定难度，因为用户的行为是无序的，在加购环节和下单环节之间可能会有很多其他操作，所以很难通过用户的路径判断出用户是如何进入商品详情页的。另外因为用户网络的问题，前端埋点的方式会令数据产生5%左右的丢失率，也会给统计带来误差

解决方案：可以采用后端埋点的方式，在用户加购时就存储用户当时的客户端、来源类型（搜索、分类页、坑位等）、分类ID、搜索关键字、坑位ID、坑位名称等关键信息，当用户从购物车中将商品取出下单时，再将这些信息插入到订单中，也就是说，订单中要预留订单来源字段，可以使用JSON的形式记录订单的来源信息

购物频次分析和购物间隔分析

第九章：自助分析平台

介绍数据中台的自助分析平台

自助分析平台可以解决数据中台数据可视化的问题

有了自助分析平台可以帮助数据中台大幅度提升开发效率，让数据中台专注于数据开发和模型设计

业务人员可以通过数据中台配置专属自己的数据看板，形成了看板的千人千面

当前市场上较成熟的数据平台

GrowingIO

诸葛io

神策

快速入门三种数据自助分析可视化产品

帆软自助看板

第一个是商用收费的数据自助分析可视化产品叫帆软，其在国内做得比较好

制作报表过程

第一步：处理数据源，需要技术人员将数据中台的数据库与帆软连接

第二步：需要针对数据库中的字段做进一步处理

主要的工作是将数据库的库表字段转化为产品/运营人员可以理解的名称。数据库的字段的初始命名往往偏技术化，产品/运营人员不一定能看懂

第三步：产品/运营人员通过选择数据源、维度、指标，就可以通过拖曳的方式制作自己想要的图表

达芬奇自助看板

达芬奇是国内开发者开发的开源产品

第一步：开发数据源管理功能，该功能主要是给数据开发工程师使用的。数据开发工程师需要把计算好的数据（一般是ADS层的数据），连接到达芬奇上。达芬奇支持多种数据源的连接。输入ADS层数据库的地址、账号、密码就可以在达芬奇中看到ADS层的数据

第二步：抽取数据。还是那个问题，产品/运营人员是看不懂数据库原始数据的，因为数据库的字段命名偏技术化，需要把字段重新命名，所以还需要数据开发工程师使用SQL处理

第三步：使用看板制作器，该功能是给产品/运营人员直接使用的。运营人员看到的数据是经过上一步的技术人员处理过的

第四步：使用看板管理器，运营人员可以快速找到自己制作的看板，形成自己的看板界面

Superset自助看板

Superset是国外开发者开发的开源产品，和达芬奇功能类似，也有数据源接入、看板制作器功能，但是没有看板管理器功能。Superset也是比较偏技术化的，但是它的灵活性更高，图表的可视化功能可以与EChart对接

实战：数据中台集成达芬奇

部署达芬奇

方法1：实时处理：对接数据中台&达芬奇账户实时接口，当在中台创建/编辑账户后，调用达芬奇接口进行同步创建/编辑方法2：定时处理：当在中台创建账户后，定时调用达芬奇接口在达芬奇批量创建/更新账户信息

这个工作可以让开发人员按照达芬奇的部署教程完成开源项目的部署

部署达芬奇后，就要解决数据中台与达芬奇用户的登录互通问题。数据中台有自己的账号体系，达芬奇也有自己的账号体系，既然数据中台集成达芬奇，那么我们的目标就是在登录数据中台后，点击菜单就可以跳转进入达芬奇的各个功能模块

简单的做法就是定期将数据中台的账号导入达芬奇，当用户登录数据中台时，调用达芬奇的登录接口，也能完成达芬奇的登录，这样就实现了两个系统的互通

移植到移动端

目的

为了在移动端上也能查看PC端配置的看板，我们需要把达芬奇的“我的看板”功能集成到移动端

问题

登录问题，我们在数据中台的移动端登录的同时，要调用达芬奇的接口进行达芬奇的登录

PC端的“我的看板”功能包含一级菜单、二级菜单以及菜单页面的图表，我们只需同步达芬奇数据库中某个用户有哪些菜单、这些菜单的地址是什么。通过在移动端查询用户的菜单、菜单对应的地址，即可完成PC端“我的看板”界面在移动端的显示

我们究竟如何将PC端的“我的看板”功能移植到移动端

移动端的界面可以分为两层：第一层是菜单的名称，第二层是菜单的具体内容，由前端开发工程师基于菜单的地址加载图表即可。因为达芬奇的前端界面是基于H5开发的，所以在移动端可以自适应显示，这样就解决了用户随时随地在移动端查看图表的问题

两个关于权限的问题

关于数据表的权限

数据表的权限决定谁能操作哪些数据。达芬奇在连接数据库后一般可以授予开发人员全部的权限，接着，数据分析师或者技术人员可以基于数据库中的数据，通过SQL输出产品/运营人员可以理解的表结构，设置好哪个是指标、哪个是维度

关于图表的权限

图表的权限决定某个用户能看到哪些看板。当使用者制作好看板时，在“我的看板”模块就可以看到自己的看板，当使用者想分享自己的看板给别人看时，就可以用分享功能将看板分享给相应的用户，移动端“我的看板”功能也要增加一层逻辑，不但能看到自己制作的看板，还能看到别人分享的菜单或者看板

第十章：自动化营销平台

介绍数据中台的数据智能应用-全渠道的自动化营销平台

通过全渠道的自动化营销平台，业务人员在做营销活动时只需专注于策略的制定与选择，其他的工作都可以交给机器来完成

自动化营销平台的设计思路

通用流程

活动策划→圈人→做活动→看效果

哪些内容是由哪个中台完成

活动策划

活动策划其实就是对活动的管理，包括对活动的新建、修改、删除和推送任务的管理，这些都是比较业务化的场景，应该放到业务中台的营销中心中

圈人

圈人是对目标人群的圈选，要根据活动的需要制定相应的圈选规则，以圈选出一批合适的用户，这属于数据中台标签平台的范畴

做活动

做活动是对任务的管理，属于业务中台的消息中心范畴。业务中台的消息中心负责对接各种第三方通讯平台，可以让各条产品线十分轻松地实现对外的通讯

看效果

看效果是对活动效果的分析，这个步骤会产生大量的计算，因此该步骤属于数据分析的范畴，这个功能应该由数据中台来实现

营销活动触达任务

短信

自定义内容推送

模板推送

APP推送

站内推送

站外推送

第十一章：推荐平台

介绍数据中台的数据智能应用-推荐平台

介绍推荐系统的经典架构，几个经典的推荐算法

如何从0-1打造一个离线的推荐系统

如何从0-1搭建一个实时的推荐系统

推荐系统架构

功能架构

召回

召回就是通过一定的方式找到用户可能感兴趣的商品

召回方式

与用户喜欢的物品相似的物品

与用户有相似兴趣的用户喜欢的物品

基于用户的标签（用户年龄、性别等）推荐的物品

过滤

整理候选集内的商品，通过一定的规则，过滤掉其中有问题的商品，比如用户曾经买过的商品、质量很差的商品等

排序

每种召回算法都会给出一个推荐结果。推荐结果的形式基本上都是“某个用户喜欢某个商品的概率是多少”

技术架构

收集产品线的用户产生的数据，包括用户行为数据、用户业务数据，这些数据都可以作为实时推荐、离线推荐的数据源。用户行为数据通过消息队列传输到日志文件或者直接供实时推荐引擎使用。用户业务数据存储在业务数据库中，由数据中台同步到数据中台的数据仓库

执行实时层、离线层的计算任务。实时层采用流式计算框架（如Flink等）获取用户近一段时间或者近几次行为可能偏好的商品，再通过偏好的商品，从商品库中计算用户可能感兴趣的商品，形成商品候选集。离线层的计算任务一般执行一些离线算法，如基于用户的协同过滤算法、基于商品的协同过滤算法、排序算法等，离线层的计算任务偏重于根据用户的长期兴趣找到用户感兴趣的商品

整合实时推荐结果和离线推荐结果。实时推荐结果一般存储在内存数据库（如Redis）中，离线推荐结果一般存储在MySQL中。实时推荐结果和离线推荐结果会通过一定的规则整合起来，形成推送给用户的最终推荐结果

展示推荐结果。当系统前端发起请求查询用户的推荐结果（比如用户进入了“猜你喜欢”模块）时，产品线将通过接口的方式请求推荐系统，由推荐系统返回上一步整合出来的推荐结果

两种经典的推荐算法

基于用户的协同过滤算法

步骤一：找到和目标用户兴趣相似的用户

步骤二：找相似用户喜欢的且目标用户没有买过的商品，将之推荐给目标用户

用户数量如果比较多，则计算起来非常吃力，有可能成为计算任务的瓶颈

用户兴趣的变化还是很快的，但是算法很难反映出用户兴趣的变化

基于物品的协同过滤算法

步骤一：找到目标用户曾经可能喜欢的商品

步骤二：计算物品的相似度

步骤三：将相似度最高的商品推荐给用户