ETL还是ELT.pdfVIP

ETL 还是 ELT ？ ETL 过程中往往含有大量的业务逻辑，实现这些业务逻辑仅仅依靠可视化的ETL 工具是不够的，大多数还需要通过硬编 码来实现。比如将某商场生产库中的购物记录ETL 到查询库中的会员积分表中，其业务逻辑为：超市商品及服装每10 元积 1 分，电子产品每20 元积1 分，金银珠宝每50 元积1 分，连续5 天消费后积分翻倍，每个月有3 次消费超过 1000 元则当 月积分翻倍。再比如这样的业务逻辑：根据利率变化计算银行客户的房贷余额，计算电信用户在不同优惠政策下的当月话 费。 实现上述业务逻辑的硬编码工具可以采用 ETL 脚本，也可以采用SQL\SP 。主流的ETL 脚本包括：TCL 、Perl、python、 以及一些 ETL 工具自带的脚本，这些语言大多擅长逻辑判断和流程控制，可以实现简单的数据整理工作，比如：数据类型 检查、增补缺失的字段、剔除重复数据、数据的国际化规范化。但缺乏批量结构化数据的计算语法或函数，比如：聚合、 分组、查询、排序、排名等，因此较难实现常规的业务算法，比如上面提到的会员积分、房贷余额、当月话费。要实现上 述业务算法，程序员不得不先实现批量结构化数据计算的底层函数，这个工作量相当大，因此 ETL 脚本只能在业务逻辑较 为简单的个别场景见到。 ETL 脚本难以实现业务逻辑，导致用户经常选择SQL\SP 来实现硬编码。这是因为SQL\SP 内置批量结构化数据的计算函 数，同时也支持逻辑判断和流程控制语法，可以实现较复杂的业务逻辑。这时，ETL 过程就变成了ELT 过程（实际是ELTL）， 其步骤一般是： 1. 从业务数据库\Txt\ 日志\Excel 等原始数据源中Extract 数据。 2. 将数据简单 Load 到中间数据库中，直接Load 基本不做计算。 3. 在中间数据库中进行Transform ，通过SQL\SP 实现业务逻辑的硬编码。这里是整个ELT 过程的核心。 4. 将计算结果 Load 进目标数据库，一般是数据仓库或非生产的查询库。 用SQL\SP 来实现Transform 的好处是业务逻辑易于实现，但它的缺点也很明显：性能差，成本高。 性能差。 用SQL\SP 来实现ELT 中的业务逻辑，就必须先将原始数据Load 到中间数据库中。这只是个简单的数据复制过程，并不 涉及清洗转换，本质上就是向硬盘文件原样写入数据，但对数据库来说这却是个极其耗时的过程。和向硬盘写文件不同， 向数据库插入数据是个复杂的过程，会涉及数据一致性、日志、约束索引、数据块连续性、分区等等因素，因此它的 I/O 性能极低。即使经过优化，将数据复制到数据库也比直接复制到文件经常会慢出1 个数量级。 ELT 中涉及的原始数据一般都比较大，比如银行的房贷客户，总数可能涉及数千万人；电信的通话记录，每天都会产生 上亿条；再比如大型连锁商场的购物明细，每个月都会产生TB 级的数据。可以想象，将原始数据 Load 进数据库会带来性 能的急剧下降，这将严重影响报表和业务分析的可用性。 成本高。 成本过高是ELT 的另一个障碍。 要想提高SQL\SP 的性能，用户必须对数据库升级。传统非MPP 数据库的升级就是纵向扩容，即通过增加硬件配置来提 高性能。纵向扩容的缺点是很容易到达性能瓶颈，同时性能的提升并不明显，并不能彻底解决问题。MPP 数据库支持并行 计算和横向扩展，可以实现高效的ELT 过程，但它会带来成本问题。迄今为止，所有产品级的MPP 数据库都是专有的，价 格非常昂贵。使用MPP 数据库，项目的初期成本以及将来的升级成本都将是个沉重的负担。 另外，ELT 要求用数据库暂存原始数据，这就需要购买额外的数据库存储设备和相应的授权，很多情况下这会导致成本 的升高。 ETL 脚本缺乏批量结构化数据计算的语法和函数，而SQL\SP 的性能差、成本高，这使ETL 中业务逻辑的计算困难重重， 用户不得不在繁重的工作量和低性能高成本中进行无奈的选择。因此，ELT 最常遭到诟病的就是遥遥无期的开发周期、迟缓 失效的分析结论、远超预算的建设成本。 如何实现带有业务逻辑的ETL 过程，如何在成本可控的情况下降低开发难度并获得高性能，使用esProc 是可选的方案 之一。 esProc 是针对结构化数据计算的程序设计语言，它提供了丰富的内置对象和库函数，可以实现复杂的业务逻辑，同时 还能降低从业务逻辑到程序代码的转换门槛。其中，有序集合可以解决