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

数据：

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

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

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的员工

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

总结：

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

随着这些年全世界数据的几何式增长，数据的存储和运算都将成为世界级的难题。之前小鸟给大家介绍过一些分布式文件系统，解决的是大数据存储的问题，今天小鸟给大家介绍一些分布式计算框架：

Hadoop框架

提起大数据，第一个想起的肯定是Hadoop，因为Hadoop是目前世界上应用最广泛的大数据工具，他凭借极高的容错率和极低的硬件价格，在大数据市场上风生水起。Hadoop还是第一个在开源社区上引发高度关注的批处理框架，他提出的Map和Reduce的计算模式简洁而优雅。迄今为止，Hadoop已经成为了一个广阔的生态圈，实现了大量算法和组件。由于Hadoop的计算任务需要在集群的多个节点上多次读写，因此在速度上会稍显劣势，但是其吞吐量也同样是其他框架所不能匹敌的。

Storm框架

与Hadoop的批处理模式不同，Storm采用的是流计算框架，由Twitter开源并且托管在GitHub上。与Hadoop类似的是，Storm也提出了两个计算角色，分别为Spout和Bolt。

如果说Hadoop是水桶，只能一桶一桶的去井里扛，那么Storm就是水龙头，只要打开就可以源源不断的出水。Storm支持的语言也比较多，Java、Ruby、Python等语言都能很好的支持。由于Storm是流计算框架，因此使用的是内存，延迟上有极大的优势，但是Storm不会持久化数据。

Samza框架

Smaza也是一种流计算框架，但他目前只支持JVM语言，灵活度上略显不足，并且Samza必须和Kafka共同使用。但是响应的，其也继承了Kafka的低延时、分区、避免回压等优势。对于已经有Hadoop+Kafka工作环境的团队来说，Samza是一个不错的选择，并且Samza在多个团队使用的时候能体现良好的性能。

Spark框架

Spark属于前两种框架形式的集合体，是一种混合式的计算框架。它既有自带的实时流处理工具，也可以和Hadoop集成，代替其中的MapReduce，甚至Spark还可以单独拿出来部署集群，但是还得借助HDFS等分布式存储系统。Spark的强大之处在于其运算速度，与Storm类似，Spark也是基于内存的，并且在内存满负载的时候，硬盘也能运算，运算结果表示，Spark的速度大约为Hadoop的一百倍，并且其成本可能比Hadoop更低。但是Spark目前还没有像Hadoop哪有拥有上万级别的集群，因此现阶段的Spark和Hadoop搭配起来使用更加合适。

Flink框架

Flink也是一种混合式的计算框架，但是在设计初始，Fink的侧重点在于处理流式数据，这与Spark的设计初衷恰恰相反，而在市场需求的驱使下，两者都在朝着更多的兼容性发展。Flink目前不是很成熟，更多情况下Flink还是起到一个借鉴的作用。

以上就是现在比较主流的大数据运算框架的介绍了，欢迎大家收藏转发。关注小鸟，获取更多大数据级相关技术的资讯与教程。

科学进步越来越多地由数据来推动，海量数据给数据分析既带来了机遇，也构成了新的挑战。大数据往往是利用众多技术和方法，综合源自多个渠道、不同时间的信息而获得的。究竟大数据技术的核心原理是哪几方面呢？

数据即价值是目前计算机领域极其推崇的观念。数据无论多少都被归结为大数据，数据分析越来越热门，资本也对贴有大数据标签的公司趋之若鹜。如同流动的数字货币一样被一再的评估、追崇。数据能告诉我们，每一个客户的消费倾向，他们想要什么，喜欢什么，每个人的需求有哪些区别，哪些又可以被集合到一起来进行分类。

数据核心原理：从“流程”核心转变为“数据”核心

大数据时代，计算模式也发生了转变，从“流程”核心转变为“数据”核心。Hadoop体系的分布式计算框架已经是“数据”为核心的范式。非结构化数据及分析需求，将改变IT系统的升级方式：从简单增量到架构变化。大数据下的新思维——计算模式的转变。

科学进步越来越多地由数据来推动，海量数据给数据分析既带来了机遇，也构成了新的挑战。大数据往往是利用众多技术和方法，综合源自多个渠道、不同时间的信息而获得的。为了应对大数据带来的挑战，我们需要新的统计思路和计算方法。

数据价值原理：有功能是价值转变为数据是价值

大数据真正有意思的是数据变得在线了，这个恰恰是互联网的特点。非互联网时期的产品，功能一定是它的价值，今天互联网的产品，数据一定是它的价值。

数据能告诉我们，每一个客户的消费倾向，他们想要什么，喜欢什么，每个人的需求有哪些区别，哪些又可以被集合到一起来进行分类。大数据是数据数量上的增加，以至于我们能够实现从量变到质变的过程。

全样本原理：从抽样转变为需要全部数据样本

需要全部数据样本而不是抽样，你不知道的事情比你知道的事情更重要，但如果现在数据足够多，它会让人能够看得见、摸得着规律。

数据这么大、这么多，所以人们觉得有足够的能力把握未来，对不确定状态的一种判断，从而做出自己的决定。这些东西我们听起来都是非常原始的，但是实际上背后的思维方式，和我们今天所讲的大数据是非常像的。

关注效率原理：由关注精确度转变为关注效率

关注效率而不是精确度，大数据标志着人类在寻求量化和认识世界的道路上前进了一大步，过去不可计量、存储、分析和共享的很多东西都被数据化了，拥有大量的数据和更多不那么精确的数据为我们理解世界打开了一扇新的大门。大数据能提高生产效率和销售效率，原因是大数据能够让我们知道市场的需要，人的消费需要。大数据让企业的决策更科学，由关注精确度转变为关注效率的提高，大数据分析能提高企业的效率。

