摘要
本次分享将结合多个大数据项目与产品研发的经验，探讨如何基于不同的需求场景搭建通用的大数据平台。内容涵盖数据采集、存储与分析处理等多方面的主流技术、架构决策与技术选型的经验教训。
https://v.qq.com/x/page/u053229kzk6.html
大数据平台内容
数据源往往是在业务系统上，大多数做数据分析的时候，不会直接对业务的数据源进行处理，这时就需要数据采集。
采集到数据之后，基于数据源的特点把这些数据存储下来。
最后根据存储的位置做数据分析和处理。
整个大的生态圈的核心就是数据采集、数据存储和数据分析。
数据源的特点
数据源的特点决定了数据采集与数据存储的技术选型。数据源的特点主要有来源、结构、可变性和数据量四大类。
来源有内部数据和外部数据，它们的处理方式是不一样的。
结构型数据和非结构型数据的选型也是不同的。
第三个特点是数据是否具有可变性，分为不变可添加和可以修改删除两种类型。
数据量则有大数据量和小数据量之分。
内部数据
内部数据来自企业系统内部，可以采用主动写入技术，从而保证变更数据及时被采用。
外部数据
外部数据分为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。
编程模型有离线编程模型、内存编程模型和实时编程模型。
基于数据源的特点、分类，采集的方式，以及存储的选型，到数据分析和处理的分类，可得出一个相对总体的大数据平台架构。
