结构化大数据分析平台设计

前言 

任何线上系统都离不开数据,有些数据是业务系统自身需要的,例如系统的账号,密码,页面展示的内容等。有些数据是业务系统或者用户实时产生的,例如业务系统的日志,用户浏览访问的记录,系统的购买订单,支付信息,会员的个人资料等。大多数企业对内,对外有很多这样的线上系统,这些数据是驱动业务发展,决策和创新最核心的东西。让这些数据更好的支撑线上系统的是数据库和数据分析平台。
数据库主要承担的是线上系统的实时数据写入和根据预定好的需求进行查询,严格说就是数据库中的OLTP类型数据库。这类数据库中最为大家所熟知的就是Oracle和MySQL。业务系统对数据库的要求可能是多样的,近些年也由传统的关系型数据库融入了NoSQL数据库和NewSQL。业务系统中除了和业务直接相关的数据存储在数据库中并累积起来外,还有海量的系统监控数据,系统业务日志产生。如果我们希望这些数据可以更持久的存储并且做一些实时或者离线的分析,辅助我们的业务做决策,提供业务大盘和报表,很多公司会构建自己的数据分析平台。也就是时下『大数据』平台的由来。这类平台主要解决以下几个问题:

1. 丰富的数据源支持和数据格式延迟绑定

丰富的数据源是因为这样一个数据分析平台是汇总我们各类业务数据的地方,数据源可能来自各类数据库例如MySQL,MongoDB,日志源等等。这个平台需要能够方便各类数据源便捷的入库,例如通常大家会发现大数据架构中有一个Kafka,各类数据源会先进入Kafka,再由Kafka推送到大数据的存储系统中。这里Kafka就承担了解耦大数据平台的存储接口和上游数据源的作用。数据格式延时绑定是一个很重要的概念,TP类数据库往往需要根据业务需求预先定义Schema,也就是通常说的写入型Schema,数据在写入时即会做严格的数据字段类型检验。但是分析系统并不希望因为Schema约束或者限制的数据入库,通常会采用读取型Schema,也就是这里的延时绑定,数据在分析时才会根据数据类型做对应的处理。

2. 存储和计算弹性扩展

存储和计算弹性扩展是指大数据系统需要能支撑海量数据和保持高吞吐的读写。数据分析平台会汇总接纳各类线上系统中的各类数据,同时数据会随着时间进行累积。大数据分析平台能够支撑海量数据的存储是必须的,而且这个规模并不是预先定义好的,而是随着数据的累积弹性增加的,这里的存储量可能从TB级到PB级别,甚至数百PB。同时整套架构的计算能力也一样具备弹性,举个直观的例子,可能我们在TB级别做一次全量处理需要20分钟,是不是到了百PB级别,处理时间也翻了好几个数量级从而导致每天的分析结果不能及时产生,从而让大数据平台的价值大打折扣,限制了业务的飞速发展。

3. 大规模低成本   

很多大数据平台设计之初未必会意识到成本,主要依据自身对开源方案的熟悉度,业务方对数据规模和分析实效性进行方案的选取。但当业务量真的起来后,不得不面临一个挑战就是大数据平台的成本问题。这里甚至会导致不得不进行平台的架构改造或者数据迁移。所以对于企业的大数据平台设计之初,我们就需要把整套架构的成本考虑进来。这对应的就是数据的分层存储和存储计算引擎的选取。时下云上的大数据平台往往最终会选择一个可扩展,低成本的存储平台落地最终的数据,例如阿里云上的OSS或者AWS的S3,这些存储平台本身也支持进一步的分层存储。这类存储之上的计算平台可以选取Elastic MapReduce方案。整套架构就组成了时下火热的『数据湖』方案。在线下用户可能会自建一个Hadoop集群,并使用HDFS来存储这些汇总的数据,进而构建自己的大数据数据仓库。

4. 在线业务和分析业务隔离

隔离是因为分析业务往往需要扫描较多的数据进行分析,这类大流量的扫描如果是发生在在线库,可能会影响线上服务的SLA。同时分析流量的访问模式和在线模式未必相同,在线库数据的存储分布和格式也未必适合分析系统。所以一般典型的大数据平台会有自己的一份存储,数据分布,格式和索引会面向分析需求而做相应的优化。例如典型的TP类引擎的存储格式往往是行存,分析的时候会转变成列存。

介绍到这里,希望引导大家来思考这样一个问题,不论是传统的数据仓库,还是云上的数据湖,我们最终还是希望可以有效的解决业务中数据存储和分析的问题。那究竟业务需求是什么,尤其是当我们希望分析数据源是数据库,日志监控这类结构化或者半结构化数据时,对大数据平台的需求是什么呢?我想这里大家可以先思考一下,后面我们会和大家一起看看时下一些主流的开源方案和云上的构建方案,然后再来总结下结构化大数据存储和分析的需求。

开源大数据存储分析平台架构

前面我们提及线上业务的实现离不开OLTP数据库的支持,来实现实时的数据读写。这一章我们一起看看,开源和云上一些主流的组合数据库和大数据分析平台的架构。

Hadoop大数据方案

方案一:Uber Hadoop大数据架构
我们以Uber的一套大数据架构为例,图中展示了各类数据库通过Kafka推送到Ha

  • 2
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值