竞争是企业的动力，而效率是企业的生命，效率低与效率高是衡量企来成败的关键。一般来讲，投入与产出比是效率，追求高效率也就是追求高价值。手工、机器、自动机器、智能机器之间效率是不同的，智能机器效率更高，已能代替人的思维劳动。智能机器核心是大数据制动，而大数据制动的速度更快。在快速变化的市场，快速预测、快速决策、快速创新、快速定制、快速生产、快速上市成为企业行动的准则，也就是说，速度就是价值，效率就是价值，而这一切离不开大数据思维。

关注相关性原理：由因果关系转变为关注相关性

关注相关性而不是因果关系，社会需要放弃它对因果关系的渴求，而仅需关注相关关系，也就是说只需要知道是什么，而不需要知道为什么。这就推翻了自古以来的惯例，而我们做决定和理解现实的最基本方式也将受到挑战。

在这个不确定的时代里面，等我们去找到准确的因果关系，再去办事的时候，这个事情早已经不值得办了。所以“大数据”时代的思维有点像回归了工业社会的这种机械思维——机械思维就是说按那个按钮，一定会出现相应的结果，是这样状态。而农业社会往前推，不需要找到中间非常紧密的、明确的因果关系，而只需要找到相关关系，只需要找到迹象就可以了。社会因此放弃了寻找因果关系的传统偏好，开始挖掘相关关系的好处。

非法在屋内打隔断的建筑物着火的可能性比其他建筑物高很多。纽约市每年接到2.5万宗有关房屋住得过于拥挤的投诉，但市里只有200名处理投诉的巡视员，市长办公室一个分析专家小组觉得大数据可以帮助解决这一需求与资源的落差。该小组建立了一个市内全部90万座建筑物的数据库，并在其中加入市里19个部门所收集到的数据：欠税扣押记录、水电使用异常、缴费拖欠、服务切断、救护车使用、当地犯罪率、鼠患投诉，诸如此类。

接下来，他们将这一数据库与过去5年中按严重程度排列的建筑物着火记录进行比较，希望找出相关性。果然，建筑物类型和建造年份是与火灾相关的因素。不过，一个没怎么预料到的结果是，获得外砖墙施工许可的建筑物与较低的严重火灾发生率之间存在相关性。利用所有这些数据，该小组建立了一个可以帮助他们确定哪些住房拥挤投诉需要紧急处理的系统。他们所记录的建筑物的各种特征数据都不是导致火灾的原因，但这些数据与火灾隐患的增加或降低存在相关性。这种知识被证明是极具价值的：过去房屋巡视员出现场时签发房屋腾空令的比例只有13%，在采用新办法之后，这个比例上升到了70%——效率大大提高了。

全世界的商界人士都在高呼大数据时代来临的优势：一家超市如何从一个17岁女孩的购物清单中，发现了她已怀孕的事实；或者将啤酒与尿不湿放在一起销售，神奇地提高了双方的销售额。大数据透露出来的信息有时确实会起颠覆。比如，腾讯一项针对社交网络的统计显示，爱看家庭剧的男人是女性的两倍还多；最关心金价的是中国大妈，但紧随其后的却是90后。而在过去一年，支付宝中无线支付比例排名前十的竟然全部在青海、西藏和内蒙古地区。

预测原理：从不能预测转变为可以预测

大数据的核心就是预测，大数据能够预测体现在很多方面。大数据不是要教机器像人一样思考，相反，它是把数学算法运用到海量的数据上来预测事情发生的可能性。正因为在大数据规律面前，每个人的行为都跟别人一样，没有本质变化，所以商家会比消费者更了消费者的行为。

此外，随着系统接收到的数据越来越多，通过记录找到的最好的预测与模式，可以对系统进行改进。它通常被视为人工智能的一部分，或者更确切地说，被视为一种机器学习。真正的革命并不在于分析数据的机器，而在于数据本身和我们如何运用数据。一旦把统计学和现在大规模的数据融合在一起，将会颠覆很多我们原来的思维。所以现在能够变成数据的东西越来越多，计算和处理数据的能力越来越强，所以大家突然发现这个东西很有意思。所以，大数据能干啥？能干很多很有意思的事情。

互联网、移动互联网和云计算机保证了大数据实时预测的可能性，也为企业和用户提供了实时预测的信息，相关性预测的信息，让企业和用户抢占先机。由于大数据的全样本性，人和人都是一样的，所以云计算机软件预测的效率和准确性大大提高，有这种迹象，就有这种结果。

信息找人原理：从人找信息，转变为信息找人

互联网和大数据的发展，是一个从人找信息，到信息找人的过程。先是人找信息，人找人，信息找信息，现在是信息找人的这样一个时代。信息找人的时代，就是说一方面我们回到了一种最初的，广播模式是信息找人，我们听收音机，我们看电视，它是信息推给我们的，但是有一个缺陷，不知道我们是谁，后来互联网反其道而行，提供搜索引擎技术,让我知道如何找到我所需要的信息，所以搜索引擎是一个很关键的技术。

大数据还改变了信息优势。按照循证医学，现在治病的第一件事情不是去研究病理学，而是拿过去的数据去研究，相同情况下是如何治疗的。这导致专家和普通人之间的信息优势没有了。原来我相信医生，因为医生知道的多，但现在我可以到谷歌上查一下，知道自己得了什么病。

谷歌有一个机器翻译的团队，最开始的时候翻译之后的文字根本看不懂，但是现在60%的内容都能读得懂。谷歌机器翻译团队里头有一个笑话，说从团队每离开一个语言学家，翻译质量就会提高。越是专家越搞不明白，但打破常规让数据说话，得到真理的速度反而更快。

机器懂人原理：由人懂机器转变为机器更懂人

