6 步搭建数据平台—从指标体系到相关技术

 

在开始介绍数据平台搭建的流程之前，先简单说说为什么企业需要搭建数据平台。

互联网与智能移动设备的迅速发展，使记录并保存用户的每一次日常行为及交易行为成为可能，这些信息以数据的形式保存下来，实现了各行业的商业数据原始积累。为了高效组织和利用海量数据进行商业决策优化，搭建数据平台是企业的不二之选。

搭建一套切合企业商业模式并高效运作的数据平台，主要有以下几个优点：一是可以使原来分散于各业务系统的数据实现体系化存储，告别取数低效与数据缺漏；二是能够实时监控业务 KPI，并通过数据分析，发现核心问题与一些依靠经验不能发现的潜在问题，提出有效建议，辅助决策，驱动业务快速增长；三是确保海量数据抽取、存储和计算的稳定性与安全性。

下面进入正题，本文将从以下 6 个步骤介绍数据平台搭建流程：

• 明确业务模式和现阶段战略目标

• 拆解战略目标，形成各业务环节的“第一关键指标”

• 第一关键指标再分解

• 数据需求上报

• 数据采集、接入、存储和计算的实现

• 数据可视化应用与输出 API

明确业务模式和现阶段战略目标

做事切忌知其然而不知其所以然。搭建数据平台之前，我们首先需要确定数据指标体系，而数据指标体系又是为企业的商业模式和战略目标所服务的。

因此，先跟公司管理层敲定业务模式与战略目标，我们才能知道指标体系怎么搭，数据平台该满足什么功能，为什么要满足这些功能，只有满足用户需求的数据平台，才是好的数据平台。

在这里补充一下数据指标体系的重要性。有人可能会问，为什么搭建数据平台之前，要先确定数据指标体系。

这是因为，数据指标体系将直接影响“数据抽取>数据存储>数据预处理与计算>数据可视化应用”整个数据平台功能实现流程。如果一开始没有做好数据指标体系的建设工作，后续将会导致无休止的修改。

对于业务部门来说，可能会经常发现缺少某个指标，然后进行频繁的数据需求修改，这样的修改会导致指标体系与报表结构的逻辑混乱，形成数据泥泞，分析师不得不花大量时间去理清指标关系和找数据；对于开发部门来说，频繁的需求修改会导致冗长的开发迭代周期，浪费人力物力。

拆解战略目标，形成各业务环节的“第一关键指标”

有了战略目标，接下来我们可以将其分解成更微观的目标，以便后续落实到数据平台上去，按照产品业务流程进行拆分是个明智的选择。

那么如何按照产品业务流程对战略目标进行拆分？我们需要对产品业务流程进行分解，明确各个环节所涉及的业务部门，可能产生的数据。这些信息我们可以通过对公司各业务部门进行调研得出。

最后我们以战略目标为中心，结合以上信息，并对业务部门负责人进行访谈，共同把战略目标拆分为各业务环节的“第一关键指标”。

这其实就是搜集数据需求的过程。

下面通过展示一个 SaaS 产品的简化业务流程来进行举例说明（图中内容仅为参考）。

图 1 某 SaaS 产品业务流程分解图

明确各个环节所涉及的业务部门，可以让我们有体系地去确定数据需求，并通过对这些特定业务部门的调研，确保各个环节的数据指标实用且全面。

明确可能产生的数据，可以让我们了解各环节乃至整个产品流程所产生的数据种类和体量，并启发我们敲定所需指标。 

而“第一关键指标”，来自于《精益数据分析》一书所提出的来的概念——“这是一个在当前阶段高于一切，需要你集中全部注意力的数字”，这有助于集中精力与资源解决特定阶段最重要的问题。在这里，我们把战略目标拆分成各业务环节的第一关键指标，作为部门核心 KPI。

关于思考业务环节第一关键指标的思路，除了与业务部门头脑风暴外，还可参考 AARRR 模型。对此，我以 AARRR 模型为基础整理了互联网产品常用的 38 个原始指标，可以作为指标池，图 2 列示了这些指标。

图 2 互联网产品常用原始指标池

第一关键指标再分解

有了第一关键指标和了解业务流程所产生的各种数据后，我们需要对第一关键指标进行再拆分，拆分标准为各种与当前业务环节及第一关键指标有关联的维度。

当然，我们也要跳出具体环节俯瞰全局，维度的划分不应脱离整个业务逻辑。 

下面我们以图 1 的“新增用户数”来举例说明，如何对第一关键指标进行维度下钻。

