剖析大数据平台的数据源

我在一次社区活动中做过一次分享,演讲题目为《大数据平台架构技术选型与场景运用》。在演讲中,我主要分析了大数据平台架构的生态环境,并主要以数据源、数据采集、数据存储与数据处理四个方面展开分析与讲解,并结合具体的技术选型与需求场景,给出了我个人对大数据平台的理解。本文是演讲内容的第一部分。

大数据平台是一个整体的生态系统,内容涵盖非常丰富,涉及到大数据处理过程的诸多技术。在这些技术中,除了一些最基础的平台框架之外,针对不同的需求场景,也有不同的技术选择。这其中,显然有共性与差异性的特征。若从整个开发生命周期的角度看,无论是需求、架构,还是开发、测试到最后的部署与运维,各种技术都会牵扯其中,不同的角色关注点自然也有不同。

大数据平台的核心功能

从大数据平台工程师的角度看,决定整个大数据平台关键质量的不外三方面:

  • 数据采集
  • 数据存储
  • 数据处理

至于系统监控、资源协调、部署运维及其他管理功能都是大数据平台整个生态环境中不可缺少的拼图,但对于面向数据的架构,核心还是与数据打交道的一部分。如下图所示:

根据我在大数据项目中的经验,我发现,无论是数据采集、存储还是分析,在技术选型与方案设计上,似乎又与数据源的特征息息相关,甚至在某种程度上,可以认为是数据源的特点决定了整个大数据平台架构的设计。

数据源的特点

于是,我将关注点首要放在了数据源上。分析数据源的数据特征,我从四个不同的维度对数据源进行了分类:

来源

数据的来源不同,意味着我们对数据的掌控也就不同,更意味着我们对数据的访问机制也有所不同。

企业的内部数据通常与具体业务紧密相关,且多数来自我们可以掌控(或者通过兄弟团队)的软件系统,如CRM、ERP或者HR系统。从企业架构的角度考虑,我们本身就应该避免企业系统出现所谓的“烟囱系统”,规避“信息孤岛”。设计良好的系统应该要提供相关的接口允许其他系统有限度地访问该系统的内部数据,又或者主动地将内部数据写入到一个完全解耦合的系统中。例如,一个常见的做法是将内部系统实时产生的输入写入到Kafka中。

通常,我们会尽量避免直接将内部系统的数据库公开给大数据平台。因为这种方式不仅会带来潜在的安全威胁,还可能会因为资源占用的缘故影响到业务系统。

外部数据的获取方式不外乎两种:

  • API调用
  • 通过网络爬虫抓取

与内部数据不同,外部数据不可能听指挥地“召之即来挥之即去”,我们需要定期或不定期地去获取数据,好处是我们可以根据业务场景和数据的特点自主地选择数据存储。

结构

只要了解过大数据项目,都知道数据结构直接影响了存储与处理技术的选择。RDB之于结构型数据,NoSQL之于非结构数据,这是司空见惯的配对了。相当而言,RDB的选择比较简单,NoSQL则有更复杂的分类。Pramod J·Sadalage与Martin Fowler在NoSQL Distilled一书中将NoSQL分为四类:

  • 键值数据库
  • 文档数据库
  • 列族数据库
  • 图数据库

针对不同结构类型的数据,我们将这一分类作为选型的参考。

可变性

Datomic数据库的设计哲学是将所有过去发生的事情(或事件)认为是一个“fact(事实)”,基于事实不能篡改的本质,则数据库中存储的数据也当是不变的。无论是添加、删除还是修改,在数据库层面都是增加一条记录。

然而,多数数据库并未添加这种不变性的约束,虽然这种不变性带来的好处是明显的,不过也会给业务系统的设计与实现带来不必要的复杂度。然而,作为大数据平台的数据源而言,情况则相反,若数据允许更改,数据采集过程就会变得更复杂。