不是让人更懂机器，而是让机器更懂人，或者说是能够在使用者很笨的情况下，仍然可以使用机器。甚至不是让人懂环境，而是让我们的环境来懂我们，环境来适应人，某种程度上自然环境不能这样讲，但是在数字化环境中已经是这样的一个趋势，就是我们所在的生活世界，越来越趋向于它更适应于我们，更懂我们。哪个企业能够真正做到让机器更懂人，让环境更懂人，让我们随身携带的整个的生活世界更懂得我们的话，那他一定是具有竞争力的了，而“大数据”技术能够助我们一臂之力。

大数据技术的其中一个核心目标是要从体量巨大、结构繁多的数据中挖掘出隐蔽在背后的规律，从而使数据发挥最大化的价值。由计算机代替人去挖掘信息，获取知识。从各种各样的数据（包括结构化、半结构化和非结构化数据）中快速获取有价值信息的能力，就是大数据技术。大数据机器分析中，半监督学习、集成学习、概率模型等技术尤为重要。

电子商务智能原理：大数据改变了电子商务模式，让电子商务更智能

商务智能，在今天大数据时代它获得的重新的定义。例如：传统企业进入互联网，在掌握了“大数据”技术应用途径之后，会发现有一种豁然开朗的感觉，就像在黑屋子里面找东西，找不着，突然碰到了一个开关，发现那么费力的找东西，原来很容易找得到。大数据思维，事实上它不是一个全称的判断，只是对我们所处的时代某一个纬度的描述。

大数据时代不是说我们这个时代除了大数据什么都没有，哪怕是在互联网和IT领域，它也不是一切，只是说在我们的时代特征里面加上这么一道很明显的光，从而导致我们对以前的生存状态，以及我们个人的生活状态的一个差异化的一种表达。

当然，同样的技术也可以运用到疾病诊断、推荐治疗措施，甚至是识别潜在犯罪分子上。或者说，在你还不知道的情况下，体检公司、医院提醒你赶紧去做检查，可能会得某些病，商家比你更了解你自己，以及你这样的人在某种情况下会出现的可能变化。就像互联网通过给计算机添加通信功能而改变了世界，大数据也将改变我们生活中最重要的方面，因为它为我们的生活创造了前所未有的可量化的维度。

定制产品原理：由企业生产产品转变为由客户定制产品

下一波的改革是大规模定制，为大量客户定制产品和服务，成本低、又兼具个性化。比如消费者希望他买的车有红色、绿色，厂商有能力满足要求，但价格又不至于像手工制作那般让人无法承担。因此，在厂家可以负担得起大规模定制带去的高成本的前提下，要真正做到个性化产品和服务，就必须对客户需求有很好的了解，这背后就需要依靠大数据技术。

在互联网大数据的时代，商家最后很可能可以针对每一个顾客进行精准的价格歧视。我们现在很多的行为都是比较粗放的，航空公司会给我们里程卡，根据飞行公里数来累计里程，但其实不同顾客所飞行的不同里程对航空公司的利润贡献是不一样的。所以有一天某位顾客可能会收到一封信，“恭喜先生，您已经被我们选为幸运顾客，我们提前把您升级到白金卡。”这说明这个顾客对航空公司的贡献已经够多了。有一天银行说“恭喜您，您的额度又被提高了，”就说明钱花得已经太多了。

正因为在大数据规律面前，每个人的行为都跟别人一样，没有本质变化。所以商家会比消费者更了消费者的行为。也许你正在想，工作了一年很辛苦，要不要去哪里度假？打开e-Mail，就有航空公司、旅行社的邮件。

企业产品直接销售给用户，省去了中间商流通环节，使产品的价格可以以出厂价销售，让销费者获得了好处，网上产品便宜成为用户的信念，网购市场形成了。要让用户成为你的产品粉丝，就必须了解用户需要，定制产品成为用户的心愿，也就成为企业发展的新方向。

“

本账号提供最新物联网展会活动资讯，和多家物联网企业形成战略合作伙伴，带领用户与物联网行业大咖、各地物联网俱乐部共同来玩转物联网，为行业创造最酷的物联网线下体验和思想交流的平台。

IOTCOFFEE

大数据平台架构的层次划分没啥标准，以前笔者曾经做过大数据应用规划，也是非常纠结，因为应用的分类也是横纵交错，后来还是觉得体现一个“能用”原则，清晰且容易理解，能指导建设，这里将大数据平台划分为“五横一纵”。

当前BAT基本公开了其大数据平台架构，从网上也能查询到一些资料，关于大数据平台的各类技术介绍也不少，但在那个机制、那个环境、那个人才、那个薪酬体系下，对于传统企业，可借鉴的东西也是有限的。

技术最终为业务服务，没必要一定要追求先进性，各个企业应根据自己的实际情况去选择自己的技术路径。

与传统的更多从技术的角度来看待大数据平台架构的方式不同，笔者这次，更多的从业务的视角来谈谈关于大数据架构的理解，即更多的会问为什么要采用这个架构，到底能给业务带来多大价值，实践的最终结果是什么。

它不一定具有通用性，但从一定程度讲，这个架构可能比BAT的架构更适应大多数企业的情况，毕竟，大多数企业，数据没到那个份上，也不可能完全自研，商业和开源的结合可能更好一点，权当抛砖引玉。

大数据平台架构的层次划分没啥标准，以前笔者曾经做过大数据应用规划，也是非常纠结，因为应用的分类也是横纵交错，后来还是觉得体现一个“能用”原则，清晰且容易理解，能指导建设，这里将大数据平台划分为“五横一纵”。

具体见下图示例，这张图是比较经典的，也是妥协的结果，跟当前网上很多的大数据架构图都可以作一定的映射。

何谓五横，基本还是根据数据的流向自底向上划分五层，跟传统的数据仓库其实很类似，数据类的系统，概念上还是相通的，分别为数据采集层、数据处理层、数据分析层、数据访问层及应用层。

