文 | 帆软数据应用研究院 贾强

数据分析平台的搭建从规模上分类，确定企业规模，明确合作点，非常重要。

以服装行业为例，大型企业如波司登，本身的大数据系统架构已经完善，数据分析平台（报表/商业智能软件）在整个系统架构下的角色定位为“工具”更合适，发挥工具易用、高效开发、交互性强，稳定等优点。

中小型企业从成本上考虑，并没有成熟的架构以及大量的投入。对于整合数据，构建数据中心报表系统，我们可以进行合理规划，控制整个项目建设和运维成本，从而能够达成更好的合作。

在时尚业行业中，对于各个分店的有效管理，如何构建合理高效的报表中心变得非常关键。这里从两方面讲述，系统架构和技术实现方式，主要是鞋服行业，其他行业仅供借鉴。

首先是系统架构，从架构上分为分店管理系统（ERP和POS）及数据库、服务器和应用层客户端。系统架构如图：

（１）分店管理系统及数据库。分店使用管理系统管理本店进销存业务及相关管理工作，并定期按需将各个分店数据上传至云端服务器。

（２）服务器。构建服务器集群。数据分散在不同的服务器主机上可以并行存取，提高了数据的存取速度。服务器负责存储分店采集的各种数据，并以这些数据为基础构建数据仓库。再部署帆软数据分析平台，将处理结果给返回客户端，供业务层和决策层使用。

（３）应用层客户端。应用层客户端分为决策和统筹管理两部分。决策层根据所获得的报表、图形和走势图等来支持其决策。设置一个统筹管理的职能部门，统筹各分店统一促销，畅销商品管理和会员行为分析。企业通过云改变了以前处理数据和接入数据的方式，数据更集中，数据一致性更强，数据质量提高，分店之间的联系更紧密更便捷，在这种环境下，企业的决策依据将更准确。

（４）服务器的构建。架构如图，ETL工具通过远程访问。各个分店的服务器完成数据收集的任务，收集的数据是最原始的数据不做处理，先存储在数据中心。数据中心为基础数据库，数据中心集中了所有分店的数据。数据上传完成后继续对数据进行ETL处理，并将处理后的数据存入到数据仓库。数据分析应用程序根据客户端的请求调用数据仓库中的数据进行处理，并将结果返回给请求客户端，同时将常用的分析按计划定期自动分析并将结果保存到预定义分析结果模块中。每个分店和总部的管理层都有接入云的权限，云端数据共享。作为总部，可以监控各个分店的运营情况，作为分店可以及时了解其他分店的运行情况，借鉴经验并制定销售策略。

其次是技术实现方式，包含数据仓库、ETL、数据分析平台。

数据仓库（DataWarehouse，DW）是一个收集、组织、存储和共享历史数据的系统，其中数据ETL工具（选开源工具的话，可以用Kettle）。支持多种类型的数据源，还可以将数据库文件下载到本地进行ETL工作。PDI分为两个步骤，一个叫Transformation，另一个叫job，可以设定这些转换的执行时间和频率，这一点对于数据仓库的自动化更新是很有帮助。

下面聊一聊数据采集与分析

每个分店有各自的分店管理系统及数据库，根据中央服务器要求将需要的数据进行上传。对于零售业来说，需要上传的数据主要包括销售数据、会员数据、商品数据、库存数据、调研数据等。需要预定义所需采集的数据，包括数据的类型、数据结构。对于数据库的数据，数据库名称、表名称、表字段都采取统一格式和名称。对于文本型数据也要统一格式，或以xml方式存储。服务器收集各个分店管理数据库的数据并对每个分店的数据标记以区分。统一标准数据可很大程度地提高数据采集的质量和后续处理效率。

对于除了分店以外的数据源，如商业共享数据平台等，需要根据实际情况设计相应接口和采集方法，帆软数据分析平台内置采集数据功能，可以非常方便根据业务情况定制数据采集模块。

数据的分析工作在按照数据仓库对数据的要求并选择合适的工具对不同类型的数据进行处理，然后保存到数据仓库中。随着时间的推移，数据中心的数据量会不断增加，运用大数据工具是非常有必要的。大数据工具的主要特点是通过服务器集群中的主机并行处理数据，将一个庞大的任务分解为小任务处理。

应用程序部署到云端以后，客户端通过浏览器调用相应的功能，只需将结果返回给客户端，在客户端进行数据分析结果的展现。针对时尚业的数据分析可以包括多个方面，比如：销量分析、客户购买偏好分析、商品关联分析、精准推送服务等。

这篇呢是小编从年薪百万的大数据架构师那里得到的课堂笔记：大数据大型综合项目实战:搜狗日志查询分析，有在学的赶紧来看看了，不常有哦！

数据：

=======================================

一、电商大数据平台整体架构

1、大数据（Hadoop、Spark、Hive）都是一种数据仓库的实现方式

核心问题：数据存储、数据计算

什么是数据仓库？传统的解决大数据的方式，就是一个数据库

一般只做查询

2、大数据平台整体的架构

部署：Apache、Ambari（HDP）、CDH

二、在项目中使用使用瀑布模型（软件工程：方法论）

1、瀑布模型几个阶段?

2、每个阶段完成的任务

三、使用MapReduce进行分析处理（Java程序）

1、MapReduce的基本原理（编程模型）

(*) 思想来源：Google的论文：MapReduce 问题 PageRank（网页排名）

(*) 先拆分、再合并----->分布式计算

2、使用MapReduce进行日志分析

四、使用Spark进行分析和处理（Scala语言、Java语言）

1、Spark的优点和体系架构

2、使用Scala开发Spark任务进行日志分析

bin/spark-shell --master spark://bigdata11:7077

val rdd1 = sc.textFile("hdfs://mydemo71:8020/myproject/data/SogouQ1.txt")

val rdd2=rdd1.map(_.split("\t")).filter(_.length==6)

rdd2.count()

val rdd3=rdd2.filter(_(3).toInt==1).filter(_(4).toInt==2)

rdd3.count()

rdd3.take(3)

五、使用Hive（蜂巢）进行分析和处理

1、什么是Hive？特点？Hive体系结构

是基于HDFS之上的数据仓库

支持SQL语句

是翻译器：SQL ---->MapReduce（Spark任务）

2、使用Hive进行查询操作

①　创建Hive对应的表

create table sogoulog(accesstime string,useID string,keyword string,no1 int,clickid int,url string) row format delimited fields terminated by ',';

②　将原始数据进行清洗：因为有些不满足长度为6

val rdd1 = sc.textFile("hdfs://mydemo71:8020/myproject/data/SogouQ1.txt")

val rdd2=rdd1.map(_.split("\t")).filter(_.length==6)

val rdd3 = rdd2.map(x=>x.mkString(",")) 这里需要注意转成字符串

rdd3.saveAsTextFile("hdfs://mydemo71:8020/myproject/cleandata/sogou")

③　将清洗后的数据导入Hive

load data inpath '/myproject/cleandata/sogou/part-00000' into table sogoulog;

load data inpath '/myproject/cleandata/sogou/part-00001' into table sogoulog;

④　使用SQL查询满足条件的数据（只显示前10条）

select * from sogoulog where no1=1 and clickid=2 limit 10;

查询10号部门 工资大于2000的员工

