A big data platform
Big Data applications at work in three ways:
- Related decision-making, the field of data science to understand the statistical algorithm, which is the scope of data scientists;
- Associated with the project, how to implement, how to solve any business problem, which is the working data engineers.
Engineers data between business and data scientists to build a bridge practice. In this paper to share large data platform architecture and technology selection scenario biased in favor of the use of engineering.
As shown, the first element of big data platform is the data source, we have to deal with data sources are often on business systems, data analysis, the time may not be the business of the data source is processed directly, but to go through the data acquisition, data storage, data analysis and data then is processed.
As can be seen from the entire large ecosystem, to complete the project data requires a lot of resources; large amounts of data need to cluster; to control and coordinate these resources need to monitor and coordinate the assignment; how the face of large-scale deployment of data easier and more convenient ; also involves logging, security, and cloud is also possible to combine the edges of these data are big circle, the same is very important.
Second, the characteristics of the data source
Technical characteristics of the data source determines the selection of data acquisition and data storage, I according to the characteristics of the data source will be divided into four categories:
- First class: the data are divided into internal and external data sources from the point of view;
- The second category: divided into structured data and unstructured data from a structural point of view;
- The third category: divided immutable data variability may be added to modify and delete data view;
- The fourth category is divided into a lot of data and a small amount of data from the scale point of view.
Internal data
From the internal system, can be written using active technology (push), so as to ensure timely change data is collected.
External Data
Enterprises need to do big data, then certainly not limited to only the data within the enterprise, such as bank credit to do, you can not just banking system transaction data and user information, but also to go to the Internet to pull external data.
External data is divided into two categories:
- One is an external data to be acquired itself provides API, API calls can be acquired, such as micro-channel;
- The other is the data itself does not provide API, need to come crawling reptiles.
这两类数据都不是我们可控制的，需要我们去获得，它的结构也可能跟我们企业内部数据的结构不一样，还需要进行转换，爬虫爬取的数据结构更乱，因此大数据平台里需要做ETL，由ETL进行数据提取、转换、加载，清洗、去重、去噪，这个过程比较麻烦。爬虫爬过来的数据往往是非结构性的、文档型的数据，还有视频、音频，这就更麻烦了。
结构化数据 & 非结构化数据
结构化和非结构化数据在存储时的选型完全不同，非结构化数据偏向于文件，或者选择NoSQL数据库；考虑到事务的一致性，我们也可能选择传统的数据库。
不变可添加数据
如果数据源的数据是不变的，或者只允许添加（通常，数据分析的事实表，例如银行交易记录等都不允许修改或删除），则采集会变得非常容易，同步时只需要考虑最简单的增量同步策略，维持数据的一致性也相对变得容易。
对于大数据分析来说，我们每天在处理的数据大部分是不可变更的。正如Datomic数据库的设计哲学就是数据为事实（fact），它是不可变的，即数据是曾经发生的事实，事实是不可以被篡改的，哪怕改一个地址，从设计的角度来说也不是改动一个地址，而是新增了一个地址。交易也是如此。
可修改可删除数据
银行的交易记录、保险单的交易记录，互联网的访客访问记录、下单记录等都是不可变的。但是数据源的数据有些可能会修改或删除，尤其是许多维表经常需要变动。要对这样的数据进行分析处理，最简单的办法就是采用直连形式，但直连可能会影响数据分析的效率与性能，且多数数据模型与结构可能不符合业务人员进行数据分析的业务诉求。如果采用数据采集的方式，就要考虑同步问题。
大数据量
针对大数据量，如果属于高延迟的业务，可以采用batch的处理方式，实时分析则需要使用流式处理，将两者结合就是Lambda架构，即有实时处理、又能满足一定的大数据量，这是现在比较流行的大数据处理方式。
三、数据存储的技术选型
大数据平台特征：相同的业务数据会以多种不同的表现形式，存储在不同类型的数据库中，形成一种poly-db的数据冗余生态。
先把数据源进行分类，然后根据其特点判断用什么方式采集，采集之后要进行存储。数据存储的技术选型依据有三点：
- 第一点取决于数据源的类型和采集方式。比如非结构化的数据不可能拿一个关系数据库去存储。采集方式如果是流失处理，那么传过来放到Kafka是最好的方式。
- 第二点取决于采集之后数据的格式和规模。比如数据格式是文档型的，能选的存储方式就是文档型数据库，例如MongoDB；采集后的数据是结构化的，则可以考虑关系型数据库；如果数据量达到很大规模，首选放到HDFS里。
- 第三点是分析数据的应用场景。根据数据的应用场景来判定存储技术选型。
场景一：舆情分析
做舆情分析的时候客户要求所有数据存放两年，一天600多万，两年就是700多天×600多万，几十亿的数据。而且爬虫爬过来的数据是舆情，做了分词之后得到的可能是大段的网友评论，客户要求对舆情进行查询，做全文本搜索，并要求响应时间控制在10s以内。
我们后来选择用ES，在单机上做了一个简单的测试，大概三亿多条数据，用最坏的查询条件进行搜索，保证这个搜索是全表搜索（基于Lucence创建了索引，使得这种搜索更高效），整个查询时间能控制在几秒以内。
如图所示，爬虫将数据爬到Kafka里，在里面做流处理，去重去噪做语音分析，写到ElasticSearch里。我们做大数据的一个特点是多数据库，会根据不同的场景选择不同的数据库，所以会产生大量的冗余。
场景二：商业智能产品
BI产品主要针对数据集进行的数据分析以聚合运算为主，比如求合、求平均数、求同比、求环比、求其他的平方差或之类的标准方差。我们既要满足大数据量的水平可伸缩，又要满足高性能的聚合运算。选择Parquet列式存储，可以同时满足这两个需求。
场景三：Airbnb的大数据平台
Airbnb的大数据来自两块：一是本身的业务数据，二是大量的事件。数据源不同，采集方式也不一样。日志数据通过发送Kafka事件，而线上数据则通过Sqoop同步。数据存储选择HDFS集群，然后通过Presto对Hive表执行即席查询。S3是一个独立的存储系统。
四、数据处理
数据处理分为三大类：
- 第一类是从业务的角度，细分为查询检索、数据挖掘、统计分析、深度分析，其中深度分析分为机器学习和神经网络。
- 第二类是从技术的角度，细分为Batch、SQL、流式处理、machine learning、Deep learning。
- 第三类是编程模型，细分为离线编程模型、内存编程模型、实时编程模型。
结合前文讲述的数据源特点、分类、采集方式、存储选型、数据分析、数据处理，我在这里给出一个总体的大数据平台的架构。值得注意的是，架构图中去掉了监控、资源协调、安全日志等。
左侧是数据源，有实时流的数据（可能是结构化、非结构化，但其特点是实时的），有离线数据，离线数据一般采用的多为ETL的工具，常见的做法是在大数据平台里使用Sqoop或Flume去同步数据，或调一些NIO的框架去读取加载，然后写到HDFS里面，当然也有一些特别的技术存储的类型，比如HAWQ就是一个支持分布式、支持事务一致性的开源数据库。
从业务场景来看，如果我们做统计分析，就可以使用SQL或MapReduce或streaming或Spark。如果做查询检索，同步写到HDFS的同时还要考虑写到ES里。如果做数据分析，可以建一个Cube，然后再进入OLAP的场景。
这个图基本上把所有的内容都涵盖了，从场景的角度来分析倒推，用什么样的数据源、采用什么样的采集方式、存储成什么样子，能满足离线、内存、实时、流的各种模型，都能从图中得到解答。