同时，大数据平台架构跟传统数据仓库有一个不同，就是同一层次，为了满足不同的场景，会采用更多的技术组件，体现百花齐放的特点，这是一个难点。

数据采集层：既包括传统的ETL离线采集、也有实时采集、互联网爬虫解析等等。

数据处理层：根据数据处理场景要求不同，可以划分为HADOOP、MPP、流处理等等。

数据分析层：主要包含了分析引擎，比如数据挖掘、机器学习、 深度学习等。

数据访问层：主要是实现读写分离，将偏向应用的查询等能力与计算能力剥离，包括实时查询、多维查询、常规查询等应用场景。

数据应用层：根据企业的特点不同划分不同类别的应用，比如针对运营商，对内有精准营销、客服投诉、基站分析等，对外有基于位置的客流、基于标签的广告应用等等。

数据管理层：这是一纵，主要是实现数据的管理和运维，它横跨多层，实现统一管理。

1、数据采集层，这是基础。

离线批量采集，采用的是HADOOP，这个已经成为当前流线采集的主流引擎了，基于这个平台，需要部署数据采集应用或工具。

诸如BAT都是自己研发的产品，一般企业，可以采用商用版本，现在这类选择很多，比如华为BDI等等，很多企业技术实力有，但起步的时候往往对于应用场景的理解比较弱，细节做工很差，导致做出来的产品难以达到要求，比如缺乏统计功能等，跟BAT差距很大，传统企业去采购这类产品，要谨慎小心。

一个建议是，当采购产品的时候，除了技术先进性和指标外，更多的应该问问是版本啥时候上线的，是否在哪里成功部署，是否有足够多的客户，如果能做个测试就更好，否则，你就是小白鼠哦，这个坑踩了不少。

能做和做成产品是两个境界的事情，小的互联网企业当然也能做出对于自己好用的采集工具，但它很难抽象并打造出一个真正的产品，BAT自研其实形成了巨大的优势。

实时采集现在也成了大数据平台的标配，估计主流就是FLUME+KAFKA，然后结合流处理+内存数据库吧，这个技术肯定靠谱，但这类开源的东西好是好，但一旦出现问题往往解决周期往往比较长。

除了用FLUME，针对ORACLE数据库的表为了实现实时采集，也可以采用OGG/DSG等技术实现实时的日志采集，可以解决传统数据仓库抽全量表的负荷问题。

爬虫当前也逐渐成为很多企业的采集标配，因为互联网新增数据主要靠它，可以通过网页的解析获取大量的上网信息，什么舆情分析、网站排名啥的，建议每个企业都应该建立企业级的爬虫中心，如果它未在你的大数据平台规划内，可以考虑一下，能拿的数据都不拿，就没什么好说了。

企业级的爬虫中心的建设难度蛮大，因为不仅仅是需要爬虫，还需要建立网址和应用知识库，需要基于网页文本进行中文分词，倒排序及文本挖掘等，这一套下来，挑战很大，当前已经有不少开源组件了，比如solr、lucent、Nutch、ES等等，但要用好它，路漫漫其修远兮。

还有一个就是，如果有可能，笔者建议将数据采集平台升级为数据交换平台，因为其实企业内有大量的数据流动，不仅仅是单向的数据采集，而且有很多数据交换，比如需要从ORACLE倒数据到GBASE，从HBASE倒数据到ASTER等等，对于应用来讲，这个价值很大。

既然数据采集和数据交换有很多功能非常类似，为什么不做整合呢?也便于统一管理，感觉企业的数据交换大量都是应用驱动，接口管理乱七八糟，这也是我的一个建议。

总得来讲，建设大数据采集平台非常不易，从客户的角度讲，至少要达到以下三个要求：

多样化数据采集能力：支持对表、文件、消息等多种数据的实时增量数据采集(使用flume、消息队列、OGG等技术)和批量数据分布式采集等能力(SQOOP、FTP VOER HDFS)，比基于传统ETL性能有量级上的提升，这是根本。

可视化快速配置能力：提供图形化的开发和维护界面，支持图形化拖拽式开发，免代码编写，降低采集难度，每配置一个数据接口耗时很短，以降低人工成本。

统一调度管控能力：实现采集任务的统一调度，可支持Hadoop的多种技术组件(如 MapReduce、Spark 、HIVE)、关系型数据库存储过程、 shell脚本等，支持多种调度策略(时间/接口通知/手工)。

2、数据处理层，现在有个词叫混搭，的确是这样。

Hadoop的HIVE是传统数据仓库的一种分布式替代。应用在传统ETL中的数据的清洗、过滤、转化及直接汇总等场景很适合，数据量越大，它的性价比越高。但目前为止看，其支撑的数据分析场景也是有限的， 简单的离线的海量分析计算是它所擅长的，相对应的，复杂的关联交叉运算其速度很慢。

一定程度讲，比如企业客户统一视图宽表用HIVE做比较低效，因为涉及到多方数据的整合，但不是不可以做，最多慢点嘛，还是要讲究个平衡。

hadoop到了X000台集群的规模也撑不住了,当前很多企业的数据量应该会超过这个数量，除了像阿里等自身有研发能力的企业(比如ODPS)，是否也要走向按照业务拆分Hadoop集群的道路?诸如浙江移动已经拆分了固网、移网、创新等多个hadoop集群。

Hadoop的SPARK的很适合机器学习的迭代，但能否大规模的应用于数据关联分析，能否一定程度替代MPP，还需要实践来验证。

MPP应该来说，是采用分布式架构对于传统数据仓库最好的替代，毕竟其实际上是变了种的关系型数据库，对于SQL提供完整支持，在HIVE做了转化分析后，数据仓库的融合建模用它来做性能绰绰有余，其性价比较传统DB2更好一点，比如经过实用，Gbase30-40台集群就能超过2台顶配的IBM 780。