经常有初学者在博客和QQ问我，自己想往大数据方向发展，该学哪些技术，学习路线是什么样的，觉得大数据很火，就业很好，薪资很高。如果自己很迷茫，为了这些原因想往大数据方向发展，也可以，那么我就想问一下，你的专业是什么，对于计算机/软件，你的兴趣是什么?是计算机专业，对操作系统、硬件、网络、服务器感兴趣?是软件专业，对软件开发、编程、写代码感兴趣?还是数学、统计学专业，对数据和数字特别感兴趣。

其实这就是想告诉你的大数据的三个发展方向，平台搭建/优化/运维/监控、大数据开发/ 设计/ 架构、数据分析/挖掘。请不要问我哪个容易，哪个前景好，哪个钱多。

分享之前我还是要推荐下我自己创建的大数据学习交流Qun531629188无论是大牛还是想转行想学习的大学生小编我都挺欢迎，今天的已经资讯上传到群文件，不定期分享干货，包括我自己整理的一份最新的适合2018年学习的大数据教程，欢迎初学和进阶中的小伙伴。

先扯一下大数据的4V特征：

数据量大，TB->PB

数据类型繁多，结构化、非结构化文本、日志、视频、图片、地理位置等;

商业价值高，但是这种价值需要在海量数据之上，通过数据分析与机器学习更快速的挖掘出来;

处理时效性高，海量数据的处理需求不再局限在离线计算当中。

现如今，正式为了应对大数据的这几个特点，开源的大数据框架越来越多，越来越强，先列举一些常见的：

文件存储：Hadoop HDFS、Tachyon、KFS

离线计算：Hadoop MapReduce、Spark

流式、实时计算：Storm、Spark Streaming、S4、Heron

K-V、NOSQL数据库：HBase、Redis、MongoDB

资源管理：YARN、Mesos

日志收集：Flume、Scribe、Logstash、Kibana

消息系统：Kafka、StormMQ、ZeroMQ、RabbitMQ

查询分析：Hive、Impala、Pig、Presto、Phoenix、SparkSQL、Drill、Flink、Kylin、Druid

分布式协调服务：Zookeeper

集群管理与监控：Ambari、Ganglia、Nagios、Cloudera Manager

数据挖掘、机器学习：Mahout、Spark MLLib

数据同步：Sqoop

任务调度：Oozie

眼花了吧，上面的有30多种吧，别说精通了，全部都会使用的，估计也没几个。就我个人而言，主要经验是在第二个方向(开发/设计/架构)，且听听我的建议吧。

第一章：初识Hadoop

1.1 学会百度与Google

不论遇到什么问题，先试试搜索并自己解决。Google首选，翻不过去的，就用百度吧。

1.2 参考资料首选官方文档

特别是对于入门来说，官方文档永远是首选文档。相信搞这块的大多是文化人，英文凑合就行，实在看不下去的，请参考第一步。

1.3 先让Hadoop跑起来

Hadoop可以算是大数据存储和计算的开山鼻祖，现在大多开源的大数据框架都依赖Hadoop或者与它能很好的兼容。

关于Hadoop,你至少需要搞清楚以下是什么：

Hadoop 1.0、Hadoop 2.0

MapReduce、HDFS

NameNode、DataNode

JobTracker、TaskTracker

Yarn、ResourceManager、NodeManager

自己搭建Hadoop，请使用第一步和第二步，能让它跑起来就行。建议先使用安装包命令行安装，不要使用管理工具安装。另外：Hadoop1.0知道它就行了，现在都用Hadoop 2.0.

1.4 试试使用Hadoop

HDFS目录操作命令;上传、下载文件命令;提交运行MapReduce示例程序;打开Hadoop WEB界面，查看Job运行状态，查看Job运行日志。知道Hadoop的系统日志在哪里。

1.5 你该了解它们的原理了

MapReduce：如何分而治之;HDFS：数据到底在哪里，什么是副本;

Yarn到底是什么，它能干什么;NameNode到底在干些什么;Resource Manager到底在干些什么;

1.6 自己写一个MapReduce程序

请仿照WordCount例子，自己写一个(照抄也行)WordCount程序，

打包并提交到Hadoop运行。你不会Java?Shell、Python都可以，有个东西叫Hadoop Streaming。如果你认真完成了以上几步，恭喜你，你的一只脚已经进来了。

第二章：更高效的WordCount

2.1 学点SQL吧

你知道数据库吗?你会写SQL吗?如果不会，请学点SQL吧。

2.2 SQL版WordCount

在1.6中，你写(或者抄)的WordCount一共有几行代码?给你看看我的:

SELECT word,COUNT(1) FROM wordcount GROUP BY word;

这便是SQL的魅力，编程需要几十行，甚至上百行代码，我这一句就搞定;使用SQL处理分析Hadoop上的数据，方便、高效、易上手、更是趋势。不论是离线计算还是实时计算，越来越多的大数据处理框架都在积极提供SQL接口。

2.3 SQL On Hadoop之Hive

什么是Hive?官方给的解释如下：The Apache Hive data warehouse software facilitates reading, writing, and managing large datasets residing in distributed storage and queried using SQL syntax.

为什么说Hive是数据仓库工具，而不是数据库工具呢?有的朋友可能不知道数据仓库，数据仓库是逻辑上的概念，底层使用的是数据库，数据仓库中的数据有这两个特点：最全的历史数据(海量)、相对稳定的;所谓相对稳定，指的是数据仓库不同于业务系统数据库，数据经常会被更新，数据一旦进入数据仓库，很少会被更新和删除，只会被大量查询。而Hive，也是具备这两个特点，因此，Hive适合做海量数据的数据仓库工具，而不是数据库工具。

2.4 安装配置Hive

请参考1.1 和 1.2 完成Hive的安装配置。可以正常进入Hive命令行。

2.5 试试使用Hive

请参考1.1 和 1.2 ，在Hive中创建wordcount表，并运行2.2中的SQL语句。

在Hadoop WEB界面中找到刚才运行的SQL任务。看SQL查询结果是否和1.4中MapReduce中的结果一致。

2.6 Hive是怎么工作的

明明写的是SQL，为什么Hadoop WEB界面中看到的是MapReduce任务?

2.7 学会Hive的基本命令

创建、删除表;加载数据到表;下载Hive表的数据;请参考1.2，学习更多关于Hive的语法和命令。

如果你已经按照《写给大数据开发初学者的话》中第一章和第二章的流程认真完整的走了一遍，那么你应该已经具备以下技能和知识点：

MapReduce的原理(还是那个经典的题目，一个10G大小的文件，给定1G大小的内存，如何使用Java程序统计出现次数最多的10个单词及次数);

HDFS读写数据的流程;向HDFS中PUT数据;从HDFS中下载数据;

自己会写简单的MapReduce程序，运行出现问题，知道在哪里查看日志;

会写简单的SELECT、WHERE、GROUP BY等SQL语句;

Hive SQL转换成MapReduce的大致流程;

Hive中常见的语句：创建表、删除表、往表中加载数据、分区、将表中数据下载到本地;

从上面的学习，你已经了解到，HDFS是Hadoop提供的分布式存储框架，它可以用来存储海量数据，MapReduce是Hadoop提供的分布式计算框架，它可以用来统计和分析HDFS上的海量数据，而Hive则是SQL On Hadoop，Hive提供了SQL接口，开发人员只需要编写简单易上手的SQL语句，Hive负责把SQL翻译成MapReduce，提交运行。

此时，你的”大数据平台”是这样的：那么问题来了，海量数据如何到HDFS上呢?

第三章：把别处的数据搞到Hadoop上

