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

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

大数据平台内容

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

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

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

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

数据源的特点

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

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

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

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

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

内部数据

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

外部数据

外部数据分为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。

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

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

我今天的分享就到这里，谢谢大家！