介绍一下一般开发 ETL 的流程。每只 ETL 都可以看作是独立的程序，有独立的开发流程。但是不同的 ETL 程序又可以使用类似的系统或架构来帮助开发和管理。

Initiate & Design

资料面

跟一般的软件开发一样，先从最关键的点开始做 POC，确认商业逻辑和资料是可行的再做後续开发。

如果是简单的 SQL Aggregation，就先确认 SQL 语法和逻辑没有问题；如果是比较复杂的流程（例如多个 ETL 转换），就要先确认每次 SQL 的结果与运算是没有问题的。等流程确认好之後再着手开发正式的 ETL Job。

一般来说大部分的 ETL Job 流程会很雷同，所以在设计上需要反覆将雷同的部分精炼成共同的元件，这样 Job 之间只要最小幅度的改动商业逻辑或变项就能快速开发新的 ETL Job。

系统面

以下就提几点在设计 Data Pipeline 系统时，通常需要考量的点：

• 资料延迟性
  这边的延迟性是只说从收到资料到处理资料需要多久时间、可以容忍多久的延迟？这会影响到资料需要做即时处理还是批次处理？例如硬体系统的监控资料、或是线上使用者人数可能需要即时，或至少五分钟内的资料。如果像是每天看的 BI 报表，需要等前一天的资料都收完才能计算的，处理频次就是每天一次，相对来说也可以容忍比较大的延迟。

• 资料精准性
  在计算资料时，需要到多精准？例如银行的金额就没有容许误差的可能；但是像是线上即时使用者数、或是推文数就多少有误差的空间。那另外像处理即时资料时，要求是「最少一次」还是「仅此一次」？对於资料先後顺序有没有特别要求？如果使用者每天需要 Aggregate 一次资料，那原始资料中每条资料的先後顺序或许就没有太大影响。

• 系统的高可用性
  一般来说越接近资料源的「资料收集」系统，越注重高可用性。因为最源头的资料一但掉了就ＧＧ了。必须让原始资料尽早落地，才能安心做後续资料清洗或计算等开发。

• 其他维运面考量
  系统能不能支援版本回滚？
  资料处理逻辑有时候难免会更新，如果错的话能不能快速回滚的之前的版本重跑资料？

• 纪录任务进行时间
  能不能量测每次的时间，如果有天处理时间异常增加能不能发送告警？

• 防止错误资料进入正式环境
  资料处理有件有趣的事情是，即便程序逻辑正确，也不代表商业逻辑正确。通常一个新上线或是新修改後的资料处理程序，不会马上将结果导入正式环境中以免污染当前的资料。如何透过环境设定切割来做到这件事，後面会有专文讨论。

• 资源监控
  能否简单监控甚至预测所需资源？

• 易於开发/部署
  开发 Data Pipeline 系统的人，和之後使用 Data Pipeline 建立任务的人可能是不同的两群人（例如系统架构师开发系统、之後交由资料工程师建立任务）。那这套系统使用的语言能不能符合之後使用者主要的开发语言？或能不能允许其他语言来使用（例如 Python 或 Shell Script）

• 自动化的维运工具
  Data Pipeline 系统和其他任何软件系统一样都需要维运，越自动的维运机制以及越完整的自我修复功能，都能大大降低未来的负担。

Implement

变数设置

为了减少程序的变动，一些常用容易变化的部分建议抽出来做成变项，同长几个比较固定的变项会包括：

• database 和 table 的名称
  对於 ETL 来说， database 和 table 的名称很容易根据部署的环境和阶段来改变，透过变数来管理会比较方便。

• 连线方式
  呈上，连线路径、帐号密码也是独立於商务逻辑会根据状况改变的部分，所以这部分也需要透过变数来管理。

如果有些 Adhoc Query 只有每次搜寻条件不一样的话，也可以将 where condition 做成变数，这样就可以很简单的下类似的查询。

测试

通常测试会有几个阶段

• Unit Test：如果你有自己些处理资料小工具的话，会针对这个小工作来做 Unit Test，例如测试能不能顺利读取档案、将清除不合法的资料，再将资料存到 DB 去等等。这边通常会用 Mock 或是小量的资料来做 Unit Test。

• 整合测试：每个 ETL Job 是由多个小的 Task 组合再一起，这边主要是测试流程和商务逻辑。
  Staging 环境测试：Staging 环境理论上资料会近似生产环境，这边主要是测试 ETL Job 能不能负荷生产环境的资料的量，包括能不能在预定的时间内将结果产出、运算资源是否足够等。

Deployment

一般程序部署流程就是分 Staging 和生产环境，但是如前面文章说的，资料很的不确定性很高，为了怕资料在意外的情况下污染到正式环境的资料，所以理想上的部署流程上可以分为这几个阶段：

• 资料来源：Staging；ETL 後的产物：Staging
• 资料来源：Production；ETL 後的产物：Staging
• 资料来源：Production；ETL 後的产物：Production

Evaluation

正式上线後，还是要注意资料品质和 ETL 运行状况，通常可以分为资料和资源两个面向来做监测：

• 资料面
  基本的包括每天原始资料量、处理後的资料量、以及处理过程中有没有错误的状况。比较进阶的话还会监测几个关键的统计值，确保资料有没有异常。

• 系统面
  包括运算资源以及储存资源的监控。当 ETL Job 越来越多的时候，就要观察运算环境的资源够不够，不然不同排程的运算相互冲突时，会造成运算失败或是没有在预计的时间内完成。

除此之外，储存资源的监控也是非常必要，有时候运算单元会在 local 存放暂存档案，当硬碟爆满将会造成任务失败；另外生产环境中的储存空间也是要持续监控，不管是前端收资料的 Kafka、或是存放最终资料的 DB，一但没有注意到将会造成资料永久的损失。

小结

跟任何一项开发一样，在实作 Data Pipeline 之前，一定要先确认需求。而且因为资料有重力（Data Gravity），千万不能只满足当下需求，更要再多想一点点，不然之後在搬迁或是转移上会很麻烦滴。