⑴ Hadoop分布式存储
为了降低整体的带宽消耗和读取延时，HDFS会尽量让读取程序读取离它最近的副本。如果在读取程序的同一个机架上有一个副本，那么就读取该副本。如果一个HDFS集群跨越多个数据中心，那么客户端也将首先读本地数据中心的副本
Namenode启动后会进入一个称为安全模式的特殊状态。处于安全模式的Namenode是不会进行数据块的复制的。Namenode从所有的 Datanode接收心跳信号和块状态报告。块状态报告包括了某个Datanode所有的数据块列表。每个数据块都有一个指定的最小副本数。当Namenode检测确认某个数据块的副本数目达到这个最小值，那么该数据块就会被认为是副本安全(safely replicated)的；在一定百分比（这个参数可配置）的数据块被Namenode检测确认是安全之后（加上一个额外的30秒等待时间），Namenode将退出安全模式状态。接下来它会确定还有哪些数据块的副本没有达到指定数目，并将这些数据块复制到其他Datanode上
所有的HDFS通讯协议都是建立在TCP/IP协议之上。客户端通过一个可配置的TCP端口连接到Namenode，通过ClientProtocol协议与Namenode交互。而Datanode使用DatanodeProtocol协议与Namenode交互。一个远程过程调用(RPC)模型被抽象出来封装ClientProtocol和Datanodeprotocol协议。在设计上，Namenode不会主动发起RPC，而是响应来自客户端或 Datanode 的RPC请求
⑵ 基于mogileFS搭建分布式文件系统--海量小文件的存储利器
1.简介
分布式文件系统（Distributed File System）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。分布式文件系统的设计基于客户机/服务器模式。一个典型的网络可能包括多个供多用户访问的服务器。另外，对等特性允许一些系统扮演客户机和服务器的双重角色。例如，用户可以“发表”一个允许其他客户机访问的目录，一旦被访问，这个目录对客户机来说就像使用本地驱动器一样。
当下我们处在一个互联网飞速发展的信息 社会 ，在海量并发连接的驱动下每天所产生的数据量必然以几何方式增长，随着信息连接方式日益多样化，数据存储的结构也随着发生了变化。在这样的压力下使得人们不得不重新审视大量数据的存储所带来的挑战，例如：数据采集、数据存储、数据搜索、数据共享、数据传输、数据分析、数据可视化等一系列问题。
传统存储在面对海量数据存储表现出的力不从心已经是不争的事实，例如：纵向扩展受阵列空间限制、横向扩展受交换设备限制、节点受文件系统限制。
然而分布式存储的出现在一定程度上有效的缓解了这一问题，之所以称之为缓解是因为分布式存储在面对海量数据存储时也并非十全十美毫无压力，依然存在的难点与挑战例如：节点间通信、数据存储、数据空间平衡、容错、文件系统支持等一系列问题仍处在不断摸索和完善中。
2.分布式文件系统的一些解决方案
Google Filesystem适合存储海量大个文件，元数据存储与内存中
HDFS（Hadoop Filesystem）GFS的山寨版，适合存储大量大个文件
TFS（Taobao Filesystem）淘宝的文件系统，在名称节点上将元数据存储与关系数据库中，文件数量不在受限于名称节点的内容空间，可以存储海量小文件LustreOracle开发的企业级分布式系统，较重量级MooseFS基于FUSE的格式，可以进行挂载使用MogileFS
擅长存储海量的小数据，元数据存储与关系型数据库中
1.简介
MogileFS是一个开源的分布式文件系统，用于组建分布式文件集群，由LiveJournal旗下DangaInteractive公司开发，Danga团队开发了包括 Memcached、MogileFS、Perlbal等不错的开源项目：(注：Perlbal是一个强大的Perl写的反向代理服务器)。MogileFS是一个开源的分布式文件系统。
目前使用 MogileFS 的公司非常多,比如国外的一些公司,日本前几名的公司基本都在使用这个.
国内所知道的使用 MogileFS 的公司有图片托管网站 yupoo又拍,digg, 薯仔, 豆瓣,1 号店, 大众点评,搜狗,安居客等等网站.基本很多网站容量，图片都超过 30T 以上。
2.MogileFS特性
1) 应用层提供服务，不需要使用核心组件
2）无单点失败，主要有三个组件组成，分为tracker（跟踪节点）、mogstore（存储节点）、database（数据库节点）
3）自动复制文件，复制文件的最小单位不是文件，而是class
4）传输中立，无特殊协议，可以通过NFS或HTTP实现通信
5）简单的命名空间：没有目录，直接存在与存储空间上，通过域来实现
6）不用共享任何数据
3.MogileFS的组成
1）Tracker--跟踪器，调度器
MogileFS的核心，是一个调度器，mogilefsd进程就是trackers进程程序,trackers的主要职责有：删除数据、复制数据、监控、查询等等.这个是基于事件的( event-based ) 父进程/消息总线来管理所有来之于客户端应用的交互(requesting operations to be performed), 包括将请求负载平衡到多个"query workers"中,然后让 mogilefs的子进程去处理.
mogadm,mogtool的所有操作都要跟trackers打交道,Client的一些操作也需要定义好trackers,因此最好同时运行多个trackers来做负载均衡.trackers也可以只运行在一台机器上，使用负载均衡时可以使用搞一些简单的负载均衡解决方案，如haproxy，lvs，nginx等，
tarcker的配置文件为/etc/mogilefs/mogilefsd.conf，监听在TCP的7001端口
2）Database--数据库部分
主要用来存储mogilefs的元数据，所有的元数据都存储在数据库中，因此，这个数据相当重要，如果数据库挂掉，所有的数据都不能用于访问，因此，建议应该对数据库做高可用
3）mogstored--存储节点
数据存储的位置，通常是一个HTTP（webDAV）服务器，用来做数据的创建、删除、获取，任何 WebDAV 服务器都可以, 不过推荐使用 mogstored . mogilefsd可以配置到两个机器上使用不同端口… mogstored 来进行所有的 DAV 操作和流量,IO监测, 并且你自己选择的HTTP服务器(默认为 perlbal)用来做 GET 操作给客户端提供文件.
典型的应用是一个挂载点有一个大容量的SATA磁盘. 只要配置完配置文件后mogstored程序的启动将会使本机成为一个存储节点.当然还需要mogadm这个工具增加这台机器到Cluster中.
配置文件为/etc/mogilefs/mogstored.conf，监听在TCP的7500端口
4.基本工作流程
应用程序请求打开一个文件 (通过RPC 通知到 tracker, 找到一个可用的机器). 做一个 “create_open” 请求.
tracker 做一些负载均衡(load balancing)处理，决定应该去哪儿，然后给应用程序一些可能用的位置。
应用程序写到其中的一个位置去 (如果写失败，他会重新尝试并写到另外一个位置去）.
应用程序 (client) 通过”create_close” 告诉tracker文件写到哪里去了.
tracker 将该名称和域命的名空间关联 (通过数据库来做的)
tracker, 在后台, 开始复制文件，知道他满足该文件类别设定的复制规则
然后,应用程序通过 “get_paths” 请求 domain+key (key == “filename”) 文件, tracker基于每一位置的I/O繁忙情况回复(在内部经过 database/memcache/etc 等的一些抉择处理), 该文件可用的完整 URLs地址列表.
应用程序然后按顺序尝试这些URL地址. (tracker’持续监测主机和设备的状态，因此不会返回死连接,默认情况下他对返回列表中的第一个元素做双重检查，除非你不要他这么做..)
1.拓扑图
说明：1.用户通过URL访问前端的nginx
2.nginx根据特定的挑选算法，挑选出后端一台tracker来响应nginx请求
3.tracker通过查找database数据库，获取到要访问的URL的值，并返回给nginx
4.nginx通过返回的值及某种挑选算法挑选一台mogstored发起请求
5.mogstored将结果返回给nginx
6.nginx构建响应报文返回给客户端
2.ip规划
角色运行软件ip地址反向代理nginx192.168.1.201存储节点与调度节点1
mogilefs192.168.1.202存储节点与调度节点2
mogilefs192.168.1.203数据库节点
MariaDB192.168.1.204
3.数据库的安装操作并为授权
关于数据库的编译安装，请参照本人相关博文http://wangfeng7399.blog.51cto.com/3518031/1393146，本处将不再累赘，本处使用的为yum源的安装方式安装mysql
4.安装mogilefs. 安装mogilefs，可以使用yum安装，也可以使用编译安装，本处通过yum安装
5.初始化数据库
可以看到在数据库中创建了一些表
6.修改配置文件，启动服务
7.配置mogilefs
添加存储主机
添加存储设备
添加域
添加class
8.配置192.168.1.203的mogilefs 。切记不要初始化数据库，配置应该与192.168.1.202一样
9.尝试上传数据，获取数据，客户端读取数据
上传数据，在任何一个节点上传都可以
获取数据
客户端查看数据
我们可以通过任何一个节点查看到数据
要想nginx能够实现对后端trucker的反向代理，必须结合第三方模块来实现
1.编译安装nginx
2.准备启动脚本
3.nginx与mofilefs互联
查看效果
5.配置后端truckers的集群
查看效果
大功告成了，后续思路，前段的nginx和数据库都存在单点故障，可以实现高可用集群
⑶ 华为突破分布式数据库和存储技术，打通数字化转型“雄关漫道”
2019年，我们将进入数字化转型的攻关期。所谓“攻关期”即数字化转型2.0阶段，需要攻坚企业关键业务上云和数字化转型改造的课题。在一份市场调查公司IDC的报告中指出：IDC自2014年提出数字化转型以来，看到企业在数字化转型层面已经投入了大量人力物力，但是效果并不理想，有一些企业已经成功屹立在潮头，有一些企业在向上游进发，还有一些企业只能在浪潮的挟裹中被动前行。
对于企业来说，数字化转型是“雄关漫道”。IDC认为，目前阶段来看，企业亟待解决的是数字化能力提升，包括：与业务的深入结合能力；数据处理和挖掘能力；以及IT技术运营和管理能力。特别是数据处理和挖掘能力，因为数字化转型推进企业从以流程为核心向以数据为核心转型，对海量、异构、多类型的数据处理和挖掘能力是释放数据价值的前提，对数据全生命周期的管控治理是释放数据价值的保障。而随着数字化转型引入大量新技术而导致IT复杂度变高，企业IT技术运营和管理能力是提升企业“IT生产力”的关键。
攻关数字化转型的“雄关漫道”，需要一个具备融合、智能、可传承三大特性的数字平台。这是2019年3月华为与IDC联合推出的《拥抱变化，智胜未来—数字平台破局企业数字化转型》白皮书所提出的观点。融合主要指把传统技术和创新技术相结合；智能主要指平台智能化和智能化能力输出；可传承主要指解耦、功能复用、可配置等理念打造的架构。而承载这三大观点的，就是新一代分布式企业级技术。
2019年5月15日，华为发布了业界首款支持ARM架构的新一代智能分布式数据库GaussDB以及分布式存储FusionStorage 8.0，作为新一代数据基础设施，诠释了具备融合、智能、可传承三大特性的数字平台。华为常务董事、ICT战略与Marketing总裁汪涛在发布会上表示，千行百业正在加速智能化进程，越来越多的企业已经意识到数据基础设施是智能化成功的关键。华为围绕计算、存储和数据处理三个领域重定义数据基础设施，加速迈向智能时代。
今天所讨论云和工业互联网等概念的背后是一个新时代的到来，这就是体系架构大迁徙。传统企业级技术是在单体应用和单机环境中，保证数据存储、调用等操作的高可靠、高可用、高稳定，特别是满足金融级事物处理的ACID（原子性、一致性、隔离性和耐久性）要求，为企业关键业务提供数据管理支撑。随着企业技术向云架构迁移，数据库技术也面临转型。
2018年，基于云计算技术的分布式数据库成为了业界的热点。简单理解，云计算技术就是把“单机”环境替换为由X86服务器机群所组成的分布式计算环境。原先由几台小型机完成的计算任务，要分散到上百甚至上千台X86服务器上，而且还可能跨数据中心操作，挑战可想而之。特别是在线支付等金融级业务，不能在断网或网络连接有问题时出错，也不能因响应速度慢而影响用户体验。
2018年8月，中国支付清算协会与中国信息通信研究院联合举办了“金融分布式事务数据库研讨会”，与业界厂商和用户共商核心数据库分布式转型之路，同时发布了《金融分布式事务数据库》白皮书。金融分布式事务数据库的工作推进，为分布式数据库进入企业关键业务系统，提供了产业化支撑。而华为作为企业ICT解决方案供应商，早在2012年就开始研发面向大数据分析的数据仓库，在基于传统关系型数据库SQL引擎和事务强一致性等基础上，进行了分布式、并行计算的改造，历时6年打造了面向PB级海量数据分析的分布式数据库。
在OLAP数据仓库之外，华为与行业用户合作了面向OLTP的分布式事务型数据库研发。2017年，华为与招商银行合作成立了分布式数据库联合创新实验室，研发具有高性能企业级内核、完整支持分布式事物、满足金融行业对数据强一致要求、单机事物处理能力要达到每分钟百万级别等的OLTP分布式数据库。
本次发布的GaussDB数据库新品包括：联机事务处理OLTP数据库、联机分析处理OLAP数据库、事务和分析混合处理HTAP数据库。而华为GaussDB数据库将AI技术融入数据库设计、开发、验证、调优、运维等环节，可实现基于AI的自调优、自诊断自愈、自运维，让数据库更高效、更智能，引领数据库架构的发展。
更进一步，本次发布的GaussDB系列数据库是业界首款支持ARM芯片的分布式数据库。华为推动计算架构从以X86+GPU为主的单一计算架构到以X86+GPU+ARM64+NPU为主的异构计算架构快速发展。基于X86架构，华为引入AI管理和智能加速能力，率先推出了智能服务器FusionServer Pro；基于ARM64打造了业界性能最强的TaiShan服务器；基于Ascend芯片的Atlas智能计算，实现了业界首个端边云协同的人工智能平台。而GaussDB可充分利用并融合ARM、X86、GPU、NPU等多种异构算力组合，大幅提升数据库性能。
汪涛强调，作为全球首款AI-Native数据库，GaussDB有两大革命性突破：第一，首次将人工智能技术引入数据库的全生命周期流程，实现自运维、自管理、自调优和故障自诊断。在交易、分析和混合负载场景下，基于最优化理论，首创深度强化学习自调优算法，把业界平均性能提升60%。第二，支持异构计算，充分发挥X86/ARM/GPU/NPU多样性算力优势，最大化数据库性能，在权威标准测试集TPC-DS上，华为GaussDB排名第一。GaussDB还支持本地部署、私有云、公有云等多种场景。
在以云计算为代表的分布式计算环境中，数据管理解决方案除了需要分布式数据库外，为了更好的扩缩容以及满足多样化数据存储需求，计算与存储分离已经成为分布式数据库设计的主要架构。分布式云化架构，就是要支持计算、存储分离和多租户等架构设计要求。
GaussDB已经从数据库层面实现了高可用、高可靠、高稳定的分布式数据库，本次发布的FusionStorage 8.0则是分布式存储架构，创新地实现一套系统同时支持块、文件、对象、HDFS协议，1套存储支持4类存储能力，适用于全业务场景混合负载，最终让“一个数据中心一套存储”成为可能。
IDC发布的《中国软件定义存储（SDS）及超融合存储（HCI）系统市场季度跟踪报告，2018年第四季度》显示，2018年，软件定义存储市场达到了54.9%的同比增长。软件定义存储在中国整体存储市场的占有率稳步上升，分别达到了22.1%的市场占有率。华为凭借文件解决方案在政府、广电和电信等行业得到认可，在2018年中国软件定义存储市场排名第一。
FusionStorage 8.0采用华为ARM-based处理器鲲鹏920加速，使IOPS提升 20%，结合华为AI Fabric无损网络，时延进一步降低15%。基于华为在计算、网络和存储领域多年的芯片和算法积累，FusionStorage 8.0在SPC-1的性能测试中，单节点性能达到了16.8万IOPS以及1ms以内时延，成为承载企业关键应用的新选择。
此外，通过华为云的云上训练及本地AI芯片，FusionStorage 8.0将智能管理贯穿业务使用的全生命周期，如业务上线前对存储资源的规划，使用过程中的风险预判及故障定位，大幅提升存储效率，帮助行业客户应对智能时代的数据新挑战。
汪涛在发布会上强调，新一代智能分布式存储FusionStorage 8.0通过重定义存储架构，从“Storage for AI”和“AI in Storage”两个维度实现效率大幅提升，引领存储智能化。首先，“Storage for AI”通过融合共享，让AI分析更高效。其次，“AI in Storage”率先将AI融入存储全生命周期管理，从资源规划、业务发放、系统调优、风险预测、故障定位等方面实现智能运维。
辽宁移动就采用了华为FusionStorage。作为辽宁省内最大的移动通信运营商，辽宁移动一直在 探索 先进的存储方案在自身IT系统的应用。由于5G的快速发展，辽宁移动关键数据库的应用也向云化方向发展，分布式存储也要满足其可靠性和高性能要求。华为在深入分析辽宁移动需求后，首先在边缘开发测试业务小规模试点分布式存储，进行了大量的实验和测试后性能和可靠性都达到了预期，最终决定将全部业务迁移至FusionStorage。该方案通过采用双活、可写快照、端到端DIF等特性，顺利完成Billing、经营分析、B2B等系统从老旧存储至FusionStorage的搬迁工作，助力辽宁移动的存储架构迈入新的 历史 阶段。
值得一提的是，华为分布式数据库与华为分布式存储深度结合，把数据库的操作下沉到存储节点，极大提升了分布式数据库的性能。利用新的网络技术和人工智能技术，华为帮助用户提升数据中心的吞吐量，提升网络应用的可伸缩性，并且能自动调优。
除了推出新一代突破性的分布式数据库和存储技术外，华为也积极与客户、伙伴在数据库与存储领域，从行业应用、平台工具、标准组织和社区等多个层面共建开放、合作、共赢的产业生态。在行业应用层面，华为与软通智慧、神州信息、东华软件、易华录、用友政务、亚信国际等独立软件开发商长期合作；在平台和工具层面，华为与Tableau、帆软、ARM、Veritas等合作伙伴联合创新；在标准组织和社区层面，华为深度参与OpenSDS、中国人工智能产业联盟、OCP、OpenStack、CNCF基金会等组织和社区的建设。
总结来说，华为全线分布式数据库和分布式存储产品的发布，是华为具备融合、智能、可传承三大特性数字平台的最新成果。华为分布式数据库与分布式存储结合，能消除企业各业务系统数据孤岛，构建面向行业场景的数据建模、分析和价值挖掘能力，对多源异构的数据进行汇聚、整合和分析，形成统一的全量数据和数据底座，实现数据价值挖掘和共享。而基于AI的智能化，可对基础设施进行高效的管理，为行业应用开发和迭代赋能，全面帮助企业突破关键应用上云的“雄关漫道”。（文/宁川）
⑷ 分布式存储是什么东西
关于分布式存储实际上并没有一个明确的定义，甚至名称上也没有一个统一的说法，大多数情况下称作 Distributed Data Store 或者 Distributed Storage System。
其中维基网络中给 Distributed data store 的定义是：分布式存储是一种计算机网络，它通常以数据复制的方式将信息存储在多个节点中。
在网络中给出的定义是：分布式存储系统，是将数据分散存储在多台独立的设备上。分布式网络存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。
尽管各方对分布式存储的定义并不完全相同，但有一点是统一的，就是分布式存储将数据分散放置在多个节点中，节点通过网络互连提供存储服务。这一点与传统集中式存储将数据集中放置的方式有着明显的区分。
⑸ 如何实现企业数据 大数据平台 分布式存放
Hadoop在可伸缩性、健壮性、计算性能和成本上具有无可替代的优势，事实上已成为当前互联网企业主流的大数据分析平台。本文主要介绍一种基于Hadoop平台的多维分析和数据挖掘平台架构。作为一家互联网数据分析公司，我们在海量数据的分析领域那真是被“逼上梁山”。多年来在严苛的业务需求和数据压力下，我们几乎尝试了所有可能的大数据分析方法，最终落地于Hadoop平台之上。
1. 大数据分析大分类
Hadoop平台对业务的针对性较强，为了让你明确它是否符合你的业务，现粗略地从几个角度将大数据分析的业务需求分类，针对不同的具体需求，应采用不同的数据分析架构。
按照数据分析的实时性，分为实时数据分析和离线数据分析两种。
实时数据分析一般用于金融、移动和互联网B2C等产品，往往要求在数秒内返回上亿行数据的分析，从而达到不影响用户体验的目的。要满足这样的需求，可以采用精心设计的传统关系型数据库组成并行处理集群，或者采用一些内存计算平台，或者采用HDD的架构，这些无疑都需要比较高的软硬件成本。目前比较新的海量数据实时分析工具有EMC的Greenplum、SAP的HANA等。
对于大多数反馈时间要求不是那么严苛的应用，比如离线统计分析、机器学习、搜索引擎的反向索引计算、推荐引擎的计算等，应采用离线分析的方式，通过数据采集工具将日志数据导入专用的分析平台。但面对海量数据，传统的ETL工具往往彻底失效，主要原因是数据格式转换的开销太大，在性能上无法满足海量数据的采集需求。互联网企业的海量数据采集工具，有Facebook开源的Scribe、LinkedIn开源的Kafka、淘宝开源的Timetunnel、Hadoop的Chukwa等，均可以满足每秒数百MB的日志数据采集和传输需求，并将这些数据上载到Hadoop中央系统上。
按照大数据的数据量，分为内存级别、BI级别、海量级别三种。
这里的内存级别指的是数据量不超过集群的内存最大值。不要小看今天内存的容量，Facebook缓存在内存的Memcached中的数据高达320TB，而目前的PC服务器，内存也可以超过百GB。因此可以采用一些内存数据库，将热点数据常驻内存之中，从而取得非常快速的分析能力，非常适合实时分析业务。图1是一种实际可行的MongoDB分析架构。
图1 用于实时分析的MongoDB架构
MongoDB大集群目前存在一些稳定性问题，会发生周期性的写堵塞和主从同步失效，但仍不失为一种潜力十足的可以用于高速数据分析的NoSQL。
此外，目前大多数服务厂商都已经推出了带4GB以上SSD的解决方案，利用内存+SSD，也可以轻易达到内存分析的性能。随着SSD的发展，内存数据分析必然能得到更加广泛的应用。
BI级别指的是那些对于内存来说太大的数据量，但一般可以将其放入传统的BI产品和专门设计的BI数据库之中进行分析。目前主流的BI产品都有支持TB级以上的数据分析方案。种类繁多，就不具体列举了。
海量级别指的是对于数据库和BI产品已经完全失效或者成本过高的数据量。海量数据级别的优秀企业级产品也有很多，但基于软硬件的成本原因，目前大多数互联网企业采用Hadoop的HDFS分布式文件系统来存储数据，并使用MapRece进行分析。本文稍后将主要介绍Hadoop上基于MapRece的一个多维数据分析平台。
数据分析的算法复杂度
根据不同的业务需求，数据分析的算法也差异巨大，而数据分析的算法复杂度和架构是紧密关联的。举个例子，Redis是一个性能非常高的内存Key-Value NoSQL，它支持List和Set、SortedSet等简单集合，如果你的数据分析需求简单地通过排序，链表就可以解决，同时总的数据量不大于内存（准确地说是内存加上虚拟内存再除以2），那么无疑使用Redis会达到非常惊人的分析性能。
还有很多易并行问题（Embarrassingly Parallel），计算可以分解成完全独立的部分，或者很简单地就能改造出分布式算法，比如大规模脸部识别、图形渲染等，这样的问题自然是使用并行处理集群比较适合。
而大多数统计分析，机器学习问题可以用MapRece算法改写。MapRece目前最擅长的计算领域有流量统计、推荐引擎、趋势分析、用户行为分析、数据挖掘分类器、分布式索引等。
2. 面对大数据OLAP大一些问题
OLAP分析需要进行大量的数据分组和表间关联，而这些显然不是NoSQL和传统数据库的强项，往往必须使用特定的针对BI优化的数据库。比如绝大多数针对BI优化的数据库采用了列存储或混合存储、压缩、延迟加载、对存储数据块的预统计、分片索引等技术。
Hadoop平台上的OLAP分析，同样存在这个问题，Facebook针对Hive开发的RCFile数据格式，就是采用了上述的一些优化技术，从而达到了较好的数据分析性能。如图2所示。
然而，对于Hadoop平台来说，单单通过使用Hive模仿出SQL，对于数据分析来说远远不够，首先Hive虽然将HiveQL翻译MapRece的时候进行了优化，但依然效率低下。多维分析时依然要做事实表和维度表的关联，维度一多性能必然大幅下降。其次，RCFile的行列混合存储模式，事实上限制死了数据格式，也就是说数据格式是针对特定分析预先设计好的，一旦分析的业务模型有所改动，海量数据转换格式的代价是极其巨大的。最后，HiveQL对OLAP业务分析人员依然是非常不友善的，维度和度量才是直接针对业务人员的分析语言。
而且目前OLAP存在的最大问题是：业务灵活多变，必然导致业务模型随之经常发生变化，而业务维度和度量一旦发生变化，技术人员需要把整个Cube（多维立方体）重新定义并重新生成，业务人员只能在此Cube上进行多维分析，这样就限制了业务人员快速改变问题分析的角度，从而使所谓的BI系统成为死板的日常报表系统。
使用Hadoop进行多维分析，首先能解决上述维度难以改变的问题，利用Hadoop中数据非结构化的特征，采集来的数据本身就是包含大量冗余信息的。同时也可以将大量冗余的维度信息整合到事实表中，这样可以在冗余维度下灵活地改变问题分析的角度。其次利用Hadoop MapRece强大的并行化处理能力，无论OLAP分析中的维度增加多少，开销并不显着增长。换言之，Hadoop可以支持一个巨大无比的Cube，包含了无数你想到或者想不到的维度，而且每次多维分析，都可以支持成千上百个维度，并不会显着影响分析的性能。
而且目前OLAP存在的最大问题是：业务灵活多变，必然导致业务模型随之经常发生变化，而业务维度和度量一旦发生变化，技术人员需要把整个Cube（多维立方体）重新定义并重新生成，业务人员只能在此Cube上进行多维分析，这样就限制了业务人员快速改变问题分析的角度，从而使所谓的BI系统成为死板的日常报表系统。
3. 一种Hadoop多维分析平台的架构
整个架构由四大部分组成：数据采集模块、数据冗余模块、维度定义模块、并行分 析模块。
数据采集模块采用了Cloudera的Flume，将海量的小日志文件进行高速传输和合并，并能够确保数据的传输安全性。单个collector宕机之后，数据也不会丢失，并能将agent数据自动转移到其他的colllecter处理，不会影响整个采集系统的运行。如图5所示。
数据冗余模块不是必须的，但如果日志数据中没有足够的维度信息，或者需要比较频繁地增加维度，则需要定义数据冗余模块。通过冗余维度定义器定义需要冗余的维度信息和来源（数据库、文件、内存等），并指定扩展方式，将信息写入数据日志中。在海量数据下，数据冗余模块往往成为整个系统的瓶颈，建议使用一些比较快的内存NoSQL来冗余原始数据，并采用尽可能多的节点进行并行冗余；或者也完全可以在Hadoop中执行批量Map，进行数据格式的转化。
维度定义模块是面向业务用户的前端模块，用户通过可视化的定义器从数据日志中定义维度和度量，并能自动生成一种多维分析语言，同时可以使用可视化的分析器通过GUI执行刚刚定义好的多维分析命令。
并行分析模块接受用户提交的多维分析命令，并将通过核心模块将该命令解析为Map-Rece，提交给Hadoop集群之后，生成报表供报表中心展示。
核心模块是将多维分析语言转化为MapRece的解析器，读取用户定义的维度和度量，将用户的多维分析命令翻译成MapRece程序。核心模块的具体逻辑如图6所示。
图6中根据JobConf参数进行Map和Rece类的拼装并不复杂，难点是很多实际问题很难通过一个MapRece Job解决，必须通过多个MapRece Job组成工作流（WorkFlow），这里是最需要根据业务进行定制的部分。图7是一个简单的MapRece工作流的例子。
MapRece的输出一般是统计分析的结果，数据量相较于输入的海量数据会小很多，这样就可以导入传统的数据报表产品中进行展现。
⑹ Bigtable---分布式的结构化数据存储系统
sina
Bigtable 是一个分布式的结构化数据存储系统，它被设计用来处理海量数据：通常是分布在数千台普通服务器上的PB 级的数据。Google 的很多项目使用Bigtable 存储数据，包括Web 索引、GoogleEarth、Google Finance。这些应用对Bigtable 提出的要求差异非常大，无论是在数据量上（从URL到网页到卫星图像）还是在响应速度上（从后端的批量处理到实时数据服务）。
Bigtable 已经实现了下面的几个目标：适用性广泛、可扩展、高性能和高可用性,Bigtable 是一个稀疏的、分布式的、持久化存储的多维度排序Map。
图一：一个存储Web 网页的例子的表的片断。行名是一个反向URL。contents 列族存放的是网页的内容，anchor 列族存放引用该网页的锚链接文本（alex 注：如果不知道HTML 的Anchor，请Google一把）。CNN 的主页被Sports Illustrater和MY-look 的主页引用，因此该行包含了名为“anchor:cnnsi.com”和“anchhor:my.look.ca”的列。每个锚链接只有一个版本（alex 注：注意时间戳标识了列的版本，t9 和t8 分别标识了两个锚链接的版本）；而contents 列则有三个版本，分别由时间戳t3，t5，和t6 标识。
行
Bigtable 通过行关键字的字典顺序来组织数据。表中的每个行都可以动态分区。每个分区叫做一个”Tablet”，Tablet 是数据分布和负载均衡调整的最小单位。
列族
Webtable 有个列族language，language 列族用来存放撰写网页的语言。
我们在language 列族中只使用一个列关键字，用来存放每个网页的语言标识ID。Webtable 中另一个有用的列族是anchor；这个列族的每一个列关键字代表一个锚链接，如图一所示。Anchor 列族的限定词是引用该网页的站点名；Anchor 列族每列的数据项存放的是链接文本。访问控制、磁盘和内存的使用统计都是在列族层面进行的。
时间戳
不同版本的数据通过时间戳来索引。Bigtable 时间戳的类型是64 位整型。
Bigtable 可以给时间戳赋值，用来表示精确到毫秒的“实时”时间；用户程序也可以给时间戳赋值。如果应用程序需要避免数据版本冲突，那么它必须自己生成具有唯一性的时间戳。数据项中，不同版本的数据按照时间戳倒序排序，即最新的数据排在最前面。为了减轻多个版本数据的管理负担，我们对每一个列族配有两个设置参数， Bigtable 通过这两个参数可以对废弃版本的数据自动进行垃圾收集。用户可以指定只保存最后n 个版本的数据，或者只保存“足够新”的版本的数据（比如，只保存最近7 天的内容写入的数据）。
Bigtable支持的其他特性
1、Bigtable 支持单行上的事务处理，利用这个功能，用户可以对存储在一个行关键字下的数据进行原子性的读-更新-写操作。
2、Bigtable 允许把数据项用做整数计数器。
3、Bigtable 允许用户在服务器的地址空间内执行脚本程序
4、Bigtable 可以和MapRece一起使用，MapRece 是Google 开发的大规模并行计算框架。我们已经开发了一些Wrapper 类，通过使用这些Wrapper 类，Bigtable 可以作为MapRece 框架的输入和输出。
Bigtable依赖于google的几项技术。用GFS来存储日志和数据文件；按SSTable文件格式存储数据；用Chubby管理元数据：
Bigtable是建立在其它的几个Google基础构件上的。BigTable 使用Google 的分布式文件系统(GFS)存储日志文件和数据文件。BigTable 集群通常运行在一个共享的机器池中，池中的机器还会运行其它的各种各样的分布式应用程序，BigTable 的进程经常要和其它应用的进程共享机器。BigTable 依赖集群管理系统来调度任务、管理共享的机器上的资源、处理机器的故障、以及监视机器的状态。
BigTable 内部存储数据的文件是Google SSTable 格式的。SSTable 是一个持久化的、排序的、不可更改的Map 结构，而Map 是一个key-value 映射的数据结构，key 和value 的值都是任意的Byte串，从内部看，SSTable 是一系列的数据块（通常每个块的大小是64KB，这个大小是可以配置的）。。SSTable 使用块索引（通常存储在SSTable 的最后）来定位数据块；在打开SSTable的时候，索引被加载到内存。每次查找都可以通过一次磁盘搜索完成：首先使用二分查找法在内存中的索引里找到数据块的位置，然后再从硬盘读取相应的数据块。也可以选择把整个SSTable 都放在内存中，这样就不必访问硬盘了。
BigTable 还依赖一个高可用的、序列化的分布式锁服务组件，叫做Chubby。Chubby有五个活跃副本，同时只有一个主副本提供服务，副本之间用Paxos算法维持一致性，Chubby提供了一个命名空间（包括一些目录和文件），每个目录和文件就是一个锁，Chubby的客户端必须和Chubby保持会话，客户端的会话若过期则会丢失所有的锁。
Bigtable 包括了三个主要的组件：链接到客户程序中的库、一个Master主服务器和多个Tablet片 服务器。
Bigtable会将表（table）进行分片，片（tablet）的大小维持在100-200MB范围，一旦超出范围就将分裂成更小的片，或者合并成更大的片。每个片服务器负责一定量的片，处理对其片的读写请求，以及片的分裂或合并。片服务器可以根据负载随时添加和删除。这里片服务器并不真实存储数据，而相当于一个连接Bigtable和GFS的代理，客户端的一些数据操作都通过片服务器代理间接访问GFS。主服务器负责将片分配给片服务器，监控片服务器的添加和删除，平衡片服务器的负载，处理表和列族的创建等。注意，主服务器不存储任何片，不提供任何数据服务，也不提供片的定位信息。
客户端需要读写数据时，直接与片服务器联系。因为客户端并不需要从主服务器获取片的位置信息，所以大多数客户端从来不需要访问主服务器，主服务器的负载一般很轻。
Master 服务器主要负责以下工作：为Tablet 服务器分配Tablets、检测新加入的或者过期失效的Table 服务器、对Tablet 服务器进行负载均衡、以及对保存在GFS 上的文件进行垃圾收集。除此之外，它还处理对模式的相关修改操作，例如建立表和列族。
我们使用一个三层的、类似B+树的结构存储Tablet 的位置信息。
第一层是一个存储在Chubby 中的文件，它包含了Root Tablet 的位置信息。这个Chubby文件属于Chubby服务的一部分，一旦Chubby不可用，就意味着丢失了root tablet的位置，整个Bigtable也就不可用了。
第二层是root tablet。root tablet其实是元数据表（METADATA table）的第一个分片，它保存着元数据表其它片的位置。root tablet很特别，为了保证树的深度不变，root tablet从不分裂。
第三层是其它的元数据片，它们和root tablet一起组成完整的元数据表。每个元数据片都包含了许多用户片的位置信息。
片的数据最终还是写到GFS里的，片在GFS里的物理形态就是若干个SSTable文件。下图展示了读写操作基本情况。
BigTable和GFS的关系
集群包括主服务器和片服务器，主服务器负责将片分配给片服务器，而具体的数据服务则全权由片服务器负责。但是不要误以为片服务器真的存储了数据（除了内存中memtable的数据），数据的真实位置只有GFS才知道，主服务器将片分配给片服务器的意思应该是，片服务器获取了片的所有SSTable文件名，片服务器通过一些索引机制可以知道所需要的数据在哪个SSTable文件，然后从GFS中读取SSTable文件的数据，这个SSTable文件可能分布在好几台chunkserver上。
一个简化的Bigtable结构图：
结构图以Webtable表为例，表中存储了网易、网络和豆瓣的几个网页。当我们想查找网络贴吧昨天的网页内容，可以向Bigtable发出查询Webtable表的(com..tieba, contents:, yesterday)。
假设客户端没有该缓存，那么Bigtable访问root tablet的片服务器，希望得到该网页所属的片的位置信息在哪个元数据片中。使用 METADATA.Webtable.com..tieba 为行键在root tablet中查找，定位到最后一个比它大的是 METADATA.Webtable.com..www ，于是确定需要的就是元数据表的片A。访问片A的片服务器，继续查找 Webtable.com..tieba ，定位到 Webtable.com..www 是比它大的，确定需要的是Webtable表的片B。访问片B的片服务器，获得数据。
这里需要注意的是，每个片实际都由若干SSTable文件和memtable组成，而且这些SSTable和memtable都是已排序的。这就导致查找片B时，可能需要将所有SSTable和memtable都查找一遍；另外客户端应该不会直接从元数据表获得SSTable的文件名，而只是获得片属于片服务器的信息，通过片服务器为代理访问SSTable。
⑺ 什么是分布式数据存储
什么是分布式存储
分布式存储是一种数据存储技术，它通过网络使用企业中每台机器上的磁盘空间，这些分散的存储资源构成了虚拟存储设备，数据分布存储在企业的各个角落。
分布式存储系统，可在多个独立设备上分发数据。传统的网络存储系统使用集中存储服务器来存储所有数据。存储服务器成为系统性能的瓶颈，也是可靠性和安全性的焦点，无法满足大规模存储应用的需求。分布式网络存储系统采用可扩展的系统结构，使用多个存储服务器共享存储负载，利用位置服务器定位存储信息，不仅提高了系统的可靠性，可用性和访问效率，而且易于扩展。
⑻ 分布式存储和传统存储比较在哪些应用场景比较有优势
1、分布式存储优势
分布式存储可以使生产系统在线运行的情况下进行纵向扩展（Scale-Up）或横向扩展（Scale-Out），且存储系统在扩展后可以达到容量与性能均线性扩展的效果。其具有以下特性：
高性能
分布式存储系统能够将所有存储节点的处理器资源、硬盘资源、网络资源进行整合，将任务切分给多台存储节点，进行并发数据处理，避免了单个硬盘或设备造成的瓶颈，提升整个集群的处理能力。分布式存储系统具有良好的性能扩展能力，可以满足应用程序对存储性能不断增长的要求。
高扩展性
分布式存储系统通过扩展集群存储节点规模从而提高系统存储容量、计算和性能的能力，通过增加和升级服务器硬件，或者指通过增加存储节点数量来提升服务能力。分布式存储系统支持在线增加存储节点，对前端业务透明，系统整体性能与存储节点数量呈线性关系。
高可用性
分布式存储系统同时基于硬件及软件设计了高可用机制，在面对多种异常时（如存储节点宕机、网络中断、硬盘故障、数据损坏等）仍可提供正常服务，提高分布式存储系统硬件的可用性可以通过增加存储节点数量或者采用多种硬件冗余机制保证。分布式存储系统多采用副本机制或纠删码机制保证数据的高可用性，副本机制可以提供较高的数据冗余度，但会降低存储系统有效空间的利用率，纠删码机制可以在保证一定数据冗余度的情况下，大幅提高存储系统的有效空间利用率。
高安全性
分布式存储系统支持可靠的权限控制及互信确认机制，同时采用私有的数据切片及数据编码机制，可以从多重角度保证集群系统不受恶意访问和攻击，保护存储数据不被窃取。
2、分布式存储应用场景
分布式的“四高”特性，使得其在高性能计算、大数据视频云及大数据分析等应用场景中有着广泛的应用。
高性能计算场景
在如气象气候、地质勘探、航空航天、工程计算、材料工程等领域，基于集群的高性能计算，已成为必需的辅助工具。集群系统有极强的伸缩性，可通过在集群中增加或删减节点的方式，在不影响原有应用与计算任务的情况下，随时增加和降低系统的处理能力。根据不同的计算模式与规模，构成集群系统的节点数可以从几个到成千上万个。这些业务对后端的存储系统提出了新的需求，包括统一的存储空间、高效率的文件检索、高带宽的吞吐性能，高可靠的数据安全保障等。
大数据视频云应用场景
随着视频高清技术及超高清技术的普及，视频大数据应用场景，如雪亮工程、平安城市、广电媒资、影视制作、视频网站等领域，对存储设备提出了大容量、高读写性能、高可靠性、低延时及可扩展性等需求。针对这样大规模视频数据应用场景，就需要一个技术先进、性能优越的存储系统作为后端数据存储的支撑者。
大数据分析应用场景
伴随着互联网技术及人工智能的发展，各种基于海量用户/数据/终端的大数据分析及人工智能业务模式不断涌现，同样需要充分考虑存储功能集成度、数据安全性、数据稳定性，系统可扩展性、性能及成本各方面因素。
在数据爆发增长的“数字时代”，软件定义的分布式存储是存储技术高速发展的结晶，并具有着很大的成长空间，必将应用于更广泛的大数据业务场景。
⑼ 在大数量级的数据存储上，比较靠谱的分布式文件存储有哪些
一、 Ceph
Ceph最早起源于Sage就读博士期间的工作、成果于2004年发表，并随后贡献给开源社区。经过多年的发展之后，已得到众多云计算和存储厂商的支持，成为应用最广泛的开源分布式存储平台。
二、 GFS
GFS是google的分布式文件存储系统，是专为存储海量搜索数据而设计的，2003年提出，是闭源的分布式文件系统。适用于大量的顺序读取和顺序追加，如大文件的读写。注重大文件的持续稳定带宽，而不是单次读写的延迟。
三、 HDFS
HDFS(Hadoop Distributed File System)，是一个适合运行在通用硬件(commodity hardware)上的分布式文件系统，是Hadoop的核心子项目，是基于流数据模式访问和处理超大文件的需求而开发的。该系统仿效了谷歌文件系统(GFS)，是GFS的一个简化和开源版本。