有赞数据中台建设实践

标签： dev | 发表时间：2019-12-11 00:00 | 作者：
出处：http://itindex.net/relian
作者：贺飞
团队：大数据团队
概述究竟什么是中台, 业界并没有一个标准答案, 各个厂商都有自己的定义. 笔者比较认可的一个定义是 ThoughtWorks 提出的"企业级能力复用平台". 各个领域涌现出很多中台产品, 如业务中台, 搜索中台, 数据中台等. 其中数据中台这个词汇越来越多的出现在视野中, 从百度指数中可以看到这一趋势.



本文,介绍有赞的数据中台产生的背景和建设思路. 简单来说, 有赞的数据中台解决的是"有赞的数据资产的加工和复用", 这里提到了数据中台的两个重要功能: 数据加工和数据复用, 分别由数据技术中台和数据资产中台解决. 数据技术中台主要解决数据的加工问题, 在众多大数据组件中,帮助数据开发者简化开发过程,提高开发效率. 数据资产中台主要是解决数据复用的问题, 要做到数据复用, 数据口径的统一是重中之重. 双管齐下, 提高对前台业务的支撑效率.


二. 数据团队面临的挑战数据团队面临的挑战主要有两方面:
  • 业务挑战
  • 技术挑战

2.1 业务挑战
有赞是一家服务商家的 SaaS 公司, 服务数百万各行各业的商家, 提供电商解决方案. 有赞数据团队的服务对象主要是各个前台业务线, 所以一切故事的开始来源于业务团队. 因为业务特点决定, 目前有赞的数据需求有以下特点:


  1. 垂直业务线众多: 有赞微商城, 有赞零售, 有赞美业, 有赞教育等
  2. 业务域众多: 商品, 店铺, 会员, 交易, 支付等
  3. 数据需求多样: 商家后台数据报表需求, 运营侧数据分析需求, 大促看板需求, 实时报表需求等
  4. 业务需求迅速迭代: 业务模型的迭代演进, SaaS领域对已有功能比较高的兼容要求等
  5. ...


2.2 技术挑战业务线各种各样的数据需求, 给数据团队提出了很多挑战, 主要体现在两方面:
  1. 组件多, 维护成本高
  2. 开发门槛高


组件多, 维护成本高软件行业"没有银弹"在大数据领域显现的淋漓尽致. 在有赞的大数据技术栈中, 针对不同的场景, 分别维护着众多的大数据组件. 如数据基础组件的 HDFS, YARN 组件;离线计算元数据组件 HIVE META, 离线计算引擎 HIVE, Spark SQL, Presto;实时计算框架 Storm, Spark Streaming, Flink 等. 这些还只是组件本身并不包括组件配套的鉴权, 安全, 脱敏, 质量相关的服务.


开发门槛高比如，针对最普通的实时计算场景，任务的开发者通常考虑以下几个方面问题:


  1. 数据Source流在哪儿, 如何接入
  2. 数据处理后的Sink是流还是其他存储,如果是其他存储系统,可用性是怎样的,单机房可用还是多机房,扩展性怎么样, 写入是否有热点,是否可以配合实时链路的并行度调整做水平扩展
  3. 实时任务本身的高可用部署，监控及报警
  4. 消息的一致性语义是什么(at least once, exactly once 还是 at most once), 每种语义对上下游服务的要求是怎么样的
  5. 实时计算任务的计算资源如何配置, 水位如何,大促期间如何扩容
  6. 公司内部各种各样非大数据的技术组件,如何做适配
  7. ...


对于没有相关经验的同学, 需要查阅多种组件的文档, 势必会有开发成本高的困扰.


三. 数据中台按照产生顺序, 数据中台主要包括:
  • 数据技术中台
  • 数据资产中台


3.1 数据技术中台构建所以, 技术上的复杂性, 带来了开发成本高的问题. 所以易用性的本质是为了提效, 数据技术中台由一些列工具型平台构成, 最主要的几部分如下:
  1. 基础组件运维管控
  2. 数据开发平台
  3. 数据资产管理平台
  4. 数据指标管理
  5. 统一数据服务



基础组件运维管控上文也有提到, 大数据基础组件种类繁多, 概括下来可以分为三类:


  • 离线计算组件 (HDFS,YARN, HIVE, Spark)
  • 分布式在线存储组件(HBase, Kafka, Druid)
  • 实时计算组件(Storm, Spark Streaming, Flink)