一种简单的应对办法是采用直连的形式。由于数据分析可能会基于不同的数据场景对数据存储提出不同的要求,直连的数据源未必满足这种要求。例如,假设我们的分析场景是要做基于关键字的全文本搜索,在大数据量高性能的要求下,选择ElasticSearch或者Solr会表现更好,若直连的数据源是MySQL,事情就会变得较为棘手。

数据量

数据量小,则一切都可迎刃而解,这里不再赘述。

针对大数据量,实则是两个不同的场景。一种是批处理方式,典型地算法是MapReduce,主要针对非实时需求场景,我们可以编写定期以及批量执行的任务来完成数据的采集。需要费心的是对Job的监控、管理与调度。另一种则是流处理方式,(准)实时对产生的数据进行处理,这种场景对数据源的限制更多,最常见的方案就是将源源不断产生的数据写入到Kafka中。

在真实场景下,批处理与流处理方式可能共存。Lambda架构提出创新的三层架构方式,将此二者有机地融合起来,分别为:

  • Batch Layer:针对批处理场景
  • Speed Layer:针对流处理场景
  • Serving Layer:由流处理场景提供实时数据模型,再对批处理的大数据进行预计算,从而提供批处理数据模型(聚合计算后),合并后提供给Serving Layer。

Lambda架构图如下所示:

OLAP分析平台druid就采用了Lambda架构。

原文发布于微信公众号 - 逸言(YiYan_OneWord)

原文发表时间:2017-06-14

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏大数据

后 Hadoop 时代的大数据技术思考:数据即服务

1. Hadoop 的神话正在破灭 IBM leads BigInsights for Hadoop out behind barn. Shots heard ...

2975
来自专栏编程坑太多

『高级篇』docker之springboot,springcloud(八)

PS:下面我们一步一步spring cloud+spring boot创建的微服务,部署在服务编排框架上。

1102
来自专栏hadoop学习

学习Hadoop大数据基础框架

什么是大数据?进入本世纪以来,尤其是2010年之后,随着互联网特别是移动互联网的发展,数据的增长呈爆炸趋势,已经很难估计全世界的电子设备中存储的数据到底有多少,...

997
来自专栏风火数据

大数据 Hadoop:一把杀鸡用的宰牛刀

Hadoop是个庞大的重型解决方案,它的设计目标本来就是大规模甚至超大规模的集群,面对的是上百甚至上千个节点,这样就会带来两个问题:

972
来自专栏数据和云

YH10:分布式存储解决方案zData

云和大数据时代的到来导致各行各业数据量的爆发,面对业务数据的日益剧增,企业的IT系统在性能、稳定性和扩展性等方面都面临前所未有的巨大挑战。如何有效应对云和大数据...

3534
来自专栏服务端技术杂谈

牛B的网站怎么设计Feed流

大型互联网公司招聘的时候总是要求具备:高并发,高负载,大数据处理的能力。我们做了N多的系统项目,互联网产品,究竟哪些项目或者产品能够真正体现出高并发,高负载的处...

4496
来自专栏前沿技墅

智能监控利器:时序数据库

微博广告基础架构团队负责人、技术专家,商业大数据平台及智能监控平台发起人,目前负责广告核心引擎基础架构、Hubble智能监控系统、商业基础数据平台(D+)等基础...

1154
来自专栏Java后端技术

分布式架构之美~

​  我们都知道,当今无论在BAT这样的大公司,还是各种各样的小公司,甚至是传统行业刚转互联网的企业都开始使用分布式架构,那么什么叫分布式架构呢?分布式架构有什...

1231
来自专栏大数据

使用Hadoop分析大数据

大数据由于其庞大的规模而显得笨拙,并且大数据需要工具进行高效地处理并从中提取有意义的结果。Hadoop是一个用于存储,分析和处理数据的开源软件框架和平台。本文是...

1392
来自专栏四蛋科技

驱动大数据的技术发展

据估计,每天会创建2.5百万兆字节的数据,我们需要将这些前所未有的大量数据妥善储存以便日后访问以及对其进行分析。这些数据量大到需要使用鲜为人知的单位来衡量,如Z...

2354

扫码关注云+社区