本文是贝贝大数据团队数据中台建设阶段性总结，借此机会感谢现在仍然携手以及曾经一起并肩的小伙伴的努力！

贝贝集团创建于2011年，当前处于业务多元化阶段，旗下拥有贝贝网（母婴家庭购物平台）、贝店（会员制折扣商城）、贝仓（品牌特卖平台）、贝省（购物省钱平台）、贝贷（消费金融平台）等业务。进入业务多元化阶段后，如何高效高质量支持集团各业务，对于大数据团队来说是新的挑战。

一、要不要做数据中台？艰难的选择

“中台”可能是近几年互联网技术领域最火的概念之一，“技术中台”、“业务中台”、“数据中台”、“算法中台”，各种中台如雨后春笋般涌现，大厂小厂也纷纷启动中台战略，似乎是包治百病的神丹妙药。然而，最近爆出的中台失败案例：《中台翻车纪实：一年叫停，员工转岗被裁，资源全浪费》、《中台搞了2年，项目叫停，CIO被裁！本以为中台是道送分题，没想到是送命题！》，又让中台陷入了质疑和尴尬。

To be or not to be, that is a question？

在这个问题想明白之前，我们并没有贸然启动项目，而是审慎地关注业界的动态，结合外部经验和集团内部实际情况进行分析。

谋定而后动，我们的决策：干！

决策的依据，是针对以下几方面进行了充分的讨论和思考：

1、价值收益：为什么要做？做了有什么用？数据中台能一定程度上解决目前的问题和挑战，带来质量、效率、成本方面的收益。

2、技术储备：最佳实践是什么？技术方案明确吗？数据中台建设主要依赖大数据平台的和数据仓库领域的技术，在相关领域我们已经具备一定的理论和实践储备。

3、组织保障：数据中台是系统性的项目，贯穿整个大数据业务和技术栈，需要基础平台、数仓、BI、搜索、推荐、广告、风控等上下游团队的配合和支持，跨部门协同才能拿到结果。组织协同非常关键，这也是很多公司数据中台项目落地失败的原因之一，而贝贝整个大数据技术和业务都归属于同一个大部门，天然具备协同作战的组织优势。

二、面临什么挑战？数据中台能解决问题吗？

2.1 贝贝大数据体系

大数据团队要把数据和技术有机结合起来，才能让数据成为生产力，发挥其价值。我们一直致力于生产高质量的数据能源和打造更加强大的技术引擎，结合业务应用场景，通过数据赋能商业、创造价值。

数据是能源，技术是引擎， 赋能商业、创造价值。

大数据系统由上下游三层组成，从下往上依次是：

• 数据平台（引擎层）：作为大数据体系的基础设施，负责海量数据的存储和计算，大数据引擎基本运行在这层，当前阶段我们重点关注稳定性和成本。
  
• 数据仓库（能源层）：数据的大管家，负责数据建模和数据管理，大数据体系中高质量的数据能源主要在这层生产，重点关注数据的质量和上层使用数据的效率（易用性）。
  
• 数据应用（价值层）：数据本身没有价值，甚至是成本，数据经加工处理后结合业务应用场景才具备价值属性。贝贝目前有数据化运营（数据产品、业务监控、经营洞察等）和人工智能业务（个性化推荐、广告、搜索、用户增长、风控等业务），重点关注数据应用于业务决策支持和人工智能业务的商业价值。
  

2.2 我们面临的挑战：数据灾难

我们给数据的一个定义：数据=对业务过程的记录。用数学公式表示，更加直观，数据是业务的积分

从公式可以得出

• 业务不增长→数据线性增长
• 业务线性增长→数据指数增长

怎么理解呢？简化技术细节举个例子，假设业务处于平稳状态，每天的DAU和订单数是个常数，但大数据集群存储的流量数据和交易数据都会线性增长，实际的情况涉及全量/增量建模，数据分层加工，会更加复杂。

数据灾难：数据增长快于业务增长，数据价值密度下降是自然趋势

如何应对数据价值密度下降？数据中台+价值变现

• 数据中台：降低数据增长速度，优化数据平台和数据仓库
• 价值变现：提升数据业务价值，探索更多的数据变现业务

好的数据中台，能提供高质量数据和高效率的平台工具，有助于对数据价值的深度变现

2.3 数据中台解决哪些问题？

分析贝贝的实际情况，我们认为当前重点目标是：降低成本、提升效率、更高质量，各维度可以拆解如下：

基于核心目标，我们启动了如下一系列技术项目，本文后续会对重点项目展开介绍

这些项目并非孤立，在大数据体系里各司其职、互相配合，下图展现各项目在体系中的角色

三、重点项目

3.1 大禹治水——数仓公共层重构：建设更好的数据仓库