通常我们可以从以下维度对指标进行拆解（如图 3）。当然，我们要时刻谨记具体问题具体分析，不同的商业模式与产品的不同阶段，即使是同一个指标，划分时参考的维度也不一样。

图 3 新增用户数指标拆分维度

在通过“第一关键指标+维度”矩阵敲定所有数据指标后，数据指标体系的建立工作基本完成。

需要重点注意的是，必须与业务部门和开发人员明确每个指标的定义与计算方式，务必让所有人对此达成共识，否则后续大概率会因为各人对同一指标的定义不明确而造成数据采集出错与分析结果无效。例如，对于新增用户，我们定义的是注册并激活，而不是只是注册。

数据需求上报

走完前面三步以后，数据需求基本采集完成，数据指标体系成型，这个时候我们需要根据数据指标的定义和计算逻辑，填写数据需求上报文档并提交给开发人员。

数据需求上报文档有两个重要的作用：一是让各数据关联方（如业务人员、分析人员、开发人员）对数据指标有统一的定义认知，避免数据出错与降低沟通成本；二是其决定了数据如何传输、存储，并被如何分析处理。

数据需求上报文档应包含的内容如下所示：

图 4 数据需求上报文档的主要内容

为了保证数据上报的可行性和准确性，建议与开发人员一同敲定最终的数据采集、存储和计算方案。

数据采集、接入、存储和计算的实现

这部分主要是数据开发工程师等技术人员的工作，涉及概念与技术较多，我们分步展开。

1.数据源

先说说数据来源。企业的数据来源可分为内部数据源和外部数据源 。

内部数据源主要是个业务系统数据库和日志数据，外部数据源主要是一些爬虫数据或第三方数据。

这些数据按照结构形式又可以分为结构化数据、半结构化数据和非结构化数据。

结构化数据是指可以由二维表结构来逻辑表达和实现的数据，严格地遵循数据格式与长度规范，例如用户基本信息、订单信息等。

非结构化数据是指不适于由数据库二维表来表现的非结构化数据，包括所有格式的办公文档、XML、HTML、各类报表、图片和音频、视频信息等。

而半结构化数据是结构化的数据，但是结构变化很大，不能简单的建立一个表和它相对应。如存储员工的简历，不像员工基本信息那样一致，每个员工的简历大不相同。有的员工的简历很简单，比如只包括教育情况；有的员工的简历却很复杂，比如包括工作情况、婚姻情况、出入境情况、户口迁移情况等。

业务系统数据库的数据一般是结构化数据，日志数据和爬虫数据三者均有。

2. 数据采集

数据是采集到数据仓库的，采集过程的重点是 ETL，ETL 即抽取（extract）、转置（transform）、加载（load）。

会存在 ETL，是因为数据源的数据通常是以各种不同结构和方式存在的，且包含脏数据与无用数据，把数据源粗暴直接地不作加工就导入数据仓库是大忌。 

为了更好的理解内容，先补充一下数据仓库的概念。

关于数据仓库

我们日常所说的数据库，是面向业务的数据库，也称操作型数据库，用于支撑业务，主要对业务数据进行增删改查，典型数据库有 Oracle、MySQL 等。 

而数据仓库是分析型数据库，它把各种数据有条理地集合在一起，供企业多维度进行分析决策。正因如此，数据仓库有以下两个主要特点：

一是它是面向主题的数据库，数据按照主题域进行组织，这里所说的主题，指的是用户使用数据仓库进行决策时所关心的重点方面，如用户行为、订单等。

二是数据仓库是集成的和汇总性的。数据仓库的数据来自于分散的操作型数据库或日志数据等数据源，我们将所需数据从原来的数据中抽取出来，进行加工与集成，统一与综合之后才能进入数据仓库。

知道什么是数据仓库之后，也就不难理解为什么需要 ETL。

ETL 的具体过程如下：一是抽取，我们需要对数据源进行筛选，抽取出有用的数据；二是转换，此环节主要是数据预处理，也可以叫数据清洗，具体为删除对决策没有意义的数据与重复数据、处理缺失值、简单的汇总计算以及把不同的数据定义方式统一，最终形成符合数据仓库结构模式且有分析价值的数据；三是加载，即把转换好的数据加载到数据仓库里。

3.数据接入

在介绍数据接入工具前，我们先来大致了解一下大数据平台的架构，这也是为后续介绍数据存储与计算做铺垫。