MPP现在产品很多，很难做优劣判断，但一些实践结果可以说下，GBASE不错，公司很多系统已经在上面跑了，主要还是国产的，技术服务保障相对靠谱，ASTER还有待观望，自带一些算法库是有其一些优势，GreenPlum、Vertica没用过，不好说。

现在有个说法是MPP最终也要被Hadoop那套框架替代，毕竟诸如SPARK啥的都在逐步稳定和成熟，但在短期内，我觉得还是很靠谱的，如果数据仓库要采用渐进的演化方式，MPP的确是很好的选择。

现在诸如中国移动，eBAY等大量公司都在采用这类混搭结构，以适应不同的应用场景，显然是一种自然的选择。

大数据平台的三驾马车，少不了流处理。

对于很多企业来讲，其显然是核武器般的存在，大量的应用场景需要它，因此务必要进行建设，比如在IOE时代不可想象的实时、准实时数据仓库场景，在流处理那里就变得很简单了，以前统计个实时指标，也是很痛苦的事情，当前比如反欺诈实时系统，一天系统就申请部署好了。

只尝试过STORM和IBM STREAM，推荐IBM STREAM，虽然是商业版本，但其处理能力超过STORM不是一点半点，据说STORM也基本不更新了，但其实数据量不大，用啥都可以，从应用的角度讲，诸如IBM这种商业版本，是不错的选择，支撑各类实时应用场景绰绰有余。

流处理集群以流处理技术结合内存数据库，用以实时及准实时数据处理，基于IBM Streams流处理集群承载公司的实时业务：

3、数据分析层，与时俱进吧。

先谈谈语言，R和Python是当前数据挖掘开源领域的一对基友，如果要说取舍，笔者真说不出来，感觉Python更偏向工程一点，比如有对分词啥的直接支撑，R的绘图能力异常强大。但他们原来都以样本统计为主，因此大规模数据的支撑有限。

笔者还是更关注分布式挖掘环境，SPARK是一种选择，建议可以采用SPARK+scala，毕竟SPARK是用scala写的，对很多原生的特性能够快速支持。

TD的MPP数据库ASTER也内嵌了很多算法，应该基于并行架构做了很多优化，似乎也是一种选择，以前做过几度交往圈，速度的确很快，但使用资料屈指可数，还需要老外的支持。

传统的数据挖掘工具也不甘人后，SPSS现在有IBM SPSS Analytic Server，加强了对于大数据hadoop的支撑，业务人员使用反馈还是不错的。

也许未来机器学习也会形成高低搭配，高端用户用spark，低端用户用SPSS，也是要适应不同的应用场景。

深度学习现在渐成潮流，TensorFlow是个选择，公司当前也部署了一套，希望有机会使用，往人工智能方向演进是大势所趋。

无论如何，工具仅仅是工具，最终靠的还是建模工程师驾驭能力。

4、数据开放层，也处在一个战国时代。

有些工程师直接将HIVE作为查询输出，虽然不合理，也体现出计算和查询对于技术能力要求完全不同，即使是查询领域，也需要根据不同的场景，选择不同的技术。

HBASE很好用，基于列存储，查询速度毫秒级，对于一般的百亿级的记录查询那也是能力杠杠的，具有一定的高可用性，我们生产上的详单查询、指标库查询都是很好的应用场景。但读取数据方面只支持通过key或者key范围读取，因此要设计好rowkey。

Redis是K-V数据库，读写速度比HBASE更快，大多时候，HBASE能做的，Redis也能做，但Redis是基于内存的，主要用在key-value 的内存缓存，有丢失数据的可能，当前标签实时查询会用到它，合作过的互联网或广告公司大多采用该技术，但如果数据越来越大，那么，HBASE估计就是唯一的选择了?

另外已经基于IMPALA提供互联网日志的实时在线查询应用，也在尝试在营销平台采用SQLFire和GemFire实现分布式的基于内存的SQL关联分析，虽然速度可以，但也是BUG多多，引入和改造的代价较大。

Kylin当前算是基于hadoop/SPARK的多维分析的杀手级工具，应用的场景非常多，希望有机会使用。

5、数据应用层，百花齐放吧。

每个企业应根据自己的实际规划自己的应用，其实搞应用蓝图很难，大数据架构越上层越不稳定，因为变化太快，以下是运营商对外变现当前阶段还算通用的一张应用规划图，供参考：

6、数据管理层，路漫漫其修远兮

大数据平台的管理有应用管理和系统管理之分，从应用的角度讲，比如我们建立了DACP的可视化管理平台，其能适配11大搭数据技术组件，可以实现对各类技术组件的透明访问能力，同时通过该平台实现从数据设计、开发到数据销毁的全生命周期管理，并把标准、质量规则和安全策略固化在平台上，实现从事前管理、事中控制和事后稽核、审计的全方位质量管理和安全管理。

其它诸如调度管理、元数据管理、质量管理当然不在话下，因为管住了开发的源头，数据管理的复杂度会大幅降低。

从系统管理的角度看，公司将大数据平台纳入统一的云管理平台管理(私有云)，云管理平台包括支持一键部署、增量部署的可视化运维工具、面向多租户的计算资源管控体系(多租户管理、安全管理、资源管理、负载管理、配额管理以及计量管理)和完善的用户权限管理体系，提供企业级的大数据平台运维管理能力支撑，当然这么宏大的目标要实现也非一日之功。

总结下大数据平台的一些革命性价值。

大数据时代，大多数企业的架构必然向着分布式、可扩展及多元化发展，所谓合久必分，不再有一种技术能包打天下了， 这冲击着传统企业集中化的技术外包模式，挑战是巨大的。

大数据及云计算时代，面多这么多技术组件，要采用一项新的技术，机遇和风险共存：

对于大数据平台的商业版本，企业面对的是合作伙伴的服务跟不上，因为发展太快，对于开源版本，企业面临的是自身运维能力和技术能力的挑战，对于自主能力实际要�...

