如何用数据赋能业务

原创张磊微盟技术中心

作者：张磊

本文为原创，转载请注明作者及出处

一、概述

在大数据时代，数据技术发展迅速，无论是计算能力还是存储能力，相比老一代数据引擎，都有了突飞猛进的飞跃，利用数据技术来驱动业务的增长，赋能业务，也已经是被大家广泛认同的概念。要能够顺利落地一个数据项目，需要技术和业务同学的协力配合，技术人员要加深对业务的理解，业务人员要知道如何去运用数据。

本文为大家介绍一下构建数据项目的基本要素，帮助大家梳理数据驱动的流程，从而顺利落地数据项目。构建数据项目分为4个环节，它们分别是：数据采集、数据建模、数据分析、数据应用。

二、数据采集

人们一谈到数据驱动，一般会首先想到酷炫的数据大盘，纷繁的数据分析，或者高深的人工智能，但其实在整体数据流程中最重要的，是数据采集。完整、准确、稳定的数据源，是一切数据技术的基石。

数据采集的对象一般有3类：

前端日志一般为用户端的操作行为日志，比如按钮点击，下拉框筛选，页面滚动等；后端日志主要是服务端日志，会依照业务逻辑记录对应的业务日志，如推荐、下单、支付等；业务数据一般指数据库数据，比如用户表，订单表等。

对于日志的采集，我们一般讲究“全”，“细”，“时”：

“全”是指覆盖面要全，在业务上要考虑各种用户的数据覆盖，如买方、卖方、平台方等全角度的数据；在应用端上要考虑 PC、APP、小程序等各个端的数据；在数据来源上要考虑前端、后端、数据库、甚至第三方数据源的采集；在量级上，我们要获取全量的数据，而非抽样的数据，尽量做到各种数据的全覆盖。

“细”是指日志数据要记录的细致，在埋点设计时不能唯需求论。因为需求只需要这5个字段，所以我只记录这5个字段，这会大幅度限制后续的数据探索和使用。我们一般通过事件模型来定义需要采集的信息，包括 Who、When、Where、How、What，来记录一个事件的完整信息，保证后续数据分析的弹药充足。

“时”是指时效性要高，比如双十一的活动，我们一定想知道实时的准确的活动业绩；又比如广告投放场景，我们也需要高时效的数据反馈，来实时调整我们的投放策略，这是真金白金的效果。高时效的数据价值普遍会比低时效的数据价值高，当然高时效也会带来成本的提高，所以时效性的选择也是基于业务的实际需要来确定。

在采集方式上，也有全埋点、可视化埋点、代码埋点等方式，各有各的优缺点，不同类型的产品，或者处在不同阶段的产品，应该基于自身的特点和需求，选择合适自己的采集方式。

微盟内部有自己的埋点管理平台，通过事件模型来定义和实现各个业务的点位注册和管理，并提供复合事件、开发测试、质量监控告警等辅助功能，大幅度降低了整个埋点流程中容易发生的沟通流程长、信息不统一、质量难保障等一系列问题。

三、数据建模

当我们讨论建模时，首先要明确一个点：一种模型一般是为了一类需求而建立的，换一个需求，原本的模型可能就行不通了，我们工作中并没有以一概全、一劳永逸的数据模型。

下面介绍几种数据仓库中常用的模型：3NF，维度模型，Cube 模型，宽表模型。

1.3NF模型

第一范式：保证每列的原子性，表中的所有字段值都是不可分割的原子值。
第二范式：保证每行的原子性，表中所有行都有主键，其他字段的值与主键一一对应。
第三范式：保证每张表的数据是原子性的，表中数据不存在冗余关系。

学过计算机的同学都学过数据库原理，其中 3NF 应该是一个核心的知识点。3NF 是一个数据库建表的设计原则，主要应用于业务系统数据库中，能够很好地支持 OLTP 过程，但 3NF 由于太过于严格，模型的易读性差，实现复杂查询的难度高，在数据分析的场景中是不适用的。即使是在现代的业务系统中，也不会严格的去遵守 3NF 模型。

