ETL
Extract, transform, load https://en.wikipedia.org/wiki/Extract,_transform,_load
抽取,转换,加载 https://baike.baidu.com/item/ETL/1251949?fr=aladdin
说的通俗点,就是帮我们从源表 select 数据 –> 经过一系列计算 / join 等操作 –> update / insert 到目标表 这一套流程的工具,除此以外工具还有定时任务、任务执行顺序约束等一系列功能,通过 ETL 让我们表与表之间、库与库之间实现了可控的信息流转。
还有叫做 ELT 的工具,调换了顺序,针对了不同的场景
Informatica 与 Azure Data Factory
此文撰写于 2020.4,对比内容为个人有限的使用经历,并不权威,不保证公正,若有错误或侵权内容请告知,会尽快删改。
两者都可以进行 ETL 功能,相对来说前者具有全面的功能,后者在中国区里功能较弱(其他区有 Data Flow 功能集可以做更多地边界操作),让我们从功能角度来看看差异。
https://docs.microsoft.com/zh-cn/azure/data-factory/introduction
https://www.informatica.com/
一个执行任务
Informatica 里面使用叫做 Mapping 的模块存储一个执行任务,里面会进行从多个源表读数据、各种运算处理、存储到多个目标表等一系列的相关联操作
除此以外 Informatica 还有Synchronization Task 可以快速的做简单地 表对表拷贝,中间不进行复杂逻辑,最多就是字段名映射关系控制
ADF 通过一个 Pipeline 来配置一个执行任务,通过 Pipeline 里的 Copy Data 功能块来进行源与目标的拷贝配置
Copy Data 是一个完整的块,只能进行一个到一个表的拷贝,源与目标配置在了一起,难以做到读取多个表经过各种操作后写入到多个表的操作行为(Data Flow 功能集可以做到分离)
而 Mapping 是有 Source 与 Target 两个功能块,将源和目标分离,更灵活的进行配置
控制执行时间
job 不只是一系列操作的聚合,还需要掌控时机。真的要让数据自由的流转,那必须要让其可以被自动的触发,所有 ETL 都具有类似于定时器的功能。
Informatica 使用 Mapping Task 功能对上述提到的 Mapping 进行执行周期/频次等配置,而 ADF 通过 trigger 对 Pipeline 进行配置,相对来说两者功能近似。但除此以外 Informatica 还有 PowerCenter Task 以及对于简单拷贝 Sync Task 可以直接配置好执行时间周期。
一个执行队列
一系列的任务,我们不能去人工的都安排好具体的执行时间,因为我们也无法确定每次的执行总时间,如果遇到强依赖的右前后顺序的任务就需要进行执行队列控制了。
Informatica 有 Taskflow 系列功能可以对各种任务进行执行顺序的安排。
对于 ADF 比较特殊,他还是通过 Pipeline 进行管控,Pipeline 里面有很多功能除了能够 Copy Data,还可以 Excute Pipeline 模块可以去指定的执行其他 pipeline,通过此功能可构成了 Pipeline 之间的树形关系,进而实现执行顺序的控制
执行存储过程
对于过于复杂的逻辑,如果使用 各种 join 等 ETL 功能,可能会导致可视化界面极其混乱且不易懂,也许又到了翻出存储过程的时候了
Informatica 的 Mapping 必须最少有一个 Source 一个 Target,这就很难操作,需要 Source 一个 select 1 等方式构建假信息,并对于 Target 写出一个假信息来满足这个必要条件,然后再 Source 里可以通过 pre sql 或者 post sql 等方式实现存储过程的执行,但无法获取执行结果
ADF 有专门的 Stored Procedure 模块可传参也可获取返回结果
其他细节差异
错误处理:默认 Informatica 写入过程是分批 / 逐条的,当有错误后会跳过这条进行后续的,并记录下来;ADF 默认是出错后直接停止报错,可以配置错误记录位置并跳过(ADF 更像是一个开放的云平台,给的资源并不多,这里就要自己有资源存储位置了)。
运行环境变量:Informatica 可以通过变量的方式获取上次运行时间等信息,ADF 需要自己存好、需要的时候取来用自己配置好这一套记录方式,还是上面说的给的资源并不多
自定义能力:Informatica 几乎对于每一个行为都给了前后可自定义执行脚本的功能,比如 source 在获取数据前后有 pre sql 和 post sql,同时可以在读取同时进行 sort 和 filter 等操作,ADF 对于自定义脚本执行等功能相对较少,但可以通过各种功能块魔改出来
upsert 功能:ADF 并不原生支持,需要自己通过存储过程等方式执行,会多一次数据拷贝,尤其是对于其也不原生完整支持跳过错误并记录等功能,需要自建很多存储过程。并且由于调用的是存储过程将难以参看 upsert 进度。
datasets:ADF 独有的一个概念,将 connect 与某个表绑定到一起,实现了复用,但是对于 copydata 的 target(sink) 要求必须使用 datasets,这样在拷贝操作数量极其庞大时下会产生海量的 datasets,而且复用就意味着一个改了其他的连带的被改变,增加了这一层不知道有什么特殊目的
……
敏捷团队如何做基于数仓的报表
最初开始时,不能把数仓的设计当多一个简单地 epic,认为只是在一个业务功能的开发,否则后患无穷。
开始时需要整个团队了解认知要做的是什么,在业务明确后进行一次整体设计,制定好开发方式以及严格的详细的 code review 过程,我们还需要尽早的考虑多个超出报表最终产物的内容,比如:
- 数据来源稳定性
- 第一次上线大量数据如何处理,根据什么分库分表?还是根据时间段划分?
- 如何测试
- 报表结构合理性
- 更新频率
- 共用数据 / 字段以及如果在频率不同时确定依赖关系
- ……
不要直接就 IPM、开卡、逐个报表开发,否则上面的几个问题后续会不断地对进行遍及所有报表全面改动,进一步衍生出遍及所有报表的全面测试,以及遍地 bug 四处救火的收尾时期……
数据仓库只是开始
回看前面多篇文章,我们可以发现数仓很大的问题:
- 单体架构,随着规模的庞大数仓如何支撑复杂运算与大量数据
- 层次紧耦合,虽然有 ETL 的逻辑与数据解耦但仍然是难以拆解的层次耦合,超级复杂的层次关系
- 数据流复杂,经过多层的梳理,数据经历了业务库、OBS、事实与多层维度、多层指标……以及中间的各种 ETL 逻辑,如何梳理出最终一个数的来源?
- 领域知识传输困难,数仓的复杂性往往会独立构建团队,这就与业务团队分离了,业务知识传递过程难免遗漏,而且业务逻辑的变化如何对应的更改呢?
- 增量困难,数仓的设计可以看到更加的偏重于设计,如果有超出设计的需求出现,我们如何快速的响应?构建新的 obs 表,重建维度模型或者是在一堆模型里找线索?如何新增一个产品的数据呢?
- 低演进能力,几乎无法演进的设计是由于上面各项导致的牵一发而动全身,谁敢随便改?单纯从技术角度来看看一个 table 会被什么使用: view、procedure、etl……
后面该如何?Data Lake~Micro Data Warehouse~Data Mesh~
我们真正希望的是挖掘出数据的潜在价值,让资源尽可能的充分利用。支撑业务系统是数据的第一价值,然后呢?
感谢阅读,欢迎关注微信公众号:coologic
报表相关的系列文章请参考:
最新评论