剖析大数据平台的数据源

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

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

大数据平台的核心功能

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

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

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

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

数据源的特点

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

来源

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

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

相关文章

来自专栏CSDN技术头条

Lambda架构已死,去ETL化的IOTA才是未来

经过这么多年的发展,已经从大数据1.0的BI/Datawarehouse时代,经过大数据2.0的Web/APP过渡,进入到了IOT的大数据3.0时代,而随之而来...

35540
来自专栏ThoughtWorks

软件测试反模式——杯型蛋糕简介 | TW洞见

今日洞见 文章作者来自:ThoughtWorks-Fabio Pereira,译者:ThoughtWorks-张力文。 感谢ThoughtWorks校对小组:陈...

38580
来自专栏后端技术探索

从既有系统到微服务架构

微服务近年来可谓炙手可热,合理的使用微服务架构可以解耦系统、提供更好的软件伸缩性以及提高组织的敏捷性。然而现实中较少有项目一开始就会选择使用微服务架构,绝大多数...

14220
来自专栏云计算D1net

什么是开发混合云应用的核心因素

虽然为混合云部署开发应用并不是某种黑暗魔法,但是对于很多企业来说,这还是一项具有一定神秘性的工作。 可以想象,任何设想进行混合云开发的用户最终都需要完成很多个这...

39270
来自专栏微信小开发

起底小程序数据分析,每一个指标都不应该被忽视

你可能做了一个小程序,也做了很多推广。 然后查看了后台的一些数据: 有本地也有外地; 有男粉丝也有女粉丝; 有青年才俊,也有中年大叔; 有iPhone也有安卓;...

75390
来自专栏云计算D1net

混合云应用对于企业的意义

虽然为混合云部署开发应用并不是某种黑暗魔法,但是对于很多企业来说,这还是一项具有一定神秘性的工作。 可以想象,任何设想进行混合云开发的用户最终都需要完...

26730
来自专栏互联网数据官iCDO

你是否需要Google Data Studio 360?

译者:吴昊、审校:骆姿亦 本文长度为2079字,预估阅读时间4分钟。 我们今天要向大家介绍的是谷歌发布的一款可视化工具GoogleData Studio 360...

46890
来自专栏数据科学与人工智能

【ETL工程】大数据技术核心之ETL

抛开大数据的概念与基本知识,进入核心。我们从:数据采集、数据存储、数据管理、数据分析与挖掘,四个方面讨论大数据在实际应用中涉及的技术与知识点。 核心技术 架构挑...

692100
来自专栏IT技术精选文摘

规则引擎-BRMS在企业开发中的应用

1. 什么是规则 复杂企业级项目的开发以及其中随外部条件不断变化的业务规则(business logic),迫切需要分离商业决策者的商业决策逻辑和应用开发者的技...

1.1K70
来自专栏后端技术探索

简述架构设计原则

1.全面解耦原则:对业务进行抽象建模,业务数据与业务逻辑解耦,软硬件解耦,平台和产品解耦,系统各部件解耦。模块、组件高内聚,低耦合。

17030

扫码关注云+社区

领取腾讯云代金券