2.维度模型

常见维度模型有2种，星型模型和雪花模型。

星型模型：

在设计星型模型时，我们把操作分为2类，一类是基础信息，也就是事实发生的前提，如商品列表，商户列表等；一类是操作结果的记录，也就是当时事实的记录结果，所以也叫事实表，如上图中的订单事实表，会记录什么时间，买了几个商品，花了多少钱。两类信息需要结合起来，才能知道完整的交易信息。

雪花模型:

雪花模型相比星型模型，维度拆表拆得更细，在早期存储资源比较昂贵的时期，用得更为广泛。拿地区维表举例，星型模型中字段可能有省 ID，省名称，市 ID，市名称，县 ID，县名称，其中省 ID，省名称，市 ID，市名称都会有大量重复存储，但在雪花模型中，省维表可能只有几十条数据。

3.Cube模型：

Cube 中包含所有维度数据和事实数据，其中维度可以做任意组合，一个包含 N 个维度的 Cube，会有

种维度组合。在上述订单例子中，你可以通过类目、月份、省这三个维度，统计订单量和订单金额，也可以砍掉一个维度仅通过月份、省来统计这两个指标，这个称为上卷，反之增加维度，称为下钻。

Cube 的实现方式有多种，拿 Apache Kylin 举例，他是一个预计算的 MOLAP 产品，他利用空间换时间，事先穷举这

组合进行预计算，保障查询时的响应速度极快。也有Clickhouse 这种即时查询产品，可以不做任何预计算，完全依赖明细数据来计算结果，保证了空间的利用率，再通过内部优化一定程度上缩短响应时间。

4.宽表模型：

宽表其实就是 3NF 的退化，在一张表里尽可能多的描述更多的信息，就是宽表。在早期资源紧张的情况下宽表是不可能存在的，在大数据时代随着存储成本的降低和查询能力的提高，在数据分析领域宽表的应用越来越广泛，前面提到的 Clickhouse 就是基于宽表模型来做深度优化，从而实现空间和时间都符合期望的优秀产品。

就如前文所说，一种模型一般是为了解决一类问题，不同模型的易读性、存储方式、数据完整性、查询性能，都是不同的，应该根据实际问题选择自己需要的模型。

在上文数据采集中我们提到了数据时效性，在建模阶段，也有离线和实时之分：

1.离线模型

离线模型一般将数据源利用工具同步至 HDFS 形成 ODS 贴源层，在 HDFS 中进行加工，最后可能将结果同步至 OLAP 数据库进行分析，也可能同步至 OLTP 数据库支撑业务功能。离线模型的分层方式，不同公司可能各不相同，有的4层，有的6层，有的甚至8层，区别基本都在 HDFS 阶段，不同的模型分层规范能够提供不同的灵活性、稳定性、可维护性等等。

2.实时模型

实时的分层模型会参考离线模型，但层数不会很多，实时数据流的处理方式也有所不同，实时模型一般会放在 Kafka 中，用到的维度表因性能考虑会放到 Hbase 等 KV 中，结果可能放在数据库，也可能放入 MQ 继续下发。

实时还有一种处理方式，利用高性能的OLAP数据库来实现准实时能力。比如基于Clickhouse，将明细宽表灌入 CK 后，利用 CK 强大的 function 能力将结果实时统计出来；比如基于 StarRocks，利用物化视图的能力，在 OLAP 内自动预计算。

总结离线建模和实时建模的区别，对比如下：

分层方式上，离线为了考虑效率问题，一般会利用空间换时间，层级划分较多；实时更多考虑时效性，分层较少，也减少了中间流程出错的概率。
存储上，离线更多基于 HDFS，实时更多使用 MQ 或 OLAP 数据库。
ETL 上，离线多基于 HIVE、Spark 等批处理，实时则基于实时计算引擎如 Strom、Flink 等。

推荐阅读

WKMS微盟密钥管理系统

须臾现码虫，一键纳乾坤——Hubble在微盟微前端中的应用

继续滑动看下一个