面向海量非结构化数据的管理与规划

一、本次活动中从设计思路、存储技术、高可用架构方面探讨了如何对非结构化数据的进行管理和规划，针对企业大数据应用的基础设施建设过程，提出以下建议：

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甚至全球的数据存储，可靠性高很多，但读写速度不比前两个，NoSQL一般不能够跨IDC，同时NoSQL有很多数据库的特性，比如表、联表查询、事务等等的特性，更贴合业务。

三、关于海量非结构化数据的处理方面，会员交流的问题大多关注在如何对非结构化数据进行优化，在非结构化数据“海量”的前提下如何进行压缩、重删，最终实现非结构化数据的利用价值等：

1. 根据业务场景，有的都是大量小文件，文件系统的不同参数对这些会有影响，可以在创建文件系统时进行优化；
2. 数据压缩：一般是在保存数据的时候就进行压缩了，压缩一种是有损压缩（比如业务票据，在保证一定清晰度的前提下可以适当有损压缩），一种是无损压缩，这是一种典型的“时间换空间”的思路，需要根据业务需求判断是否进行压缩。
3. 生命周期：每个业务都有一定的生命周期，建议在规划的时候就规划好生命周期，这样每天晚上批量删除比较一年之前的业务数据，通过这种方式来保持一定时间窗口的数据。
4. 海量非结构化数据不应该用传统备份和恢复方法。传统方法不仅仅备份耗时太长，需要恢复的时间也难以接受，很多情况下即使有备份，恢复的成本也很高，不适合实际应用。建议通过专门针对海量数据进行数据归档的产品来进行数据保护。

具体实施案例：

底层架构采用的是Hadoop，小文件合并是采用Hadoop支持的Sequence File文件格式。 在存储结构上，Sequence File主要由一个Header后跟多条Record组成。每个Record由一系列的二进制key/value组成。我们的文件合并实现中，将key作为小文件名，value作为文件内容。 合并文件后Hadoop 集群中写入的过程主要通过Hadoop提供的API完成。

最后，在做好非结构化数据的管理和存储后，就要考虑如何能够充分利用非结构化数据实现数据挖掘价值。对于非结构化数据的挖掘利用，着重关注以下两个方面：

1. 非结构化数据的清洗：非结构化数据本身就很难被彻底清洗干净，特别是存在海量的多维度性，有很多数据噪声的干扰，这给清洗带来了很大麻烦。而且，清洗过程中，也可能会丢失一些有价值的信息。
2. 非结构化数据的融合分析：在非结构化数据中，不同来源的数据从字段上应该具有互补性，这是进行数据融合的入手点。接下来就是充分利用现有相应大数据平台的计算框架如Hadoop的Map-Reduce 框架构建计算集群，对数据键/值对进行分析计算。

四、针对海量非结构化数据，其管理与优化的难点除了“海量”，还存在数据“异构”的问题，在本次活动中，也围绕了这一难点进行了讨论，会员也对此提供了“逻辑统一、物理分散”的建设思路：

1. 统一访问入口：在统一访问入口处根据客户端提交的应用程序信息返回客户端后续和哪个存储入口进行访问；
2. 各地建立缓存：由于非结构化数据一般比较大，我们建立一个缓存服务器功能，比如业务上传时，将数据保存到缓存服务器，后续业务可以直接从就近的缓存服务器下载，非结构化的数据采用版本号增加的方式进行管理，比如有一批文件中的一个文件发生变化，则只提交数据差就可以；
3. 多租户资源隔离：每个业务系统根据不同的需要进行不同存储资源的使用，隔离资源；
4. 数据声明周期管理：通过梳理业务需求对数据进行生命周期管理，不同的数据在不同生命阶段保存到不同的介质中；

五、非结构化数据的安全性问题也是本次讨论的热点

对于非结构化数据数据的安全性问题，总结了下面几个方面值得关注：

• 隐私保护方面，可以借助如Hive中的Kerberos身份 认证机制来实现如角色的认证、LDAP等安全策略等。
• 访问控制可以分为登录访问控制和数据查询访问控制，通过设定约束阀值检查用户权限。
• 可以按照数据生命周期进行管理，分为热数据、温数据和冷数据，冷数据就不再有修改权限；这样每次备份的就是热数据和一点点需要修改的温数据，冷数据由于具有三份副本，由于不做修改，其实可以满足三副本的数据冗余要求。
• 划分权限和租户管理：
  （1）使用数据平台现有的身份认证模块，如Hadoop的Hive框架可直接使用Kerberos的身份认证机制做用户认证和管理，但是该机制实现的功能较为有限。
  （2）可以在数据处理平台中自行开发基于角色的权限管理模型或动态的权限管理模型，来实现多租户的管理，二次开发工作量比较大。