结构化数据:表,关系型数据库//有严格的约束
半结构化数据:html、json、yaml,有元数据//有约束,缺少严格的约束
非结构化数据:没有预定义的模型,元数据//日志数据等
搜索引擎:搜索组件,索引组件
网络爬虫:爬到的内容多为半结构化或者非结构化数据
构建倒排索引(基于精确搜索或模糊搜索基于相关度匹配)存储到存储系统非RDBMS中。
2003年:Google文件系统//谷歌如何实现文件存储,不支持对数据进行随机和实时访问,仅适用于存储少量的体积巨大的文件。
假如爬到html页面发生了改变,需要修改。则古耳fs无法满足该需求
2004年:MapReduce:简化数据进动> 2006年:BigTable:分布式存储系统结构数据//存储结构化数据的分布式存储
GFS→山寨后HDFS:
MapReduce→MapReduce:
BigTable→HBase:
HDFS + Hadoop MapReduce=//作者儿子的一个玩具
HBase: Hadoop的database
Nutch:一个网络爬虫程序,为Lucene爬取数据
Hadoop的一个缺陷:MapReduce是批处理程序,
HDFS采用的是有中心节点的存储格式
,客户
|
元数据节点
|
===========================
node1, node2, node3,节点n
11“22”
数据查询过程:客户→元数据节点(数据分布在哪些节点上)——祝辞(节点1、2、3,n]——在客户端用户查询(写代码)——比;先调用MapReduce的开发框架,在交由该框架运行
地图:该代码需要分别运行在node1和node2上,各节点分别处理自己所用的那一部分
,,,,,,,,,,,,//node1拥有1,node2拥有2
减少:最后要把node1和node2上的运行结果进行合并
最终速度:取决于速度最慢的节点
MapReduce:
1。开发API
2。运行框架
3。提供运行时环境
NAS和SAN的缺点:存储系统只有1个,面对海量数据,需要进行数据存取,磁盘IO和网络IO将面临极大挑战
因此出现了分布式存储
<强>
1。无中心节点,
2。有中心节点HDFS//元数据节点是瓶颈和核心所在。//GFS, HDFS,
元数据节点:神经网络:名字节点//公顷,内存数据持久化。他的数据都是存储在内存中的
//事务日志,写入到持久存储后,宕机后,重新加载,减少丢失的数据。
后端主机要保证:服务可用+数据可用//DN:数据node
在宕机后回可能需要文件系统检测,数据量过大时,需要浪费大量时间。
//简单的说:一旦NN崩溃,再次启动需要半个小时,因为hadoop 1。X NN不支持HA
SNN:第二namenode后期提供,
NN需要在内存中不断更新数据,写入日志,日志和映像文件合并等
SNN:负责合并数据,假如NN崩溃SNN加载共享存储的文件,自己工作。
节省了时间,但是文件系统检测需要的时间,依然没有少。只是不用立即修复NN
磅:对不同的请求,分发到不同的主机
,客户
|
NN - SNN
|
[镜像](SHM)
|
===========================
node1, node2, node3,节点n
11“22”
2.0 HDFS之后的神经网络可以高可用
元数据不再存放到本地存储,而是存储到一个共享存储存放,基于内存完成元数据存放。
例如:NFS(脑裂)不常用,饲养员
NN1和NN2的更新操作都向饲养员同步,因此每一个节点都可以从饲养员获取同样的数据。
//管理员:分布式协调工具(分布式锁),谷歌的胖乎乎的(不开源)
http://www.cnblogs.com/wuxl360/p/5817471.html/参考网站
数据节点:存放各个块的
每个数据存储副本:存储到其他节点。默认存储3个副本。
存储的时候,之存储一个,由HDFS另找两个节点进行存储。
每一个存储节点会向服务节点周期报告自己所存储的数据块信息+自身状态信息。
神经网络有两个表:
1。以数据为中心,分布在哪些节点上
2。以节点为核心,持有哪些数据块
数据如何处理://运行程序的集群
MapReduce:集群方式工作。
地图:分散运行
减少:合并
一个任务可以分为几个地图,由MapReduce的框架进行控制的。
需要一个总的节点,进行调度JobTracker
理想情况:让拥有请求数据的节点都运行任务//但是有的节点可能已经很忙了
假如拥有数据的节点繁忙解决方案:
1。等待
2。找副本所在节点//可能副本节点也比较忙
