1.1 禧云大数据发展历程

知名咨询公司麦肯锡称：『数据，已经渗透到当今每一个行业和业务职能领域，成为重要的生产因素。人们对海量数据的挖掘和运用，预示着新一波生产率增长和消费盈余浪潮的到来。』良好的数据管理和处理技术，已经成为企业不可或缺的竞争优势。

禧云集团（以下简称禧云）将大数据列为企业发展战略，始终秉持『数据驱动』的理念，时刻跟随大数据发展趋势。经过几年的探索和发展，逐步构建起集数据管理、开发协作、自助分析、数据开放和运维管控等于一体的数芯大数据平台。

图1：数芯大数据平台

1.2 数芯大数据平台介绍

数芯大数据平台建设始终围绕『开放共享、数据赋能』的理念，为集团、合作伙伴的运营发展提供强有力的支撑和助力。经过多年的实践，逐步构建了从底层数据采集、数据处理，到数据应用服务以及数据产品的全链路、高管控、开放式的大数据体系。图2所示，是数芯大数据平台赋能业务全景图。

图2：数芯大数据平台赋能业务全景图

为覆盖数据处理的整个链路环节，数芯大数据平台建设之初，规划了数据资产管理、数据开放共享、开发协作调度、数据采集与迁移管理、数据可视化及自助分析、平台运维管控六大技术领域，分别对应数芯大数据平台的不同子系统，我们将在下章节中详细展开。

图3：数芯六大技术领域

从数据生产效率和对外赋能角度，数芯大数据平台又可抽象出数据产品体系、平台支撑体系和数据管理体系三大支撑体系。具体作用如图4所示：

图4：数芯三大支撑体系

本文以数芯三大支撑体系为章节，本着相互学习、交流的态度，详细介绍数芯大数据平台的建设过程。在当前『一切业务数据化，一切数据业务化』的背景下，数据已经成为企业战略和在市场竞争中取得优势的关键，因此我们以数芯大数据平台的数据管理体系开篇。

第二章：数据管理体系

禧云下设信息、数科、世纪品牌等诸多子公司，每个下属公司或关联ISV都独立运营，专注于解决团餐的某一领域业务问题。如果没有良好的数据管理体系，很容易造成数据烟囱式生产、信息孤岛等现象，无法为集团决策部门提供全面立体的数据支撑，大大地降低子公司间的协同增幅能力。

图5：数据管理体系图

如图5所示，数芯大数据平台数据管理体系在数据接入、数据仓库规划建设、数据集市方面制定了统一的规范，对接集团各子公司和关联ISV，可以构建同时面向集团、各业务单元和子公司的数据分析系统。数据湖、数据仓库和数据集市加上数据接入、数据清洗、数据生产等规范共同组成了数据管理体系。

2.1 数据湖

·数据湖作用

数据湖的定义以及与数据仓库的区别，目前业内还没有达成一致的意见，但许多企业已经开始实践。数据湖在禧云的实践是作为存储集团各子公司、ISV各种各样原始数据的大型仓库，其中的数据可供存取、处理、分析和传输。这样处理主要有以下两方面优点：

1. 数据统一存储，统一规划，可同时支持集团、各子公司和ISV的数据分析业务；

2. 与上游系统解耦，数据一次接入，多次利用，接入后的数据可用于实时分析和数据仓库建设等不同用途，减少与上游系统的耦合。

·技术解决方案

禧云数据大多为关系型数据库和键值数据存储等结构化、半结构化数据，基于数据吞吐性能和查询分析能力，我们选择Apache HBase（一个高可靠性、高性能、面向列、可伸缩的分布式数据库）作为数据湖的技术解决方案。

如图5所示，上游数据经过自研的数据迁移平台（第三章：平台支撑体系部分介绍）会批量或实时写入数据湖，利用Apache HBase列式存储的特点，数据迁移平台解决了上游数据元数据发生变更（例如：增加或删除字段）对数据湖的写入无感知问题。

·数据存储规范

为合理利用存储资源，根据数据的不同特点，对存储在数据湖中的数据制定了相应的数据存储规范，例如对交易流水等数据量较大的表，在数据仓库中做好数据分区和备份后，利用Apache HBase TTL（数据生存时间）特性，设置相应的生命周期（生命周期默认保存六个月，指从当前时刻开始向前六个月时间内产生的数据）。