国内大数据服务企业主力阵营：

1、TakingData

TakingData以SmartDP为核心的数据智能应用生态为企业赋能，帮助企业逐步实现以数据为驱动力的数字化转型。

2、友盟+

友盟+基于全域数据、数据技术和商业场景，构建以7亿消费者为核心，覆盖数据化运营、数据营销、新零售数据服务、金融及手机解决方案的数据智能服务体系，驱动业务持续增长。

3、精准科技

精准科技是一家以用户画像为特色的大数据技术公司，致力于推动大数据在营销场景中的使用，业务主要涵盖汽车、金融、房产三大领域。

4、浪潮

浪潮互联网大数据采集中心已经采集超过2PB数据，并已建立5大类数据分类处理算法。近日成功发布海量存储系统的最新代表产品AS130000。

5、腾讯

腾讯拥有用户关系数据和基于此产生的社交数据，腾讯的思路主要是用数据改进产品，注重QZONE、微信、电商等产品的后端数据打通。

6、 探码科技

探码科技自主研发的DYSON只能分析系统，可以完整的实现大数据的采集、分析、处理。一直做的国外项目美国最大的律师平台、医生平台和酒店、机票预订平台的数据采集、分析、处理。将在国内推出一系列面向政务、企业的创新型大数据研究项目与合作，为各大企业提供高端信息技术咨询服务。

7、中兴通讯

中兴通讯推出的“聚焦ICT服务的高效数据中心整体服务解决方案”，可帮助运营商有效解决大数据时代建设IDC面临的大部分问题，提升运营商ICT融合服务能力。

8、神州融

神州融整合了国内权威的第三方征信机构和电商平台等信贷应用场景的征信大数据，通过覆盖信贷全生命周期管理的顶尖风控技术，为微金融机构提供大数据驱动的信贷风控决策服务。

9、中科曙光

中科曙光XData大数据一体机可实现任务自动分解，并在多数据模块上并行执行，全面提高了复杂查询条件下的效率。

10、华胜天成

华胜天成自主研发的大数据产品“i维数据”，颇具创新，近期又与IBM达成战略合作关系，涵盖Linux on Power市场、智慧城市、存储业务、管理服务、咨询与应用管理服务。

11、神州数码

“神州数码”启动了“智慧城市”战略布局，先后推出了市民融合服务平台、自助终端服务平台等产品，并在佛山、武汉等“智慧城市”建设中实践运用。

12、用友

用友在商业分析、大数据处理等领域进行研发，先后推出了用友BQ、用友AE等产品。

13、东软

东软大数据战略以医疗行业为突破口，凭借在社保、医疗行业积累的资源，搭建了东软熙康这一智慧医疗平台。

14、金蝶

金蝶KBI与金蝶ERP无缝集成，实现BI数据采集——集成——分析决策支持的一体化应用。

15、宝德

宝德大数据云备份，是一个专为大数据而设的云备份方案，支持实体机及虚拟机备份，而且具有无限扩充的可能，并且完全自动。

16、启明星辰

大数据时代的IP治理和审计，启明星辰提供了终端审计、终端数据防泄露、日志审计，通过综合审计平台来帮助用户解决IP治理需求等解决方案。

17、拓尔思

拓尔思通过收购天行网安，可以拓展在公安行业的应用，目前正着力开拓行业应用市场，挖掘各个产业链中的大数据价值。

18、荣之联

零售、证券、生物、政府等都是荣之联大数据业务的主要目标行业，已为零售业提供了大数据分析的解决方案，解决了库存问题。

19、中科金财

中科金财作为国内领先的高端IT综合服务商，主要服务于金融业的大数据。

20、美亚柏科

美亚柏科专注于公安市场，其业务包括电子数据取证、电子数据鉴定、网络舆情分析、数字维权、公证云、搜索云以及取证云服务。

21、赛思信安

国内存储技术与服务供应商赛思信安推出了自主研发的大数据管理系统，适用范围包括互联网、公众服务、商业智能、金融、医疗卫生、能源等多个行业。

22、华宇软件

华宇软件作为大数据、食品安全、法务软件等相关热门行业软件，同时也是公安领域大数据的上市公司。

23、天玑科技

天玑科技的数据中心运维管理服务，为大数据的分析能力提供了强大的后台支撑和保障。

24、东方国信

东方国信主营业务为企业商业智能软件及系统解决方案，收购北科亿力和科瑞明，有效拓展了工业和金融大数据领域。

25、华三

华三全融合虚拟化网络技术能够极大简化网络结构，减轻网络管理和维护量，为企业数据中心大规模建设提供最强有力的技术支持。

26、海康威视

海康威视基于英特尔Hadoop发行版，并融合可以灵活按需调配IT资源对应用和服务进行支持的开放架构云计算技术，打造出了视频智能云计算方案。

27、高德

高德与阿里将在地图搜索、产品商业化、数据共享、云计算等领域展开合作，特别是在数据共享方面，高德和阿里巴巴将共建一个大数据服务体系，

28、四维图新

作为提供导航地图、地理信息系统软件建设的内容提供商，现在已尝试使用大数据为政府部门提供决策。

29、海捷科技

专注于商业智能领域(BI)、数据仓库领域、数据库领域的专业咨询、项目实施、软件开发、系统集成等方面，为金融、电信、快速消费品等行业提供相应方案。

30、北京信合运通

信合运通专注于为运营商和行业客户提供基于大数据的深度分析和挖掘技术、渠道支撑服务及行业解决方案。

31、海云数据

海云数据专注于从事数据可视化，可为客户提供数据可视化的创意设计、制作和软硬件集成系统服务。

32、九次方金融数据

九次方金融数据在国内唯一以企业大数据分析的角度对有投资价值和并购价值的企业进行价值判断，持续跟踪企业动态变化的金融大数据公司。