此处也可以叫做数据采集，把各个数据源的数据采集到Hadoop上。

3.1 HDFS PUT命令

这个在前面你应该已经使用过了。put命令在实际环境中也比较常用，通常配合shell、python等脚本语言来使用。建议熟练掌握。

3.2 HDFS API

HDFS提供了写数据的API，自己用编程语言将数据写入HDFS，put命令本身也是使用API。

实际环境中一般自己较少编写程序使用API来写数据到HDFS，通常都是使用其他框架封装好的方法。比如：Hive中的INSERT语句，Spark中的saveAsTextfile等。建议了解原理，会写Demo。

3.3 Sqoop

Sqoop是一个主要用于Hadoop/Hive与传统关系型数据库，Oracle、MySQL、SQLServer等之间进行数据交换的开源框架。就像Hive把SQL翻译成MapReduce一样，Sqoop把你指定的参数翻译成MapReduce，提交到Hadoop运行，完成Hadoop与其他数据库之间的数据交换。

自己下载和配置Sqoop(建议先使用Sqoop1，Sqoop2比较复杂)。了解Sqoop常用的配置参数和方法。

使用Sqoop完成从MySQL同步数据到HDFS;使用Sqoop完成从MySQL同步数据到Hive表;如果后续选型确定使用Sqoop作为数据交换工具，那么建议熟练掌握，否则，了解和会用Demo即可。

3.4 Flume

Flume是一个分布式的海量日志采集和传输框架，因为“采集和传输框架”，所以它并不适合关系型数据库的数据采集和传输。Flume可以实时的从网络协议、消息系统、文件系统采集日志，并传输到HDFS上。

因此，如果你的业务有这些数据源的数据，并且需要实时的采集，那么就应该考虑使用Flume。

下载和配置Flume。使用Flume监控一个不断追加数据的文件，并将数据传输到HDFS;Flume的配置和使用较为复杂，如果你没有足够的兴趣和耐心，可以先跳过Flume。

3.5 阿里开源的DataX

之所以介绍这个，是因为我们公司目前使用的Hadoop与关系型数据库数据交换的工具，就是之前基于DataX开发的，非常好用。

可以参考我的博文《异构数据源海量数据交换工具-Taobao DataX 下载和使用》。现在DataX已经是3.0版本，支持很多数据源。你也可以在其之上做二次开发。有兴趣的可以研究和使用一下，对比一下它与Sqoop。

第四章：把Hadoop上的数据搞到别处去

Hive和MapReduce进行分析了。那么接下来的问题是，分析完的结果如何从Hadoop上同步到其他系统和应用中去呢?其实，此处的方法和第三章基本一致的。

4.1 HDFS GET命令

把HDFS上的文件GET到本地。需要熟练掌握。

4.2 HDFS API

同3.2.

4.3 Sqoop

同3.3.使用Sqoop完成将HDFS上的文件同步到MySQL;使用Sqoop完成将Hive表中的数据同步到MySQL。

4.4 DataX

同3.5. 如果你认真完成了上面的学习和实践，此时，你的”大数据平台”应该是这样的：

如果你已经按照《写给大数据开发初学者的话2》中第三章和第四章的流程认真完整的走了一遍，那么你应该已经具备以下技能和知识点：

知道如何把已有的数据采集到HDFS上，包括离线采集和实时采集;你已经知道sqoop(或者还有DataX)是HDFS和其他数据源之间的数据交换工具;你已经知道flume可以用作实时的日志采集。

从前面的学习，对于大数据平台，你已经掌握的不少的知识和技能，搭建Hadoop集群，把数据采集到Hadoop上，使用Hive和MapReduce来分析数据，把分析结果同步到其他数据源。

接下来的问题来了，Hive使用的越来越多，你会发现很多不爽的地方，特别是速度慢，大多情况下，明明我的数据量很小，它都要申请资源，启动MapReduce来执行。

第五章：快一点吧，我的SQL

其实大家都已经发现Hive后台使用MapReduce作为执行引擎，实在是有点慢。因此SQL On Hadoop的框架越来越多，按我的了解，最常用的按照流行度依次为SparkSQL、Impala和Presto.这三种框架基于半内存或者全内存，提供了SQL接口来快速查询分析Hadoop上的数据。关于三者的比较，请参考1.1.

我们目前使用的是SparkSQL，至于为什么用SparkSQL，原因大概有以下吧：使用Spark还做了其他事情，不想引入过多的框架;Impala对内存的需求太大，没有过多资源部署。

5.1 关于Spark和SparkSQL

什么是Spark，什么是SparkSQL。

Spark有的核心概念及名词解释。

SparkSQL和Spark是什么关系，SparkSQL和Hive是什么关系。

SparkSQL为什么比Hive跑的快。

5.2 如何部署和运行SparkSQL

Spark有哪些部署模式?

如何在Yarn上运行SparkSQL?

使用SparkSQL查询Hive中的表。Spark不是一门短时间内就能掌握的技术，因此建议在了解了Spark之后，可以先从SparkSQL入手，循序渐进。

关于Spark和SparkSQL，如果你认真完成了上面的学习和实践，此时，你的”大数据平台”应该是这样的。

第六章：一夫多妻制

请不要被这个名字所诱惑。其实我想说的是数据的一次采集、多次消费。

在实际业务场景下，特别是对于一些监控日志，想即时的从日志中了解一些指标(关于实时计算，后面章节会有介绍)，这时候，从HDFS上分析就太慢了，尽管是通过Flume采集的，但Flume也不能间隔很短就往HDFS上滚动文件，这样会导致小文件特别多。

为了满足数据的一次采集、多次消费的需求，这里要说的便是Kafka。

6.1 关于Kafka

什么是Kafka?Kafka的核心概念及名词解释。

6.2 如何部署和使用Kafka

使用单机部署Kafka，并成功运行自带的生产者和消费者例子。使用Java程序自己编写并运行生产者和消费者程序。Flume和Kafka的集成，使用Flume监控日志，并将日志数据实时发送至Kafka。

如果你认真完成了上面的学习和实践，此时，你的”大数据平台”应该是这样的。

这时，使用Flume采集的数据，不是直接到HDFS上，而是先到Kafka，Kafka中的数据可以由多个消费者同时消费，其中一个消费者，就是将数据同步到HDFS。

如果你已经按照《写给大数据开发初学者的话3》中第五章和第六章的流程认真完整的走了一遍，那么你应该已经具备以下技能和知识点：

为什么Spark比MapReduce快。

使用SparkSQL代替Hive，更快的运行SQL。

使用Kafka完成数据的一次收集，多次消费架构。

自己可以写程序完成Kafka的生产者和消费者。

从前面的学习，你已经掌握了大数据平台中的数据采集、数据存储和计算、数据交换等大部分技能，而这其中的每一步，都需要一个任务(程序)来完成，各个任务之间又存在一...

从“大数据”时代被宣称到来的那一天，至今日，数据量已经几何倍数的翻增，数据，已经渗透到当今每一个行业和业务职能领域，成为重要的生产因素。

大数据的第一个特征是数据量大，大数据的起始计量单位至少是P、E甚至 ZB级别；第二个特征是数据类型繁多，包括网络日志、音频、视频、图片、地理位置信息等等。

同时，海量多类型的数据对数据的处理能力提出了更高的要求，不仅要提供海量的数据存储空间，又要满足多种类文件的高效存储。

目前，解决这种需求最常用的方式就是采用分布式存储系统。