每类组件的管控需求都不尽相同, 比如在线存储组件对 rt, 可用性要求较高; 实时计算组件对延迟, 积压问题比较在意; 离线计算组件对数据吞吐能力要求较高, 但是因为是分布式计算,所以对慢盘, 慢任务需要有特别关注, 否则很容易一个节点拖慢整个集群.


运维管理好大数据组件, 做好动物管理员, 本身就是一件类似数据运营的工作, 找到系统的北极星指标, 关注它, 使用它来帮助做系统的优化.


总结下来, 做好数据组件的管理需要解决以下问题:
  1. 确定核心指标. 需要 case by case 的确认每个子系统的最核心的指标, 比如对 HDFS 系统来说, 文件数目, 文件操作 tps, 文件操作的 rt, 99% rt, 是否有丢块等,就是核心指标, 需要特别关注.
  2. 监控. 采集核心指标, 展现到监控上, 便于观察趋势, 帮助问题排查和扩容等操作的判断依据.
  3. 报警. 根据核心指标, 确定安全水位, 配置报警, 缩短故障发现时间.
  4. 具备一定的定制开发能力. 对使用组件不要求有核心 feature 的开发改造能力(这不符合 ROI), 但是在权限/安全方面, 社区版本很难满足定制需求, 这就需要对基础组件做一定的改造; 另外需要关注社区,对于重大隐患的 bug, 需要打回的公司的版本.
  5. 软件发布/配置发布规范. 多人协作, 多组件协作, 需要一个完整的开发/测试/发布流程, 不止对软件, 对配置的发布也一定要规范. 这方面曾经踩过不少的坑.
  6. 故障演练, 要定期的主动对技术组件做故障演练, 有些组件虽然支持某类功能,但是随着数据量, 负载的不同, 这类功能实际效果具体是怎样的需要通过实践来确认. 比如 HBase 支持单机宕机自动恢复, 但是宕机恢复时间究竟是多少, 跟集群负载, 各方面的配置都是相关的, 需要通过故障演练来组件优化系统.
  7. 性能摸底. 需要对组件做标准的 Benchmark, 一来掌握系统极限,二来在业务接入时能够提供准确的性能指标, 帮助业务方做选型判断.
  8. ...


数据开发平台数据开发平台关注的是数据的加工, 是数据开发用户(数据产品开发同学, 数仓开发同学, 业务线数据开发同学)最频繁接触到的产品, 数据开发平台主要包括两个平台型产品, 分别解决离线和实时场景的数据加工需求.


  1. 离线开发平台, 主要负责离线数据的加工, 任务调度, 数据 ETL, 临时查询, 监控报警等
  2. 实时计算平台, 主要负责实时计算任务的管理, 监控报警等


关于这两个平台, 有更具体的文章介绍(见参考文章),这里不在赘述.
数据资产管理平台数据资产管理平台主要解决数据资源的管理, 数据资产遍布在各个大数据组件中, 有 hive 的表, 有 hbase 的表, 有 druid 的 datasource, 有 kafka 中的流, 各个组件的管控系统很难互相打通, 所以需要一个统一的数据资产管理服务, 来统筹大数据资源的管理.


总体说来, 数据资产管理平台关注的是数据的静态状态, 比如 Hive 的库表/字段, HBase 的表, Kafka的 Topic. 提供以下几方面的工具:


  1. 数据地图(方便用户查找,定位已有的数据自产并复用)
  2. 数据质量(对数据资源,根据预设的规则做质量检查,提前发现潜在问题,比如每日数据量,是否有字段缺失等,并且在数据不合格的状况下能够及时通知出来)
  3. 成本核算(统计各个团队,组件的成本占用,利于做成本降低之类的优化,当数据体量达到一定规模的时候, 成本问题会变的越来越重要)
  4. 数据血缘管理(管理所有的数据资源的依赖关系, 主要用在两个场景: a. 数据问题评估, 当上游数据变更或者质量问题的时候, 能够快速确定影响面和修复方案. b. 数据生命周期管理, 当下游应用下线,不再使用某个数据的时候,能够找到不被引用的数据, 及时下线,避免不必要的计算)
  5. ...


数据指标管理如果说数据平台关注的是数据的加工/转换,既数据任务的管理; 数据资产管理平台关注的是具体的数据表和字段的质量和血缘; 那么指标库管理的就是数据指标的口径统一和复用. 在有赞, 我们通过指标库系统来管理数据指标的口径.


