大数据量日志存储

1. 大数据解决方案主要用于存储哪种类型的数据

大数据解决方案主要用于存储二进制类型的数据。

数据还包括了结构化数据和非结构化数据，邮件，Word,图片，音频信息，视频信息等各种类型数据，已经不是以往的关系型数据库可以解决的了。非结构化数据的超大规模和增长，占总数据量的80~90%，比结构化数据增长快10倍到50倍，是传统数据仓库的10倍到50倍。

大数据特点：

海量数据有不同格式，第一种是结构化，我们常见的数据，还有半结据化网页数据，还有非结构化视频音频数据。而且这些数据化他们处理方式是比较大的。数据类型繁多，如网络日志、视频、图片、地理位置信息，等等。

2. 第三章 大数据存储

一，HDFS的基本特征与构架
1.基本特征
（1）大规模数据分布存储能力：以分布式存储能力和良好的可扩展性。（基于大量分布节点上的本地文件系统，构建一个逻辑上具有巨大容量的分布式文件系统，并且整个文件系统的容量可随集群中节点的增加而线性扩展）
（2）高并发访问能力：提供很高的数据访问宽带（高数据吞吐率），并且可以把带宽的大小等比例扩展到集群中的全部节点上
（3）强大的容错能力：（设计理念中硬件故障被视作常态）保证在经常有节点发生硬件故障的情况下正确检测硬件故障，并且能自动从故障中快速恢复，确保数据不丢失（采用多副本数据块形式存储）
（4）顺序式文件访问：（大数据批处理都是大量简单数据记录的顺序处理）对顺序读进行了优化，支持大量数据的快速顺序读出，代价是对于随机的访问负载较高
（5）简单的一致性模型（一次写多次读）：支持大量数据的一次写入，多次读取；不支持已写入数据的更新操作，但允许在文件尾部添加新的数据
（6）数据块存储模式：默认的块大小是64MB。好处：减少元数据的数量，允许这些数据块通过随机方式选择节点，分布存储在不同地方
2.基本框架与工作过程
（1）基本组成结构与文件访问过程
[1]HDFS；一个建立在一组分布式服务器节点的本地文件系统之上的分布式文件系统（采用经典主-从结构）
[2]主控节点NameNode:
1）是一个主服务器，用来管理整个文件系统的命名空间和元数据,以及处理来自外界的文件访问请求
2）保存了文件系统的三中元数据
命名空间：整个分布式文件系统的目录结构
数据块与文件名的映射表
每个数据块副本的位置信息，每一个数据块默认有3个副本
[3]从节点DataNode：
1）用来实际存储和管理文件的数据块
2）为了防止数据丢失，每个数据块默认有3个副本，且3个副本会分别复制在不同节点上，以避免一个节点失效造成一个数据块的彻底丢失
[4]程序访问文件时，实际文件数据流并不会通过NameNode传送，而是从NameNode获得所需访问数据块的存储位置信息后，直接去访问对应的DataNode获取数据
[5]设计好处：
1）可以允许一个文件的数据能同时在不同DataNode上并发访问，提高数据访问的速度
2）减少NameNode的负担，避免使NameNode成为数据访问瓶颈
[6]基本访问过程：
1）首先，用户的应用程序通过HDFS的客户端程序将文件名发送至NameNode
2）NameNode接收到文件名之后，在HDFS目录中检索文件名对应的数据块，再根据数据块信息找到保存数据块的DataNode地址，讲这些地址回送到客户端
3）客户端接收到这些DataNode地址之后，与这些DataNode并行的进行数据传输操作，同时将操作结果的相关日志提交到NameNode
2.数据块
（1）为了提高硬盘的效率，文件系统中最小的数据读写单元是数据块
（2）HDFS数据块的默认大小是64MB，实际部署中，可能会更多
（3）将数据块设置大的原因是减少寻址开销的时间
（4）当应用发起数据传输请求：
[1]NameNode首先检索文件对应的数据块信息，找到数据块对应的DataNode
[2]DataNode根据数据块信息在自身的存储中寻找相应的文件，进而与应用程序之间交换数据
[3]因为检索过程是但进行，所以要增加数据块大小，这样就可以减少寻址的频度和时间开销
3.命名空间
（1）文件命名遵循“目录/子目录/文件”格式
（2）通过命令行或者是API可以创建目录，并且将文件保存在目录中。可以对文件进行创建，删除，重命名操作
（3）命令空间由NameNode管理。所有对命名空间的改动都会被记录
（4）允许用户配置文件在HDFS上保存的副本数量，保存的副本数称作“副本因子”
4.通信协议
（1）采用TCP协议作为底层的支撑协议
（2）应用协议
[1]应用可以向NameNode主动发起TCP连接
[2]应用和NameNode交互协议称为Client协议
[3]NameNode和DataNode交互的协议称为DataNode协议
（3）用户和DataNode的交互是通过发起远程调用（RPC），并由NameNode响应来完成的。另外，NameNode不会主动发起远程过程调用请求
5.客户端：是用户和HDFS通信最常见的渠道，部署的HDFS都会提供客户端
二，HDFS可靠性设计
1.HDFS数据块多副本存储设计
（1）采用了在系统中保存多个副本的方式保存数据，且同一个数据块的多个副本会存放在不同节点上
（2）优点：
[1]采用多副本，可以让客户从不同数据块中读取数据，加快传输速度
[2]HDFS的DataNode之间通过网络传输数据，如果采用多个副本可以判断数据传输是否出错
[3]多副本可以保证某个DataNode失效的情况下，不会丢失数据
2.可靠性的设计实现
（1）安全模式：
[1]HDFS启动时，NameNode进入安全模式
[2]处于安全模式的NameNode不能做任何文本操作，甚至内部的副本创建不允许
[3]NameNode需要和各个DataNode通信，获得其中保存的数据块信息，并对数据块信息进行检查
[4]只有通过了NameNode检查，一个数据块被认为安全。当被认为安全的数据块所占比例达到某个阈值，NameNode退出
（2）SecondaryNmaeNode
[1]使用它来备份NameNode元数据，以便在其失效时能从中恢复出其上的元数据
[2]它充当NameNode的一个副本，本身并不处理任何请求。
[3]作用：周期性保存NameNode的元数据
（3）心跳包和副本重新创建
[1]心跳包：位于HDFS核心的NameNode，通过周期性的活动检查DataNode的活动
[2]检测到DataNode失效，保存在其上的数据不可用。则其上保存的副本需要重新创建这个副本，放到另外可用的地方
（4）数据一致性
[1]采用了数据校验和机制
[2]创建文件时，HDFS会为这个文件生成一个校验和，校验和文件和文件本身保存在同一空间上，
[3]传输数据时会将数据与校验和一起传输，应用收到数据后可以进行校验
（5）租约
[1]防止同一个文件被多个人写入数据
[2]NameNode保证同一个文件只会发放一个允许的租约，可以有效防止出现多人写入的情况
（6）回滚
三，HDFS文件存储组织与读写
1.文件数据的存储组织
（1）NameNode目录结构
[1]借助本地文件系统来保存数据，保存文件夹位置由配置选项（{dfs.name.dir}/{/tmp/dfs/name}）决定
[2]在NameNode的${dfs.name.dir}之下有3个文件夹和1个文件：
1）current目录：
文件VERSION:保存了当前运行的HDFS版本信息
FsImages:是整个系统的空间镜像文件
Edit：EditLog编辑文件
Fstime：上一次检查点时间
2）previous.checkpoint目录：和上一个一致，但是保存的是上一次检查点的内容
3）image目录：旧版本的FsImage存储位置
4）in_use.look:NameNode锁，只在NameNode有效（启动并且能和DataNode正常交互）时存在。
（2）DataNode目录结构
[1]借助本地文件系统来保存数据。保存文件夹位置由配置选项{dfs.data.dir}决定
[2]在其之下有4个子目录和2个文件
1）current目录：已经成功写入的数据块，以及一些系统需要的文件
a)文件VERSION：保存了当前运行的HDFS版本信息
b)subdirXX:当同一目录下文件超过一定限制，新建一个目录，保存多出来的数据块和元数据
2）tmp目录和blockBeingWritten目录：正在写入的数据块，是HDFS系统内部副本创建时引发的写入操作对应的数据块
3）detach目录：用于DataNode升级
4）Storage目录：防止版本不同带来风险
5）in_user.lock文件：DataNode锁。只有在DataNode有效时存在。
（3）CheckPointNode目录结构：和上一个基本一致
2.数据的读写过程
（1）数据读取过程
[1]首先，客户端调用FileSystem实例的open方法，获得这个文件对应的输入流，在HDFS中就是DFSInputStream
[2]构造第一步的输入流时，通过RPC远程调用NameNode可以获得NameNode中此文件对应的数据块保存位置，包括这个文件副本的保存位置（注：在输入流中会按照网络拓扑结构，根据与客户端距离对DataNode进行简单排序）
[3]-[4]获得此输入流后，客户端调用READ方法读取数据。输入流选择最近的DFSInputStream会根据前面的排序结果，选择最近的DataNode建立连接并读取数据。
[5]如果已达到数据块末端，关闭这个DataNode的连接，然后重新查找下一个数据块
[6]客户端调用close，关闭输入流DFSInputStream
（2）数据输入过程
[1]-[2]:客户端调用FileSystem实例的create方法，创建文件。检查后，在NameNode添加文件信息，创建结束之后，HDFS会返回一个输出流DFSDataOutputStream给客户端
[3]调用输出流的write方法向HDFS中对应的文件写入数据。
数据首先会被分包，这些分包会写入一个输出流的内部队列Data队列中，接收完整数据分包，输出流回想NameNode申请保存文件和副本数据块的若干个DataNode
[4]DFSDataOutputStream会（根据网络拓扑结构排序）将数据传输给距离上最短的DataNode，这个节点接收到数据包后传给下一个。数据在各节点之间通过管道流通，减少传输开销
[5]数据节点位于不同机器上，数据需要通过网络发送。（为保证数据节点数据正确，接收到数据的节点要向发送者发送确认包）
[6]执行3-5知道数据全部写完，DFSDataInputStream继续等待知道所有数据写入完毕并确认，调用complete方法通知NameNode文件写入完成
[7]NameNode接收到complete消息之后，等待相应数量的副本写入完毕后，告知客户端
传输过程，当某个DataNode失效，HDFS执行：
1）关闭数据传输的管道
2）将等待ACK队列的数据放到Data队列头部
3）更新正常DataNode中所有数据块版本。当失效的DataNode重启，之前的数据块会因为版本不对被清除
4）在传输管道中删除失效的DataNode,重新建立管道并发送数据包
4.HDFS文件系统操作命令
（1）HDFS启动与关闭
[1]启动过程：
1）进入到NameNode对应节点的Hadoop安装目录
2）执行启动脚本:bin/start-dfs.sh
[2]关闭过程:bin/stop-dfs.sh
（2）文件操作命令格式与注意事项
[1]基本命令格式：
1）bin/hadoop dfs-cmd <args> args-> scheme://authority/path
2）args参数基本格式前面是scheme，authority是机器地址和对应端口
a)本地文件，scheme是file
b)HDFS上文件，scheme是hdfs
（3）文件操作基本格式
[1]hadoop dfs-cat URL [URL ...]
[2]作用：将参数所指示文件内容输出到stdout