关于大数据平台架构与 Hadoop

现今大数据平台采用分布式系统（分布式系统可以通俗理解为，海量数据的存储和处理是一台计算机难以实现的，那么可以通过把数据分布在多台计算机形成一个分布式集群，实现海量数据的存储与处理），而 Hadoop 是主流的分布式系统基础架构，让我们可以充分利用集群的威力进行数据存储和数据计算。

Hadoop 以 HDFS 和 MapReduce 为核心，HDFS 是分布式文件处理系统，为海量数据提供分布式存储，而 MapReduce 是分布式数据处理和执行环境，用于对大规模数据集进行运算。在这些基础上，部署了众多用于数据接入、存储和计算的工具，这些工具都是 Hadoop 生态组件，主要有 Hive、HBase、Sqoop、Flume。

对于业务系统数据库的数据，我们一般用 Sqoop。Sqoop 是一款 Hadoop 和关系型数据库之间进行数据导入导出的工具。借助这个工具，可以把数据从诸如 Oracle 和 MySQL 等关系型数据库中导入到 HDFS 中，也可以把数据从 HDFS 中导出到关系型数据库。

对于业务日志类数据，则需要用 Flume。Flume 是由 Cloudera 提供的高可用、高可靠、分布式，进行海量日志采集、聚合和传输的系统，后成为 Hadoop 组件之一。Flume 可以将应用产生的数据存储到任何集中存储器中，如 HDFS。

4.数据存储

数据存储涉及 Hive 和 HBase，二者都是基于 HDFS 的数据（仓）库。 

结构化数据存储在 Hive，并通过 Hive 实现数据离线查询。Hive 是基于 Hadoop 的一个数据仓库工具，以 HDFS 为基础，可以将结构化的数据文件映射为数据库表，并提供简单的 SQL 查询功能，将 SQL 转化为 MapReduce 进行运算，避免使用者撰写大量且复杂的 MapReduce 代码，降低使用门槛。

非结构化数据存储在 HBase，且 HBase 能实现 Hive 所做不到的数据实时查询。HBase 是分布式的、面向列的开源数据库，同样以 HDFS 为存储基础，以 MapReduce 为数据处理基础。

5.数据计算

海量数据的计算处理涉及 MapReduce 和 Spark。如前文所述，MapReduce 是 Hadoop 两大核心之一，用于对大规模数据集进行运算，关于其计算原理，涉及内容较多且技术性较强，在此不展开说明。 

那么 Spark 则是 MapReduce 的替代方案，通俗点也可以说是 MapReduce 的升级版，Spark 现今已经成为大数据计算领域的核心，它弥补了 MapReduce 不能处理较为复杂的多重计算需求（如迭代计算、机器学习）问题，且算法性能相对 MapReduce 提高 10-100 倍。

数据可视化应用与输出 API

需要有这么一个应用程序，业务人员可以通过简单的点击或拖动来访问平台中的数据，而平台计算的数据结果也能以可视化的形式来展现，这就是数据平台的数据应用层，是做可视化 BI 分析的地方。

这个时候，可以直接对接主流的 BI 系统，如 Tableau。

图 5 Tableau 操作界面

我们也可以自建 BI 应用，这就涉及应用终端的功能设计与开发。这里所说的应用终端的功能设计，我指的是该应用应包含哪些分析功能、报表和数据看板等，形式上可以参考市面上的一些产品。但有时会存在 BI 系统或者终端应用的功能不能满足分析需求的时候，或者业务人员想直接获取数据仓库内的数据，这个时候通过输出 API 来实现。

除此之外，很多企业也开始抛弃 BI ，或在 BI 的基础上引进一些市面上已经非常成熟的集数据分析与用户行为分析一体的数据平台（如神策分析），以此省去企业自身建造数据平台的投入和试错成本，特别是对于创业型和正在转型的公司，借力市面上已得到市场验证和认可的产品减少与资金雄厚的市场巨头的差距并逐步超越是目前的最佳选择。

图 6 神策分析电商 demo（数据均为虚拟）

结语

事实上，前文中的步骤 1-4，有关搭建数据指标体系和采集数据需求的部分，具有通用性。但对于数据平台的搭建技术，视企业的数据量大小和预算高低，技术方案会有所不同，不能一概而论。

注：本文为 VanessaChao 投稿，文中观点不代表神策数据立场。

标签：指标,存储,数据库,平台,数据仓库,指标体系,数据,搭建
来源： https://blog.51cto.com/u_14438762/2901686