大数据平台架构技术选型与场景运用

摘要

本次分享将结合多个大数据项目与产品研发的经验,探讨如何基于不同的需求场景搭建通用的大数据平台。内容涵盖数据采集、存储与分析处理等多方面的主流技术、架构决策与技术选型的经验教训。

视频内容

大数据平台内容

数据源往往是在业务系统上,大多数做数据分析的时候,不会直接对业务的数据源进行处理,这时就需要数据采集。

采集到数据之后,基于数据源的特点把这些数据存储下来。

最后根据存储的位置做数据分析和处理。

整个大的生态圈的核心就是数据采集、数据存储和数据分析。

数据源的特点

数据源的特点决定了数据采集与数据存储的技术选型。数据源的特点主要有来源、结构、可变性和数据量四大类。

来源有内部数据和外部数据,它们的处理方式是不一样的。

结构型数据和非结构型数据的选型也是不同的。

第三个特点是数据是否具有可变性,分为不变可添加和可以修改删除两种类型。

数据量则有大数据量和小数据量之分。

内部数据

内部数据来自企业系统内部,可以采用主动写入技术,从而保证变更数据及时被采用。

外部数据

外部数据分为API调用和网络爬虫。

如果要取到的数据本身提供了API,可以通过调用API来获得数据。

另一种情况是没有提供API,通过爬虫去把数据“爬”过来。

非结构化数据&结构化数据

非结构化数据和结构化数据在存储的时候选型完全不同。非结构化数据更多会选择NoSQL的数据库,而结构化数据考虑到数据的一致性和查询在某些方面做join时的快速性,则会更偏向于选择传统的关系型数据库,或是像TERADATA这样非开源的专业数据库,以及PostgreSQL这种支持分布式的数据库。

不变可添加

如果数据源的数据是不变的,或者只允许添加,则采集会变得非常容易,同步时只需要考虑最简单的增量同步策略,维持数据的一致性也变得相对容易。

可修改可删除

数据源的数据有些可能会修改或删除,尤其是许多维表经常需要变动。要对这样的数据进行分析处理,最简单的办法就是采用直连形式。如果要进行数据采集,就要考虑同步问题。

大数据量

利用时间来处理大数据量并不是一个实时的处理方式。要做到实时的处理方式,应该采用流式处理。要将两种方式结合起来,就要用到大数据的lambda架构。

Lambda架构分为了三层,最下层是speed layer,要求速度快,也就是实时。

最上层是batch layer,也就是批处理。

通过中间层serving layer,定期或不定期地把batch views和speed views去做merged,会产生一个结合了batch的数据。它既满足了一定的实时性,又能满足一定的大数据量。这是目前比较流行的一种大数据的处理方式。

一个典型的数据加载架构

数据存储的技术选型

取决于数据源的类型与数据的采集方式。

取决于采集后数据的格式与规模。

取决于分析数据的应用场景。

大数据平台的特征就是,相同的业务数据会以多种不同的表现形式,存储在不同类型的数据库中,形成一种poly-db的数据冗余生态。

场景一:舆情分析

针对某手机品牌的舆情分析。客户提出的需求是能够对舆情数据进行全文本搜索。舆情数据最高可能达到70亿条,而全文本搜索的性能指标要求响应时间控制在10s以内。

爬虫爬到kafka里面,进行流处理去虫去噪,再做语义分析,语义分析完之后将舆情数据写入ES,全量数据写入HDFS。

场景二:商业智能产品

聚合运算把数据源采集存储的时候,是基于列的运算,而传统数据库是行式存储。行式存储针对于列的运算需要全表才能拿到,这时选择用parquet。因为parquet是以列式方式做存储,所以做统计分析很快。但parquet执行查询会很慢,没有优势。

场景三:Airbnb的大数据平台

Airbnb的数据一部分来自于本身的业务数据在MySQL,还有一部分是大量的事件。数据源不同,处理的方式也不一样。

基于日志,就用事件写入kafka;如果是针对MySQL,就用Sqoop,写入HDFS里,并建立Hive的集群。还存了一份数据放入亚马逊的S3。

有一部分业务就是对数据合并后放入HDFS做大量的业务查询和业务统计。这时希望用SQL的方式进行查询,会有很多选项,它选择的是Presto。

还有一些流式处理或机器学习要用到Spark,选型就会不同。

数据处理的分类

从业务角度来看,可以分为查询检索、数据挖掘、统计分析和深度分析。

从技术角度分为五类,batch MapReduce、SQL、流式处理、Machine Learning和DeepLearning。

编程模型有离线编程模型、内存编程模型和实时编程模型。

基于数据源的特点、分类,采集的方式,以及存储的选型,到数据分析和处理的分类,可得出一个相对总体的大数据平台架构。

我今天的分享就到这里,谢谢大家!

原文发布于微信公众号 - IT大咖说(itdakashuo)

原文发表时间:2017-08-01

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏林德熙的博客

硬件分配

以前做的是把一个软件分配到硬件,只需要让用背包问题最大化硬件的使用,但是没有让所有资源最大化。

13910
来自专栏我是极客人

【译】怎样监控与可视化微服务架构

构建和部署分布式应用程序后,监视和可视化它至关重要,以确保软件的可靠性,可用性和预期的性能。这并不容易。

42230
来自专栏流柯技术学院

系统吞吐量(TPS)、用户并发量、性能测试概念和公式

  一个系统的吞度量(承压能力)与request对CPU的消耗、外部接口、IO等等紧密关联。

72210
来自专栏开源项目

新零售时代如何玩转微信商城 | 码云周刊第 74 期

34120
来自专栏北京马哥教育

系统吞吐量、TPS(QPS)、用户并发量、性能测试概念和公式

PS:下面是性能测试的主要概念和计算公式,记录下: 一.系统吞度量要素: 一个系统的吞度量(承压能力)与request对CPU的消耗、外部接口、IO等等紧密...

1.2K50
来自专栏WeTest质量开放平台团队的专栏

服务器压力测试的一次优化历程

对技术人员来说,知其然还需知其所以然。搞清技术的底层机制、弄明白问题的深层次原因、知悉解决方案的适用场景,是每个开发人员应有的技术素养,也是个人发展上积累功底、...

2.3K20
来自专栏黑泽君的专栏

软件开发文档介绍

50120
来自专栏杨建荣的学习笔记

运维开发流程梳理和思考

记得之前梳理过一个运维开发流程,也做了一些实践,从我的认识和理解来看,其实这更适合一个团队内的协作。

25630
来自专栏北京马哥教育

基础拾遗--【转】性能测试的主要概念和计算公式

PS:下面是性能测试的主要概念和计算公式,记录下: 一.系统吞度量要素: 一个系统的吞度量(承压能力)与request对CPU的消耗、外部接口、IO等等紧...

34080
来自专栏DevOps时代的专栏

无服务器化的微服务持续交付

前言 我在刚进入 ThoughtWorks 的时候就做微服务,当时不知道什么叫做微服务,只是我们通过一个小的技术应用替换原先的大应用的一个部分,当时只是做一个解...

42160

扫码关注云+社区

领取腾讯云代金券