3. 日志管理大数据分析，合规就是这么简单

本篇文章将讨论 SIEM 解决方案一个非常重要的因素:集成合规性管理。

现如今，数据泄露的情况越来越严重，企业每天还要面对各种各样的网络攻击，并且合规要求也越来越严格。

Log360 通过提供一系列功能，帮助企业合规管理日志:

预定义的合规性报表:

Log360提供了多个预定义 合规性报表 ，包括PCI DSS、SOX、HIPAA、FISMA、GLBA、ISO 27001、GDPR以及信息安全等级保护（ISLP）合规性报表。您可以根据需要查看或导出报表。

自定义合规性报表:

由于随时可能发布新的法规，而且一些企业也有内部需求，所以Log360允许您通过几个简单的步骤来构建自定义合规性报表。

安全控制的建立:

合规性规则不仅仅是处理审计报表所定义的一组报表，该规则要求您具有严格的安全机制，以帮助您及早发现安全事件，并证明您已经采取了所有必要的措施来保护您的网络免受攻击。

Log360帮助您建立以下安全机制:

事件检测机制:

高级安全事件检测方法可以帮助您在事件的早期阶段进行检测，对于发现的事件都提供了详细的文档，您可以证明您拥有严格的事件检测机制。

数据发现:

合规性策略要求您不断地在您的网络中监视个人身份信息(PII)，并采取措施始终保持其安全性。Log360的自动数据发现功能可以帮助您做到这一点，主页也提供了关于所有已发现数据的必要信息。

详细报告:

Log360记录所有事件调查的详细搜索报告，可以很方便的以您喜欢的格式导出。

事件管理 :

事件管理记录可以帮助您证明您在处理所有安全事件时都尽职尽责。

安全日志归档:

大多数合规性策略都要求您在指定的最短时间内安全地归档日志，因为将来的调查可能需要这些日志。

Log360提供了灵活的归档选项，使您能够以自定义的间隔自动归档日志，并根据需要存储日志。使用MD5校验对存档进行安全加密，MD5是文件计算唯一的哈希值。

