大数据平台架构设计探究

作者：刘延江
来源：vivo互联网技术

近年来，随着IT技术与大数据、机器学习、算法方向的不断发展，愈来愈多的企业都意识到了数据存在的价值，将数据做为自身宝贵的资产进行管理，利用大数据和机器学习能力去挖掘、识别、利用数据资产。若是缺少有效的数据总体架构设计或者部分能力缺失，会致使业务层难以直接利用大数据大数据，大数据和业务产生了巨大的鸿沟，这道鸿沟的出现致使企业在使用大数据的过程当中出现数据不可知、需求难实现、数据难共享等一系列问题，本文介绍了一些数据平台设计思路来帮助业务减小数据开发中的痛点和难点。

本文主要包括如下几个章节:前端

• 本文第一部分介绍一下大数据基础组件和相关知识。
• 第二部分会介绍lambda架构和kappa架构。
• 第三部分会介绍lambda和kappa架构模式下的通常大数据架构
• 第四部分介绍裸露的数据架构体系下数据端到端难点以及痛点。
• 第五部分介绍优秀的大数据架构总体设计
• 从第五部分之后都是在介绍经过各类数据平台和组件将这些大数据组件结合起来打造一套高效、易用的数据平台来提升业务系统效能，让业务开发不在畏惧复杂的数据开发组件，无需关注底层实现，只须要会使用SQL就能够完成一站式开发，完成数据回流，让大数据再也不是数据工程师才有的技能。
  
  

1、大数据技术栈
大数据总体流程涉及不少模块，每个模块都比较复杂，下图列出这些模块和组件以及他们的功能特性，后续会有专题去详细介绍相关模块领域知识，例如数据采集、数据传输、实时计算、离线计算、大数据储存等相关模块。


2、lambda架构和kappa架构

目前基本上全部的大数据架构都是基于lambda和kappa架构，不一样公司在这两个架构模式上设计出符合该公司的数据体系架构。lambda 架构使开发人员可以构建大规模分布式数据处理系统。它具备很好的灵活性和可扩展性，也对硬件故障和人为失误有很好的容错性，关于lambda架构能够在网上搜到不少相关文章。而kappa架构解决了lambda架构存在的两套数据加工体系，从而带来的各类成本问题，这也是目前流批一体化研究方向，不少企业已经开始使用这种更为先进的架构。




3、kappa架构和lambda架构下的大数据架构
目前各大公司基本上都是使用kappa架构或者lambda架构模式，这两种模式下大数据总体架构在早期发展阶段多是下面这样的：



4、数据端到端痛点

虽然上述架构看起来将多种大数据组件串联起来实行了一体化管理，可是接触过数据开发的人会感觉比较强烈，这样的裸露架构业务数据开发须要关注不少基础工具的使用，实际数据开发中存在不少痛点与难点，具体表如今下面一些方面。运维

• 缺少一套数据开发IDE来管理整个数据开发环节，长远的流程没法管理起来。
• 没有产生标准数据建模体系，致使不一样数据工程师对指标理解不一样计算口径有误。
• 大数据组件开发要求高，普通业务去直接使用Hbase、ES等技术组件会产生各类问题。
• 基本上每一个公司大数据团队都会很复杂，涉及到不少环节，遇到问题难以定位难以找到对应负责人。
• 难以打破数据孤岛，跨团队跨部门数据难以共享，互相不清楚对方有什么数据。
• 须要维护两套计算模型批计算和流计算，难以上手开发，须要提供一套流批统一的SQL。
• 缺少公司层面的元数据体系规划，同一条数据实时和离线难以复用计算，每次开发任务都要各类梳理。
  
  

基本上大多数公司在数据平台治理上和提供开放能力上都存在上述问题和痛点。在复杂的数据架构下，对于数据适用方来讲，每个环节的不清晰或者一个功能的不友好，都会让复杂链路变动更加复杂起来。想要解决这些痛点，就须要精心打磨每个环节，将上面技术组件无缝衔接起来，让业务从端到端使用数据就像写SQL查询数据库同样简单。

5、优秀的大数据总体架构设计

提供多种平台以及工具来助力数据平台：多种数据源的数据采集平台、一键数据同步平台、数据质量和建模平台、元数据体系、数据统一访问平台、实时和离线计算平台、资源调度平台、一站式开发IDE。

6、元数据-大数据体系基石

元数据是打通数据源、数据仓库、数据应用，记录了数据从产生到消费的完整链路。元数据包含静态的表、列、分区信息(也就是MetaStore)。动态的任务、表依赖映射关系；数据仓库的模型定义、数据生命周期；以及ETL任务调度信息、输入输出等元数据是数据管理、数据内容、数据应用的基础。例如能够利用元数据构建任务、表、列、用户之间的数据图谱；构建任务DAG依赖关系，编排任务执行序列；构建任务画像，进行任务质量治理；提供我的或BU的资产管理、计算资源消耗概览等。

能够认为整个大数据数据流动都是依靠元数据来管理的，没有一套完整的元数据设计，就会出现上面的数据难以追踪、权限难以把控、资源难以管理、数据难以共享等等问题。

