数据中台搭建

采集

存储

打通

使用

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

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

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

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

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

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

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

影响

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

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

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

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

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

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

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

用户中心

商品中心

交易中心

支付中心

营销中心

第一层是数据采集层

第二层是数据计算层

第三层是数据服务层

第四层是数据应用层

流程图例

说明

优点

缺点

说明

优点

缺点

埋点公共字段定义

浏览页面事件的接口定义

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

点击事件的接口定义

说明

优点

缺点

第一步：前端工程师同步异步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便会同步

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

数据域

修饰类型

修饰词

原子指标

维度

属性

派生指标

数据库

数据仓库

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

DIM层（Dimension，维度数据层）

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

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

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

图示

数据仓库为什么要建模

实战案例

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

召回方式

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

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

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

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

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

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

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

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

问题

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

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

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

优势

采用冷启动-保底算法