ETL万岁

提取转换负载是用于从一个数据系统中提取数据并加载到另一个数据系统中的过程。 涉及的数据系统称为源系统和目标系统。

来自源系统的数据形状与目标系统不匹配，因此需要进行一些转换以使其兼容，该过程称为Transformation 。 转换是由map / filter / reduce操作完成的。

为了处理数据系统之间的不兼容性，需要一些元数据。 哪种类型的元数据会有用？
将源数据转换为许多不同的形状以处理各种业务用例是非常普遍的，因此对于源系统使用描述 性元数据，对于目标系统使用描述性元数据是有意义的。

元数据在使系统向后和向前兼容方面起着重要作用。

很多时候仅拥有元数据是不够的，因为某些源/目标系统数据太大或太小而无法容纳。

这是当变换变得有趣的情况。 这意味着某些值必须删除或设置为NULL或默认值，对此做出正确的决定对于转换的向后/向前兼容性非常重要。 我想说许多企业的成功还取决于如何解决这个问题！ 如果正确完成，可以避免许多集成梦night。

到目前为止，我们只是在讨论单一源系统，但是对于许多用例，都需要来自其他系统的数据进行一些转换，例如将userid转换为name，派生新的列值，查找编码等等。

添加多源系统会增加转换的复杂性，以处理丢失的数据，陈旧的数据等。

随着数据系统的发展，今天不仅涉及关系存储，我们还看到键值存储，文档存储，图形数据库，列存储，缓存，日志等。

新的数据系统也已分发，因此这增加了转换复杂性的另一个维度。

我们的旧关系数据库也可以描述为它是使用ETL模式构建的，通过使用更改日志作为数据库所做的一切工作的源

关于ETL的神话之一是它是批处理过程，但是随着Stream处理器（即Spark Streaming，Flink等）和Pub Sub系统（Kafka，Pulsur等）的超时而变化。 这样可以在事件推送到源系统后立即进行转换。

流式流行词不要被太多带走，不
无论您使用哪个流处理器或发布子系统，但您仍然必须应对上述挑战或利用某些新平台来解决这一问题。

投资转换/业务逻辑，因为它是构建可维护和可扩展的成功系统的关键。
使其保持无状态，元数据驱动，处理重复/重试等，更重要的是编写Tests以在快速变化的时间内对其进行良好的维护。

下次当您对ETL流程有疑问时
您处理实时还是批量处理？

你的答案应该是
这是基于事件的处理。

ETL万岁

翻译自: https://www.javacodegeeks.com/2020/04/long-live-etl.html