1、背景
贝贝集团之前的数仓整体架构设计于2016年，这四年里支持了各类业务的发展，基本解决了“看数据”的问题。随着业务的快速发展迭代，数据的重要性也越来越突出，业务对数据的需求已经从“看数据”到“用数据”阶段了。现有的这套数仓模型已经不太能满足业务的发展要求，并且随着数据量和任务的增多，管理维护成本也直线上升，现有数仓体系的局限性也越来越突出，急需基于当前业务要求和未来的发展，以及新的技术和方法论，对数仓整体模型进行重构。

局限性主要体现在2个方面：

2、建设思路

严格遵循数据体系化建设的模型分层，数据分域的思路，借鉴阿里onedata数据体系建设方法论，重构整体数仓
1）模型分层

按照以上的模型层级，确定每一个层级的作用和建设方式，严格规范各层级数据的依赖关系，分层建设。通过统一数据接入和明细层的建设规范，建设完整规范、稳定可靠的基础数据(ODS/DIM/DWD)；以基础数据为依托，通过对各类业务数据应用场景的沉淀，抽象出通用的指标和逻辑，建设准确丰富、统一通用的指标体系；以统一通用的指标体系为基础，结合具体的业务应用场景，搭建数据集市、报表和数据接口等，为包括BI、风控、算法等团队提供灵活多样、快速响应的数据应用层。

2）数据分域

根据当前的实际业务情况，结合业务系统的来源，重新划分为以上12个数据域。同时对各个数据域内的业务活动事件进行抽象，生成对应的业务过程。遵循数据域内高内聚、数据域之间低耦合的设计思想，采用基于业务过程抽象的事实表设计方法建设DWD数据明细层。

3）onedata指标体系化

采用阿里onedata指标定义规范，结合具体的数据应用场景，抽象出每个数据域的每个业务过程下的原子指标、派生指标、时间周期和修饰词，确定原子指标和派生指标的生成逻辑，制定指标的命名规范，建设统一通用的指标体系。

我们通过指标字典来管理指标体系，涵盖指标体系的配置、指标的增删改查。

3、应用效果

使用新公共层进行开发，有以下收益：

• 更快交付：依赖任务少，代码清爽整洁，开发效率高
• 更快产出：更低的存储计算资源消耗，数据产出更快
• 更高质量：基于指标体系开发，避免烟囱式开发导致的数据口径不一致

3.2 闪电计划——流计算平台建设

1、背景

• 数据价值与数据时效性相关，越实时的数据，往往价值越大。业务渴望实时数据，实时需求越来越多
• 贝贝老的实时计算平台基于JStorm，使用java语言开发效率低下

有限的技术交付能力与越来越多的实时数据需求矛盾凸显，因此我们探索更高效的实时计算平台，这时候Flink的几个特性引起了我们的关注。

• 可以使用SQL开发
• 资源隔离、窗口、checkpoint等一系列新的特性

2、平台建设
我们主要做了2件事情：

（1）实时平台

• 统一开发平台：提供代码开发、任务管理、任务运维、权限管理、监控告警、异常排查等功能
• 二次开发：基于开源版本做了一些二次开发，增强SQL功能和扩展外部存储介质

（2）实时数仓
实时数仓借鉴离线数仓“分层+分域”的思路，建设实时数据公共层，避免烟囱式开发。

3、收益

• 高效性：基于SQL，降低技术复杂度，提升开发效率，原先数百行java代码可以减少到10行SQL
• 一致性：核心业务指标离线实时差距十万分之一以下
• 复用性：流量数据天然是流式的，实时任务解析后的数据可同步到离线集群，离线无需再次计算。一次计算，多处使用，节约集群资源

3.3 灯塔计划——数据驱动的自动化智能化计算优化

1、背景

随着业务增长，更大的数据计算量和更多的业务应用场景，对大数据集群资源提出更高的要求，除了增加物理资源，探索如何提高资源利用率是更具创新性的解决方案。

基于分析，我们发现：

• 大数据任务处理的数据量差距悬殊，业务逻辑差异性大，对于资源的需求也不太一样。但是，hive配置对所有任务一视同仁，势必会导致小任务存在资源浪费，而大任务却资源不足。
• 绝大部分的大数据任务都是周期调度的任务，且这些任务的输入一般比较稳定，如果能对这部分任务进行优化，那么整个集群的计算资源的使用率将会得到显著提升。

因此，我们提出了基于任务执行历史的资源消耗信息，自动化智能化的计算资源优化方案，为每个作业按需分配资源，实现计算资源的更优分配。

2、原理

本系统分为筛选，优化，验证和评估四个部分，对map个数、map内存、reduce内存等参数进行优化。

