剖析大数据平台的数据源

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

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

大数据平台的核心功能

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

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

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

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

数据源的特点

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

来源

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

企业的内部数据通常与具体业务紧密相关,且多数来自我们可以掌控(或者通过兄弟团队)的软件系统,如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 条评论
登录 后参与评论

相关文章

来自专栏FreeBuf

Hunting系统:简述如何通过智能分析异常来检测网络入侵行为

? 当组织内发生数据泄露事件时,泄漏检测系统(BDS)能够给我们提供足够有效的提醒,但如果敏感等级设置的非常低的话,我们还需要考虑风险报告的假阳性问题。而基于...

1956
来自专栏媒矿工厂

网络媒体联合工作组(JT-NM)技术规范介绍

目前,专业媒体行业面临着从专用广播设备和接口(SDI,AES,交叉点切换器等)到基于IT的分组网络(以太网,IP,服务器,存储,云等)的转变。如何通过在网络上进...

620
来自专栏大数据

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

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

2785
来自专栏大数据文摘

快播CEO认罪,成人网站对技术的要求有多高?

1505
来自专栏CSDN技术头条

Kylin正式发布:面向大数据的终极OLAP引擎方案

日前,eBay公司隆重宣布已经正式向开源业界推出分布式分析引擎:Kylin(http://kylin.io)。作为一套旨在对Hadoop环境下分析流程进行加速、...

1849
来自专栏BestSDK

Facebook、亚马逊是如何构建超集群数据库的

我们建立了Keen IO,是为了以让大多数软件工程团队无需从头架设所有内容,就可以利用最新的大型事件数据技术。但是,如果您对如何成为巨头公司感到...

3755
来自专栏BestSDK

想用APP创业,那你要明白API的重要性?

每一家初创企业和公司都会有提供给世界的接口。有的接口超级简单,比如Google—你能做的只有搜索;有的复杂一点,比如在Amazon上面买东西—你可以浏览、搜索、...

2809
来自专栏PPV课数据科学社区

【工具】六大工具帮你做好大数据分析

大数据是一个含义广泛的术语,是指数据集,如此庞大而复杂的,他们需要专门设计的硬件和软件工具进行处理。该数据集通常是万亿或EB的大小。这些数据集收集自各种各样的来...

2637
来自专栏EAWorld

Prometheus vs. Graphite:时序数据监控工具选择

原题:Prometheus vs. Graphite: Which Should You Choose for Time Series or Monitorin...

643
来自专栏携程技术中心

微分享回放 | 携程是如何把大数据用于实时风控的

作者简介 郁伟,携程技术中心风险控制部高级开发经理。2010加入携程,参与了携程结算平台、风控系统的开发,对系统架构、流式数据处理等有比较深入的研究。 *视频...

2818

扫描关注云+社区