说批处理ETL已死？这让我想起十年前，那个挽救过公司命运的传统ETL项目

也许是命运的捉弄，也许是机缘的巧合，在我职业生涯得前半段里，与「数据转换和处理」之间曾留下过不少的故事片段。

或许也正是因为这些故事片段的弥补，才使我的职业生涯显得不那么枯燥乏味。

与所有的科技系相同，「数据转换和处理」也在过去二十年间随着需求的变化而不断成熟起来，之前基于数据仓库数据模型的模式逐渐与当今时代之间显得格格不入，主要归因或许就像文章中所提到的那样：

传统ETL 的数据清洗和管理需要手工操作并且易于出错；

传统ETL 的操作成本很高：它通常很慢，并且是时间和资源密集型的；

传统ETL 所构建的范围非常有限，只关注于以批处理的方式连接数据库和数据仓库；

历史总是惊人的相似，这些 “传统ETL” 的疾病早在十年前，在那个关乎我当时就职公司 ‘生死存亡’ 的评审会上，也被批的体无完肤……

- 01. 时代：项目背景 -

回首十年前，相信许多小伙伴都为之振奋，2008，奥运年，但对金融领域的小伙伴来说，也许只能形容为颤抖。

2008，由金融危机所引发的连锁反应至今历历在目，此间受冲击最大的莫属那些为金融领域服务的软件公司。

当时，我所处的是一家向基金公司提供应用与数据服务的软件公司，尤其在「CRM与数据处理」有着不错的口碑，但随着金融危机的到来，各家基金公司都或多或少的削减信息化投入。

与众多软件公司所采取的方式雷同，我们开始尝试从「项目化」转型为「产品化」。

（图1：当年所做的转型说明，忽悠的功力凸显）

显而易见，仰望星空是务虚的，脚踏实地是务实的，在产品化提出才不到半年，也许是受金融危机影响，公司的财务状况急转直下，不仅开始拖欠社保，而且账上余额也只够再支撑两个月的工资发放，除此之外，已再无回天乏术……

此时，提出产品化策略之后的首个版本 ——「XSD数据中心3.X」，也即将进入设计阶段，而距离产品交付也只剩不到两个月时间了。

更值得一提的是，产品交付的对象恰恰正是当年国内最为知名、规模较大的某金融公司。

如果第一炮打响，不但工资有了找落，而且品牌效应极利于推广，对于公司而言，命悬一线，直到今天我还是想用这四个字来形容当时的感受。

- 02. 博弈：架构选型 -

在陈述技术选型的博弈过程之前，先来说下针对客户需求所整理出的技术要求：

基础数据：600W（预计年度增长100%）/用户

衍生数据：3000W（预计年度增长200%）

报表数量（固化）：480张/日

批处理ETL时间：小于3小时30分

由于时间跨度较长，我已无法准确的写出精确的技术指标，但从以上四项信息中已足以看出，即便在十年前，无论从性能、容量、扩展性及业务特性都可以算规模不小。

方案一：基于JMS体系架构的批处理ETL系统

在WebLogic+Tuxedo流行的岁月里，基于JMS的体系架构，我们很容易就能实现类似伪分布事件驱动的数据处理系统。

（图2：基于JMS体系架构的示意图）

方案一的技术属性标注：

可扩展性：高

技术风险：高

技术力量（WebLogic）：低（无精通）

技术耦合度：低

技术抽象度：高

时间成本：高

.

方案二：基于Oracle PL/SQL的批处理ETL系统

在金融领域里，大部分企业甚今还将Oracle数据库作为技术选型的首选，当年就更不稀奇了，所以采用传统OLAP数据清洗也是个不错的选择。

（图3：基于传统ORACLE OLAP的示意图 ）

方案二的技术属性标注：

可扩展性：低

技术风险：低

技术力量（Oracle）：高（有不少）

技术耦合度：高

技术抽象度：低

时间成本：低

从某种程度上看，方案一虽然无法与现代流处理同日而语，但就分布计算这一项而言并无太大差别。两个方案，单从技术视角而言，优劣鲜明，但最终我们为了避免风险，并能在有效的时间下实现产品化，我们还是选择了方案二。

值得一提，当方案选择结果公布之后，此前极力拥护方案二的两位核心开发提出离职，理由是 “毫无技术情怀，学不到东西”。

- 03. 实施：方案设计 -

由于采用纯Oracle技术进行实现，架构细节就没必要在这里多费口舌了，我翻了翻资料，粗略的凑了凑当年的设计文稿：

（图4：数据中心整体架构 ）

（图5：数据中心整合流程 ）

（图6：数据处理Processor - 样例）

如果技术架构是命脉，那么标准化则是灵魂，为产品化所设立的PL/SQL标准样例：

（图7：Oracle Procedure编写规范 - 样例）

- 最后总要说几句 -

最终，这套系统不仅比原计划提前一周上线，顺利帮助公司度过了难关，并且借助产品化策略的优势，在只增加30%成本的基础上，完成多家新增客户在数据中心项目上的实施。

时光飞逝，在「流式数据处理架构」盛行的今天，仍然有不少企业的核心数据处理业务奔跑在「传统ETL数据处理架构」上，用它的余热默默地为业务贡献着自己的微薄之力。

或许，新技术能够掀起一场大革命，但却无法脱离 “理解业务，符合场景，风险评估，人才匹配” 等因素。

至于老技术是否已死，那还得看针对业务场景所做出的技术选型与架构设计是否更合理，更立竿见影。

毕竟，在许多业务驱动型的企业看来，能抓住老鼠的才是好猫，您说是吗？