如果以任何方式修改存档文件，那么该值也会随之变化，您可以使用它来证明它们没有被篡改。历史日志导入功能还允许您根据需要导入和搜索归档日志。

Log360是一个完整的SIEM解决方案，它帮助企业满足各种审计、安全和合规性需求，并展示了Log360如何凭借其强大的SIEM功能在竞争对手中脱颖而出。

点击下方了解更多，可以了解Log360更多功能！

4. 大数据存储与应用特点及技术路线分析

大数据存储与应用特点及技术路线分析

大数据时代，数据呈爆炸式增长。从存储服务的发展趋势来看，一方面，对数据的存储量的需求越来越大；另一方面，对数据的有效管理提出了更高的要求。大数据对存储设备的容量、读写性能、可靠性、扩展性等都提出了更高的要求，需要充分考虑功能集成度、数据安全性、数据稳定性，系统可扩展性、性能及成本各方面因素。

大数据存储与应用的特点分析

“大数据”是由数量巨大、结构复杂、类型众多数据构成的数据集合，是基于云计算的数据处理与应用模式，通过数据的整合共享，交叉复用形成的智力资源和知识服务能力。其常见特点可以概括为3V:Volume、Velocity、Variety(规模大、速度快、多样性)。

大数据具有数据规模大(Volume)且增长速度快的特性，其数据规模已经从PB级别增长到EB级别，并且仍在不断地根据实际应用的需求和企业的再发展继续扩容，飞速向着ZB(ZETA-BYTE)的规模进军。以国内最大的电子商务企业淘宝为例，根据淘宝网的数据显示，至2011年底，淘宝网最高单日独立用户访问量超过1.2亿人，比2010年同期增长120%,注册用户数量超过4亿，在线商品数量达到8亿，页面浏览量达到20亿规模，淘宝网每天产生4亿条产品信息，每天活跃数据量已经超过50TB.所以大数据的存储或者处理系统不仅能够满足当前数据规模需求，更需要有很强的可扩展性以满足快速增长的需求。

(1)大数据的存储及处理不仅在于规模之大，更加要求其传输及处理的响应速度快(Velocity)。

相对于以往较小规模的数据处理，在数据中心处理大规模数据时，需要服务集群有很高的吞吐量才能够让巨量的数据在应用开发人员“可接受”的时间内完成任务。这不仅是对于各种应用层面的计算性能要求，更加是对大数据存储管理系统的读写吞吐量的要求。例如个人用户在网站选购自己感兴趣的货物，网站则根据用户的购买或者浏览网页行为实时进行相关广告的推荐，这需要应用的实时反馈;又例如电子商务网站的数据分析师根据购物者在当季搜索较为热门的关键词，为商家提供推荐的货物关键字，面对每日上亿的访问记录要求机器学习算法在几天内给出较为准确的推荐，否则就丢失了其失效性；更或者是出租车行驶在城市的道路上，通过GPS反馈的信息及监控设备实时路况信息，大数据处理系统需要不断地给出较为便捷路径的选择。这些都要求大数据的应用层可以最快的速度，最高的带宽从存储介质中获得相关海量的数据。另外一方面，海量数据存储管理系统与传统的数据库管理系统，或者基于磁带的备份系统之间也在发生数据交换，虽然这种交换实时性不高可以离线完成，但是由于数据规模的庞大，较低的数据传输带宽也会降低数据传输的效率，而造成数据迁移瓶颈。因此大数据的存储与处理的速度或是带宽是其性能上的重要指标。

(2)大数据由于其来源的不同，具有数据多样性的特点。

所谓多样性，一是指数据结构化程度，二是指存储格式，三是存储介质多样性。对于传统的数据库，其存储的数据都是结构化数据，格式规整，相反大数据来源于日志、历史数据、用户行为记录等等，有的是结构化数据，而更多的是半结构化或者非结构化数据，这也正是传统数据库存储技术无法适应大数据存储的重要原因之一。所谓存储格式，也正是由于其数据来源不同，应用算法繁多，数据结构化程度不同，其格式也多种多样。例如有的是以文本文件格式存储，有的则是网页文件，有的是一些被序列化后的比特流文件等等。所谓存储介质多样性是指硬件的兼容，大数据应用需要满足不同的响应速度需求，因此其数据管理提倡分层管理机制，例如较为实时或者流数据的响应可以直接从内存或者Flash(SSD)中存取，而离线的批处理可以建立在带有多块磁盘的存储服务器上，有的可以存放在传统的SAN或者NAS网络存储设备上，而备份数据甚至可以存放在磁带机上。因而大数据的存储或者处理系统必须对多种数据及软硬件平台有较好的兼容性来适应各种应用算法或者数据提取转换与加载(ETL)。

大数据存储技术路线最典型的共有三种：

第一种是采用MPP架构的新型数据库集群，重点面向行业大数据，采用Shared Nothing架构，通过列存储、粗粒度索引等多项大数据处理技术，再结合MPP架构高效的分布式计算模式，完成对分析类应用的支撑，运行环境多为低成本 PC Server，具有高性能和高扩展性的特点，在企业分析类应用领域获得极其广泛的应用。

这类MPP产品可以有效支撑PB级别的结构化数据分析，这是传统数据库技术无法胜任的。对于企业新一代的数据仓库和结构化数据分析，目前最佳选择是MPP数据库。

第二种是基于Hadoop的技术扩展和封装，围绕Hadoop衍生出相关的大数据技术，应对传统关系型数据库较难处理的数据和场景，例如针对非结构化数据的存储和计算等，充分利用Hadoop开源的优势，伴随相关技术的不断进步，其应用场景也将逐步扩大，目前最为典型的应用场景就是通过扩展和封装 Hadoop来实现对互联网大数据存储、分析的支撑。这里面有几十种NoSQL技术，也在进一步的细分。对于非结构、半结构化数据处理、复杂的ETL流程、复杂的数据挖掘和计算模型，Hadoop平台更擅长。

第三种是大数据一体机，这是一种专为大数据的分析处理而设计的软、硬件结合的产品，由一组集成的服务器、存储设备、操作系统、数据库管理系统以及为数据查询、处理、分析用途而特别预先安装及优化的软件组成，高性能大数据一体机具有良好的稳定性和纵向扩展性。

以上是小编为大家分享的关于大数据存储与应用特点及技术路线分析的相关内容，更多信息可以关注环球青藤分享更多干货

5. ElasticSearch性能优化实践(JVM调优+ES调优)

近一年内对公司的 ELK 日志系统做过性能优化，也对 SkyWalking 使用的 ES 存储进行过性能优化，在此做一些总结。本篇主要是讲 ES 在 ELK 架构中作为日志存储时的性能优化方案。

