做网站网站会怎么样,网站开发的必要性,数据分析师工资,主题公园网站建设基于PB级海量数据实现数据服务平台#xff0c;需要从各个不同的角度去权衡#xff0c;主要包括实践背景、技术选型、架构设计#xff0c;我们基于这三个方面进行了架构实践#xff0c;下面分别从这三个方面进行详细分析讨论#xff1a;实践背景该数据服务平台架构设计之初…基于PB级海量数据实现数据服务平台需要从各个不同的角度去权衡主要包括实践背景、技术选型、架构设计我们基于这三个方面进行了架构实践下面分别从这三个方面进行详细分析讨论实践背景该数据服务平台架构设计之初实践的背景可以从三个维度来进行说明当前现状、业务需求、架构需求分别如下所示当前现状收集了当前已有数据、分工、团队的一些基本情况如下所示数据收集和基础数据加工有专门的Team在做我们是基于收集后并进行过初步加工的基础数据结合不同行业针对特定数据的需求进行二次加工的。数据二次加工会集成基础数据之外的其它有业务属性的数据比如引入第三方POI数据等。原始数据每天增量大约30~40TB左右。计算集群采用Spark on YARN部署模式大约400个节点。所有数据各种属性、行为信息都是围绕大约40亿的移动设备ID进行很多倍膨胀比如每天使用微信App的设备的行为信息。参与该平台的研发人员对实际数据业务需求了解不会非常深入因为跨多个行业及其不同数据需求的变化较快。业务需求另外实现的该数据服务平台需要满足当前的基本数据业务需求主要包括使用平台的人员特点需要支撑的各种基本数据需求经过梳理如下所示平台初期面向内部业务人员使用几乎没有技术背景。40亿的移动设备大表包含各类设备ID及其设备属性需要提供批量匹配功能给定一类或多类设备ID的批量文件从大表中获取到匹配上的设备信息(ID及多个属性信息)。对PB级数据进行各种快速探索输入各种过滤条件如地域(国家/省/市/区)、地理围栏(地图圈选/上传文件/直接输入)、使用的App及分类(安装/活跃)、时间范围(日/周/月)、POI及分类等等理论上不限制条件个数经验值最多在5~6个左右。输出主要包括明细信息、多维度统计(画像)、图表(热力图)等。平台提供的数据服务都是批量模式的计算所以需要为用户提交的数据作业给予准确的状态变化反馈。有小部分面向开发人员的需求将在数据平台Web系统操作进行的数据匹配、提取、探索等操作进行服务化以供其他系统中的服务调用。架构需求在未来业务模式变化的情况下能够非常容易地扩展并尽量复用大部分核心组件。同时还要面向开发人员复用数据平台的数据业务服务以增加平台利用率间接产出数据价值。考虑如下一些当前需要以及未来可能演变的架构需求定义作业和任务的概念作业是用户为满足一次业务需要而提交的数据获取请求最终输出想要的数据结果任务是为满足输出一个作业结果从逻辑上拆分成的基本计算单元。一个作业由多个任务的计算组合而完成。对于一个作业输入的多个过滤条件如果作为一个单独的计算任务根本无法在PB量级的数据上输出结果所以需要将作业拆分成多个任务进行分别计算最后输出结果。对用户作业状态的管理具有一定的业务含义基本不能在公司级别进行复用具体涉及内容包括排队、组成作业的任务列表管理、作业优先级管理。任务是最基本的计算单位设计能够协调整个任务计算的架构可以分离出任何业务状态实现为无状态的任务计算架构在公司级别可以复用比如大量基于Spark的计算可以抽象为任务计算。由于时间范围条件跨度需要支持几年(如1~3年)计算依赖的数据量级在TB甚至PB级别所以一定要通过预计算的方式压缩数据并能提供支持快速计算的方式。预计算可以使用Spark计算集群每天通过控制计算所需资源进行大规模ETL处理。ETL处理迫切需要一个简单、轻量的ETL作业调度系统可以从开源产品中甄选。采用原生Spark计算基本无法为平台上用户提供快速计算的体验可能会考虑列式分布式数据库或基于Bitmap结构的分布式计算系统。面向开发人员部分涉及业务相关内容的模块第一阶段可以通过硬编码方式处理业务逻辑后续第二阶段可以基于对业务流程的熟悉来进行改造抽取通用业务逻辑规则构建能够快速交付业务功能的模块。对平台架构进行分解分离有状态和无状态模块分离带业务属性和不带业务属性的模块保持模块轻量易于随架构演进进行改造、升级、维护。技术选型技术选型主要从如下几个方面进行考虑数据存储原始数据存储数据量级达到PB级所以作为整个数据服务平台的最初输入数据我们称为数据服务平台的原始数据后续简称原始数据这些原始数据是直接存储在HDFS文件系统中根据时间的维度分为小时数据、日数据、月数据。这样可以根据数据计算需要按照小时、日、月进行加工处理能够在可允许的计算资源配额和计算时间范围内完成处理。另外根据每天大约30~40TB的增量数据原始数据采用parquet格式压缩存储我们进行二次加工的输出仍然是以parquet格式存储。分布式关系数据存储对于PB级的数据想要在数据服务平台中快速为用户提供数据服务根据业务特点存储在适合快速加载、快速计算的分布式数据存储系统中。快速加载必然要对数据进行特殊格式处理并在一定程度上压缩数据这样才能减少数据加载时间。可以很容易想到使用支持列式存储的分布式数据库。比如Vertica分布式数据库就是一款支持列式存储的MPP数据库。Vertica是HP开发的商用分布式数据库同时也发布了开源的免费社区版本不过社区版本有一定限制只支持1TB原始数据、3节点集群规模。如果变通一些可以通过Vertica社区版本进行改造以支持解除3个节点集群规模和1TB存储的限制不过要在分片逻辑控制、分片数据一致性方面做更多工作尤其是面向上层应用提供单一的统一存取视图是非常必要的。因为列式存储支持计算时只加载用于计算的列故而能够达到快速加载的目的。 快速计算首先要求计算能够并行化那么数据就应该分片存储使数据计算本地化。Vertica自然能够实现数据的并行计算我们在前期使用过程中验证了对于从40亿的大表中批量匹配出任意信息(匹配ID以及ID对应的关联表中的其它明细信息)效率非常好基本分钟级便可以输出匹配结果。 我们也对开源不久的MPP数据库Greenplum进行了调研它原生支持分布式架构支持列式和行式两种存储自然具有Vertica对应的列式存储的优势又不需要手动对分片进行管理控制但性能要比Vertica差一些。然而Greenplum数据库能够支持数组类型支持多种编程语言的UDF结合我们之前做过很多有关Bitmap的实践采用开源的RoaringBitmap能够很好的基于Greenplum实现快速的Bitmap计算。消息存储 消息存储主要是用来解耦后台多个较重的系统之间的通信。因为本身这类系统比较重如果采用RPC调用的方式进行通信某个系统进行升级会导致依赖于该系统提供服务的其它系统管理更多的特殊情况处理。而采用消息机制使得各个系统之间不需要关注交互系统处理状态而对消息交换只需要关注消息的生成和消费。 这样我们可以随时对系统进行改造、升级、Bug修复重启等操作而不会使整个平台陷入不可控的状态。消息中间件我们选择使用RabbitMQ。数据处理数据处理主要包括原始数据ETL处理、应用数据计算两大类原始数据ETL处理基于HDFS存储的数据最方便最高效的技术方案自然是使用Spark计算集群来对数据进行ETL处理。我们基于原生的Scala编程语言来开发各种ETL程序实现数据清洗、抽取、转换操作。应用数据计算数据服务平台中面向用户的应用数据计算基于Greenplum数据库支持的SQL语言来实现数据处理并基于Java编程语言来实现整个应用服务的开发。ETL作业调度数据处理需要进行大量的ETL计算管理各种计算任务之间的依赖关系及其调度我们采用了非常轻量的Azkaban调度系统。业务元数据管理业务元数据主要用于支撑数据服务平台Web UI上面的各种业务条件选项比如常用的有如下一些移动设备机型、品牌、运营商、网络、价格范围、设备物理特性应用名称、包名、哈希值应用分类地域信息如国家、省份、城市、区县POI名称、地址POI分类包括一级分类、二级分类这些元数据有些来自于基础数据部门提供的标准库比如品牌、价格范围等可以从对应的数据表中同步或直接读取而有些具有时间含义的元数据需要每天通过ETL处理生成比如应用信息POI数据需要从外部抓取并进行处理一般每个月更新一次。这些元数据为支撑应用计算使用被存储在MySQL数据库中而对于填充页面上对应的条件选择的数据则使用Redis存储每天/月会根据MySQL中的数据进行加工处理生成易于快速查询的键值对类数据存储到Redis中。数据服务数据服务主要支撑后台的数据应用全平台采用标准的REST接口风格来定义主要使用Spring Boot来快速开发对应的接口。离线批量服务进行REST接口封装还有一点我们需要遵循的是任何具有复杂的数据处理逻辑的服务都通过一层REST接口进行封装将全部的离线批量服务后置。这样得到一个聚合服务的REST接口层该层主要负责定义和管理接口的各个请求、响应参数REST接口不变而对应的数据处理逻辑可以根据实际情况进行调整以后对存储或计算方案进行升级改动都不影响使用上层REST接口调用方。Greenplum服务网关比如我们采用Greenplum数据库在Greenplum前面增加了一层Greenplum服务网关对于任何需要访问Greenplum数据库的应用必须通过与Greenplum服务网关进行交互而不是直接去访问Greenplum数据库。理想状态下Greenplum服务网关可以实现为无状态的服务网关通过Nginx做反向代理实现HA这样后续因为业务变更可以非常平滑地进行变更和升级而不影响依赖于Greenplum服务网关的业务接口调用。微服务除了数据服务平台内部进行服务调用最外层通过Web界面的风格只需要拖动或选择可视化组件实现对非技术背景的业务用户进行数据提取和分析未来我们还要将全部的服务暴露到外部(数据服务平台所属部门之外的其它部门以及公司外部)最大化数据服务的价值。微服务部分我们选择了Spring Cloud来快速构建微服务。UI展示UI层主要根据我们开发人员的技术背景使用Vue来构建面向业务用户的数据服务Web系统。架构设计整个数据服务平台的架构设计如下图所示如上图所示对应的各个核心子平台及其服务下面将分别详细说明数据服务Web系统数据服务Web系统是面向用户使用的主要通过可视化业务组件的方式将数据服务暴露出来方便业务用户使用。同时该系统提供用户权限管理的功能可以设置用户权限主要包括业务用户和管理用户。数据服务Web系统的设计如下图所示该系统的设计比较容易核心的思想就是前端和后端分离。前端定义的各种可视化组件都是根据不同业务线的需求经过梳理分类将需求频度较高的抽象出来做成业务功能组件。后端服务包括两类一类是业务元数据服务接口包括各种需要在页面展示的数据项如设备机型、地域、应用、POI等另一类是作业管理服务接口主要负责管理作业相关内容如作业查询、保存等。业务作业调度平台业务作业调度平台是整个数据服务平台最核心的子平台之一设计该平台主要考虑除了当前支撑面向业务用户需求之外还要能够很好的扩展以支持其他业务部门开发人员对服务的使用。该平台的架构如下图所示该平台主要负责作业的解析编排、排队、调度。作业编排采用调用外部编排服务的方式主要考虑的是编排需要根据业务的一些属性进行实现所以将易变的业务部分从作业调度平台分离出去。如果后续有对编排逻辑进行调整和修改都无需操作业务作业调度平台。排队支持多队列排队配置比如根据当前及其未来的发展趋势需要具有面向业务用户的业务队列、面向开发人员的服务队列而这两种队列所负责的作业调度的SLA是完全不同的业务队列中的作业每天可能成百上千个而服务队列在初期对于每个业务线只需要每天调用一次或多次(正常会严格限制服务调用数量)初期从作业量上来看这两个作业容量的比例大概是8:2通过队列来隔离调度能够更好地满足具有不同需求的用户。调度是对作业、以及属于该作业的一组任务进行调度为了简单可控起见每个作业经过编排后会得到一组有序的任务列表然后对每个任务进行调度。这里面稍有点复杂的是作业是一级调度任务是二级调度但是要保证属于同一个作业的任务能够按照先后顺序被调度运行。所以作业是排队的基本单位在每一个排队单元中要包含作业ID、任务个数、作业状态同时为能够控制任务正确调度也需要包含当前调度运行中任务ID、运行中任务状态可见任务是调度运行的基本单位。被调度运行的任务会发送到RabbitMQ中然后等待任务协调计算平台消费并运行任务这时作业调度平台只需要等待任务运行完成的结果消息到达然后对作业和任务的状态进行更新根据实际状态确定下一次调度的任务。另外还有几个点需要注意第一被调度运行的任务需要进行超时处理第二控制同时能够被调度的作业(实际上运行的是作业对应的某个任务)的数量第三作业优先级控制。任务协调计算平台任务协调计算平台也整个数据服务平台最核心的子平台之一它是无状态的除了能够支撑我们的数据服务平台如果有其它想要接入的任务都可以通过该平台协调来运行。该平台的架构如下图所示该平台的设计是主从架构Master和Slave之间通过RPC调用进行通信通信层使用了Netty网络通信框架。Worker可以根据实际计算任务的压力进行水平扩展。Master负责控制从RabbitMQ中拉取任务消息然后根据Worker节点的资源状况进行任务的协调和调度并将Worker上作业完成的信息发送到RabbitMQ供上游业务作业调度平台消费从而控制更新作业的运行状态。同时Master管理注册的Worker状态、Worker资源状态、Worker上运行的任务的状态。Worker是实际运行任务的工作节点它负责将任务调度到后端的计算集群或者调用数据处理服务来实现任务的运行。由于任务都是批量处理型计算任务所以Worker要管理任务的提交以及对已提交任务运行状态的异步查询(轮询)。Greenplum REST服务网关Greenplum REST服务网关直接与Greenplum数据库进行交互这样起到保护Greenplum数据库的作用。因为实际Greenplum数据库集群的计算容量有限不能无限支持很高并发所以通过控制并发来加快每个计算任务。该REST服务网关的设计如下图所示上图中通过排队机制来保护Greenplum并进行任务的调度运行所以该服务是有状态的。而且该服务具有一定的业务特征根据不同的数据需求需要对接口以及SQL进行调整最好的方式是将业务接口与任务计算分离业务接口层可以将调用任务保存到Redis队列中实现接口层的冗余部署和平滑升级然后作为消费的任务处理服务直接消费Redis队列中的任务提交到Greenplum数据库计算。数据微服务平台数据微服务平台主要考虑复用已存在的数据服务以及支撑数据服务的核心组件如业务作业调度平台、任务协调计算平台等为面向开发人员使用的服务调用通过服务接口的方式暴露出来。数据微服务平台的架构如下图所示该平台主要基于Spring Cloud构建使用Eureka作为服务注册中心。由于整个数据服务平台是以离线计算为主没有高并发、服务降级的、调用链跟踪等需求所以并没有完全使用Netflix OSS中大部分组件如Zuul、Hystrix等。如果后续需要可以非常容地集成进来。鉴权网关是所有调用微服务平台的外部调用方的入口。为了保证整个微服务平台的正常运行通过用户、时间(调用期限)、调用频率等限制调用方。比如某些业务线的应用需要使用微服务平台的服务由于对方业务可能下线而服务程序没有下线仍然持续调用我们平台服务这会对微服务平台资源造成浪费。另外也避免了服务调用方测试、调试对整个微服务平台造成不可控的状况。上图左面服务注册中心及其以上部分是整个微服务平台的核心部分我们在构建该平台时也考虑了接入非微服务的组件。比如热力图服务数据是需要批量处理生成而访问时是同步调用的所以在数据服务平台的Web部分提交的作业如果是热力图类型会调用微服务平台的热力图服务异步生成数据而用户可以在Web系统中查看热力图(如果未生成则提示正在生成中)对其它上层数据应用也可以直接调用微服务平台的热力图服务生成数据并下载对应数热力图据。其它服务/系统其它服务/系统比较简单所以这里只是简单说明一下Java REST服务网关要对某些从Greenplum数据库中计算得到的数据需要进行再加工处理以满足实际业务如热力图数据生成和压缩等将这些服务封装成REST风格接口调用。Spark REST服务网关对于需要对HDFS上指定数据集处理生成需要的结果数据使用Spark开发程序同时将Spark计算作业封装成REST风格接口调用。数据ETL调度系统使用开源的Azkaban调度系统实现所有ETL作业的统一调度。数据采集服务根据数据业务需要从网上或其它渠道采集数据比如通过高德API采集POI数据等。架构总结通过上面的架构设计实践我们总结一下实践的经验如下所示底层数据处理引擎可能会随着业务的发展以及新技术的更迭我们会有更多选择所以在数据处理引擎之上设计一层REST服务实现上层应用与底层数据处理引擎解耦和。多个相对较重的服务如业务作业调度平台、任务协调计算平台它们之间通过消息解耦和能更好的降低各个服务的复杂性以及因为变更对双方造成的影响。系统架构分解要考虑将有状态和无状态的部分分离甚至在某个服务中也有必要将有状态和无状态的部分进行分离。业务部分和非业务部分的分离这样能够适应业务需求的变更持续对业务部分进行更新升级而非业务部分可能是相对稳定的。对于无状态的服务我们可以通过冗余部署多个服务实例再通过反向代理的方式实现服务的高可用甚至在演进为微服务架构时也比较容易做到。对于有状态的服务因为单个服务需要维护状态更新所以实现高可用的思路是启动多个实例但是同一时刻只有一个是Active服务可以操作状态而其它实例作为Standby服务需要通过一种机制来监听并发现Active服务的可用性然后在其失败时能切换到Standby服务比如常用的Zookeeper等。作者时延军原文http://shiyanjun.cn/archives/1702.html如有侵权或不周之处敬请劳烦联系若飞(微信1321113940)马上删除谢谢·END·
