說批處理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體系架構的示意圖）
方案一的技術屬性標註：
.
方案二：基於Oracle PL/SQL的批處理ETL系統
在金融領域裡，大部分企業甚今還將Oracle資料庫作為技術選型的首選，當年就更不稀奇了，所以採用傳統OLAP數據清洗也是個不錯的選擇。
（圖3：基於傳統ORACLE OLAP的示意圖 ）
方案二的技術屬性標註：
從某種程度上看，方案一雖然無法與現代流處理同日而語，但就分布計算這一項而言並無太大差別。兩個方案，單從技術視角而言，優劣鮮明，但最終我們為了避免風險，並能在有效的時間下實現產品化，我們還是選擇了方案二。
值得一提，當方案選擇結果公布之後，此前極力擁護方案二的兩位核心開發提出離職，理由是 「毫無技術情懷，學不到東西」。
- 03. 實施：方案設計 -
由於採用純Oracle技術進行實現，架構細節就沒必要在這裡多費口舌了，我翻了翻資料，粗略的湊了湊當年的設計文稿：
（圖4：數據中心整體架構 ）
（圖5：數據中心整合流程 ）
（圖6：數據處理Processor - 樣例）
如果技術架構是命脈，那麼標準化則是靈魂，為產品化所設立的PL/SQL標準樣例：
（圖7：Oracle Procedure編寫規範 - 樣例）
- 最後總要說幾句 -
最終，這套系統不僅比原計劃提前一周上線，順利幫助公司度過了難關，並且藉助產品化策略的優勢，在只增加30%成本的基礎上，完成多家新增客戶在數據中心項目上的實施。
時光飛逝，在「流式數據處理架構」盛行的今天，仍然有不少企業的核心數據處理業務奔跑在「傳統ETL數據處理架構」上，用它的餘熱默默地為業務貢獻著自己的微薄之力。
或許，新技術能夠掀起一場大革命，但卻無法脫離 「理解業務，符合場景，風險評估，人才匹配」 等因素。
至於老技術是否已死，那還得看針對業務場景所做出的技術選型與架構設計是否更合理，更立竿見影。
畢竟，在許多業務驅動型的企業看來，能抓住老鼠的才是好貓，您說是嗎？
TAG:吃草的羅漢 |