随着接入ELK的应用越来越多， 每日新增索引约 230 个，新增 document 约 3000万到 5000万 。

每日上午和下午是日志上传高峰期，在 Kibana 上查看日志，发现问题：
(1) 日志会有 5-40 分钟的延迟
(2) 有很多日志丢失，无法查到判羡

数据先是存放在 ES 的内存 buffer，然后执行 refresh 操作写入到操作系统的内存缓存 os cache，此后数据就可以被搜索到。

所以，日志延迟可能是我们的数据积压在 buffer 中没有进入 os cache 。

查看日志发现很多 write 拒绝执行的情况

从日志中可以看出 ES 的 write 线程池已经满负荷，执行任务的线程已经达到最大16个线程，而200容量的队列也已经放不下新的task。

查看线程池的情况也可以看出 write 线程池有很多写入的任务

所以我们需要优化 ES 的 write 的性能。

ES 的优化悔侍分为很多方面，我们要根据使用场景考虑对 ES 的要求。

根据个人实践经验，列举三种不同场景下的特点 ：

这三类场景的特点如下：

关于实时性

可以从三方面进行优化：JVM性能调优、ES性能调优、控制数据来源

可以从三方面进行优化：JVM 性能调优、ES 性能调优、控制数据来源

第一步是 JVM 调优。
因为 ES 是依赖于 JVM 运行，没有合理的设置 JVM 参数，将浪费资源，甚至导致 ES 很容易 OOM 而崩溃。

(1) 查看 GC 日志

(2) 使用 jstat 看下每秒的 GC 情况

用下面几种方式都可查看新、老年代内存大小
(1) 使用 jstat -gc pid 查看 Eden 区、老年代空间大小
(2) 使用 jmap -heap pid 查看 Eden 区、老年代空间大小
(3) 查看 GC 日志中的 GC 明细

上面的几种方式都查询出，新生代总内存约1081M，即1G左右；老年代总内存为19864000K，约19G。新、老比例约1:19，出乎意料。

这真是一个容易踩坑的地方。
如果没有显示设置新生代大小，JVM 在使用 CMS 收集器时会自动调参，新生代的大小在没有设置的情况下是通过计算得出的，其大小可能与 NewRatio 的默认配置没什么关系而与 ParallelGCThreads 的配置有一定的碧冲吵关系。

所以： 新生代大小有不确定性，最好配置 JVM 参数 -XX:NewSize、-XX:MaxNewSize 或者 -xmn ，免得遇到一些奇怪的 GC，让人措手不及。

新生代过小，老年代过大的影响

32G 的内存，分配 20G 给堆内存是不妥当的，所以调整为总内存的50%，即16G。
修改 elasticsearch 的 jvm.options 文件

设置要求:

因为指定新生代空间大小，导致 JVM 自动调参只分配了 1G 内存给新生代。

修改 elasticsearch 的 jvm.options 文件，加上

老年代则自动分配 16G-8G=8G 内存，新生代老年代的比例为 1:1。修改后每次 Young GC 频率更低，且每次 GC 后只有少数数据会进入老年代。

ES默认使用的垃圾回收器是：老年代（CMS）+ 新生代（ParNew）。如果是JDK1.9，ES 默认使用G1垃圾回收器。

因为使用的是 JDK1.8，所以并未切换垃圾回收器。后续如果再有性能问题再切换G1垃圾回收器，测试是否有更好的性能。

优化前

每秒打印一次 GC 数据。可以看出，年轻代增长速度很快，几秒钟年轻代就满了，导致 Young GC 触发很频繁，几秒钟就会触发一次。而每次 Young GC 很大可能有存活对象进入老年代，而且，存活对象多的时候(看上图中第一个红框中的old gc数据)，有(51.44-51.08)/100 * 19000M = 约68M。每次进入老年代的对象较多，加上频繁的 Young GC，会导致新老年代的分代模式失去了作用，相当于老年代取代了新生代来存放近期内生成的对象。当老年代满了，触发 Full GC，存活的对象也会很多，因为这些对象很可能还是近期加入的，还存活着，所以一次 Full GC 回收对象不多。而这会恶性循环，老年代很快又满了，又 Full GC，又残留一大部分存活的，又很容易满了，所以导致一直频繁 Full GC。

优化后

每秒打印一次 GC 数据。可以看出，新生代增长速度慢了许多，至少要60秒才会满，如上图红框中数据，进入老年代的对象约(15.68-15.60)/100 * 10000 = 8M，非常的少。所以要很久才会触发一次 Full GC 。而且等到 Full GC 时，老年代里很多对象都是存活了很久的，一般都是不会被引用，所以很大一部分会被回收掉，留一个比较干净的老年代空间，可以继续放很多对象。

ES 启动后，运行14个小时

优化前