分布式存储存放的数据，包含数据和元数据信息，那么什么是数据和元数据呢？

用户需要存放到存储设备的文件，就是数据

数据有很多种类，日志、音频、视频、图片等，不同的文件大小是不同的。

存储设备为了存放用户文件而生成的数据记录，就是元数据

如果用户数据比喻成一本书，元数据就是这本书的目录。

分布式存储依照存放数据和元数据的方式不同，分为全对称和非对称模式。

全对称：所有的节点都会处理元数据，各个节点间实时同步元数据信息；

非对称：我有元数据节点，元数据节点单独处理元数据信息，所有信息必须通过元数据节点进行管理。

思考一个问题：当不同类型、不同大小的海量数据需要实时存储时，这两种架构会有怎样的情况发生？

全对称：海量文件带来的海量元数据在各个节点间同步，带来了性能和带宽等瓶颈问题；

非对称：元数据采用独立的节点，处理能力有限，不能很好的满足海量小文件的性能问题。

如何解决这种问题呢？我做了一个大胆的设想，提出一种新的逆向思维解决方式，我把它叫做集群元数据后处理架构。

每个存储节点管理一个虚拟磁盘MD，虚拟磁盘MD由多个存储节点的磁盘块按照一定的规律组合而成，几个存储节点形成一个冗余群组，群组内部统一元数据信息，单个节点采用SSD加速缓存，并在自身的存储空间中，保留一份元数据备份。

客户端进行数据写入时，不再经过集群元数据节点，而是直接采用轮询方式写入存储节点，存储节点负责客户端元数据的建立、存储和同步。

根据前面的架构，我们可以并行的高效的进行文件的写入操作，而不需要经过集群元数据节点，下面，我们来解决数据统一命名空间的文件读取问题，我把这种读取分为二种模式：

本地用户文件读取：客户端自身存放的文件，可以通过直接访问数据节点的方式，获取数据，避免元数据节点瓶颈和减轻元数据节点压力；

其他用户文件读取：通过元数据集群，获取目录信息后访问数据节点。

图示可以看到，元数据通过这种方式，进行统一模式的集中处理，并可以根据应用需求进行数据索引，提升访问效率。

总结：

我把这种模式称为：分布式存储 – 集群元数据分层处理架构。更多编程知识详询462403503共同学习。

随着公司业务的增长，大量和业务、流程、规则相关的半结构化数据也爆发式增长。但数据分散在公司的各个系统中，如何将它们汇总并形成统一的企业级数据仓库，使企业灵活，高效的运用成了难题。

如需将分散的各个底层数据汇总则需建立完整的体系，支撑风控的大数据框架则是重中之重。

拥有5000万+注册用户；13亿+设备标签；100亿+行为数据；1500万+行业关注名单等海量多维数据的拍拍信则是从这几个方面落实：

1. 数据采集

面对来源各异、以结构化/半结构化为主的数据，我们使用linkedin开源的camus来采集消息类数据，使用kettle来采集RMDB的数据。

2. 数据储存

将采集到的原始数据存储到hadoop集群的分布式文件系统中。此外，基于hdfs文件系统对小文件并不是很友好的前提下，定期对历史文件进行合并、压缩、归档的操作也很有必要。

3. 离线处理

数据的离线处理则是一个非常大的话题，相当多的工作量都在这里，但它的价值却往往不会马上得到体现，从而被企业忽视。不仅仅包含以下这些内容：

l 构建并不停地丰富数据仓库

参照传统的ODS，DW，DM将数仓分层，对数据进行加密、去重后分门别类，持续不断的坚持做这件事。

l 管理元数据

建立数据字典，统一数据编码，描绘数据血缘等。

l 检测数据质量

从众数、少数、中位数、平均值等多维度来检测和把握数据的质量。

4. 流式处理

我们使用spark streaming将特征工程、模型结果计算与流式处理相结合，提供秒级的输出。甚至成功的将类似RNN（循环神经网络）这样的深度学习计算添加到整个流式处理的过程中。

5. 数据可视化

使用不同的工具以满足不同场景、不同职责的人员对数据的使用。不仅仅包含以下这些内容：

l 数据的即席查询

懂SQL、随意组合查询条件，进行自助查询，可以忍受分钟级的耗时。

l 多维分析

不懂SQL的情况下，在给定的维度和指标下，随意组合，并在秒级得到查询结果。

l 静态报表

只关注关键性指标。

l 数据分析挖掘

会使用像python、R这样的语言，结合集群的Spark、hive这样的分布式处理工具，对数据进行更深层次的利用。

经过处理的底层大数据相对于以往，在实际业务中使源数据种类更丰富，数据量更多， 借助集群的助力，处理速度更快，回溯时间更久远。

实际运用：

模型训练：风控模型是互联网金融，传统金融等行业在风控流程中不可或缺的环节。

模型应用：将模型与流式计算相结合，提供秒级的风控决策。

数据产品：对数据加工处理，产生像多头、风险名单一类的数据产品。

常用业务：企业在日常工作中各个环节都涉及到数据如：处理数据，更新数据，数据调用，查询日志等。

运用大数据架构前后比对：

在进行大数据框架搭建时还需注意以下几点：

现在即使在同一细分领域，也有很多开源技术可供选择，请尽量选用相对成熟，社区活跃的；能选用开源的，尽量避免自研；另外代码如果要维护自己分支，请特别要谨慎，避免与社区越走越远；hadoop最初并没有太多的考虑数据安全方面，这点要自己加强；高稳定性和高性能往往一个是鱼，一个是熊掌，请考虑好取舍。

本期对大数据底层架构的分享就到这里，欢迎大家联系探讨。

本文为拍拍信原创，未经许可，禁止转载，侵权必究。申请授权，请联系我们。

感谢您对拍拍信的认可与支持

我们一直在路上

马总说过这是一个DT的时代，一个从IT到DT转变的时代。确实这几年到处都能听到诸如“云计算”、“大数据”、“上云”的谈论，确实随着云计算的兴起，依托于相对低成本、高稳定性的云设施构建平台的成本越来越低，越来越多的公司都在推数据相关的平台、产品。如阿里、京东、百度、腾讯，以及一些打着大数据旗号的创业公司都有出自己的数据平台和产品，用户依托于平台确实大大降低了数据处理、使用的难度，降低了从数据挖掘价值的时间成本。于此同时，平台架构的变迁也成为备受关注的问题。今天我们就来看看有哪些大数据的平台架构你不知道。

489034603

一、首先是数据方面（大数据时代以数据为主导）：如何进行模型分层？一般模型分层计算程序，以哪种语言为主？

从数据仓库 或 大数据平台 的角度来讲，数据的分层，大体有两种思路：

a) 基础数据层：主要避免后续数据应用层的大变更。一般面向各业务系统或数据源集，利用业界较为先进的数据模型（如FS-LDM），按数据的特性（即数据驱动）进行数据的整合,以形成相对稳定的基础数据模型层。

b) 应用数据层：一般是面向各应用需求 或 业务用户，利用业界较为合理的数据模型理念（如星型\维度模型），按需求的要求（即需求驱动）进行数据的分布，以形成统计方便、展示友好、满足需求的应用数据模型层。

在数据流向 或 数据处理的过程中，所使用到的语言或方式可能更多的是以下两大类：

a) 基于传统数据库：大多采用ETL的方式，进行数据的抽取、清洗、整合；这中间，可能会利用到类似DataStage，Kettle等工具，用得最多的，可能就是各数据库提供的SQL语言了，SQL语言使用简单、方便、学习门槛较低，且易于掌握。

