英语原文共 9 页，剩余内容已隐藏，支付完成后下载完整资料
翻译
一个基于Elasticsearch和Kibana对社交媒体数据分析的框架
摘要
实时在线数据处理已经迅速成为分析社交媒体中政治趋势、广告、公共卫生意识计划和政策制定的重要工具。传统上，只有数据收集是一次性过程时，与离线分析关联的过程才具有生产效率。当前，最前沿的研究需要实时数据分析，这带来了一系列挑战，特别是在当前NoSQL和关系数据库的上下文中连续数据获取的效率。在本文中，我们演示了一种使用可配置的Elasticsearch有效解决实时分析难题的解决方案搜索引擎。我们正在使用分布式数据库架构，为大型文本挖掘预先构建索引并标准化Elasticsearch框架。来自查询引擎的结果几乎是实时可见的。
关键词：社交媒体，大数据，实时分析，ElasticSearch，可视化
1介绍
在线数据的指数增长使得在获取可转化为实际的结果的有代表性数据集过程中构成了一个重大挑战。实时预处理增加了另一层复杂性，尤其当数据是文本和非结构化或大众型资源时。在云计算和存储领域中，处理大数据集的解决方案正在快速增长，但是当我们考虑以PB的规模处理大数据时，基于云的分析受到网络传输数据效率低下的限制，以及执行实时分析所需的计算资源的重复成本。在基于云的存储中，访问和隐私也带来了挑战，因为服务器管理员有权查看数据及其流量。由于计算限制，诸如加密搜索之类的安全解决方案无法实施实时分析所特有的方法。当前，用于分析大型数据库的三大工具是Elasticsearch，Hadoop和Spark。Elasticsearch是一个分布式搜索和分析引擎，它允许以相对较高的速度进行实时数据转换、搜索查询、文档流处理和索引。此外，Elasticsearch可以索引数字，地理坐标，日期以及几乎任何数据类型，同时支持多种语言（如Python、Java和Ruby）。Elasticsearch引擎的速度基于其执行聚合、搜索和处理数据索引的能力。Hadoop是使用MapReduce算法的分布式批处理计算平台，其中包括数据提取和转换功能。虽然该平台基于NoSQL技术，可以轻松上传非结构化数据，但其查询处理HBASE没有像Elasticsearch这样的高级分析搜索功能。Elasticsearch是一个文本搜索和分析工具，带有可视化插件，可使用开源许可证进行实时分析。最后，Elasticsearch托管了Hadoop和Spark插件，以缩短两种不同技术之间的距离，并允许实施混合系统。
支持大型数据集和实时数据获取管理的工具包括关系（MySQL、Oracle数据库、SQLite）、图（Neo4j、Oracle Spatial）和NoSQL（MongoDB、IBM Domino、Apache CouchDB）。与所有类型的数据库相关的限制因素包括缺乏对实时全文搜索的支持。尽管NoSQL可用于全文搜索，但与关系数据库模型相比缺乏可靠性。传统的数据库要求首先上传数据，然后管理员必须主动决定应为哪些数据建立索引，这又增加了一层处理，因此无法进行实时分析。Elasticsearch为这些限制因素提供了解决方案通过提供一个高效的数据获取和实时分析系统，该系统：
- 在存储数据之前执行预索引，以避免需要实时获取和查询特定数据；
- 与传统解决方案相关的资源和计算能力要求有限；以及
- 提供分布式且易于扩展的系统。
通过标准化配置过程、碎片大小管理和数据上传到Elasticsearch之前的标准化，增强了Elasticsearch为高效、实时数据分析做出贡献的能力，并通过对工作架构和实时社会可视化的讨论对2017年12月至2018年5月期间收集的拥有超过10亿个twitter数据点的媒体数据进行了演示。
1.1关键贡献
- 为Elasticsearch优化和标准化Twitter数据
- 创建一个配置文件，并选择最佳的碎片大小
- 演示超大规模社交媒体数据集的实时可视化
2 实时分析和存储架构
2.1 Elasticsearch
Elasticsearch于2004年作为一个名为compass的开源项目启动，该项目基于Apache Lucene。Elasticsearch是用Java编写的稳定且独立于平台的分布式可伸缩全文搜索引擎。这些功能与特定于需求的灵活性和轻松的扩展选项相结合，有助于实时大数据分析。我们将讨论Elasticsearch的一些一般功能，为本研究产生的Elasticsearch配置、数据标准化和碎片管理程序提供上下文。
2.2 抽象视图
图1展示了基于Elasticsearch和Kibana的超大规模数据实时分析框架。第一步，使用Twitter API抓取存储在MongoDB数据库中的Twitter数据（每分钟大约1400条推文），该数据库安装在容量为16TB的网络连接存储（NAS）上。twitter数据被传输到预处理单元，预处理单元处理数据并几乎实时地将其传输到高性能计算（HPC）基础设施。由于包括MongoDB在内的传统数据库的效率不足以处理实时查询，因此我们将数据的处理和分析转移到Elasticsearch，而Elasticsearch是通过HPC实验室资源实现的。在上传数据之前，我们对Elasticsearch的twitter对象进行了标准化，并使用多线程上传数据，以提高实时性能并缩短接收和处理数据之间的间隔。当用户需要任何数据时，将使用Kibana前端将查询发送到Elasticsearch。Elasticsearch处理该查询，并将查询结果对象（JSON格式）发送到Kibana，其中Kibana向用户显示查询对象。
图1使用Elasticsearch进行实时分析的框架
在搜索引擎的一般功能范围内，Elasticsearch使用一个称为节点的运行实例，该实例可以承担一个或多个角色，包括主节点或数据节点（参见第2.1节，图2）。Elasticsearch内的数据集集群至少需要一个主节点和一个数据节点，但是一个节点可能承担多个角色，因此一个集群可能由一个节点组成。与Elasticsearch唯一兼容的数据存储格式是JSON，因此由于Twitter数据的非结构化格式，因此需要数据映射以进行功能分析和可视化。我们观察到，对JSON格式的依赖使系统比MySQL和其他RDBMS更灵活，但不比MongoDB灵活。传统数据库（如RDBMS）使用表存储数据，而MongoDB使用BSON（如JSON）格式，Elasticsearch通过Apache Lucene体系结构使用倒排索引存储数据。Elasticsearch中的典型索引是具有不同属性的文档的集合，这些文档是通过用户定义的映射进行组织的，该映射概述了不同数据源的文档类型和字段，类似于SQL数据库中的表。然后，将索引分成碎片容纳在多个节点，其中一个分片分布在不同节点上的索引的一部分。在Elasticsearch框架内，倒排索引允许在节点和分片中更大分类地存储大数据集，从而使实时搜索查询更加有效。Elasticsearch使用RESTful API与用户通信，有关基本架构比较，请参阅表1。此外，还有其他库，例如Python中的Elasticsearch和Java以获得更好的集成。
表1 Elasticsearch和RDBMS基本架构之间的比较
2.2.1骨干
尽管Elasticsearch是功能强大的工具，它需要模型来优化功能以实现针对社交媒体的实时大数据分析。本研究的目的是提供：①一个特定的配置文件来优化数据集的组织，②优化碎片大小以最大程度地提高存储和处理的效率，以及③标准化Twitter中存在的数据字段的结构，以消除在Elasticsearch中存储数据时对无关信息的过度处理，它首先将数据存储在索引中，然后使用自动标记器将索引数据存储为倒排索引。当我们在Elasticsearch中搜索时，我们会得到数据的“快照”，这意味着Elasticsearch不需要托管实际内容，而是链接到存储在节点内的文档以通过倒排索引提供结果。这些结果不是真实数据，而是查询到每个节点中存储的所有关联文档的链接的表示。作为该项目的一部分，开发了以下配置文件，并且可以根据节点数和服务器容量编辑配置文件，从而在任何HPC上的Elasticsearch中复制这些配置文件。表2描述了Elasticsearch的基本配置文件。
表2主节点和数据节点配置文件
此处，群集的名称是dslab，并且即使只有单个节点，群集名称也是必需的。由于Elasticsearch是一个分散的数据库，其中一个或多个节点充当头节点，其他节点充当数据节点，因此此参数用于互连集群中的所有节点。我们可以使用不同的Elasticsearch实例和不同的配置文件，使用相同的硬件创建多个集群。
表3 Elasticsearch节点配置文件功能
表3是任何Elasticsearch节点的配置文件功能示例。在Elasticsearch集群中的每个节点，我们必须在每个实例中配置相同的文件。当存储数据时，我们使用索引来存储特定类型的数据，类似于MySQL中的数据集。Elasticsearch的性能基于索引的映射以及我们如何调整数据集的碎片大小。公式1给出了决定碎片大小的公式。
Number of shards = （Size of index in GB）/ 50 （1）
考虑使用50 GB作为碎片大小背后的原因是由于Elasticsearch架构。该架构支持32 GB索引大小和32 GB高速缓冲存储器，从而理想地认为碎片的存储器应该是小于64 GB，并且通过实验我们观察到最好的结果是使碎片保持在 50 GB的大小。
2.3 Kibana：可视化
除了Elasticsearch可以高效地进行实时分析外，诸如Kibana和Logstash之类的扩展插件还便于实时进行大数据功能的表示。它是elastic stack的一部分，可以在开源许可下免费获得。Kibana默认情况下提供多种标准可视化，通过拖放功能简化了为最终用户开发可视化的过程。由于Kibana得到了Elasticsearch体系结构的支持，因此它可以快速运行并且足够高效以进行实时分析。最后，它提供了在构建和处理查询过程中进行图形交互的机会，并且可以对数据库中的集群运行状况和属性进行可访问的可视化。
3 社交媒体数据分析
3.1 Elasticsearch的配置
实时社交媒体流数据存储在弹性集群中。每个弹性群集包含6个节点，每个节点具有2个线程和12 GB的内存。在这6个节点中，一个节点充当主节点，其余5个充当数据节点。elastic群集的架构如图2所示。
图2 在Lakehead大学HPC上托管的Elasticsearch集群架构
3.2 社交媒体数据集
我们使用Elasticsearch分析了使用Twitter API收集的2017年12月至2018年5月期间10亿条推文中的2.5亿条。由于Twitter API响应是JSON格式的，并且包含非结构化和不一致的数据，因此不能保证推文JSON对象中所有数据字段的顺序收集。因此，对于Elasticsearch映射来说，必须将数据标准化和转换为结构化格式，以便将数据的每个字段加载到索引中时都存在。为了优化Elasticsearch，我们更改了推文的存储格式，以便所有数据都处于JSON格式的第一层深度。表4描述了Elasticsearch中重构数据的基本示例。
表4 正常结构与更新结构之间的区别
如前所述，数据存储为倒排索引，该索引针对文本搜索进行了优化，因此非常高效。例如，如果我们在Elasticsearch中的所有推文（2.5亿 条）中搜索关键字“pizza”，花费的时间为4060毫秒（4.06s），总共找到192,118条以“pizza”作为关键字出现的推文。表5显示了来自Elasticsearch中关键字“ pizza”的文本搜索查询响应的示例。图3a显示了按国家划分的“pizza”推文的地理分布饼图，其中仅美国就占推文总数的47%，其他国家（不包括排名前五的国家）占推文总数的30%，占推文总数的77%。此外，可视化显示执行查询所需的时间为13毫秒（0.013秒）。图3b显示了与“pizza”相关的推文中使用最多的语言，其中超过77%的推文中使用英语，12%使用西班牙语，6%使用葡萄牙语，3%使用法语，2%使用日语。在本例中，Elasticsearch共花费17毫秒进行查询处理。
表5“ pizza”关键词的搜索查询结果
图3c显示了用于发送推文的设备，38%的推文发自iPhone twitter应用程序，Android twitter应用程序占29%，twitter web客户端仅占11%，twitter lite和Tweetdeck的总和约占7%。其余15%的推文为其他消息来源。这个查询花费了11ms来执行，考虑到数据的结构和数量，这是相当合理的。
以上结果证明了该数据分析系统的效率，因为这三项任务（获取数据，执行描述性分析和创建图形）均在2.5亿条推文的数据库中使用不到15秒的时间完成。显然，该框架已证明适合实时分析大型文本数据，而不会损失准确性。它还表明，在资源有限的情况下，对数据使用重组和标准化程序有助于优化结果的准确性和流程的效率。
图3 对“比萨饼”一词的Twitter数据进行实时分析
3.3 可视化仪表板
目前，本文描述的监视框架用于显示
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[238514]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