不少公司都是依靠hive来管理元数据，可是我的认为在发展必定阶段仍是须要本身去建设元数据平台来匹配相关的架构。

关于元数据能够参考饿了么一些实战:https://www.jianshu.com/p/f60b2111e414

7、流批一体化计算

若是维护两套计算引擎例如离线计算Spark和实时计算Flink，那么会对使用者形成极大困扰，既须要学习流计算知识也须要批计算领域知识。若是实时用Flink离线用Spark或者hadoop，能够开发一套自定义的DSL描述语言去匹配不一样计算引擎语法，上层使用者无需关注底层具体的执行细节，只须要掌握一门DSL语言，就能够完成Spark和Hadoop以及Flink等等计算引擎的接入。

8、实时与离线ETL平台

ETL 即 Extract-Transform-Load，用来描述将数据历来源端通过抽取（extract）、转换（transform）、加载（load）至目的端的过程。ETL 一词较经常使用在数据仓库，但其对象并不限于数据仓库。通常而言ETL平台在数据清洗、数据格式转换、数据补全、数据质量管理等方面有很重要做用。做为重要的数据清洗中间层，通常而言ETL最起码要具有下面几个功能:

• 支持多种数据源，例如消息系统、文件系统等
• 支持多种算子，过滤、分割、转换、输出、查询数据源补全等算子能力
• 支持动态变动逻辑，例如上述算子经过动态jar方式提交能够作到不停服发布变动。
  

9、智能统一查询平台

大多数数据查询都是由需求驱动，一个需求开发一个或者几个接口，编写接口文档，开放给业务方调用，这种模式在大数据体系下存在不少问题：

• 这种架构简单，但接口粒度很粗，灵活性不高，扩展性差，复用率低.随着业务需求的增长，接口的数量大幅增长，维护成本高企。
• 同时，开发效率不高，这对于海量的数据体系显然会形成大量重复开发，难以作到数据和逻辑复用，严重下降业务适用方体验。
• 若是没有统一的查询平台直接将Hbase等库暴露给业务，后续的数据权限运维管理也会比较难，接入大数据组件对于业务适用方一样很痛苦，稍有不慎就会出现各类问题。
  
  

一套智能查询解决上述大数据查询痛点问题

10、数仓建模规范体系

随着业务复杂度和数据规模上升，混乱的数据调用和拷贝，重复建设带来的资源浪费，数据指标定义不一样而带来的歧义、数据使用门槛愈来愈高。以笔者见证明际业务埋点和数仓使用为例，同一个商品名称有些表字段是good_id,有些叫spu_id，还有不少其余命名，对于想利用这些数据人会形成极大困扰。所以没有一套完整的大数据建模体系，会给数据治理带来极大困难，具体表如今下面几个方面：

• 数据标准不一致，即便是一样的命名，但定义口径却不一致。例如，仅uv这样一个指标，就有十几种定义。带来的问题是：都是uv，我要用哪一个？都是uv，为何数据却不同？
• 形成巨大研发成本，每一个工程师都须要从头至尾了解研发流程的每一个细节，对一样的“坑”每一个人都会从新踩一遍，对研发人员的时间和精力成本形成浪费。这也是目标笔者遇到的困扰，想去实际开发提取数据太难。
• 没有统一的规范标准管理，形成了重复计算等资源浪费。而数据表的层次、粒度不清晰，也使得重复存储严重。
  
  

所以大数据开发和数仓表设计必需要坚持设计原则，数据平台能够开发平台来约束不合理的设计，例如阿里巴巴的OneData体。通常而言，数据开发要通过按照下面的指导方针进行：

有兴趣的能够参考阿里巴巴的OneData设计体系。

11、一键集成平台

很简单的就能将各类各式数据一键采集到数据平台，经过数据传输平台将数据无缝衔接到ETL平台。ETL经过和元数据平台打通，规范Schema定义，而后将数据转换、分流流入到实时与离线计算平台，后续任何针对该数据离线和实时处理，只须要申请元数据表权限就能够开发任务完成计算。数据采集支持多种各式数据来源，例如binlog、日志采集、前端埋点、kafka消息队列等

12、数据开发IDE-高效的端到端工具

高效的数据开发一站式解决工具，经过IDE能够完成实时计算与离线计算任务开发，将上述平台所有打通提供一站式解决方案。数据开发IDE提供数据集成、数据开发、数据管理、数据质量和数据服务等全方位的产品服务，一站式开发管理的界面，经过数据IDE完成对数据进行传输、转换和集成等操做。从不一样的数据存储引入数据，并进行转化和开发，最后将处理好的数据同步至其余数据系统。经过高效率的大数据开发IDE，基本上让大数据工程师能够屏蔽掉各类痛点，将上述多种平台能力结合起来，让大数据开发能够向写SQL同样简单。

关于数据开发工具能够参考阿里云的DataWorks。

解决端到端难点还须要其余若干能力辅助，这里就再也不叙述，有兴趣的同窗能够自行研究。

13、其余

完整的数据体系研发还包括告警与监控中心、资源调度中心、资源计算隔离、数据质量检测、一站式数据加工体系，这里就再也不继续讨论了。