2.2 数据仓库

为支撑集团运营发展和决策分析，禧云起建之初构建了完善的数据仓库体系，我们称之为离线数据仓库阶段。

随着市场竞争环境的不断加剧，企业对数据的时效性要求越来越高，为应对市场变化，从2019年3月份开始规划实时数据仓库的建设，到2019年9月份历时六个月实时数据仓库结项，中间实时数仓顺利支撑了团餐峰值周运营活动。

如图5所示，现阶段数据管理体系中的数据仓库包含离线数据仓库和实时数据仓库两大部分。

2.2.1 离线数据仓库

·数据仓库作用

离线数据仓库处理T+1（当日产生的数据，下一日才能看到）场景的数据，为企业运营发展提供决策支持。

如图5所示，离线数据仓库的数据来源为数据湖，可对接不同子公司的数据，为保证公司间数据相互独立和权限划分，禧云离线数据仓库以公司为主线进行建设。

·技术解决方案

数据仓库依托数芯大数据平台完整的大数据生态体系进行构建，数据存储为HDFS、离线计算框架为Hive、Spark、SparkSQL，采用Yarn作为资源隔离与调度框架。在数据分析处理方面，我们通过开发协作平台（详见第三章：平台支撑体系部分）来完成离线计算任务的提交、工作流调度、运行监控等工作。

·数据存储规范

这里的数据存储规范包括数据分层规范和数据命名规范两种，数据分层是数据仓库设计中重要的一环，良好的分层设计能够让整个数据体系更易理解和使用。三层模型、四层模型是业内比较通用的分层模型，由于数据湖的存在，我们省去了ODS层（操作数据存储层，存储原始数据），采用三层模型，为更好的理解和使用数据，我们重新命名了仓库层级。

表1：数据存储规范

2.2.2 实时数据仓库

·数据仓库作用

实时数据仓库主要解决数据时效性问题，禧云有许多业务场景需要数据的实时支撑，例如不定期举行的团餐峰值周活动，峰值周会将目标分拆到每一天，运营人员需要实时把控目标完成情况，及时调整策略，确保目标完成。换句话说实时数据仓库完成T+0（当日产生的数据，当日看到）场景的数据分析工作。

·技术解决方案

实时数仓内部数据流转如图6所示：

图6：实时数仓技术架构图

实时数据仓库的流式计算框架为Apache Flink和Apache Storm，在实时数据仓库未正式商用前，Apache Storm是主要的流式计算框架。随着Apache Flink的普及“批流合一”的计算特性，禧云内部Flink已经逐步取代Storm。实时数据流在计算框架里计算汇总后，写入Kafka消息队列，存入基于Druid存储的数据集市主题域中。关于Druid部分将在数据集市中详细介绍。

·数据处理规范

实时数据仓库层级概念体现在实时计算部分，我们大致可以遵循以下规范，即根据计算指标的复杂度，可直接计算完成（复杂度低），也可像离线数据仓库一样分层处理，分层之间用消息队列桥接。上述规范不强制遵循，但从数据重复利用（每层数据可用于不同用途）、出现问题排查角度考虑，建议分层处理。

2.3 数据集市

数据集市的建设在禧云一直是个痛点，整个集团目前还处于快速成长期，业务发展变化快，阶段不同侧重点不同，因此相同数据指标的定义在不同阶段会发生变化，很难固化成某一纬度的主题数据。再加上数据开发需求多，数据指标缺乏统一的规划和梳理，经常造成相同数据指标重复开发，不同报表相同指标项数据不一致的现象，给数据使用人员造成了一定的困扰。

为解决上述痛点，我们对数据指标项进行了统一的梳理，发现分类治理可以解决当前问题。我们将数据指标分为活跃指标和稳定指标两类，具体定义和处理方式如下：

表2：数据集市数据指标定义

在技术解决方案上，我们调研了市面上比较流行的OLAP引擎，从社区活跃度、查询性能、自身数据特点等方面考虑，我们采用Apache Druid作为数据集市的载体。禧云数据集市已经开始支持运营人员自助分析和可视化。

·数据集市作用