Young GC 每次的时间是不长的，从上面监控数据中可以看出每次GC时长 1467.995/27276 约等于 0.05秒。那一秒钟有多少时间实在处理Young GC ? 计算公式：1467秒/ (60秒×60分 14小时）= 约0.028秒，也就是100秒中就有2.8秒在Young GC，也就是有2.8S的停顿，这对性能还是有很大消耗的。同时也可以算出多久一次Young GC， 方程是： 60秒×60分*14小时/ 27276次 = 1次/X秒，计算得出X = 0.54，也就是0.54秒就会有一次Young GC，可见 Young GC 频率非常频繁。

优化后

Young GC 次数只有修改前的十分之一，Young GC 时间也是约八分之一。Full GC 的次数也是只有原来的八分之一，GC 时间大约是四分之一。

GC 对系统的影响大大降低，性能已经得到很大的提升。

上面已经分析过ES作为日志存储时的特性是：高并发写、读少、接受30秒内的延时、可容忍部分日志数据丢失。
下面我们针对这些特性对ES进行调优。

本人整理了一下数据写入的底层原理

refresh
ES 接收数据请求时先存入 ES 的内存中，默认每隔一秒会从内存 buffer 中将数据写入操作系统缓存 os cache，这个过程叫做 refresh；

到了 os cache 数据就能被搜索到（所以我们才说 ES 是近实时的，因为1s 的延迟后执行 refresh 便可让数据被搜索到）

fsync
translog 会每隔5秒或者在一个变更请求完成之后执行一次 fsync 操作，将 translog 从缓存刷入磁盘，这个操作比较耗时，如果对数据一致性要求不是跟高时建议将索引改为异步，如果节点宕机时会有5秒数据丢失;

flush
ES 默认每隔30分钟会将 os cache 中的数据刷入磁盘同时清空 translog 日志文件，这个过程叫做 flush。

merge

ES 的一个 index 由多个 shard 组成，而一个 shard 其实就是一个 Lucene 的 index ，它又由多个 segment 组成，且 Lucene 会不断地把一些小的 segment 合并成一个大的 segment ，这个过程被称为 段merge 。执行索引操作时， ES会先生成小的segment ，ES 有离线的逻辑对小的 segment 进行合并，优化查询性能。但是合并过程中会消耗较多磁盘 IO，会影响查询性能。

为了保证不丢失数据，就要保护 translog 文件的安全:

该方式提高数据安全性的同时， 降低了一点性能.

==> 频繁地执行 fsync 操作, 可能会产生阻塞导致部分操作耗时较久. 如果允许部分数据丢失, 可设置异步刷新 translog 来提高效率，还有降低 flush 的阀值，优化如下：

写入 Lucene 的数据，并不是实时可搜索的，ES 必须通过 refresh 的过程把内存中的数据转换成 Lucene 的完整 segment 后，才可以被搜索。

默认1秒后，写入的数据可以很快被查询到，但势必会产生大量的 segment，检索性能会受到影响。所以，加大时长可以降低系统开销。对于日志搜索来说，实时性要求不是那么高，设置为5秒或者10s；对于SkyWalking，实时性要求更低一些，我们可以设置为30s。

设置如下：

index.merge.scheler.max_thread_count 控制并发的 merge 线程数，如果存储是并发性能较好的 SSD，可以用系统默认的 max(1, min(4, availableProcessors / 2))，当节点配置的 cpu 核数较高时，merge 占用的资源可能会偏高，影响集群的性能，普通磁盘的话设为1，发生磁盘 IO 堵塞。设置max_thread_count 后，会有 max_thread_count + 2 个线程同时进行磁盘操作，也就是设置为 1 允许3个线程。

设置如下：

该方式可对已经生成的索引做修改，但是对于后续新建的索引不生效，所以我们可以制作 ES 模板，新建的索引按模板创建索引。

因为我们的业务日志是按天维度创建索引，索引名称示例：user-service-prod-2020.12.12，所以用通配符 202 ..*匹配对应要创建的业务日志索引。

前文已经提到过，write 线程池满负荷，导致拒绝任务，而有的数据无法写入。

而经过上面的优化后，拒绝的情况少了很多，但是还是有拒绝任务的情况。

所以我们还需要优化write线程池。

从 prometheus 监控中可以看到线程池的情况：

为了更直观看到ES线程池的运行情况，我们安装了 elasticsearch_exporter 收集 ES 的指标数据到 prometheus，再通过 grafana 进行查看。

经过上面的各种优化，拒绝的数据量少了很多，但是还是存在拒绝的情况，如下图：

write 线程池如何设置：

参考： ElasticSearch线程池

write 线程池采用 fixed 类型的线程池，也就是核心线程数与最大线程数值相同。线程数默认等于 cpu 核数，可设置的最大值只能是 cpu 核数加1，也就是16核CPU，能设置的线程数最大值为17。

优化的方案：

config/elasticsearch.yml文件增加配置

优化后效果

Swap 交换分区 :

参考： ElasticSearch官方解释为什么要禁用交换内存

有三种方式可以实现 ES 不使用Swap分区

执行命令

可以临时禁用 Swap 内存，但是操作系统重启后失效

执行下列命令

正常情况下不会使用 Swap，除非紧急情况下才会 Swap。

config/elasticsearch.yml 文件增加配置

分片

索引的大小取决于分片与段的大小，分片过小，可能导致段过小，进而导致开销增加；分片过大可能导致分片频繁 Merge，产生大量 IO 操作，影响写入性能。

因为我们每个索引的大小在15G以下，而默认是5个分片，没有必要这么多，所以调整为3个。

分片的设置我们也可以配置在索引模板。

副本数

减少集群副本分片数，过多副本会导致 ES 内部写扩大。副本数默认为1，如果某索引所在的1个节点宕机，拥有副本的另一台机器拥有索引备份数据，可以让索引数据正常使用。但是数据写入副本会影响写入性能。对于日志数据，有1个副本即可。对于大数据量的索引，可以设置副本数为0，减少对性能的影响。

分片的设置我们也可以配置在索引模板。

有的应用1天生成10G日志，而一般的应用只有几百到1G。一天生成10G日志一般是因为部分应用日志使用不当，很多大数量的日志可以不打，比如大数据量的列表查询接口、报表数据、debug 级别日志等数据是不用上传到日志服务器，这些 即影响日志存储的性能，更影响应用自身性能 。

优化后的两周内ELK性能良好，没有使用上的问题：

参考

6. 如何对大数据量日志表做分析

对大数据量日志表做分析。

1. 内容的分析的话就只能借助软件比对分析，

2. 对标题分析的话就可以直接通过程序查找。

3. 最后办法就是人工一个个排查了。

   
   

7. 大数据中的日志数据包括哪些

日志数据的类型包括：1.错误日志(errorlog)；2.慢查询日志(slow query log) ；3.一般查询日志(general log)；4.二进制日志(binlog)；5.中继日志(relay log)；。
日志一般分成Undo与Redo：Undo一般用于事务的取消与回滚，记录的是数据被修改前的值；Redo一般用于恢复已确认但未写入数据库的数据，记录的是数据修改后的值。例如：数据库忽然断电重启，数据库启动时一般要做一致性检查，会把已写到Redo的数据但未写入数据库的数据重做一遍。
大数据以容量大、类型多、存取速度快、应用价值高为主要特征的数据集合，最早应用于IT行业，目前正快速发展为对数量巨大、来源分散、格式多样的数据进行采集、存储和关联分析，从中发现新知识、创造新价值、提升新能力的新一代信息技术和服务业态。大数据必须采用分布式架构，对海量数据进行分布式数据挖掘，因此必须依托云计算的分布式处理、分布式数据库和云存储、虚拟化技术。

8. 态势感知，懂的人不用解释，现在对于态势感知更多的是信息网络的安全态势感知，

大数据时代，除在信息网络的安全方面外，在无人机、无人驾驶、气象分析、军事、交通轨道等等方面，态势感知的应用研究日益广泛和必要！
一般来说，态势感知在大规模系统环境中，对能够引起系统状态发生变化的安全要素进行获取、理解、显示以及预测未来的发展趋势。联合作战、网络中心战的提出,推动了态势感知的产生和不断发展,作为实现态势感知的重要平台和物质基础,态势图对数据和信息复杂的需求和特性构成了突出的大数据问题.从大数据的高度思考,解决态势感知面临的信息处理难题,是研究联合作战态势感知的重要方法.通过分析联合作战态势感知的数据类型、结构和特点,得出态势感知面临着大数据挑战的结论.初步探讨了可能需要解决的问题和前沿信息技术的应用需求,最后对关键数据和信息处理技术进行了研究.该研究对于“大数据”在军事信息处理和数据化决策等领域的研究具有重要探索价值。
相关参考（摘录网上）：
1 引言

随着计算机和通信技术的迅速发展， 计算机网络的应用越来越广泛， 其规模越来越庞大， 多层面的网络安全威胁和安全风险也在不断增加， 网络病毒、 Dos/DDos攻击等构成的威胁和损失越来越大， 网络攻击行为向着分布化、 规模化、 复杂化等趋势发展， 仅仅依靠防火墙、 入侵检测、 防病毒、 访问控制等单一的网络安全防护技术， 已不能满足网络安全的需求， 迫切需要新的技术， 及时发现网络中的异常事件， 实时掌握网络安全状况， 将之前很多时候亡羊补牢的事中、 事后处理，转向事前自动评估预测， 降低网络安全风险， 提高网络安全防护能力。
网络安全态势感知技术能够综合各方面的安全因素， 从整体上动态反映网络安全状况， 并对网络安全的发展趋势进行预测和预警。 大数据技术特有的海量存储、 并行计算、 高效查询等特点， 为大规模网络安全态势感知技术的突破创造了机遇， 借助大数据分析， 对成千上万的网络日志等信息进行自动分析处理与深度挖掘， 对网络的安全状态进行分析评价， 感知网络中的异常事件与整体安全态势。
2 网络安全态势相关概念
2.1 网络态势感知
态势感知（Situation Awareness， SA） 的概念是1988年Endsley提出的， 态势感知是在一定时间和空间内对环境因素的获取， 理解和对未来短期的预测。 整个态势感知过程可由图1所示的三级模型直观地表示出来。

所谓网络态势是指由各种网络设备运行状况、 网络行为以及用户行为等因素所构成的整个网络当前状态和变化趋势。
网络态势感知（Cyberspace Situation Awareness，CSA） 是1999年Tim Bass首次提出的， 网络态势感知是在大规模网络环境中， 对能够引起网络态势发生变化的安全要素进行获取、 理解、 显示以及预测最近的发展趋势拦谈。
态势是一种状态、 一种趋势， 是整体和全局的概念， 任何单一的情况或状态都不能称之为态势。 因此对态势的理解特别强调环境性、 动态性和整体性， 环境性是指态势感知的应用环境是在一个较大的范围内具有一定规模的网络； 动态性是态势随时间不断变化， 态势信息不仅包括过去和当前的状态， 还要对未来的趋势做出预测； 整体性是态势各实体间相互关系的体现，某些网络实体状态发生变化， 会影山睁响到其他网络实体的状态， 进而影响整个网络的态势。
2.2 网络安全态势感知
网络安全态势感知就是利用数据融合、 数据挖掘、智能分析和可视化等技术， 直观显示网络环境的实时安全状况， 为网络安全提供保障。 借助网络安全态势感知， 网络监管人员可以及时了解网络的状态、 受攻击情况、 攻击来源以及哪些服务易受到攻击等情况， 对发起攻击的网络采取措施； 网络用户可以清楚地掌握所在网络的安全状态和趋势， 做好相应的防范准备， 避免和减少网络中病毒和恶意攻击带来的损失； 应急响应组织也可以从网 络安全态势中了解所服务网 络的安全状况和发展趋势， 为 制定有预见性的应急预案提供基础。
3 网络安全态势感知相关技术
对于大规模网络而言， 一方面网络节点众多、 分支复杂、 数据流量大， 存在多种异构网络环境和应用平台； 另一方面网络攻击技术和手段呈平台化、 集成化和自 动化的发展趋势， 网络攻击具有更强的隐蔽性和更长的潜伏时间， 网络威胁不断增多且造成的损失不断增逗衡岁大。 为了实时、 准确地显示整个网络安全态势状况， 检测出潜在、 恶意的攻击行为， 网络安全态势感知要在对网络资源进行要素采集的基础上， 通过数据预处理、 网络安全态势特征提取、 态势评估、 态势预测和态势展示等过程来完成， 这其中涉及许多相关的技术问题， 主要包括数据融合技术、 数据挖掘技术、 特征提取技术、 态势预测技术和可视化技术等。
3.1 数据融合技术
由于网络空间态势感知的数据来自众多的网络设备， 其数据格式、 数据内容、 数据质量千差万别， 存储形式各异， 表达的语义也不尽相同。 如果能够将这些使用不同途径、 来源于不同网络位置、 具有不同格式的数据进行预处理， 并在此基础上进行归一化融合操作，就可以为网络安全态势感知提供更为全面、 精准的数据源， 从而得到更为准确的网络态势。 数据融合技术是一个多级、 多层面的数据处理过程， 主要完成对来自网络中具有相似或不同特征模式的多源信息进行互补集成， 完成对数据的自动监测、 关联、 相关、 估计及组合等处理， 从而得到更为准确、 可靠的结论。 数据融合按信息抽象程度可分为从低到高的三个层次： 数据级融合、 特征级融合和决策级融合， 其中特征级融合和决策级融合在态势感知中具有较为广泛的应用。
3.2 数据挖掘技术
网络安全态势感知将采集的大量网络设备的数据经过数据融合处理后， 转化为格式统一的数据单元。这些数据单元数量庞大， 携带的信息众多， 有用信息与无用信息鱼龙混杂， 难以辨识。 要掌握相对准确、 实时的网络安全态势， 必须剔除干扰信息。 数据挖掘就是指从大量的数据中挖掘出有用的信息， 即从大量的、 不完全的、 有噪声的、 模糊的、 随机的实际应用数据中发现隐含的、 规律的、 事先未知的， 但又有潜在用处的并且最终可理解的信息和知识的非平凡过程（ NontrivialProcess） [1 ]。 数据挖掘可分为描述性挖掘和预测性挖掘， 描述性挖掘用于刻画数据库中数据的一般特性； 预测性挖掘在当前数据上进行推断， 并加以预测。 数据挖掘方法主要有： 关联分析法、 序列模式分析法、 分类分析法和聚类分析法。 关联分析法用于挖掘数据之间的联系； 序列模式分析法侧重于分析数据间的因果关系；分类分析法通过对预先定义好的类建立分析模型， 对数据进行分类， 常用的模型有决策树模型、 贝叶斯分类模型、 神经网络模型等； 聚类分析不依赖预先定义好的类， 它的划分是未知的， 常用的方法有模糊聚类法、 动态聚类法、 基于密度的方法等。
3.3 特征提取技术
网络安全态势特征提取技术是通过一系列数学方法处理， 将大规模网络安全信息归并融合成一组或者几组在一定值域范围内的数值， 这些数值具有表现网络实时运行状况的一系列特征， 用以反映网络安全状况和受威胁程度等情况。 网络安全态势特征提取是网络安全态势评估和预测的基础， 对整个态势评估和预测有着重要的影响， 网络安全态势特征提取方法主要有层次分析法、 模糊层次分析法、 德尔菲法和综合分析法。
3.4 态势预测技术
网络安全态势预测就是根据网络运行状况发展变化的实际数据和历史资料， 运用科学的理论、 方法和各种经验、 判断、 知识去推测、 估计、 分析其在未来一定时期内可能的变化情况， 是网络安全态势感知的一个重要组成部分。 网络在不同时刻的安全态势彼此相关， 安全态势的变化有一定的内部规律， 这种规律可以预测网络在将来时刻的安全态势， 从而可以有预见性地进行安全策略的配置， 实现动态的网络安全管理， 预防大规模网络安全事件的发生。 网络安全态势预测方法主要有神经网络预测法、 时间序列预测法、 基于灰色理论预测法。
3.5 可视化技术
网络安全态势生成是依据大量数据的分析结果来显示当前状态和未来趋势， 而通过传统的文本或简单图形表示， 使得寻找有用、 关键的信息非常困难。 可视化技术是利用计算机图形学和图像处理技术， 将数据转换成图形或图像在屏幕上显示出来， 并进行交互处理的理论、 方法和技术。 它涉及计算机图形学、 图像处理、 计算机视觉、 计算机辅助设计等多个领域。 目前已有很多研究将可视化技术和可视化工具应用于态势感知领域， 在网络安全态势感知的每一个阶段都充分利用可视化方法， 将网络安全态势合并为连贯的网络安全态势图， 快速发现网络安全威胁， 直观把握网络安全状况。
4 基于多源日志的网络安全态势感知
随着网 络规模的 扩大以及网 络攻击复杂度的增加， 入侵检测、 防火墙、 防病毒、 安全审计等众多的安全设备在网络中得到广泛的应用， 虽然这些安全设备对网络安全发挥了一定的作用， 但存在着很大的局限，主要表现在： 一是各安全设备的海量报警和日志， 语义级别低， 冗余度高， 占用存储空间大， 且存在大量的误报， 导致真实报警信息被淹没。 二是各安全设备大多功能单一， 产生的报警信息格式各不相同， 难以进行综合分析整理， 无法实现信息共享和数据交互， 致使各安全设备的总体防护效能无法得以充分的发挥。 三是各安全设备的处理结果仅能单一体现网络某方面的运行状况， 难以提供全面直观的网络整体安全状况和趋势信息。 为了有效克服这些网络安全管理的局限， 我们提出了基于多源日志的网络安全态势感知。
4.1 基于多源日志的网络安全态势感知要素获取
基于多源日志的网络安全态势感知是对部署在网络中的多种安全设备提供的日志信息进行提取、 分析和处理， 实现对网络态势状况进行实时监控， 对潜在的、恶意的网络攻击行为进行识别和预警， 充分发挥各安全设备的整体效能， 提高网络安全管理能力。
基于多源日志的网络安全态势感知主要采集网络入口处防火墙日志、 入侵检测日志， 网络中关键主机日志以及主机漏洞信息， 通过融合分析这些来自不同设备的日志信息， 全面深刻地挖掘出真实有效的网络安全态势相关信息， 与仅基于单一日志源分析网络的安全态
势相比， 可以提高网络安全态势的全面性和准确性。
4.2 利用大数据进行多源日志分析处理
基于多源日志的网络安全态势感知采集了多种安全设备上以多样的检测方式和事件报告机制生成的海量数据， 而这些原始的日 志信息存在海量、 冗余和错误等缺陷， 不能作为态势感知的直接信息来源， 必须进行关联分析和数据融合等处理。 采用什么样的技术才能快速分析处理这些海量且格式多样的数据？
大数据的出现， 扩展了计算和存储资源， 大数据自身拥有的Variety支持多类型数据格式、 Volume大数据量存储、Velocity快速处理三大特征， 恰巧是基于多源日志的网络安全态势感知分析处理所需要的。 大数据的多类型数据格式， 可以使网络安全态势感知获取更多类型的日志数据， 包括网络与安全设备的日志、 网络运行情况信息、 业务与应用的日志记录等； 大数据的大数据量存储正是海量日志存储与处理所需要的； 大数据的快速处理为高速网络流量的深度安全分析提供了技术支持， 为高智能模型算法提供计算资源。 因此， 我们利用大数据所提供的基础平台和大数据量处理的技术支撑， 进行网络安全态势的分析处理。
关联分析。 网络中的防火墙日志和入侵检测日志都是对进入网络的安全事件的流量的刻画， 针对某一个可能的攻击事件， 会产生大量的日志和相关报警记录，这些记录存在着很多的冗余和关联， 因此首先要对得到的原始日志进行单源上的关联分析， 把海量的原始日志转换为直观的、 能够为人所理解的、 可能对网络造成危害的安全事件。 基于多源日志的网络安全态势感知采用基于相似度的报警关联， 可以较好地控制关联后的报警数量， 有利于减少复杂度。 其处理过程是： 首先提取报警日志中的主要属性， 形成原始报警； 再通过重复报警聚合， 生成聚合报警； 对聚合报警的各个属性定义相似度的计算方法， 并分配权重； 计算两个聚合报警的相似度， 通过与相似度阀值的比较， 来决定是否对聚合报警进行超报警； 最终输出属于同一类报警的地址范围和报警信息， 生成安全事件。
融合分析。 多源日志存在冗余性、 互补性等特点，态势感知借助数据融合技术， 能够使得多个数据源之间取长补短， 从而为感知过程提供保障， 以便更准确地生成安全态势。 经过单源日志报警关联过程， 分别得到各自的安全事件。 而对于来自防火墙和入侵检测日志的的多源安全事件， 采用D-S证据理论（由Dempster于1967年提出， 后由Shafer于1976年加以推广和发展而得名） 方法进行融合判别， 对安全事件的可信度进行评估， 进一步提高准确率， 减少误报。 D-S证据理论应用到安全事件融合的基本思路： 首先研究一种切实可行的初始信任分配方法， 对防火墙和入侵检测分配信息度函数； 然后通过D-S的合成规则， 得到融合之后的安全事件的可信度。
态势要素分析。 通过对网络入口处安全设备日 志的安全分析， 得到的只是进入目 标网络的可能的攻击信息， 而真正对网络安全状况产生决定性影响的安全事件， 则需要通过综合分析攻击知识库和具体的网络环境进行最终确认。 主要分为三个步骤： 一是通过对大量网络攻击实例的研究， 得到可用的攻击知识库， 主要包括各种网络攻击的原理、 特点， 以及它们的作用环境等； 二是分析关键主机上存在的系统漏洞和承载的服务的可能漏洞， 建立当前网络环境的漏洞知识库， 分析当前网络环境的拓扑结构、 性能指标等， 得到网络环境知识库； 三是通过漏洞知识库来确认安全事件的有效性， 也即对当前网络产生影响的网络攻击事件。 在网络安全事件生成和攻击事件确认的过程中， 提取出用于对整个网络安全态势进行评估的态势要素， 主要包括整个网络面临的安全威胁、 分支网络面临的安全威胁、 主机受到的安全威胁以及这些威胁的程度等。
5 结语
为了解决日益严重的网络安全威胁和挑战， 将态势感知技术应用于网络安全中， 不仅能够全面掌握当前网络安全状态， 还可以预测未来网络安全趋势。 本文在介绍网络安全态势相关概念和技术的基础上， 对基于多源日志的网络安全态势感知进行了探讨， 着重对基于多源日志的网络安全态势感知要素获取， 以及利用大数据进行多源日志的关联分析、 融合分析和态势要素分析等内容进行了研究， 对于态势评估、 态势预测和态势展示等相关内容， 还有待于进一步探讨和研究。

9. [hive]一种基于Hive日志分析的大数据存储优化方法_王正也_百度文库

一种基于Hive日志分析的大数据存储优化方法 王正也 网络文库
http://wenku..com/link?url=-

2 一种基于Hive日志的大数据存储优化方法
2.1 优化方法概述
Hive作为Hadoop开源分布式平台下的数据仓库工具，他的作用是HDFS上存储的结构化数据，根据使用者的需求将其映射出数据表，并可以向用户提供类似SQL的HiveQL查询功能，并将用户提交的Query转换成Map-Rece任务执行。Hive的优点是提供类SQL的查询接口，快速实现数据的统计分析功能，而不必编写专用的Map-Rece任务。而也正是因为如此，通用的Hive数据仓库，没有进行专用化的优化设计，其查询分析效率也有很大的优化空间[4]。
文章根据常用的HiveQL的查询日志分析和根据现有的数据存储结构的关联特性提出一种通用的Hive数据存储的优化方法。

本策略认为优化一个专用的Hive海量数据仓库分为以下几个步骤： 1. 分析常用查询日志，根据使用人员习惯定制数据分区结构。 2. 使用专用的优化过的列式存储结构作为数据导入格式。 3. 根据数据表，和表中字段的实际物理意义合并压缩重复字段和数据表。 4. 根据数据表中字段实际的取值优化字段的存储类型。 5. 编写UDF，在不改变用户使用习惯的基础上，应用上述优化。 其中1.2.两点在数据导入阶段进行优化，3.4.5.是在对数据表字段和表结构的优化，需要配合UDF来进行。通过上述优化过程可以大大节省HiveQL的查询时间以及HDFS上数据的占用空间。

2.2 根据查询日志进行分区优化
Hive的日志记录了Hive的运行状况，为本文分析操作者的使用习惯提供了很大的帮助。可以通过编写Hive的EXPAIN功能进行日志的分析，利用Hive的EXPLAIN功能，本文可以得到查询语句的抽象语法树(ABSTRACT SYNTAX TREE)，通过抽象语法树，本文可以快速得到查询语句的语法结构。
例如，以下一条语句SELECT col1, SUM(col2) FROM tab1 GROUP BY col1的通过EXPLAIN命令本文可以得到如下结果：
ABSTRACT SYNTAX TREE:
(TOK_QUERY (TOK_FROM (TOK_TABREF (TOK_TABNAME tab1))) (TOK_INSERT (TOK_DESTINATION (TOK_DIR TOK_TMP_FILE)) (TOK_SELECT (TOK_SELEXPR (TOK_TABLE_OR_COL col1)) (TOK_SELEXPR (TOK_FUNCTION sum (TOK_TABLE_OR_COL col2)))) (TOK_GROUPBY (TOK_TABLE_OR_COL col1))))

可以通过使用正则表达式抓取特征数据，得到该语句的语法结构，同时通过编写Shell脚本，批量执行EXPLAIN命令，可以很快的理解到使用者的常用语法习惯，为后文的分区优化提供了数据支持。 通过对使用者常用字段进行分区(partition)，带来的便利是大大的节省了一些常用查询的在硬盘中读取数据所消耗的时间。 通常在没有进行过优化的Hive系统中，每次查询提交之后，Hive要对输入数据进行全盘扫描满足条件的的项目，通过合理的划分分区，在单次任务提交后，可以按照任务的限定条件只扫描某些关键分区的数据，大大提高的Hive查询执行的效率。

2.3 选取合适的Hive数据存储格式
在Hive中数据表创建时需要指定文件存储格式，在Hive0.90版本中，常用的数据格式分为TEXTFILE、SEQUNCEFILE、RCFILE和用户自定格式等几种，以上格式的主要区别在行式存储与列式存储，不同压缩算法等方面的区别。根据Hive数据表格的特性，和通过Hive日志观察到的用户使用习惯等特性，通过选择合适的文件存储格式，可以大大提高查询效率，减少查询耗费时间。

4 结论
本文给出了一种基于Hive日志分析的大数据存储优化方法，通过实际测试可以看出，使用该优化方法的Hive数据存储系统无论从磁盘空间利用率还是从查询效率上都得到和很大提升。

10. 大数据存储的三种方式

大数据存储的三种方式有：

1、不断加密：任何类型的数据对于任何一个企业来说都是至关重要的，而且通常被认为是私有的，并且在他们自己掌控的范围内是安全的。

然而，黑客攻击经常被覆盖在业务故障中，最新的网络攻击活动在新闻报道不断充斥。因此，许多公司感到很难感到安全，尤其是当一些行业巨头经常成为攻击目标时。随着企业为保护资产全面开展工作，加密技术成为打击网络威胁的可行途径。

2、仓库存储：大数据似乎难以管理，就像一个永无休止统计数据的复杂的漩涡。因此，将信息精简到单一的公司位置似乎是明智的，这是一个仓库，其中所有的数据和服务器都可以被充分地规划指定。然而，有些报告指出了反对这种方法的论据，指出即使是最大的存储中心，大数据的指数增长也不再能维持。

3、备份服务云端：大数据管理和存储正在迅速脱离物理机器的范畴，并迅速进入数字领域。除了所有技术的发展，大数据增长得更快，以这样的速度，世界上所有的机器和仓库都无法完全容纳它。

由于云存储服务推动了数字化转型，云计算的应用越来越繁荣。数据在一个位置不再受到风险控制，并随时随地可以访问，大型云计算公司将会更多地访问基本统计信息。数据可以在这些服务上进行备份，这意味着一次网络攻击不会消除多年的业务增长和发展。