Apache Hadoop 于 2006 年出现在 IT 舞台上,承诺为组织提供使用商品硬件存储空前数量数据的能力。这一承诺不仅涉及数据集的大小,还涉及数据类型,例如企业越来越感兴趣的 IoT 设备、传感器、服务器和社交媒体生成的数据。数据量、速度和多样性的组合通常被称为大数据。
读图在 Hadoop 的普及中起着至关重要的作用。企业认为他们不再需要担心定义哪些表包含哪些数据以及如何相互连接的繁琐过程 – 此过程需要数月时间,在完成之前无法执行单个数据仓库查询。在这个勇敢的新世界里,企业可以存储尽可能多的数据,因为他们可以在基于 Hadoop 的存储库中存储数据,这些存储库称为数据湖,并担心以后将如何分析这些数据。
数据湖开始出现在企业中。这些数据湖由商业大数据分布启用 – 支持多个独立的开源计算引擎,该平台将支持数据湖以不同的方式分析数据。最重要的是,所有这些是开源是免费尝试!会出什么问题？
读取时模式是一个错误
和生活中的许多事情一样,被吹捧为优势的Hadoop的特征也被证明是它的致命弱点。首先,随着写入模式限制的解除,数 TB 的结构化和非结构化数据开始流入数据湖。随着 Hadoop 的数据治理框架和功能仍在定义中,企业越来越难以确定其数据湖的内容及其数据的商系。此外,数据尚未准备好可供使用。企业开始对其数据湖中的数据失去信心;慢慢地,这些数据湖开始变成数据沼泽。”构建它,他们会来”的模式读取哲学失败。
Hadoop 复杂性和管道式计算引擎
其次,Hadoop 分布提供了许多开源计算引擎,如 Apache Hive、Apache Spark 和 Apache Kafka 等仅举几例。事实证明,这是一件太多好事。例如,一个商业 Hadoop 平台由 26 个此类独立引擎组成。这些计算引擎操作复杂,需要专门技能才能将在市场上难以找到的管道卷起来。
错误的焦点:数据湖与应用程序
第三,也是最重要的一点,数据湖项目开始失败,因为企业将所有企业数据存储在一个中心位置,目标是使这些数据可供所有开发人员使用 – 如果您愿意,则成为 Uber 数据仓库。考虑数据如何影响应用程序。因此,Hadoop 群集经常成为企业数据管道的网关,这些管道筛选、处理和转换数据,然后导出到其他数据库和数据集市,以便向下游报告,并且几乎从未找到通往实际业务的途径在经营面料企业中的应用。因此,数据湖最终是一组庞大的不同计算引擎,在不同的工作负载上运行,所有引擎共享相同的存储。这很难管理。此生态系统中的资源隔离和管理工具正在改进,但它们仍有一路走来。所有这些复杂性 – 仅针对报告。
企业大多无法将注意力从将数据湖作为廉价的数据存储库和处理管道转移到使用数据和为任务关键型应用程序供电的平台
这两个引擎都用于分析目的 – 处理类似 SQL 的查询 (Hive) 或执行类似 SQL 的数据转换和构建预测模型 (Spark)。这些数据湖实现不够注重如何在应用程序中操作使用数据。
前进战略
如果您的组织担心 Hadoop 生态系统的最新发展,并且越来越面临展示数据湖价值的压力,您应该首先关注操作应用程序,然后重新处理数据。
通过专注于使用数据和智能的应用程序的现代化,您将最终获得的应用程序,这些应用可以利用数据,根据经验预测未来可能发生的情况,并在实现卓越业务的那一刻主动做出决策结果。以下是成功应用现代化战略的五个要素:
- 选择一个应用程序进行现代化:而不是专注于集中数据,而是先选择一个您希望实现现代化的应用程序。这一计划的主要候选者是许多定制应用程序之一,这些应用程序在市场上已经落后,需要变得更加敏捷、智能化和数据驱动型。确定可为您的组织提供竞争优势的应用程序后,您可以专注于获取为该应用程序供电所需的数据,以及是否可以从数据湖中提供该数据。
- 将横向扩展 SQL 用于应用程序现代化:SQL 多年来一直是企业中工作负载的主力;您的组织中有数以百计的开发人员、业务分析师和 IT 人员完全熟悉 SQL。不要将原始 SQL 应用程序重新编写为低级 NoSQL API 产生额外的时间、费用和风险。选择一个平台,使您能够维护 SQL 的熟悉模式和强大功能,使应用程序现代化,但在可以弹性地在廉价基础结构上横向扩展的体系结构上执行此操作。横向扩展使整个群集在计算时具有功能,使其比在集中式系统上工作的旧 SQL 系统快得多。通过横向扩展,您可以添加更多容量,并随着工作负载的变化而将其消除。
- 采用 ACID 平台:ACID 合规性是事务在数据库中保持完整性并允许用户执行提交和回滚等操作的机制。它是为操作应用程序供电的关键功能,因为它可确保数据库在发出提交之前不会对其他人可见更改。选择在数据库中各个事务级别提供 ACID 功能的平台。否则,需要在应用程序代码中处理所有这些一致性后果。所有传统 SQL 系统都符合 ACID 标准。数据湖错误地丢弃了这些数据,使得应用程序很难编写。
- Unify 分析引擎:根据 Gartner最近的博客,从历史上看,将 IT 基础架构分离为操作 (OLTP) 和分析 (OLAP) 组件是有充分理由的,但事实并非如此。ETL 以延迟杀死我们的 SLA。过去的情况是,操作和分析工作负载相互干扰,您必须将它们分开。此外,遗留数据平台的运行情况如此糟糕,我们不得不将操作架构转换为星型架构或雪花模式,这些架构更适合分析工作负载
通过实现此平台,将确保应用程序在可最大程度地减少数据移动且不会造成应用程序中延迟的平台上运行。这将提供您的见解、报告和仪表板。
这与到目前为止使用数据湖的方法基本不同。此方法通过现在可以利用数据湖的应用程序更快地为业务线提供有形的业务价值。
这种方法将确保除了使为您的业务提供竞争优势的应用程序现代化之外,您还可以保留对数据湖的投资。