b) 基于大数据平台：大多采用的开源的工具 或 语言，如Hive, Hbase , Spark,Python等。这里面，可能使用更多的是Hive 与 Python， 这两个工具学习简单，易于掌握，并且，进行数据处理时，也更直观、方便。

二、架构方面：在架构过程中，一般以7点展开，如：

a. 存储和计算都基于HIVE；

b. GREENPLUM作为HIVE的“cache”存在，供用户做一些小数据的快查询，报表存储；

c. 调度：和canaan框架进行整合，支持用户快速新增任务，并自动导入任务依赖；

d. 主数据：保存了数据仓库元数据信息，供用户查询和系统内部各个模块交互；

e. ACL：构建了数据仓库数据访问权限控制，包括用户权限申请、审批者审批、数据赋权等；

f. 传输；

g.监控：由于任务数量增长较快（2000+），运维已经是个问题此外，需花了较大精力做了可视化的工作：

有些朋友不认为Hive是一个数据库，认为Hive是一个类似传统数据库的SQL引擎的工具，虽然Hive有自带的元数据存储库，但这个库里面，也只是存放了Hive工具为完成用户提交的请求而必须要的Hadoop的元数据信息 及两者的映射关系数据；并没有存放用户的任何数据，用户的数据还是存放在Hadoop或Hbase等文件系统或数据库中。

在以上这7点中，最难的就是：数据治理 与 系统监控 这两块

三、数据应用：数据一般以哪种形式，呈现给用户？技术上是通过哪些策略实现？

数据应用主要分成两大类：

a) 面向业务人员：一般是自行研发一个界面美观的WEB应用，调用业界成熟的工具（如MSTR,COGNOS)的API，实现数据展示给终端用户进行查看。

b) 面向IT专业人员：一般是直接从数据库/文件系统中，借助SQL或其它的开源工具，直接查询、统计、分析、挖掘；这样会更直接、更方便。

以上这些可供大家测试一下，有哪些知识是自己还不熟练的，可以再学习，个人观点不喜勿喷，谢谢大家。

另外，如果小伙伴想学习大数据技术，可以加下图片下面的交流群，群里有很多学习视频都可以下载，而且每天大数据架构师马士兵老师都会在群里分享大数据的技术。。

1.前言

为了适应大数据应用场景的要求，Hadoop以及NoSQL等与传统企业平台完全不同的新兴架构迅速地崛起。而下层技术基础的革命必将影响上层建筑：数据模型和算法。简单地将传统基于第四范式结构化关系型数据库的模型拷贝到新的引擎上，无异于削足适履，不仅增加了大数据应用开发的难度和复杂度，又无法发释放新框架的潜能。

该如何构建基于NoSQL的数据模型?现在能供参考的公开知识积累要么是空虚简单的一句“去规范化“或粗暴的宽表化(将query和应用需要访问的所有字段“排排坐“，放在一个有很多列的结构化表中)，要么是针对具体工具或具体场景的实现细节，(如《HBase权威指南》中对于如何设计HBase主键的探讨)。没有一个像编程的设计模式一样的，在模型架构层面可以遵循的方法论。

在比较不同的NoSQL数据库时，通常使用功能以外其他各种指标，如可扩展性、性能和一致性。由于这些指标通常是使用NoSQL的初衷，所以无论从理论的角度还是实践的角度被深入地研究了，而像CAP定理这样的分布式系统基础结论也同样适用于NoSQL系统。另一方面，在NoSQL的数据模型领域，却还没有很好地研究过，也缺乏关系数据库中那种系统性的理论。

我在这篇文章中从数据建模的角度对NoSQL家族系统做了比较简单的比较，并简要介绍几种常见建模技术。

2.NoSQL数据模型视图

要探索数据建模技术，必须先从系统性的NoSQL数据模型视图着手，这多多少少能帮助我们揭示其发展趋势以及相互之间的关系。下图描绘了主要NoSQL家族系统的虚拟“进化”过程，即键值存储，BigTable类型的数据库，文档数据库，全文搜索引擎，数据库和图形数据库：

首先，我们应该注意到，一般意义上讲，SQL和关系型模型都是在很久以前就被设计出来，目的是为最终用户交互之用。这种面向用户的性质有极深的影响：

最终用户往往对汇总报表信息感兴趣而不是单独的数据项，因而SQL这方面做了大量的工作。

不能指望作为自然人的用户能显式地控制并发性、完整性、一致性或者数据类型有效性。这就是为什么SQL竭力关注于事务保证、schema和参照完整性。

另一方面，软件应用程序往往对在数据库内部做聚合没有太大的兴趣，而且至少在许多情况下，程序能够自己控制完整性和有效性。除此之外，剔除这些功能对于性能和可扩展性存储的影响极其重要。

新数据模型的演变开始了：

键-值存储是一个非常简单，但非常强大的模型。下面所描述的许多技术都完全适用于这个模型。

键值模型最致命的缺点之一就是不适合按范围处理主键的场景。有序的键-值模型突破了这一限制，并显著提高了聚合能力。

有序的键-值模型非常强大，但它不提供任何针对值(value)的建模框架。在一般情况下，值的建模可以由应用程序完成，但BigTable风格的数据库想得更加周到，它可以将值按照映射的映射的映射(map-of-maps-of-maps)进行建模，说得明确点，分别是列簇(column family)、列(column)和时间戳化的版本。

文档数据库对BigTable模式提出两个明显的改善。第一，值可以被声明为任意复杂的schema，而不仅仅是一个映射的映射(map-of-maps)。第二，至少有一些产品实现了被数据库管理的索引。就这个意义上来讲，全文搜索引擎也可以同样被认为提供了灵活的schema和自动化的索引。他们之间主要区别在于，文档数据库是根据字段名对索引进行编组，而搜索引擎是使用字段值对索引编组。值得注意的是像Oracle Coherence这样的键-值存储系统增加了索引和内嵌入口处理器的功能，正逐步向文件数据库演进。

最后，图形数据模型可以被视为有序的键-值模型朝另外一个方向的进化。图形数据库允许对业务实体进行非常透明的建模(这个东西取决于那个东西)，而分层建模技术在这方面用的是另外的数据模型，但也可与之媲美。图形数据库和文件数据库息息相关，因为许多实现允许建模的值是映射或者文档。

3.NoSQL数据建模的一般注意事项

与关系型建模不同，NoSQL数据建模往往是从特定查询的应用开始：

关系型建模是典型地被手上可用数据的结构所驱动。设计主要围绕着的是“我有什么样的答案?”

NoSQL数据建模通常由特定应用的访问模式所驱动，比如需要支持的查询类型。设计主要围绕着的是“我有什么问题?”

NoSQL数据建模往往比关系数据库建模需要更加深入地了解数据结构和算法。在这篇文章中，我介绍了几个著名的数据结构，他们虽然非NoSQL所特有，但对于实际的NoSQL建模非常有用。

数据复制和去规范化是一等公民。

关系数据库在对分层或图形数据进行建模和处理时不是很方便。图形数据库显然是这个领域的完美解决方案，但实际上大多数的NoSQL也都非常善于解决这样的问题。这就是为什么这篇文章为分层数据建模单独写了一个章节。

虽然数据建模技术基本上和具体实现无关，但我还是列出了在写这篇文章时我能想到的产品：

键值存储：Oracle Coherence，Redis，Kyoto Cabinet

