ETL，是英文 Extract-Transform-Load 的缩写，用来描述将数据从来源端经过抽取（extract）、交互转换（transform）、加载（load）至目的端的过程。       

作为一个做了快三年To C端产品的PM来说，初识ETL的概念，源自刚开始进入TO B金融数据处理系统时一个资深PM的引导。只要做数据，不管是结构化数据还是非结构数据，不可避免地需要涉及到数据的抽取、清洗、转化，并同步给各个产品端来使用，我所在的数据工具团队团队首先需要支持的就是各个分层数据的推送处理，如何设计一套数据推送工具，能够让数据业务团队能够操作简单、快速上手、实时同步、性能稳定，是摆在我们面前的一道难题或者说是新的挑战。

由于自己所在的产品线经过一些调整，产品的整个生命周期没有完全参与进去，陆陆续续地作为ETL的产品经理去改造设计、商业变现，也对ETL这一产品有比较深的理解和感悟，在此分享给大家，只要能给你带来一点启发就足矣。

关于ETL这一产品经历了从初探、深入到成熟的三个阶段。

阶段一：初探阶段

数据业务方挂在嘴边的数据推送，一开始是通过开发写代码实现的，涉及到的数据业务表少的话，可以这么做，但是随着数据业务的发展，需要推送处理的业务表增加到了几十个了，由开发处理不仅耗时、维护还困难，于是就开始了自研版的ETL1.0的推送工具设计和研发。

上线的ETL1.0版本，确实起到了很大的作用，业务人员通过简单的推送模型配置和调度配置即可快速完成1个数据表的推送，经过几个版本的迭代，很多业务所需要的推送需求都迁移到了ETL工具上，省心省力。

然而，数据量越来越大，业务的复杂度越来越高，ETL的矛盾已经转化为日益增长的大数据量的业务需要和同步性能跟不上的矛盾，主要体现在：数据源与目标源的数据业务差别越来越多、转化配置需求愈发地多样和高频、大数据量的同步性能也有了瓶颈。。。。。。

慢慢地也就开启了ETL2.0阶段——基于开源的Kettle工具来进行数据的抽取、转化、加载。

新生树苗

阶段二：深入阶段

从自研的ETL1.0阶段进入基于Kettle二次开发的ETL2.0阶段，是一个重要的转变，也是一个正确的转折点。

在ETL1.0阶段，积累了大量的业务使用场景，这对于To B产品而言，可以更好地在Kettle的基础上，去深入到产品易用性、稳定性的研究上。

盗图侵删

“免费开源的基于java的企业级ETL工具，功能强大简单易用，无可抗拒！ ” 

基于此，开发人员开始了ETL的研究，在这一过程，对于产品经理而言，也是有诸多挑战。

产品经理在这一阶段能够做什么？如何发挥自己的价值？

对于缺少技术背景的产品而言，如何与开发、测试、业务人员更好地配合，快速把kettle用起来？

基于Kettle的二次开发后的产品，如何更大程度地满足业务人员的业务需求和使用习惯？

如何面对复杂的内部业务和外部客户，将ETL产品化和商业化？

TO B产品只有用起来，才能好起来。ETL 2.0阶段初始，面向的是内部数据业务部门，随着对外客户需求的挖掘和拓展，发现这一需求在很多行业都有广泛深刻的痛点，这一产品在很多数据部门都有切实可行的应用场景。于是乎，一个个项目的POC开始了。

POC测试，即Proof of Concept，是业界流行的针对客户具体应用的验证性测试，根据用户对采用系统提出的性能要求和扩展需求的指标，在选用服务器上进行真实数据的运行，对承载用户数据量和运行时间进行实际测算，并根据用户未来业务扩展的需求加大数据量以验证系统和平台的承载能力和性能变化。

经过POC过程中的打（shou）磨（nue），产品的功能日益完善、性能日益提升，产品慢慢好用了起来。

成长小树

阶段三：成熟阶段

为什么说ETL进入了成熟阶段？那是因为可以商用了，有客户买单了。

这一阶段，ETL进入3.0阶段，内部业务部门使用、外部签约客户实施、新的商业机会验证，纷纷给这一时期的ETL带来了养分，引导着他茁壮成长，也慢慢成熟，最为产品经理而言，也甚是有老母亲的欣慰感。

成熟大树

ETL会不断迭代，进入4.0/5.0/6.0时代，或许之后的roadmap我将无法参与，但是曾经1年多的产品经历，希望可以进行回顾、复盘、总结，能够给后来的人一些ETL产品生命脉络的溯源，也希望让自己一个完整的交代。

接下来，我会从自己的产品视角，去做一些ETL产品的科普或者说是分享。