数据集市在不同企业的实践过程中有的划分到数据仓库中，作为数据仓库的一个层级，有的作为数据仓库的下游。数据集市中的数据根据特定的业务或主题组织起来，可以被部门或子公司直接使用。

禧云数据集市按照各部门或子公司进行划分，下属不同主题，例如：交易主题、用户主题、营销主题等。集市数据可以直接用于部门或子公司自助分析，也可以经过数据接口服务封装后供数据报表平台、数据可视化平台和其他平台使用。其中数据接口服务、数据报表平台、数据可视化平台将在《第三章：平台支撑体系》和《第四章：数据产品体系》部分详细介绍。

·技术解决方案

技术上，禧云数据集市主要围绕着Apache Druid来建设，Apache Druid是一个分布式时序数据库，可满足以下场景：

- Historical（历史节点）数据存储使用HDFS等分布式文件存储系统，高可用，支持水平扩容；

- Lambda架构（详见附录2），Realtime（实时节点）使用LSM-Tree实现，满足流数据的即时查询需求。

- 支持SQL查询。

图7：数据集市技术架构图

从上图可以看出，数据仓库生产的数据通过Apache Druid提供的写入服务进入数据集市，实时数据仓库的数据，可以支持快速查询，分析。离线数据仓库的数据根据具体业务场景，进行冷热分层处理，经常被使用的数据做到高效查询。

·数据存储规范

禧云数据集市目前处于刚起步阶段，我们现在仅制定了比较简单的命名规范，来区分一级部门或子公司、所属主题和具体使用场景。命名规范如下图所示：

图8：数据集市命名规范

2.4 本章小结

数据湖、数据仓库、数据集市以及相应的管理规范共同构成了禧云的数据管理体系。我们在讲述过程中没有过多介绍数据仓库和数据集市的概念、模型（星型、雪花、星座等）等约定俗成的东西，而是将重点放在数据流程和技术实现上，主要是想跟大家探讨我们在数据体系建设过程中遇到的痛点和如何解决的，抛砖引玉，起到相互促进的作用。

本章内容在讲述数据管理体系的基础上，同时引出了我们的数据生产流程，稳定、高效的生产流程是支撑决策分析的前提条件，为此我们构建了比较完善的平台支撑体系。

第三章：平台支撑体系

禧云数据平台支撑体系旨在提供高效的开发工具，提升数据开发人员工作效率，提供完善的运维、监控能力，保证数据生产的正确性和时效性。平台支撑体系从数据接入、数据计算、数据服务和数据应用四个层级为数据生产提供全方位的支持和保障。

图9：数芯大数据平台技术架构图

如上图所示，平台支撑体系由数据迁移平台、开发协作平台、数据质量平台、数据开放平台、数据接口服务，以及贯穿数据接入层、计算层和服务层的运维监控平台六大子系统组成。我们按照上述顺序展开每个子系统的具体实现方式。

3.1 数据迁移平台

数据迁移平台（代号：移山，以下简称移山），是集第三方数据接入、实时数据同步、异构数据源间迁移于一体的一站式解决方案。提供简洁、易用的图像化界面，完成数据接入、同步或迁移等配置工作。目前移山每日完成千万级第三方数据接入、亿级内部数据迁移和实时数据同步工作。

·产生背景

在移山之前，禧云在数据迁移方面主要面临以下三个问题：

1. 实时同步：禧云采用阿里开源的Canal（主要用途是基于MySQL数据库增量日志解析，提供增量数据订阅和消费）作为数据实时同步组件，下游解析数据库数据变更事件写入Kafka消息队列，消息队列里的数据供实时数仓分析使用或写入数据湖。上述实现通过脚本的方式配置完成，操作复杂并且容易出错。

2. 数据迁移：离线数仓分析结果导出和计算任务封装在一个Spark计算任务中，数据计算和数据导出耦合性较高，数据导出时间过长会出现计算资源不能释放或计算任务假死等现象。除此之外，缺少统一的异构数据源迁移工具。

3. 第三方数据接入：第三方数据接入主要采用点对点方式，每次对接都需要单独开发程序，没有统一的数据标准，数据接入时间周期较长。

·技术实现

为解决上述三个问题，构建一个通用的数据迁移平台，我们对现有程序重新设计、开发，调研业界开源的异构数据源迁移工具。移山在上述整合的基础上产生，移山提供以下三种数据迁移服务能力：