33、永洪科技

永洪BI通过完全自主知识产权的数据集市产品(Z-Data Mart)支持大数据，Z-Data Mart汇聚了数十项自有专利，涵盖了分布式存储和计算、分布式传输和实时通信等关键领域。

34、集奥聚合

集奥聚合作为大数据服务提供商，其DataQuate解决方案主要用于解决运营商大数据的接入、挖掘及应用，为运营商大数据的价值转化提供端到端服务。

35、华院数云

华院数云以数据挖掘为核心、以商业智能和精准营销为主线、以SAAS云平台为主要服务模式，目前专注于电商领域，为客户提供行业领先的数据分析和精准营销平台服务。

36、杭州诚道科技

杭州诚道科技致力于为浙江、全国公安交通管理行业提供一流的信息化服务、产品和方案解决能力，其借助英特尔Hadoop分发版，已解决了大数据的采集和处理问题。

37、勒卡斯

勒卡斯是致力于为客户提供全方位直复营销解决方案和服务的大数据公司，主要有潜客沟通、会员管理、CRM软件定制及客户市场调研四大业务。

38、北京阿尔泰科技

北京阿尔泰科技专业数据采集系统的制造商。

39、智拓通达

智拓通达主要做中国主流社交平台的“大数据”分析，通过整合各大社交平台的用户数据、行为数据和 UGC 内容，为企业和个人用户提供定制化服务。

40、国双科技

国双科技数据中心拥有基于OLAP技术的强大交互式数据挖掘平台，可提供不同深度的分析报告，满足不同视角的数据挖掘和分析需求。

41、时云医疗科技

时云医疗科技今日发布了医疗领域的大数据“未病”预警云服务“康诺云”，有针对个人健康管理而设计的云律血压节律仪、云悦体质分析仪和云动智能健康监测腕表3款智能硬件。

42、百分点

百分点主要为电子商务企业提供站内流量转化和商业智能分析的整体优化解决方案，旗下有推荐引擎技术平台以及跨网站消费偏好平台。产品主要有BRE和BAE。

43、精硕科技

精硕科技是国内少有的第三方数字营销监测和调研机构，专注于为广告主提供全流程的网络广告效果监测、分析评估、媒介优化咨询和技术解决方案等服务。

44、神策数据

神策数据立足大数据及用户行为分析的技术与实践前沿，业务现已覆盖以互联网、金融、零售快消、高科技、制造等为代表的十多个主要行业、并可支持企业多个职能部门。

45、百度

百度的优势体现在海量的数据、沉淀十多年的用户行为数据、自然语言处理能力和深度学习领域的前沿研究。近来百度正式发布大数据引擎，将在政府、医疗、金融、零售、教育等传统领域率先开展对外合作。

46、阿里巴巴

阿里巴巴拥有交易数据和信用数据,更多是在搭建数据的流通、收集和分享的底层架构。

47、华为华为云服务

整合了高性能的计算和存储能力，为大数据的挖掘和分析提供专业稳定的IT基础设施平台，近来华为大数据存储实现了统一管理40PB文件系统。

48、同盾科技

同盾科技将人工智能与业务场景深度结合，为银行、保险、汽车金融、非银行信贷、基金理财、三方支付、航旅、电商、O2O、游戏、社交平台等十余个行业客户提供高效智能的风控、反欺诈及营销分析服务。

49、国双科技

国双科技是中国的企业级大数据和人工智能解决方案提供商。

50、智慧足迹

智慧足迹是由中国联通和西班牙电信合资成立的专业大数据公司，依托中国联通的数据能力，提供位置信息洞察及相关大数据业务。

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，存储到一维的键值存储系统中，这是一种非常重要的建模模式：提供了不同缩放等级下在多维空间中邻接的数据仍然顺序存储，遍历高效;同时不同主键从前向后的相似度和空间距离的远近相一致，能通过键值的简单顺序比较判断其位置“相似度”。

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

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

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

拥有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最初并没有太多的考虑数据安全方面，这点要自己加强；高稳定性和高性能往往一个是鱼，一个是熊掌，请考虑好取舍。

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

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

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

我们一直在路上

随着大数据越来越被重视，数据采集的挑战变的尤为突出。今天为大家介绍几款数据采集平台：

Apache Flume Fluentd Logstash Chukwa Scribe Splunk Forwarder

大数据平台与数据采集

任何完整的大数据平台，一般包括以下的几个过程：

数据采集–>数据存储–>数据处理–>数据展现(可视化，报表和监控)

其中，数据采集是所有数据系统必不可少的，随着大数据越来越被重视，数据采集的挑战也变的尤为突出。这其中包括：

我们今天就来看看当前可用的六款数据采集的产品，重点关注它们是如何做到高可靠，高性能和高扩展。

1、Apache Flume

Flume 是Apache旗下的一款开源、高可靠、高扩展、容易管理、支持客户扩展的数据采集系统。 Flume使用JRuby来构建，所以依赖Java运行环境。

Flume最初是由Cloudera的工程师设计用于合并日志数据的系统，后来逐渐发展用于处理流数据事件。

Flume设计成一个分布式的管道架构，可以看作在数据源和目的地之间有一个Agent的网络，支持数据路由。

每一个agent都由Source，Channel和Sink组成。

Source

Source负责接收输入数据，并将数据写入管道。Flume的Source支持HTTP，JMS，RPC，NetCat，Exec，Spooling Directory。其中Spooling支持监视一个目录或者文件，解析其中新生成的事件。

Channel

Channel 存储，缓存从source到Sink的中间数据。可使用不同的配置来做Channel，例如内存，文件，JDBC等。使用内存性能高但不持久，有可能丢数据。使用文件更可靠，但性能不如内存。

Sink

Sink负责从管道中读出数据并发给下一个Agent或者最终的目的地。Sink支持的不同目的地种类包括：HDFS，HBASE，Solr，ElasticSearch，File，Logger或者其它的Flume Agent。