概括来说,数据指标被分为原子指标和派生指标. 原子指标为不可再分割的基础指标, 由数仓团队统一开发和管理, 原子指标数据一般落在数仓的 DW 层. 但是往往业务方需要的指标, 原子指标并不能满足, 所以业务方需要在原子指标的基础上再次加工成派生指标. 比如 交易数据中 gmv 是原子指标, 微商城业务最近 30 天的gmv 指标就是派生指标 wsc30dgmv.关于指标库, 后面会有单独的文章介绍.


统一数据服务数据开发平台,资产治理平台,指标库只是解决了数据的加工和口径的统一的问题. 产出的数据并不是真正对外可用的. 绝大多数场景, 都需要数据开发的同学, 将加工后的数据, 通过数据交换组件, 导出到线存储服务中, 然后再开发数据接口, 供前台业务同学调用. 这里在线存储服务到接口这一层, 传统的业务支撑方式中存在大量的重复开发. 针对这个问题, 我们设计统一数据服务, 用户通过配置模板的方式, 生成数据 API 服务, 简化开发流程. 有赞的统一数据服务目前刚刚上线, 已经支持 10+业务场景, 后面会有单独的文章介绍.


3.2 数据资产中台构建
3.1 节中介绍了偏技术视角的中台, 涵盖了大数据的技术架构. 但是数据中台远不止技术设施,更主要的是数据资产的建设和组织, 因为对业务方而言,业务方更关注的是有哪儿些数据自产可以使用,而不是通过什么底层技术实现.



大数据团队提供的数据资产主要有以下几类:
  1. 离线数据资产(离线数仓)
  2. 数据智能服务
  3. 实时数据资产(实时数仓)


在用户数目上, 目前离线数仓承接了大多数的数据需求, 这里仅仅对离线数仓展开介绍. 离线数仓中数据的开发主要发生在数据开发平台上, 包括数据 etl 导入任务, 数据开发任务, 数据 etl 导出任务,任务流的管理和调度. 借助于指标库和数仓开发规范做数据的加工. 整个开发过程中, 数据开发平台,数据质量管理,指标库平台会通过对命名, 指标的查重等手段来强制一些开发规范的执行, 从根本上解决数据指标口径一致和数据复用等问题.


有赞离线数据资产如上图中蓝色部分, 从底向上分为三层:


公共数据层公共数据层主要承载数仓建模中的 ODS 层和 DW 层, 数据的开发和口径管理由数据仓库团队负责. 数据的开发和口径管理严格按照数仓开发规范和指标管理规范,提供公共的原子指标的开发.


垂直业务域数据层垂直业务域数据层, 树妖曾在数仓建模中的 DM 层, 数据的开发和口径管理由业务方的数据开发同学负责. 业务方同样根据数仓开发规范和指标管理规范, 完成派生指标的开发.


数据服务层数据在离线数仓中开发完毕后, 通过数据开发平台的 ETL 导出任务导出到在线存储层, 然后自行封装或者通过统一数据服务,提供在线数据接口.这一分层在实时数仓中同样适用, 本文不展开


三. 总结&展望有赞数据中台并不是一蹴而就, 而是面临着业务和技术上的挑战逐渐成长到现在, 当然还有很多待完善的地方, 比如指标库,统一数据服务还处于刚刚起步阶段. 后面有赞数据中台的建设将主要集中在成本,数据资产管理&复用,实时数仓等方面发力, 帮助我们的商家和业务方挖掘更多数据价值.


扩展阅读

  1. 实时计算在有赞的实践-效率提升之路

  2. 有赞数据仓库元数据系统实践

  3. How we redesigned the NSQ - 其他特性及未来计划

  4. HBase 写吞吐场景资源消耗量化分析及优化

  5. 有赞大数据平台安全建设实践

  6. Flink 在有赞实时计算的实践

  7. 大数据开发平台(Data Platform)在有赞的最佳实践


相关 [数据 中台 建设] 推荐：

有赞数据中台建设实践

- - IT瘾-dev
概述究竟什么是中台, 业界并没有一个标准答案, 各个厂商都有自己的定义. 笔者比较认可的一个定义是 ThoughtWorks 提出的"企业级能力复用平台". 各个领域涌现出很多中台产品, 如业务中台, 搜索中台, 数据中台等. 其中数据中台这个词汇越来越多的出现在视野中, 从百度指数中可以看到这一趋势.

有道精品课实时数据中台建设实践

