海量非结构化数据的高效管理1.docx

PAGE 1 海量非结构化数据的高效管理 海量非结构化数据本身有着数据容量庞大（规模达到TB级、PB级甚至EB级 ），数据类型繁多（如流媒体、文本、图片等多种类型），数据时效性高（响应时效要控制在用户可容忍和接受范围）等特点。在大数据环境下，如何能够快速处理格式各异的海量非结构化数据，有着诸多问题亟待解决。 社区最近组织交流“如何对PB级甚至EB级的海量非结构化数据进行有效管理？”，针对前述问题，社区专家和会员提出很多建议方案，以下是社区专家willow的总结分析。 willow，某商业银行系统工程师，专注于银行基础架构设计、系统网络规划与运维管理工作。在虚拟化、容灾备份、自动化运维领域有着丰富的项目实践经验。 一、本次活动中从设计思路、存储技术、高可用架构方面探讨了如何对非结构化数据的进行管理和规划，针对企业大数据应用的基础设施建设过程，提出以下建议： 1.存储选择时的成本比较，从实际业务入手，对数据扩展性要求高、需求变化快的应用，使用分布式存储方式肯定会节省一定的成本。而如果业务追求稳定和性能，且变化不大，从长远上看，使用集中式存储比较合适。 2.在存储设备的选择上是否考虑使用闪存存储，要考虑的因素有很多，以本活动探讨的PB、EB级别的海量非结构化数据为例，数据全部放入闪存中，既不经济也不现实。而如果是将访问量较大的元数据放入闪存中，就可以快速提高应用对非结构化数据的检索效率，进而提升整个集群存储的效能。 3.存储高可用设计方面，单点故障在设计初期也要考虑，分布式文件系统的存储方式，除了要关注存储节点还要关注计算节点的高可用。而对于异构的各单点存储，可以考虑使用如SVC等存储虚拟化网关技术，避免单点存储的存在。 二、在管理海量非结构化数据过程中，处理工具的选型、调优是非常重要的，本活动也分别针对分布式文件系统、NoSQL类数据库、对象存储等这几类在处理非结构化数据过程中常用的工具和会员们进行了详细讨论，下面分别围绕不同的解决方案对本次活动中会员提出的观点和方案进行梳理： 关于NoSQL类数据库的管理与优化： Redis方面的一些优化经验： 数据结构选用方面，考虑需求的同时还需考虑性能因素。例如，不需要set操作或list的push/pop操作的时候，尽可能的使用Hash结构； 合理设计key的过期时间，减少内存占用。 根据自己的环境，合理配置maxmemory及maxmemory-policy，以尽量规避swap拉低性能问题。maxmemory依据持久化策略，建议配置为45%或95%；maxmemory-policy依据key过期情况，建议使用volatile-ttl或allkeys-lru。 设计实用高效命令。如命令合并，避免发送大量小命令；管道命令，避免网络开销；避免使用那些高时间复杂度，降低延迟； 合理配置maxclients，缩短单client等待时间； mongodb方面的一些优化经验： 很类似rdbms。因为索引也是继续b-tree的，基本上传统数据库适用的索引优化都可以用在mongodb上 Hbase方面的一些优化经验： Hbase，从预先分配好region，到rowkey的设置，在到底层配置参数的调整等 关于分布式文件系统管理经验： 元数据管理：重点关注元数据服务器的复制结构和查询策略、元数据服务器的硬件配置（CPU/内存/缓存大小）、元数据服务器处理线程数量等 存储节点性能：重点关注存储节点底层磁盘I/O、系统读写cache大小等。 存储网络性能：关注分布式文件系统中存储网络对数据传输速率的影响。 客户端支持：不同的分布式文件系统对客户端的支持是有差别的，要关注文件系统I/O吞吐是否能够对客户端增加有较好的可扩展性。 replication数；block size；服务线程数；选用合适的调度算法；尽量减少磁盘操作；尽可能降低网络传输数据量； 基于分布式文件系统的考虑 不管是nas还是san 网络文件流的考虑很重要；各个数据节点之间是否考虑做冗余，负载均衡，大并发处理等； 同时，专家也从使用方式和场景上对几种处理海量非结构化数据的技术架构进行了剖析和比较： NAS挂载上和裸磁盘没什么区别，适合快速部署的业务需求。 DFS一般都有相应的接口，你要按照接口来读写，有些DFS支持原生POSIX接口，那么你用起来相当于使用格式化好的磁盘。 对象存储一般不支持POSIX方式，只支持自己的7层接口，比如HTTP，那么你一般是在自己程序里调HTTP接口来读写。 NoSQL一般有自己的官方客户端，你需要用官方提供的客户端/SDK进行读写操作。 从场景上简单说，NAS/DFS一般多用于一个IDC或者内网内的数据存储，比单机的可靠性高同时能保证比较高的读写速度，对象存储一般是跨IDC甚至全球的数据存储，可靠性高很多，