每个组织的每个部门的每个团队都拥有大量潜在的高价值数据。但多达73% 的未使用, 因为历史上很难获得。
不同的来源、不同的格式以及从数据中聚合和获取任何有价值的东西的其他不一致导致组织设计了提取、转换、加载 (etl) 过程, 以便他们能够从一系列来源收集数据, 实现标准化它, 并将其集中到一个存储库中。
然而, 最初的etl 流程是为十年前的业务需求而构建的。时代是如何变化的。
如今的企业有更多的数据源来联合起来。研究表明, 现代企业的环境中可以有多达400个企业应用程序, 以及产生海量数据的社交媒体平台和移动技术。要将这一切都包括在内, 现代数据管理领导者需要新的方法来平衡对更长的历史数据和更精细的细节的更多需求的需求, 以及为战略业务规划提供即时访问这些信息的必要性。
过去的失败短的 etl
在过去的好日子里, 由一小群数据科学家对少数数据源的 etl 过程进行了合理的管理。
然而, 随着数据量和速度的增加, 系统和过程发生了故障。传统的内部部署 etl 工具带来了一系列的缺点和挑战。
首先, 许多 etl 函数历来是手动编码的, 这是一个漫长且往往很复杂的过程, 大多数公司都将加入大数据革命的成本归结为。但手工编码的数据集成过程本质上具有挑战性: 它们使一个开发人员难以学习另一个开发人员的代码, 导致许多开发人员只需从头开始重写代码, 并为操作增加时间和费用。
更糟糕的是, 这些家庭环境将维护数据的负担和成本推给了公司的工程团队, 以便任何需要更新的数据、团队成员离开或代码 (或配置) 没有记录时, 公司都有亏损的真正风险宝贵的机构知识。就日常运营和对业务用户的影响而言, 内部部署 etl 系统传统上在提供企业做出明智决策所需的各种见解方面进展缓慢。
通常, 这些系统基于批处理、强制团队在非工作时间使用免费计算资源运行夜间 etl 和数据整合作业。增加容量以适应不断增长的需求, 最终将导致更高的成本 (功耗、硬件和人员开销), 并提高停机或服务中断的风险。
现代的, 基于云的 etl 救援
传统的 etl 流程具有批量提取数据, 将其转换为临时区域, 然后将其加载到数据仓库或其他数据目标中的功能。这种模式与现代商业需求不符。
在当今的业务环境中, 数据接收必须实时工作, 并为用户提供随时运行查询和查看当前情况的自助功能他们的 etl 工具必须毫不费力地处理这堆积如山的数据。
现代 etl 工具应该能够在任何云提供商上很好地工作, 并且应该能够在公司更换提供商时轻松迁移。它们端到端必须具有容错、安全、可扩展和准确的准确性, 尤其是在为新的机器学习 (ml) 或人工智能 (ai) 模型提供关键信息时。它们应启用错误消息配置、事件重新路由和按需编程数据。他们还应该利用 amazon s3 等基于对象的现代存储, 立即检索或领先的云数据仓库 (如 amazon redshift、google bigquery 和二页板), 直接转换海量数据集, 而无需专门的暂存地区。
比较表
| 传统 etl | 现代 etl |
|---|---|
| 手动编码和 sql 查询。 | 基于云并完全管理, 以减少维护并自动执行更新。 |
| 仅限批处理。 | 能够支持批处理和实时数据接收。 |
| 需要维护、升级的内部部署系统。 | 几乎任何数据源都能快速接收支持 api 的内容。 |
| 缓慢、不灵活的数据接收和来自有限的来源。 | 自动一键式和手动自定义映射。 |
| 快速学习程序和培训过程。 | 轻松地将任何类型的数据转换为任何格式, 以便立即使用。 |
| 转换非结构化或半结构化数据的难度。 | 互连数据, 以获得更多可见性和更深入的洞察。 |
| 在中断的情况下, 从头开始重新启动流。 | 中断后的实时数据流可视化和自动流排队。 |
| 资源密集型, 从其他系统或应用程序中获取有价值的计算。 | 重量轻, 非资源密集型。 |
现在是实现 etl 现代化的时候了
为了保持竞争力, 企业需要适应不断变化的竞争格局。在某些情况下, 以隔夜甚至每周批次收集和分析数据可能是值得的。但在消费者偏好几乎在一夜之间发生变化、企业争先恐后地以新产品和服务率先上市的数字时代, 企业现在需要深刻的可操作洞察, 而不是下周。