- - 有道技术沙龙博客
来源：有道技术团队（ID: youdaotech）. 本期文章中，有道精品课技术团队将和大家分享有道精品课 数据中台的架构演进过程以及 Doris 作为一个 MPP 分析型数据库是如何为不断增长的业务体量提供有效支撑并进行数据赋能的. 本文以我们在实时数仓选型的经验为切入点，进一步着重分享使用 Doris 过程中遇到的问题，以及我们针对这些问题所做出的调整和优化.

建设数据中台到底有啥用？

- - 掘金 后端
最近专注在数据和人工智能领域，从数据仓库、商业智能、主数据管理到大数据平台的建设，经过很多项目的沉淀和总结，最后我和团队一起总结了精益数据创新的体系. 企业为什么要建设数据中台，数据中台对于企业的价值到底是什么. 从概念和框架的角度，给你提供一个更全面的视角. 做好任何一件事情的前提就是弄清楚为什么.

有8亿用户的网易云音乐是怎样建设数据中台的？

- - InfoQ推荐
这几年，“中台战略”概念像是一把火，“烧遍”国内互联网. 而在业界，关于中台的实践并不多，尤其是数据中台. 带着这些疑惑，InfoQ 记者采访了 ArchSummit 全球架构师峰会讲师网易云音乐数据智能部数据开发专家朱一飞. 作为国内知名音乐平台，网易云音乐有 8 亿用户. 不过，它面临的挑战在于，一方面各个业务单元在 8 亿用户基数上积累海量的数据，另一方面，业务部门基于发展需要提出大量数据需求，并且在数据质量、数据共享、实时化方面的要求越来越高.

微服务架构-数据中台和业务中台(3.27)

- - 人月神话的BLOG
首先我们看下阿里巴巴Aliware团队对企业中台的定义. 即企业中台是由业务中台和数据中台构建起数据闭环的运营体系,实现以数字化资产的形态构建企业核心差异化竞争力. 在原来我谈企业中台的时候，很少专门谈到数据中台和业务中台，更多谈的是技术中台和业务中台，技术中台类似我们原来说的技术平台层和业务不相关.

谈主数据和数据中台区别(200707)

- - 人月神话的BLOG
主数据是描述核心业务实体（如客户、供应商、地点、产品和库存）的一个或多个属性. 所以主数据即是在进行企业业务架构分析中发现的核心业务对象. 或者讲主数据是企业已经存在的涉及到价值链核心业务流程的各个IT系统的基础数据. 对于ERP系统客户，供应商，物料，BOM，产品，合同，订单等都应该是最基础的数据，对于项目管理系统而言项目信息，WBS信息则是最基本的基础数据.

主数据和数据中台的区别

- -
今天在解释下主数据和数据中台的区别. 对于主数据和数据中台我在头条前面文章都有专门的描述，可以先参考下我前面发布过的文章. 在讲解区别下，还是先看下两个概念的定义. 主数据是描述核心业务实体（如客户、供应商、地点、产品和库存）的一个或多个属性. 所以主数据即是在进行企业业务架构分析中发现的核心业务对象.

产品数据体系建设基础：一个产品的数据体系建设

- - 人人都是产品经理
本文抽象介绍了一个产品数据体系建设，以支持产品了解数据如何采集、计算与展现. 近期有师弟师妹不断问到产品经理必备技能中，数据分析是怎么回事. 简单了解了下其产生问题的原因与诉求，将其问题拆分为二：. 关于问题2，网上已经有足够丰富的资源进行学习与讨论，这里不再赘述，简而言之根据运营或迭代的目的进行深度思考与结论沉淀.

建设大数据平台，从“治理”数据谈起 - CSDN极客头条

- -
一、大数据时代还需要数据治理吗. 二、如何面向用户开展大数据治理. 三、面向用户的自服务大数据治理架构. 一、大数据时代还需要数据治理吗. 数据平台发展过程中随处可见的数据问题. 大数据不是凭空而来，1981年第一个数据仓库诞生，到现在已经有了近40年的历史，相对数据仓库来说我还是个年轻人. 而国内企业数据平台的建设大概从90年代末就开始了，从第一代架构出现到现在已经经历了近20年的时间.

昨天讲平台、今天变中台，数据中台都干了啥？-InfoQ

- -
数据中台火的很让人不解，半年前还在炒概念，现在突然就看到各个企业都在宣传自家的数据中台了. 这半年，大家热衷于讨论什么是“数据中台”，并且还有“有一千个企业，就有一千个数据中台”的说法，但实际上企业都有“共识”，我们采访了多家企业，想给大家一个准确的“数据中台”定义. 中国企业的大数据发展大概经历了 三个阶段.