ビッグデータプラットフォーム
ビッグデータの 3つの方法で、職場での応用：
- 関連意思決定、データ科学者の範囲で統計的アルゴリズムを理解するためのデータ科学の分野。
- プロジェクトに関連する、実装する方法、作業データのエンジニアであるどのようなビジネス上の問題を、解決する方法について説明します。
ブリッジの練習を構築するための業務とデータ科学者の間でエンジニアのデータ。共有するには、この論文では大規模なデータプラットフォームのアーキテクチャと技術選択のシナリオは、エンジニアリングの使用に有利になるように偏りました。
示されているように、ビッグデータプラットフォームの最初の要素は、データソースで、我々は、データソースは、ビジネスシステム、データ解析に多いに対処する必要があり、時間が直接処理されたデータソースのビジネスではないかもしれないが、データを通過します取得、データストレージ、データ分析とデータが処理されます。
プロジェクトデータを完了するためには多くのリソースを必要とし、全体の大規模なエコシステムからわかるように、大量のデータをクラスタ化する必要があります。これらのリソースを制御し、調整するために割り当てを監視し、調整する必要があり、どのようにデータの大規模な展開の顔がより簡単に、より便利に;また、大きな円あり、同じことが非常に重要であるこれらのデータのエッジを組み合わせることも可能であるロギング、セキュリティ、およびクラウドを必要とします。
データソースの第二に、特性
データ・ソースの技術的特徴は、データ収集およびデータストレージの選択を決定し、Iは、データ・ソースの特性に応じて4つのカテゴリに分類されるであろう。
- ファーストクラス：データの観点から内部および外部のデータソースに分割されます。
- 第二のカテゴリー：構造上の観点から、構造化データと非構造化データに分割し、
- 第三のカテゴリー：分割不変データの変動は、データビューを変更し、削除するために添加してもよいです。
- 第四のカテゴリーは、大量のデータおよびビューのスケール点から少量のデータに分割されます。
内部データ
内部のシステムから、収集されたタイムリーな変更データを確保するために、アクティブテクノロジー（プッシュ）を使用して書き込むことができます。
外部データ
企業はビッグデータを実行する必要があり、確かに行うには、このような銀行のクレジットなど、企業内のデータのみが、これらに限定されない、その後、あなただけのシステムのトランザクションデータとユーザー情報を銀行することはできませんが、また、外部データを取得するには、インターネットに行くことに。
外部データは、次の2つのカテゴリに分かれています。
- 一つは、それ自体がAPIコールは、マイクロチャネルとして、取得することができ、APIを提供して取得する外部データです。
- 他には、爬虫類をクロール来る必要があり、APIを提供していないデータそのものです。
这两类数据都不是我们可控制的，需要我们去获得，它的结构也可能跟我们企业内部数据的结构不一样，还需要进行转换，爬虫爬取的数据结构更乱，因此大数据平台里需要做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的场景。
这个图基本上把所有的内容都涵盖了，从场景的角度来分析倒推，用什么样的数据源、采用什么样的采集方式、存储成什么样子，能满足离线、内存、实时、流的各种模型，都能从图中得到解答。