BigTable风格的数据库： Apache HBase，Apache Cassandra

文档数据库： MongoDB，CouchDB

全文搜索引擎： Apache Lucene，Apache Solr

图形数据库：Neo4j，FlockDB

4.概念技术

本节专门介绍NoSQL数据建模的基本原则。

1、 去规范化(Denormalization)

可以将去规范化定义为把相同的数据复制到多个文档或数据表中，这样可以简化/优化查询处理，或者让用户数据能匹配一个特定的数据模型。在本文的大多数技术用到了这样或那样的去规范化。

一般来说，去规范化用于以下的折衷：

查询的数据量或每次查询IO**与总数据量的折衷。去规范化可以将一个查询所需的所有数据组合起来存放到同一个地方。这通常意味着对相同数据的不同的查询会访问不同的数据组合。因此，数据需要被复制多份，也就意味着增加了总数据量。

处理复杂性与总数据量的折衷。建模时的规范化和相应查询的连接(join)明显增加了查询处理器的复杂度，在分布式系统中尤为明显。去规范化允许将数据按照查询友好的方式存储，从而简化查询的处理。

适用性：键值存储，文档数据库， BigTable风格的数据库

2、 聚合(Aggregates)

所有主流NoSQL都提供了这样或那样的松散schema(soft schema)支持：

键值存储和图形数据库通常不对值进行约束，所以值可能是任意格式。另外，也可以通过使用组合键将一个业务实体表示为多条记录。例如，可以将一个用户帐户建模为UserID_name，UserID_email，UserID_messages等组合键表示的一个实体集合。如果用户没有电子邮件或消息，然后相应的实体不会被记录。

BigTable模式也支持松散schema，因为一个列簇是可变的列集合，一个单元格又能存储不定数目的数据版本。

文档数据库天生就没schema，虽然某些文档数据库允许在数据输入时使用用户定义的schema进行验证。

松散schema允许使用复杂的内部结构(嵌套实体)构造实体的类，也允许改变特定实体的结构。这个更能带来了两个重要的便利：

通过嵌套的实体，最小化了一对多的关系，也因此减少了连接(join)。

异构业务实体的模型可以使用一个文档集合或者一个数据表。松散schema掩藏了这种建模和业务实体之间“技术”上的差异。

我们用下面的图来说明这些便利。该图描绘了对电子商务领域中一个产品实体进行的建模。首先我们可以认为所有的产品都有一个ID、价格(Price)和描述(Description)。进一步来看，我们发现不同类型的产品有不同的属性，如图书包含作者信息，而牛仔裤有长度属性。这些属性中间的某些属性天生就有一对多或这多对多的特性，比如音乐唱片中的曲目。

更进一步来看，可能有些实体不可能使用固定的类型进行建模。例如，不同品牌的牛仔裤的属性是不固定的，而每个制造商出产的牛仔裤的属性也是不一致的。在规范化的关系型数据模型中虽然这些问题都可以解决，但方法很猥琐。松散schema软架构允许只使用一个聚合(Aggregation)(产品)就能对所有类型的产品及其属性进行建模：

内嵌的去规范化会在性能和一致性上对更新操作造成很大的影响，所以要特别注意更新过程。

适用性：键值存储，文档数据库， BigTable的风格数据库

3、 应用端连接(Application Side Joins)

很少有NoSQL解决方案支持连接。NoSQL“问题导向”性质的后果就是，通常在设计时处理join，而关系型模型是在执行查询时处理join。查询时处理join几乎肯定会带来性能上的损失，但在许多情况下，可使用去规范化和聚合，即嵌入嵌套实体来避免join。当然，join在许多情况下是不可避免的，而且应该由应用程序处理。主要的用例：

多对多关系往往是通过链接(link)建模的，这需要join。

聚合操作往往不适合内部实体会被频繁修改的场景。通常更好的办法是将发生的事情作为一条新的记录保留，并在查询的时候将所有记录做join，而不是去更改值。例如，对于一个信息系统而言，可以用嵌套包含了Message实体的User实体来建模。但是，如果会经常地添加消息，更好的办法可能是把Message提取出来作为独立实体，并在查询时再将其与User进行连接：

适用性：键值存储，文档数据库， BigTable风格数据库，图形数据库

5.一般建模技术

在本节中，我们将讨论适用于各种NoSQL实现的一般建模技术。

1、 原子聚合(Atomic Aggregates)

许多NoSQL解决方案提供了有限的事务支持，虽然有些NoSQL不支持。在某些情况下，人们还可以使用分布式锁或应用程序管理的MVCC机制实现事务行为，但常见的是使用聚合技术来对数据建模，以保证一些ACID特性。

强大的事务处理机制对于关系型数据库而言是不可或缺的，其中原因之一就是规范化的数据通常需要在多个地方进行更新。另一方面，聚合允许一个单个业务实体存储为一个文件，行或键值对，从而可以对其进行原子性的更新：

当然，做为一种数据建模技术，原子聚合并不是一个完善的事务型解决方案，但如果存储能提供原子性、锁或者TAS(test-and-set，测试并设置)指令上的一些担保，那原子聚合就是可行的。

(译者注：即将需要事务性操作的业务数据聚合放在一起，存储在一个NoQSQL提供或者应用能提供原子性操作的数据结构中。使用HBase时，将某个用户某个业务的所有数据，如上图，用一行存储就是这种模式的应用。)

适用性：键值存储，文档数据库， BigTable风格数据库

2、 可枚举主键(Enumerable Keys)

也许无序键-值数据模型最大的好处就是可以通过将主键哈希的办法把实体数据分别存储在多个服务器上。排序使事情变得更加复杂，但是即使存储不提供这样的功能，有时应用程序也能利用到有序主键的优势。让我们将对电子邮件建模作为一个例子：

某些NoSQL存储提供原子计数器，能生成一个顺序化的ID。在这种情况下，可以使用userID_messageID作为一个复合键来存储消息。如果最新的消息ID是已知的，那就可以遍历以前的消息。另外，对于任何一个给定的消息ID，也可以向前或向后进行遍历。

也可以将消息分桶(bucket)，例如，每天的数据放到一个桶里。这样就允许从任何指定日期或当前日期开始，向前或向后遍历一个邮箱。

适用性：键值存储

(译者注：能利用主键的一些自然或业务维度的特征，将随机读写转换为顺序读写能提高遍历性能，同时能方便应用逻辑编写。但需要注意对分布式部署时并发写的影响以及对于业务的过度耦合。对于无序主键和有序主键的讨论可以参见《HBase权威指南》中Schema设计章节。)

3、 降维(Dimensionality Reduction)

降维这种技术允许将一个多维数据模型映射到一个键-值模型或其他非多维模型。

传统的地理信息系统使用四叉树(Quadtree)或R树(R-tree)的某种变形来做索引。这些结构需要就地完成更新操作，因此在数据量很大时，维护开销相当的大。另一种方法是对这个二维结构进行遍历，并将其扁平化为一个普通的条目列表。使用这种技术的一个众所周知的例子是Geohash。 Geohash使用类似Z形状的路线来扫描整个二维空间，每次移动根据行进方向被编码为0或1。交错位的经度和纬度上的变更移动以及移动。编码过程在下图中进行了说明，其中黑色和红色位分别代表经度和纬度：

