在我们上一篇解释何为 “IT智能运维”（AIOps）的博客文章中，我们展示了下图：
在这篇博客文章中，我们将深入探讨大数据层，解释为何说它对AIOps至关重要，简要介绍大数据的演变史，并讨论这对您的AIOps计划意味着什么。
关系数据库与前数字化时代
大约20年前，大多数的商业、IT、科学、医疗保健和其他系统所产生的数据都不足以达到我们现在界定的“大数据”标准。i 它们所产生的数据可以存储在当时的标准数据库中 — 关系数据库。分析可以内置到具有关系数据库后端的工具中，也可以内置在利用关系数据库的独立分析平台中。
在关系数据库中，数据被组织成由列和行组成的表。这些表通常定义实体类型（客户信息、销售信息和产品信息等），列定义属性或特征。
行包含与该实体的特定实例相关的数据。实体由于在同一个表中而“相关”；表通过键或索引彼此“相关”，以便将不同表中的数据关联起来，进行计算、报告和分析。涉及大量表和/或跨表查找的查询会严重影响系统的处理能力。关系数据库面临的挑战是优调性能以支持所需的特定用途。
关系数据库中的表必须根据需要存储在其中的数据预先定义。了解数据类型、大小以及在检索、报告、计算和分析中的预期用途对于关系数据库设计至关重要。您必须了解数据结构、数据实体之间的关系以及您打算用它做什么，才能从关系数据库查询中获得预期收益。要想处理新数据，或者更改入站数据的结构、关系或用途，则必须更改数据库设计。
随着数据量和使用量的增长，关系数据库在成本与性能之间进行了重大权衡。虽然关系数据库通常具有出色的可靠性，但是，随着表数量的激增、大小的增长以及支持同时查询请求，性能成为严峻挑战。
数据库技术的商品化以及存储和处理成本的大幅降低帮助企业解决了可扩展性问题，但从结构上讲，这项技术永远无法支持我们所说的“大数据”。
大数据
大约从2000年开始，我们看到数据创建量呈现出爆炸式增长，这在一定程度上要归因于从昂贵的专有模拟存储到商品化数字存储的过渡。数字磁带意味着更多的数据可以被存档。
CD/DVD（然后是蓝光）意味着可以分发和共享更多的数据。电脑硬盘、处理器和内存容量的增加意味着更多的数据被个人捕获和存储。
一旦这些技术渗透到医院、公司和大学等机构，数字数据的生成和收集便会呈现出爆炸式增长。人们便会开始思考如何发掘这些海量数据集中的商业、科学和知识价值。实现此目标需要克服两个技术挑战：关系数据结构的刚性以及处理关系数据库查询时的扩展问题。
第一个问题可随“数据湖”的发展而得到解决。数据湖是同时面向结构化数据（例如表、行和列等关系数据库中的数据）、半结构化数据（日志和JSON等）、非结构化数据（电子邮件和文档等）以及其他数据（图像、音频和视频等）的单一存储库。ii数据湖收集所有数据，与其格式无关，并使其可用于分析。数据湖并不是在提取数据时对其进行提取、转换和加载（ETL），而是在调用数据进行分析时执行这项任务。
第二个问题可通过大规模并行处理（MPP）得到解决。关系数据库依赖可供多个处理节点访问的单个或共享存储系统。这些存储系统由于性能或查询排队等原因而成为瓶颈。对相同数据的同时查询可能必须要排队（等待）其他查询，以确保它们使用的是最新数据。
MPP试图在处理节点之间分割数据，以消除单一存储带来的瓶颈。分割是根据数据类型、预期用途、甚至其是否为较大数据集的子集等标准进行的。这将允许同时或“并行”处理数据，从而相对传统关系数据库而言大大提高查询处理的性能。
当然，MPP分割本身也具有挑战，并且还需要对分割的数据进行校正。然而，这种方法对于早期大数据分析中典型的相对静态的数据而言效果很好。查询可以批量或并行执行，而不是连续执行，从而允许大多数组织对海量数据集进行复杂的分析。
数据湖和MPP的实施在Apache Hadoop – 大多数技术人员都很熟悉的技术 – 中得到了最好的体现，尤其是在Hadoop 1.0中。Hadoop引入了“Hadoop分布式文件系统”（HDFS）和MapReduce，旨在解决传统关系数据库对大数据分析的限制问题。
HDFS是开源代码数据湖（几乎可以接受任何类型的数据），支持跨商用硬件的数据分发，并针对分割数据的MPP查询进行了优化处理。它使存储和利用海量数据集进行分析在技术和经济上成为可行的选项。
MapReduce是旨在构造查询以便对HDFS中的分割数据开展并行查询的MPP引擎。
Apache Hadoop使大数据成为各个垂直行业中所有组织的商品。科学家、业务分析师、健康科学研究员和其他人员均已开始对大量数据集进行深入分析，试图发现治疗方案、天气模式、洞察和竞争优势。大数据热潮由此诞生。但Hadoop 1.0因为一些局限性而限制了它在某些应用中的效用：
• MapReduce是可与HDFS一起使用的唯一应用
• MapReduce仅支持结构化查询的批处理。您无法使用流式（实时）数据或开展交互式分析。
• 尽管相对容易设置和管理，但优化数据和查询却很困难。企业要求数据科学家对调查进行管理，以获得有用的结果。
Cue Hadoop 2.0 – 大数据的民主化和AIOps支持。
大数据对于AIOps至关重要
在Hadoop 2.0中，Apache发布了YARN (“Yet Another Resource Negotiator”)。YARN与MapReduce结合使用，通过支持流数据和交互式查询补充了MapReduce的调度和批处理功能。YARN还允许客户将HDFS与相兼容的非Apache解决方案结合使用。
流动的交互式大数据分析现已成为可能。将第三方应用与Hadoop集成在一起意味着垂直应用经重新设计可将分析能力提升到新的水平。然而，对于需要分析实践但却没有数据科学的组织而言，Hadoop仍是难以优化和使用的。
在市场影响力方面，由于客户需要提高解决方案的易用性和专用性，导致Elastic、Logstash和Kibana等公司应运而生（“ELK”或“Elastic Stack”），这些公司提供批处理、流式和交互式大数据分析解决方案，最终将成为Hadoop在某些用例中替代品。
为何说这对核心IT运维和服务管理很重要呢？因为这两个IT学科都依赖于流式数据和交互性。在ITOM和ITSM应用中，分析受到所用数据库技术和应用架构的限制。作为成本中心，IT无法证明为了对监控、补救和服务交付用例进行分析而雇用数据科学家是明智决策。
另一方面，企业的数字化转型在改变IT角色的同时也给IT带来了前所未有的压力，需要他们应对规模、复杂性和速度挑战。为了支持业务创新并跟上数字化转型的步伐，IT需要具有以下特征的系统：
• 可以汇集各种各样的IT数据
• 可以使用机器来实时分析大量的流动数据
• 可以为特定于IT的用例生成有意义的信息（事件管理、警报、工作负载布置、根本原因分析和云成本优化等）
• 可以识别出其他的自动化机会
• 可与IT工作流相集成，并支持交互式和历史分析。
朝着基于分析的方法过渡时，会遇到专用应用程序及其数据孤岛带来的局限性挑战。IT工具难以替换或升级，即使对它们进行重新设计来支持大数据分析，其数据仍然是孤立的。这种情况下，可通过引入AIOps来解决问题。
＋
AIOps的基本前提是：
• 为了使IT部门能够应对数字化转型，机器必须接管手动分析
• 分析必须是流动数据和历史数据的实时分析
• 数据集中必须包括来自不同孤岛的各种IT数据
• 无论是从技术还是从可用性的角度来看，系统都应是交互式的
只有在大数据技术的商品化和成熟度发展演进到现阶段，AIOps才有可能实现。它需要支持各种数据（数据湖）；它需要支持对大量数据进行同时分析；它必须能对流动数据进行实时分析；并且必须允许手动干预。
AIOps不会取代领域特定的ITOM和ITSM工具，而是从领域特定的工具中获取数据、将其存储在大数据后端、对其应用分析和机器学习、并且在整个组织中以民主方式分发洞察，借此来改变IT管理方法。
鉴于此，您在制定AIOps计划时必须注意以下几点：
• 您必须选择或者自己使用Hadoop、ELK或其他技术来构建大数据后端，或者依赖合作伙伴提供的解决方案。合作伙伴解决方案可以是大数据即服务，也可以是AIOps平台中的大数据后端。您不应围绕着传统的关系数据库来制定AIOps计划。
• 请务必明白，如果您自己构建平台，则需要承担与确保解决方案性能相关的技术债务；负责维护（公共或私有云）基础架构的弹性；并且需要创建强大的数据科学实践。该实践不仅必须符合分析理论，而且还必须与贵组织中AIOps平台所采用的理论相一致（例如Python或R开发模式）。
• 确保领域特定的IT工具具有支持将数据流式传输到AIOps大数据后端的API，或者您可以针对流向平台的关键数据（如票证、事件和日志等）执行近实时ETL。AIOps分析、关联和模式匹配算法都需要不同数据的同步馈送。
• 为转变做好组织上的准备。这不仅需要通常各自为政的各个IT团队进行数据共享和协作，而且还需要他们就审查和响应流程达成一致。在新的联合方法中，不仅需要以通用的方式直观显示数据，而且可能还需要重新定义“正常”和“异常”的评判标准。
AIOps是企业IT发展的必经之路，但它并非一朝一夕之事，而且还需要基础架构运维主管投入大量的精力、时间和资源。本文只讨论了AIOps计划的一个关键成功要素。在未来，我们将另外撰写文章来探讨其他的关键成功要素，如分析和算法。
为了帮助您实施AIOps计划，BMC提供了利用机器学习、分析和大数据技术来缩短MTTR并推动数字企业发展的TrueSight AIOps平台。TrueSight专为企业IT部门开展数字化业务转型而设计。如想了解有关TrueSight AIOps的更多信息，点击这里。
i.金融体系之前确实可以做到（并且现在依然能够做到），但大多数都依赖（并将继续依赖）另一类技术。
ii.Campbell, Chris。“数据仓库与数据湖之间的五大区别”。Blue-Granite.com。2017年5月19日检索。
如果您想了解更多关于BMC的相关信息，请点击阅读原文了解详情。