Flume在source和sink端都使用了transaction机制保证在数据传输中没有数据丢失。

Source上的数据可以复制到不同的通道上。每一个Channel也可以连接不同数量的Sink。这样连接不同配置的Agent就可以组成一个复杂的数据收集网络。通过对agent的配置，可以组成一个路由复杂的数据传输网络。

配置如上图所示的agent结构，Flume支持设置sink的Failover和Load Balance，这样就可以保证即使有一个agent失效的情况下，整个系统仍能正常收集数据。

Flume中传输的内容定义为事件(Event)，事件由Headers(包含元数据，Meta Data)和Payload组成。

Flume提供SDK，可以支持用户定制开发：

Flume客户端负责在事件产生的源头把事件发送给Flume的Agent。客户端通常和产生数据源的应用在同一个进程空间。常见的Flume 客户端有Avro，log4J，syslog和HTTP Post。另外ExecSource支持指定一个本地进程的输出作为Flume的输入。当然很有可能，以上的这些客户端都不能满足需求，用户可以定制的客户端，和已有的FLume的Source进行通信，或者定制实现一种新的Source类型。

同时，用户可以使用Flume的SDK定制Source和Sink。似乎不支持定制的Channel。

2、Fluentd

Fluentd是另一个开源的数据收集框架。Fluentd使用C/Ruby开发，使用JSON文件来统一日志数据。它的可插拔架构，支持各种不同种类和格式的数据源和数据输出。最后它也同时提供了高可靠和很好的扩展性。Treasure Data, Inc 对该产品提供支持和维护。

Fluentd的部署和Flume非常相似：

Fluentd的架构设计和Flume如出一辙：

Fluentd的Input/Buffer/Output非常类似于Flume的Source/Channel/Sink。

Input

Input负责接收数据或者主动抓取数据。支持syslog，http，file tail等。

Buffer

Buffer负责数据获取的性能和可靠性，也有文件或内存等不同类型的Buffer可以配置。

Output

Output负责输出数据到目的地例如文件，AWS S3或者其它的Fluentd。

Fluentd的配置非常方便，如下图：

Fluentd的技术栈如下图：

FLuentd和其插件都是由Ruby开发，MessgaePack提供了JSON的序列化和异步的并行通信RPC机制。

Cool.io是基于libev的事件驱动框架。

FLuentd的扩展性非常好，客户可以自己定制(Ruby)Input/Buffer/Output。

Fluentd从各方面看都很像Flume，区别是使用Ruby开发，Footprint会小一些，但是也带来了跨平台的问题，并不能支持Windows平台。另外采用JSON统一数据/日志格式是它的另一个特点。相对去Flumed，配置也相对简单一些。

3、Logstash

Logstash是著名的开源数据栈ELK (ElasticSearch, Logstash, Kibana)中的那个L。

Logstash用JRuby开发，所有运行时依赖JVM。

Logstash的部署架构如下图，当然这只是一种部署的选项。

一个典型的Logstash的配置如下，包括了Input，filter的Output的设置。

几乎在大部分的情况下ELK作为一个栈是被同时使用的。所有当你的数据系统使用ElasticSearch的情况下，logstash是首选。

4、Chukwa

官网：https://chukwa.apache.org/

Apache Chukwa是apache旗下另一个开源的数据收集平台，它远没有其他几个有名。Chukwa基于Hadoop的HDFS和Map Reduce来构建(显而易见，他用Java来实现)，提供扩展性和可靠性。Chukwa同时提供对数据的展示，分析和监视。很奇怪的是它的上一次 github的更新事7年前。可见该项目应该已经不活跃了。

Chukwa的部署架构如下：

Chukwa的主要单元有：Agent，Collector，DataSink，ArchiveBuilder，Demux等等，看上去相当复杂。由于该项目已经不活跃，我们就不细看了。

5、Scribe

代码托管：https://github/facebookarchive/scribe

Scribe是Facebook开发的数据(日志)收集系统。已经多年不维护，同样的，就不多说了。

6、Splunk Forwarder

以上的所有系统都是开源的。在商业化的大数据平台产品中，Splunk提供完整的数据采金，数据存储，数据分析和处理，以及数据展现的能力。

Splunk是一个分布式的机器数据平台，主要有三个角色：

Search Head负责数据的搜索和处理，提供搜索时的信息抽取。

Indexer负责数据的存储和索引 Forwarder，负责数据的收集，清洗，变形，并发送给Indexer

Splunk内置了对Syslog，TCP/UDP，Spooling的支持，同时，用户可以通过开发 Input和Modular Input的方式来获取特定的数据。在Splunk提供的软件仓库里有很多成熟的数据采集应用，例如AWS，数据库(DBConnect)等等，可以方便的从云或者是数据库中获取数据进入Splunk的数据平台做分析。

这里要注意的是，Search Head和Indexer都支持Cluster的配置，也就是高可用，高扩展的，但是Splunk现在还没有针对Farwarder的Cluster的功能。也就是说如果有一台Farwarder的机器出了故障，数据收集也会随之中断，并不能把正在运行的数据采集任务Failover到其它的 Farwarder上。

总结

我们简单讨论了几种流行的数据收集平台，它们大都提供高可靠和高扩展的数据收集。大多平台都抽象出了输入，输出和中间的缓冲的架构。利用分布式的网络连接，大多数平台都能实现一定程度的扩展性和高可靠性。

其中Flume，Fluentd是两个被使用较多的产品。如果你用ElasticSearch，Logstash也许是首选，因为ELK栈提供了很好的集成。Chukwa和Scribe由于项目的不活跃，不推荐使用。

Splunk作为一个优秀的商业产品，它的数据采集还存在一定的限制，相信Splunk很快会开发出更好的数据收集的解决方案。

自从像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