如图所示，Geohash的一个重要特性是能够通过这种逐位编码的近似程度来估计区域之间的距离。Geohash编码允许使用简单普通的数据模型来存储地理信息，比如用有序键值保存空间上的联系。[6.1]讲述了BigTable中的降维技术。更多有关Geohash及其相关技术的信息可以在[6.2]和[6.3]中找到。

(译者注：通过交织编码方式来能将原本需要多维度标示的数据，如cube，存储到一维的键值存储系统中，这是一种非常重要的建模模式：提供了不同缩放等级下在多维空间中邻接的数据仍然顺序存储，遍历高效;同时不同主键从前向后的相似度和空间距离的远近相一致，能通过键值的简单顺序比较判断其位置“相似度”。

它的应用远远不只地理信息的表示，有多个维度属性不同粒度的数据表示都能用到这个技术，比如线下销售交易数...

上篇文章我们学到了如何安装数据库，下来我们学习数据库的一些基本的操作，其中也包括对表的操作。

数据库基本操作

show databases;通过此命令可以实现查看所有的数据 库名称，就像下图，这是默认的一些数据库

create database dbName ；通过此我们可以在数据库系统中创建一个叫reba的数据库

create database reba character set utf8 ;这条命令与上述命令类似，我们在上面的基础上加上了对数据库字符编码集的限制，能够保证我们的中文在系统中不会出错。

use dbName ；在use后面加入数据库的名字，也就是打开数据库。在下面创建表的时候必须先打开数据库，在进行建表操作。

select database();与show类似，同样是查看数据库，不同的是Select查看的当前所正在使用的数据库名称。

show create database reba ;这条命令是查看创建数据库reba的时候所使用的字符集。

drop database dbname；删除数据库的操作，

表

数据库中创建一个表，相当于在Java中新建一个User类，然后对其封装，List便是一张数据表。

List

1.数据类型

表中的字段数据类型有很多种，如下图，其实我们常用的有int和char，varchar这几种数据类型。

表字段数据类型

在这里有人会问char和varchar有什么区别？

char是一个定长的字符串，它的长度不会变化，而varchar在小于指定长度的情况下，它的长度会根据存储的长度而改变，是一个可变长度的字符串。

2.约束

俗话说的好，没有规矩不成方圆。通过这些约束我们可以实现对数据的规范，方便我们对数据的操作。

表结构操作

1-创建表

在java中我们这样来创建一张表

class User{

int age ;

String name ;}

类比数据库中，我们使用这样的方法，其实这也是一门语言

create table t_user2(

age int ,

name varchar(100) default ‘lisi’)

创建表的语法

表建好之后我们使用desc 表名 来查看表的信息

查看表的字符编码集就是表的创建语句 show create table 表名;

2-修改表结构

在修改表中我们使用关键字alter来对表进行操作，具体的内容如下。

修改表

通过这些命令，我们可修改表的列名，表的属性以及添加和删除一列的数据。但是，我们基本不用修改表的做这些命令，迫不得已额尽量别用。

3.删除表

删除表我们也是一般不用，其中的语法有：

drop table 表名;

TRUNCATE TABLE 表名

这两种方式前面的是有条件的删除，自动增加的主键不会初始化，而后者是直接全部删除，不可退回，速度快，相当于新建了一张表，这个表与之前的一模一样，而且自增的主键也会从头开始计算。

之前你可能遇到这样的情况，强迫症的你就得使用第二种方式

这就是对表的一些基本操作，当然我们这里并没有去写对表的数据进行操作。

下篇文章我们将会对数据坤单表和多表数据的操作做一个详细的说明，有什么一下下方留言！帮助到你的话，关注一下我哟~谢谢大家支持。

感谢坚持关注的朋友

世界很大，幸好有你

欢迎在评论区留下你的问题或困惑，我将每天与你分享我的观点和心得。

聚焦最新科技咨讯，探寻未来智能领域，我是女陶。

自从像AWS这样的公共云产品开辟了大数据分析功能以来，小企业通过挖掘大量的数据做到只有大企业才能做到的事情，至今大约有10年时间。这些事情其中包括网络日志、客户购买记录等，并通过按使需付费的方式提供低成本的商品集群。在这十年中，这些产品蓬勃发展，涵盖了从实时(亚秒级延迟)流媒体式分析到用于分析批量模式工作的企业数据仓库，而企业数据仓库则可能需要数天或数周才能完成。

以下将介绍用于大数据堆栈的五个最有用的架构，以及每个架构的优点，以便更好地理解和权衡。此外，还对成本(按$ - $$$$$的规模)、何时使用、热门产品，以及每种架构的提示和技巧进行了阐述。

五个大数据架构

在此并没有什么特别的顺序，用户在AWS公共云旅程中可能遇到的五个顶级大数据架构是：

流媒体- 允许摄取(并可能分析)任务关键型实时数据，这些数据可能会以爆发的形式出现在用户面前。通用(或特定)的批处理集群—在可扩展、经济高效的集群中提供通用存储和计算功能，可以执行其他四种架构的任何和所有功能。NoSQL引擎 - 使架构师能够处理“3V” —高速度、高容量，以及底层数据的多样性/可变性。企业数据仓库(EDW) - 允许组织为多年的历史数据维护一个单独的数据库，并对该数据运行各种长期运行的分析。就地分析 - 允许用户将数据“就地”保存在低成本存储引擎中，并针对该数据运行高性能的即席查询，而无需创建单独的、昂贵的“集群”。

1. 流媒体

流媒体解决方案由以下多个因素定义：

关键任务数据—即使丢失一笔交易也会给用户带来灾难性的后果。负载中的爆发尖峰——物联网的基础设施可能会从完全无声的状态转变为同时与其通话设备中的一个。实时响应 - 高延迟响应对用户来说可能是灾难性的。

这里有很多现实世界的例子，从特斯拉公司的电动汽车(基本上是移动的4G设备)不断将汽车的位置发送到数据中心，通知司机下一个充电站在哪里。此外，人们喜欢的日本一家高度自动化的寿司专营店：Sushiro。Sushiro所做的是将RFID传感器放在每个寿司盘底，然后，寿司传送带上的传感器跟踪每个盘子的动态，将数据点发送到AWS Kinesis，其后端响应仪表板的更新，通知寿司厨师，例如“丢掉即将过期变质的食物，或者制作更多的鸡蛋寿司，或者解冻更多的金枪鱼”，通过使用流媒体技术，该连锁店不仅有上述的实时效率推荐，而且还可以获得每家餐厅的历史信息，并且可以了解顾客购买的趋势。

Sushiro是一个很好的例子，因为它符合流媒体的所有三个要求。其仪表板现在对业务运营至关重要。

成本：$$ - $$$$$(通常为RAM密集型)适用性：任务关键型数据，负载爆发尖峰，实时响应。用户需要构建KPI的实时仪表板。注意事项：独立的流媒体解决方案的构建和维护成本很高。扩展可能具有挑战性，特别是如果在EC2上构建。失败对企业来说可能是灾难性的，但大多数产品都提供故障保护，例如复制优化、备份和灾难恢复，以避免这种情况。受欢迎的产品：Kinesis(托管服务)，Kafka(基于EC2)，Spark Streaming(作为托管服务和基于EC2)和Storm。提示和技巧：使用Kinesis作为初学者(易于使用、体积小、成本低)。许多组织转向基于EC2的Kafka(如果他们只需要流媒体)或Spark Streaming，以获得更好的控制，并降低大批量成本。这是AWS中为数不多的几次托管任务，像Kinesis这样的托管服务最终会比基于EC2的Kafka解决方案花费更多的费用。

2. 通用(或特定)的批处理集群

使用Hadoop/Spark这些系统，用户可以获得高度可扩展、低成本(商用硬件和开源软件)存储和计算，这些存储和计算可能会遇到大量问题，从而以尽可能低的成本对数据进行批量分析。

Hadoop技术非常成熟，提供了一个非常丰富的软件生态系统，可以利用这些通用计算和存储资源提供从数据仓库到流媒体，甚至NoSQL的所有内容。

在Hadoop之上，现在可以运行Spark，它带有自己的可扩展框架，以低延迟(高内存)方式提供上述所有功能，甚至适用于流媒体和NoSQL。

成本：$ - $$$$(高度依赖于内存需求)适用性：最低成本、最大灵活性。如果希望采用一个集群完成所有任务，并从Hadoop或Spark内部部署转移，那么这是一个不错的选择，非常适合机器学习。注意事项：一个全能的系统很少把每件事都做好，但这可以通过使用Spark和为每个工作量身定制的集群来大大减轻工作负荷。热门产品：EMR(托管服务，也将运行Spark)，Cloudera(基于EC2)，Hortonworks(通过EMR作为托管服务，基于EC2)。提示和技巧：在S3存储桶中长期存储源数据，构建集群，并根据需要将数据加载到集群中，然后在分析任务完成后立即关闭所有数据。这实际上正是默认情况下EMR的工作原理，但即使使用的是Cloudera或Hortonworks(现在功能几乎相同)，也可以轻松编写上述所有内容。利用EC2现场实例可以节省80%-90%的成本，并检查自己的分析，以便可以向上或向下旋转集群。以利用成本最低的spot窗口。

3. NoSQL引擎

Velocity(并发事务)在这里特别重要，这些引擎被设计为处理任意数量的并发读写。虽然其他系统通常不能用于最终用户(需要低延迟响应)和员工分析团队(可能会使用长时间运行的查询锁定多个表)，同时，NoSQL引擎可以扩展以适应一个系统的两个主服务器。一些开发允许以低延迟方式实时加入和查询该数据。

成本：$$ - $$$(通常为内存密集型)适用性：“3V”问题。简单和/或快速变化的数据模型。需要构建KPI的实时仪表板。警告：必须放弃交易和丰富多样的SQL。由于它不使用SQL，因此无法使用Tableau和Microstrategy等可视化工具直接查询数据。扩展(尤其是添加新节点和重新平衡)可能很困难，并且会影响用户延迟和系统可用性。受欢迎的产品：DynamoDB(托管服务)，Neptune(托管服务，目前仍处于测试阶段)，Cassandra(基于EC2)，CouchDB(基于EC2)和HBase(通过EMR作为托管服务，基于EC2)。提示和技巧：努力采用AWS管理的服务DynamoDB，而不是配置EC2并加载第三方系统。定期修剪最终用户DynamoDB表，并在这些历史表上创建每周或每月的表。使用Dynamic DynamoDB“自动调整”配置的容量，使其始终满足消耗。使用DynamoDB Streams可以对客户服务取消等关键事件进行实时响应，或者在第二个区域提供备份。

4. 企业数据仓库(EDW)

企业数据仓库(EDW)与此处提到的其他系统截然不同。它提供了人们称之为“OLAP”(在线分析处理，可以支持来自内部用户的一些长时间运行的查询)与“OLTP”(在线事务处理，可以支持来自最终用户的大量读取和写入)功能，如Oracle的RDBMS或MySQL。当然，可以使用OLTP系统作为企业数据仓库(EDW)，但是大多数人都将OLTP数据库集中在最近用户的低延迟，最近事件(如“跟踪上周的订单”)需求和定期(通常是每天)窗口更旧数据输出到OLAP系统，业务用户可以在数月或数年的数据中运行长时间的查询。

这些OLAP系统使用诸如列式存储、数据非规范化(创建具有几乎无限维度的“数据立方体”)等策略，并提供RDBMS级ANSI 92 SQL依从性，这意味着可以完全访问SQL功能，并且可以定制Tableau等可视化工具直接与他们合作。

成本：$$ - $$$$$(通常需要大量节点来存储和处理大量数据)。适用性：如果希望专门针对业务价值分析数据或构建KPI的实时仪表板。警告：确保团队了解OLAP和OLTP之间的区别，并确保他们以正确的方式使用每个OLAP和OLTP。提示和技巧：与EMR/Hadoop一样，只在需要时启动集群，将源数据保存在S3存储桶中(这实际上是Redshift默认工作的方式)。标记集群，以便用能够以自动方式快速识别和关闭未使用的容量。考虑保留以控制成本。真正了解可用的不同节点类型(高存储、高吞吐量)以便利用每个节点类型。采用本机加密，因为它可以将性能降低多达20%-25%。通过O'Reilly课程深入了解Redshift，或考虑通过出色的“数据仓库”课程进行面对面培训，该课程几乎完全涵盖Redshift。

5. 就地分析

几年前，Presto通过提供高性能的数据分析改变了游戏规则，而无需将数据从原生的、低成本的长期存储中移出。其最终结果是，可以简单地运行查询，而不是必须为昂贵的EMR或Redshift集群支付全部费用。而是只按使用的内容收费。

此外，人们需要很多时间来尝试选择(然后管理)EMR或Redshift集群的正确节点和节点数。采用Presto，人们不再知道也不关心这种差别，而这一切都在用户需要的时候起到作用。

最后，Presto支持RDBMS级别的ANSI-92 SQL兼容性，这意味着所有可视化工具都可以直接使用它，具有的SQL背景可以在ad-hoc查询中全面使用。

费用：$ - $$适用性：成本极低。没有任何管理。可以作为低成本、中等性能的企业数据仓库(EDW)。它不需要将数据复制到第二个系统。大型连接和复杂分析效果很好。警告：需要最低延迟。为了获得不错的性能，可能会使用序列化格式Parquet、压缩、重新分区等重新格式化存储的数据。可能需要多轮查询调整和/或重新格式化才能获得正确的结果。目前不支持UDF或事务。热门产品：AWS Athena(用于查询S3数据的托管服务)，EMR(托管服务-可以自动安装Presto)，自我管理的Presto(基于EC2–用户永远不想在AWS中执行此操作)。提示和技巧：只需使用Athena。利用AWS Glue构建ETL管道，以获取原始数据，并将其重新格式化为S3或Athena可以更有效地使用的内容。使用S3生命周期策略将原有的数据移动到低成本的归档存储(如Glacier)。

把它们放在一起

通过了解将在公共云中运行的五个顶级大数据架构，用户现在可以获得有关最佳应用位置的可操作信息，以及潜伏的位置。

一旦用户开始在AWS公共云中构建大数据架构，将很快了解到更多的架构，并且在很多情况下，企业可能会最终同时使用上述所有内容，可能使用Kinesis将客户数据流媒体传输到DynamoDB和S3。用户可能偶尔会在该源数据上启动EMR(进行某些机器学习)或Redshift(分析KPI)集群，或者可以选择以可以通过AWS Athena就地访问的方式格式化数据，让它像企业数据仓库(EDW)一样发挥作用。

具有执行TMTOWTDI的能力是一件好事，AWS公司努力提供最适合用户需求的服务。如果用户从头开始，在AWS认证的全球知识培训课程中花费三天时间将可以提供满足其需求的服务，并让用户尽快开始运营，并且顺利实施。

作者：Rich Morrow