• 筛选：稳定运行一定时间周期，积累足够多历史数据，分配资源多但利用率低的任务，才有优化空间
• 优化：基于任务的历史资源消耗数据，匹配合适的优化模型，生成优化后的配置参数
• 验证：使用优化后的参数，对任务进行试跑，试跑符合预期的任务，会发布到生产环境
• 评估：跟进任务在生产环境下的表现，若任务异常，有降级和回滚措施，保证数据生产稳定性

3、效果：集群资源利用率提升15%左右

3.4 北斗计划——数据治理：建立元数据体系，打通任督二脉

1、背景

大数据存储与计算持续增长，且增长速度有加快的态势。我们猜测有大量的任务其实已经没用了，却还在生产环境周期性执行，造成浪费的原因可能有：

• 业务变化：业务迭代快，有些业务已经暂停或者下线了，但对应的任务还在执行
• 主观意愿：人员异动后交接的任务，对接手的任务熟悉度不够，保持现状“懒处理”可能是最安全的
• 缺乏工具：每日周期执行数万大数据任务，如果缺乏系统支持，人肉处理效率低下

在2019年Q4，集群资源已接近安全水位线，我们做了一轮任务“大扫除”，这个突击动作完成后，释放了可观的机器资源，解除了当时的资源紧缺风险。

除了解决资源紧缺之外，我们额外得到了2点knowhow：
1、验证了我们的设想，确实有大量的任务处于无效状态
2、在做任务清理的过程中，沉淀的方法论，为产品化奠定了基础

产品化地做好任务治理，减少资源浪费，核心是构建元数据体系。元数据（Metadata）是关于数据的数据，元数据打通了源数据、数据仓库、数据应用，记录了数据从产生到消费的全过程。

2、解决方案

1）采集数据：采集从生产到消费全链路尽可能多的数据，包括任务执行资源消耗、hive表/文件元数据（存储大小、访问情况、生命周期、增长速度）、表之间的依赖关系、表和任务的对应关系、接口调用频次、报表/数据产品使用频次等；

2）重建链路：根据采集到的点（文件/任务/接口/数据产品）信息和边信息（任务依赖/表和文件对应关系），重建资源价值传递链路，将终端节点的使用情况反向传播到上游链路

3）成本评估：将大数据集群的机器成本换算到计算单元成本（1CU的成本）和存储单元成本（1G的成本），总成本按资源消耗比例分摊到各个任务和表

4）自动化治理：依据使用情况和成本，制定治理规则，符合规则的表和任务，列入待治理队列。等待期内owner可以干预，等待期结束时自动清理

3、应用情况
1）可视化：资产盘点和评估可视化

• 大盘核心数据看板

• 大盘/部门/个人维度各指标的趋势图

• hive表的元数据

2）全链路：数据全链路的追踪和溯源

• 链路数据

3）智能化：任务治理的自动化智能化，治理闭环体系能力

3.5 任务提速——逻辑和物理双引擎加速

1、思路
加快任务产出，有2个提升方向：
（1）逻辑层面——脚本并行执行：hiveSQL动则数百上千行，大任务往往包含逻辑独立的中间表，中间表之间存在非强依赖关系，代码段之间从串执行改成并行执行
（2）物理层面——更高效的执行引擎：hiveSQL解析为MR任务，MapReduce编程模式比较简单，执行效率较低。可以探索更高效的执行引擎，比如Spark

2、脚本并行执行

原理：解析hive任务脚本，拆分为多个子任务，建立子任务间的依赖关系DAG，有序执行子任务，做好并行和顺序控制，同时要考虑子任务失败等异常情况

举个例子：下图为某报表任务，SQL脚本包含多个独立的逻辑块，大数据调度系统提交任务执行时，会自动将其拆分为8个可并行执行的子任务

效果：开启并行执行功能以后，任务执行时间从1个小时左右降低到15分钟左右

3、引擎升级
之前绝大部分ETL任务都是基于Hive，我们尝试替换为spark。为什么选spark？

• 基于集群的CPU、内存、io使用情况，spark引擎相比MapReduce能更充分利用资源
• SQL兼容性高，更换执行引擎对上层应用透明，任务脚本几乎无需修改

效果：升级spark后，任务耗时降低了一半左右

04

四、总结

在建设数据中台过程中，有两点感触颇深：

• 不能为了上中台而上中台。阿里巴巴董事长兼CEO张勇在湖畔大学分享时也说：如果一个企业奔着中台做中台，就是死。
• 不能生搬硬套，要结合企业实际情况，从面临的问题和挑战出发，寻求适合自身的解决方案

虽然目前取得了阶段性成果，但数据中台需要持续迭代，还有很多更具价值和挑战的方向值得我们去探索。



微信扫描二维码，关注我的公众号