图10：移山技术架构图

- 数据接入服务

数据接入服务约定JSON格式为统一的数据传输格式，支持HTTP请求和FTP文件采集两种数据接入能力。数据接入服务通过暴露HTTP请求接口的方式对外提供服务，请求类型根据接口参数不同分为消息指令和业务数据上报两种。数据接入流程如下图所示：

图11：数据接入服务流程图

- 数据迁移服务

我们采用阿里开源的DataX（详见附录1）作为数据迁移服务组件。DataX配置过程比较复杂，并且只支持命令行方式执行，为降低使用难度，我们将配置过程进行了图形化处理，采用Python的Flask框架进行封装，任务执行支持HTTP请求调用。数据迁移服务支持定时或指令两种执行方式，具体作用如下：

定时执行：定时拉取数据湖数据到数据仓库中或定时执行业务库间数据迁移工作。

指令执行：接收离线任务计算发送的数据迁移指令，将分析结果数据迁移至数据集市对应存储中。

依托DataX强大的插件体系，数据迁移服务支持目前主流的RDBMS数据库、NOSQL数据库、HDFS大数据存储之间的数据迁移能力。

- 实时同步服务

禧云各子公司的数据大多以关系型数据库MySQL为主，目前的实时同步服务只针对MySQL进行同步，数据同步服务采用阿里开源的Canal作为同步组件，业务数据经过Canal写入Kafka消息队列，Kafka中的数据根据需要写入数据库或供实时分析使用。

图12：实时同步服务流程图

业务系统会产生各种类型的数据，例如订单数据、日志数据等，而下游数据分析往往只针对某一类型数据，为了不造成存储等资源浪费，实时同步服务通过对应关系表来管理数据同步，例如，离线数据分析要用到业务库的订单表t_order，需要在移山实时同步任务中添加t_order对应关系，上游数据才能同步到数据湖或数据库中。如图12所示，同步到数据湖中的数据与上游业务库数据需要保持最终一致性，数据在Kafka消息队列传输过程中可能会出现乱序，导致数据最终不一致。我们在实时同步服务中通过比对binary log时间戳和偏移量，结合HBase特性解决上述乱序问题。我们以t_order表数据写入来解释乱序的处理过程。

图13：实时同步乱序处理过程

移山将数据接入、数据迁移和实时同步整合在一个平台中，开发人员只需要简单的界面化配置，就可完成上述三种操作。为保障数据迁移的稳定性和可靠性，移山同时具备完善的监控报警和数据分析能力。

3.2 开发协作平台

开发协作平台（代号：魔盒，以下简称魔盒），是一套帮助数据开发人员完成离线、实时计算任务打包、测试、数据核验和发布上线等工作的一套调度和管理系统。魔盒对离线计算任务提供串行、并行等复杂工作流设置，并提供完善的任务运行监控报警体系。

·产生背景

禧云数据分析主要分为实时计算任务和离线计算任务两种。在魔盒之前，上述两种任务主要通过在终端服务器上运行命令行方式执行，任务之间的依赖依靠脚本来控制。在任务比较多的情况下，管理起来比较困难，出现问题难以排查，直接影响数据生产。

·技术实现

为保障数据正常生产，提高开发人员工作效率，我们从资源划分（测试环境资源、生产环境资源）、任务管理、程序打包上线和运行监控报警等方面重新规划，开发出了开发协作平台魔盒。

- 离线计算

离线计算为多种业务场景提供基础计算能力，针对不再变化的数据进行分析，具有计算数据量大、业务逻辑复杂等特点，禧云离线计算支持Hive、Spark等计算框架，Hive主要用于临时数据分析，Spark为离线计算任务的主要开发框架。开发人员用Spark或SparkSQL编写完分析代码后，通过魔盒打包上线。测试、上线流程如下图所示：

图14：离线计算任务测试上线流程

禧云每天运行着上百个离线分析任务，每个分析任务服务于不同子公司或业务场景，任务之间会有依赖关系，不同优先级的任务调度时机不同。基于以上问题，魔盒的离线计算部分集成了Linkedin开源的工作流引擎Azkaban。离线计算任务工作流提交过程如下图：

图15：离线计算任务工作流提交过程

有任何问题欢迎添加学姐DKA-2018