官方承諾：K60至尊版將會首批升級MIUI 15
全新的MIUI 15今天也有了消息，在官宣了K60至尊版將會搭載天璣9200+處理器和獨(dú)顯芯片X7的同時(shí)，Redmi給出了官方承諾，K60至尊重大更新首批升級，會首批推送MIUI 15。也就是說雖然
作者 | 廖光明
隨著數(shù)據(jù)在越來越多的企業(yè)中被應(yīng)用，數(shù)據(jù)技術(shù)的發(fā)展可謂突飛猛進(jìn)。不僅基于Hadoop的大數(shù)據(jù)生態(tài)在持續(xù)完善，我們也能看到很多新興的分布式技術(shù)如潮水般涌現(xiàn)。
雖然數(shù)據(jù)技術(shù)發(fā)展飛快，但是對于做數(shù)據(jù)開發(fā)的我們，整個(gè)數(shù)據(jù)項(xiàng)目開發(fā)過程還是很痛苦。我們接觸過的客戶常常這樣抱怨：
這是什么原因呢？我們發(fā)現(xiàn)這常常是由于團(tuán)隊(duì)的數(shù)據(jù)工程實(shí)踐做得不夠好。
想要規(guī)模化實(shí)施企業(yè)數(shù)據(jù)項(xiàng)目開發(fā)，除了數(shù)據(jù)技術(shù)之外，數(shù)據(jù)工程實(shí)踐也得跟上。
這篇文章的內(nèi)容是結(jié)合我們在多個(gè)客戶的數(shù)據(jù)項(xiàng)目經(jīng)驗(yàn)，給大家分享一些行之有效的數(shù)據(jù)工程實(shí)踐。
首先，我們需要了解一下什么是數(shù)據(jù)工程。
我們一般理解的工程是以解決實(shí)際生活中的復(fù)雜問題為目標(biāo)，通常是以團(tuán)隊(duì)為單位進(jìn)行實(shí)施，綜合利用各種科學(xué)知識及經(jīng)驗(yàn)解決問題（參考wiki）。軟件工程則是在軟件開發(fā)領(lǐng)域的工程，它綜合利用各類軟件構(gòu)建知識、技術(shù)工具及經(jīng)驗(yàn)來構(gòu)建復(fù)雜軟件。
IEEE將軟件工程定義為：
將系統(tǒng)化的、規(guī)范的、可度量的方法用于軟件的開發(fā)、運(yùn)行和維護(hù)的過程，即將工程化應(yīng)用于軟件開發(fā)中。
數(shù)據(jù)工程是在數(shù)據(jù)開發(fā)這個(gè)特定的軟件開發(fā)領(lǐng)域的軟件工程，可以定義為綜合利用各類軟件構(gòu)建知識、數(shù)據(jù)技術(shù)及工具、經(jīng)驗(yàn)來構(gòu)建復(fù)雜的數(shù)據(jù)產(chǎn)品。
敏捷軟件開發(fā)已經(jīng)成為應(yīng)用軟件開發(fā)的主流工程方法。有大量團(tuán)隊(duì)驗(yàn)證了敏捷方法中推薦的實(shí)踐的有效性。
數(shù)據(jù)開發(fā)屬于一個(gè)特定的軟件開發(fā)領(lǐng)域，大部分的應(yīng)用軟件開發(fā)方法可適用于數(shù)據(jù)開發(fā)，敏捷軟件開發(fā)方法自然也不例外。因此，我們可以將敏捷數(shù)據(jù)工程定義為：
將敏捷軟件開發(fā)的思想應(yīng)用于數(shù)據(jù)開發(fā)過程中，得到的一系列工程方法的合集。
很多敏捷軟件開發(fā)思想源于極限編程，其要旨在于通過將好的實(shí)踐做到極致來改善軟件質(zhì)量。例如，構(gòu)建持續(xù)集成流水線可以讓每次提交代碼都進(jìn)行集成，從而避免集成造成的問題。另外，通過將盡可能多的項(xiàng)目內(nèi)容代碼化，可借助版本控制工具來追蹤每次修改的內(nèi)容。
在將敏捷思想應(yīng)用于數(shù)據(jù)工程時(shí)，也需要根據(jù)實(shí)際情況進(jìn)行適當(dāng)?shù)牟眉艉驼{(diào)整。
數(shù)據(jù)工程內(nèi)容非常廣泛，包括數(shù)據(jù)需求分析、數(shù)倉設(shè)計(jì)、數(shù)據(jù)開發(fā)過程、數(shù)據(jù)測試、數(shù)據(jù)運(yùn)維、數(shù)據(jù)項(xiàng)目管理等。結(jié)合敏捷的思想，本文希望拋磚引玉，挑選三個(gè)方面的實(shí)踐方法做一些分享：
在應(yīng)用軟件開發(fā)中，“代碼化一切”被討論得很多。常見的代碼化XX有：
還有更多的比如：
從上面這些“代碼化XX”中，我們可以看到一個(gè)趨勢，似乎我們正在嘗試把“一切”代碼化。為什么“代碼化”這么有吸引力？
這要追溯到開發(fā)人員日常工作方式中。作為一個(gè)程序員，每天做得最多的事情是寫代碼，最習(xí)慣最熟練的工作也是寫代碼。通過一個(gè)熟悉的集成開發(fā)環(huán)境（IDE）或者文本編輯器，開發(fā)人員可以高效的編寫、調(diào)試代碼并完成工作。
正由于此，現(xiàn)在市場上有大量成熟的幫助開發(fā)人員寫代碼的工具。它們大都支持了數(shù)量眾多的快捷鍵，可輔助編寫代碼的智能代碼提示，語法檢查等等對代碼編寫非常友好的功能。開發(fā)人員還往往會根據(jù)自己的習(xí)慣對這些工具進(jìn)行配置，以便達(dá)到最高的編碼效率。
不難看出，正是由于這些工作方式，所以開發(fā)人員會更希望以代碼化的方式來工作，這也就推動了“代碼化一切”這樣的工程思想的發(fā)展。
除了可以高效編輯之外，代碼化之后還能獲得這樣一些好處：
數(shù)據(jù)開發(fā)中，我們一般要面對這樣幾類開發(fā)資源：基礎(chǔ)設(shè)施、安全配置、ETL代碼、ETL任務(wù)配置、數(shù)據(jù)流水線、運(yùn)維腳本、業(yè)務(wù)注釋等。
事實(shí)上，這些資源均可以很容易的被“代碼化”。
基礎(chǔ)設(shè)施可以通過Terraform進(jìn)行代碼化。如果整個(gè)系統(tǒng)運(yùn)行在類似Kubernetes這樣的容器平臺上，也可以Kubernetes提供的YAML來定義基礎(chǔ)設(shè)施。
安全配置代碼化常常需要一定的開發(fā)成本，一般可借助于各類安全管理應(yīng)用提供的API進(jìn)行代碼化。一個(gè)推薦的做法如下。首先根據(jù)具體的應(yīng)用場景設(shè)計(jì)安全管理模型，并據(jù)此模型定義（較少的）配置項(xiàng)，然后提供一個(gè)程序讀取這些配置，并根據(jù)安全管理模型生成安全管理工具提供的API所對應(yīng)的數(shù)據(jù)，最后調(diào)用安全管理工具提供的API完成安全配置的應(yīng)用。
ETL一般以代碼的形式存在，大部分的數(shù)據(jù)開發(fā)工具都提供了功能，使得開發(fā)者可以用SQL的來開發(fā)ETL。但是只有SQL常常難以滿足開發(fā)需求，比如，我們很難在SQL中發(fā)送HTTP請求、打印日志或斷點(diǎn)調(diào)試。這里可以推薦Thoughtworks開源的Easy SQL，它基于SQL進(jìn)行語法增強(qiáng)，提供了一種方式使得我們可以更加模塊化的組織ETL代碼，支持了變量、日志打印、斷言、調(diào)試、外部函數(shù)調(diào)用等等功能。有了這些功能，我們可以在ETL代碼中完成各式各樣的工作，無需再結(jié)合其他工具使用，也無需自己編寫復(fù)雜的代碼。
ETL任務(wù)配置是指ETL任務(wù)運(yùn)行時(shí)使用的各類配置。很多數(shù)據(jù)計(jì)算引擎都提供了配置接口，以便我們可以根據(jù)需要來配置最適當(dāng)?shù)挠?jì)算資源、配置程序運(yùn)行所需的外部文件、配置算法等。這些配置看起來不起眼，但是也非常重要，因?yàn)樗鼈兂３？梢詻Q定程序運(yùn)行時(shí)性能，而這跟ETL任務(wù)的運(yùn)行時(shí)間、穩(wěn)定性緊密相關(guān)。所以，將ETL配置納入到代碼庫中管理就顯得十分必要。Easy SQL提供了一種能力，使得開發(fā)人員可以在ETL文件中定義ETL執(zhí)行所需的配置，是一種支持將配置與對應(yīng)的代碼放在一起的好的實(shí)踐。
數(shù)據(jù)流水線常常以一種“非代碼化”的方式進(jìn)行開發(fā)。很多調(diào)度工具都提供了界面，使得我們可以通過拖拽及配置來完成流水線的開發(fā)。比如阿里的Dataworks，Azure的ADF等。以“非代碼化”的方式開發(fā)流水線的靈活性很差且無法享受到版本控制的優(yōu)勢。一些開源工具提供了代碼化能力，比如受到很多數(shù)據(jù)開發(fā)人員喜愛的Airflow，它支持用python代碼來定義數(shù)據(jù)流水線，然后根據(jù)流水線定義進(jìn)行可視化展示。對開發(fā)人員更友好的方式是，提供一種自動管理數(shù)據(jù)流水線的機(jī)制，這樣開發(fā)人員就無需編寫流水線了。這是可能的，事實(shí)上，完全可以編寫一個(gè)程序，解析出ETL代碼中的輸入輸出表，然后根據(jù)這些信息自動提取ETL間的依賴關(guān)系，接著根據(jù)這些依賴關(guān)系就可以自動生成數(shù)據(jù)流水線了。
運(yùn)維腳本常常以代碼的形式呈現(xiàn)，但是很多數(shù)據(jù)工具希望將此類腳本納入工具內(nèi)部管理。這容易讓我們喪失代碼化的能力，因?yàn)樗偸枪膭钗覀儗⒋祟惔a配置到工具的UI界面里（可以想象一下在Jenkins還不支持用Groovy編寫CI/CD流水線時(shí)的使用方式）。
業(yè)務(wù)注釋是另一類可以考慮代碼化的資源。很多團(tuán)隊(duì)將此類信息納入到一個(gè)名為元數(shù)據(jù)管理的應(yīng)用中進(jìn)行管理。元數(shù)據(jù)管理應(yīng)用通常可以提供一些基于自然語言的搜索能力，而且可以提供友好的界面展示。這是其優(yōu)勢，但是對于此類信息的維護(hù)，就不得不在元數(shù)據(jù)管理應(yīng)用中完成。這常常帶來另一些問題。比如，當(dāng)我們重建某些數(shù)據(jù)庫表時(shí)，元數(shù)據(jù)管理應(yīng)用無法將原來的元數(shù)據(jù)遷移到新表。還比如，元數(shù)據(jù)管理應(yīng)用常常無法提供完善的數(shù)據(jù)版本管理功能，從而使得我們無法進(jìn)行版本追溯及回滾。如果將此類業(yè)務(wù)注釋放到代碼庫中進(jìn)行管理，就可以享受到代碼化的優(yōu)勢，并且，通過調(diào)用元數(shù)據(jù)管理應(yīng)用的API可以此元數(shù)據(jù)同步到元數(shù)據(jù)管理應(yīng)用，從而我們也能享受到元數(shù)據(jù)管理應(yīng)用提供的搜索即友好的數(shù)據(jù)展示的能力。
當(dāng)然，實(shí)際項(xiàng)目中可能還有其他一些沒有提到的資源類型，這里不在于為所有資源列舉代碼化方案，而是更多的提供一種代碼化一切的建議。當(dāng)我們發(fā)現(xiàn)團(tuán)隊(duì)正在以一種非代碼化的方式進(jìn)行數(shù)據(jù)開發(fā)時(shí)，可能需要思考有沒有什么好的方案可以轉(zhuǎn)變?yōu)榇a化的方式。這將給我們的開發(fā)帶來非常多的好處。
在應(yīng)用軟件開發(fā)中，代碼復(fù)用是一項(xiàng)顯而易見的工作，開發(fā)人員幾乎每天都會進(jìn)行。良好的代碼復(fù)用可以有效降低代碼重復(fù)率，提高效率，并減少潛在的BUG。
應(yīng)用軟件開發(fā)中有哪些復(fù)用代碼的方式呢？從代碼復(fù)用的粒度上看，有兩種基本的形式：
數(shù)據(jù)開發(fā)與應(yīng)用軟件開發(fā)存在一個(gè)顯著不同，那就是進(jìn)行數(shù)據(jù)開發(fā)時(shí)，我們不僅要關(guān)注代碼還要關(guān)注數(shù)據(jù)。
(1) 數(shù)據(jù)計(jì)算成本
在應(yīng)用軟件開發(fā)中，有了現(xiàn)代CPU的支持，一般而言，一段代碼的運(yùn)行非?？?。但是在數(shù)據(jù)開發(fā)中，我們經(jīng)常會發(fā)現(xiàn)運(yùn)行一個(gè)數(shù)據(jù)任務(wù)花費(fèi)的時(shí)間甚至比開發(fā)這個(gè)任務(wù)花費(fèi)的時(shí)間都長。這就導(dǎo)致我們不得不將很大的精力放在運(yùn)行數(shù)據(jù)任務(wù)上。
我們常常小心地設(shè)計(jì)或選擇算法，謹(jǐn)慎地優(yōu)化任務(wù)運(yùn)行所需的資源，仔細(xì)的比較兩種不同的存儲類型的性能差異，反復(fù)在同一個(gè)數(shù)據(jù)集上面進(jìn)行驗(yàn)證。
我們不得不這么做，因?yàn)橐欢涡阅艿拖碌臄?shù)據(jù)計(jì)算代碼，可能導(dǎo)致10倍的運(yùn)行時(shí)間延長，最后不僅消耗了大量的計(jì)算資源，還無法滿足業(yè)務(wù)需求。
在應(yīng)用軟件開發(fā)中，這個(gè)問題沒那么顯著，但是在數(shù)據(jù)開發(fā)中，這個(gè)問題的重要性就凸顯出來。因?yàn)槲覀兂３Ｐ枰{(diào)度上百臺計(jì)算機(jī)同時(shí)進(jìn)行運(yùn)算，這時(shí)，計(jì)算資源的支出就將成為我們不得不關(guān)注的問題。
以AWS云服務(wù)的定價(jià)進(jìn)行計(jì)算，采用AWS Glue服務(wù)做計(jì)算引擎，按照本文撰寫時(shí)的官方定價(jià)，如果調(diào)度100DPU進(jìn)行10小時(shí)的計(jì)算，則將花費(fèi)的費(fèi)用是100 * 10 * 0.44 = 440美元，也就是約3000人民幣的費(fèi)用！
這還只是一個(gè)數(shù)據(jù)計(jì)算任務(wù)的費(fèi)用，如果我們有100個(gè)任務(wù)呢？這個(gè)費(fèi)用支出確實(shí)不菲！
做應(yīng)用軟件開發(fā)時(shí)，我們常常說，可以用廉價(jià)的計(jì)算成本來代替較高昂的人工成本。但是這一條規(guī)則在數(shù)據(jù)開發(fā)中并不那么適用。
(2) 基于數(shù)據(jù)復(fù)用
耗費(fèi)如此長的時(shí)間與金錢才能計(jì)算出來的數(shù)據(jù)，自然是一筆重要的企業(yè)資產(chǎn)。于是，在數(shù)據(jù)開發(fā)中，我們采用最多的復(fù)用方式是基于數(shù)據(jù)的復(fù)用。
在數(shù)倉分層設(shè)計(jì)方法中，我們常常構(gòu)建可復(fù)用的數(shù)據(jù)分層，下圖是一個(gè)典型的數(shù)倉分層結(jié)構(gòu)。
ODS貼源層作為一個(gè)可復(fù)用的數(shù)據(jù)分層，為DWD明細(xì)層及公共維度層提供數(shù)據(jù)。DWD明細(xì)層及公共維度層作為基礎(chǔ)數(shù)據(jù)，為上層的眾多指標(biāo)開發(fā)提供數(shù)據(jù)支持。開發(fā)出來的指標(biāo)數(shù)據(jù)作為一個(gè)分層，支持更上層的數(shù)據(jù)應(yīng)用層數(shù)據(jù)。（此處的數(shù)據(jù)分層命名僅供參考，業(yè)界尚無統(tǒng)一的標(biāo)準(zhǔn)）
在實(shí)踐中，我們常常需要仔細(xì)設(shè)計(jì)數(shù)據(jù)分層，在不失靈活性的同時(shí)達(dá)到良好的復(fù)用效果。
基于數(shù)據(jù)分層的方式進(jìn)行復(fù)用應(yīng)用非常廣泛，但是它也存在一些缺點(diǎn)。
(1) 首先是靈活性較差。
后一層對前一層的數(shù)據(jù)存在很強(qiáng)的依賴，所以，如果前一層的數(shù)據(jù)結(jié)構(gòu)沒有被設(shè)計(jì)出來時(shí)，就無法進(jìn)行后一層的開發(fā)。而當(dāng)我們希望設(shè)計(jì)一個(gè)數(shù)據(jù)分層可以滿足后一層的大量的數(shù)據(jù)需求時(shí)，這里的設(shè)計(jì)又會變得特別復(fù)雜，常常要左右權(quán)衡，花費(fèi)了大量的后一層開發(fā)不愿意等待的時(shí)間。當(dāng)前一層數(shù)據(jù)構(gòu)建好了之后，如果后一層需要的數(shù)據(jù)無法滿足時(shí)，還不得不修改上一層的代碼并重新運(yùn)行計(jì)算任務(wù)。
(2) 其次是整體數(shù)據(jù)計(jì)算過程難以理解。
當(dāng)我們發(fā)現(xiàn)計(jì)算結(jié)果不符合預(yù)期時(shí)，我們往往要追溯從數(shù)據(jù)源開始的整個(gè)數(shù)據(jù)計(jì)算過程，仔細(xì)分析內(nèi)部轉(zhuǎn)換邏輯，才能找到問題。當(dāng)存在多個(gè)數(shù)據(jù)分層時(shí)，我們不得不往下查找每一層的計(jì)算過程。而越往下越難。這通常是由于下層在設(shè)計(jì)上要保持更高的適用度，以便支持更多的上層數(shù)據(jù)需求，而這導(dǎo)致很多與當(dāng)前需要的數(shù)據(jù)無關(guān)的計(jì)算雜糅在一起。
在分析問題時(shí)，一個(gè)較理想的情況是，和某個(gè)指標(biāo)相關(guān)的ETL的全部代碼都在一個(gè)文件里面，這樣就不需要多個(gè)文件跳轉(zhuǎn)。同時(shí)，我們也不希望有不相關(guān)的邏輯存在于這個(gè)ETL文件中，這樣我們就可以專注在問題分析上。基于數(shù)據(jù)分層的復(fù)用恰好產(chǎn)生了與期望相反的副作用。
在這里我希望給大家介紹“基于代碼的復(fù)用”這一實(shí)踐?；诖a的復(fù)用方式雖然可能會由于不能共享計(jì)算資源而導(dǎo)致付出較大的計(jì)算資源成本，但沒有上述缺點(diǎn)。而且，如何處理得當(dāng)，基于代碼的復(fù)用也可以一定程度上避免計(jì)算資源浪費(fèi)。
基于代碼的復(fù)用方式在數(shù)據(jù)開發(fā)中實(shí)踐不太多，但卻是非常值得嘗試的一個(gè)方向。
在數(shù)據(jù)開發(fā)時(shí)，如何使用在應(yīng)用軟件開發(fā)中廣泛使用的基于代碼的復(fù)用方式呢？
(1) 數(shù)據(jù)庫視圖
大部分?jǐn)?shù)據(jù)庫都提供了視圖機(jī)制，視圖是一個(gè)虛擬的表，它本身僅僅包含了一些轉(zhuǎn)換邏輯，但并沒有真實(shí)的將數(shù)據(jù)計(jì)算出來并存放在物理存儲中。這給我們帶來了一些啟示。是不是可以利用視圖的原理進(jìn)行代碼復(fù)用呢？視圖可以理解為一段代碼，查詢視圖即是在進(jìn)行代碼復(fù)用。
事實(shí)上，現(xiàn)在的很多數(shù)據(jù)庫還在視圖的基礎(chǔ)上提供了物化視圖的機(jī)制，我們可以將一個(gè)視圖轉(zhuǎn)換為物化視圖，讓數(shù)據(jù)庫在合適的時(shí)機(jī)將視圖中的數(shù)據(jù)計(jì)算出來，從而自動的提升數(shù)據(jù)計(jì)算性能。
視圖及物化視圖給我們提供了非常好的靈活性，因?yàn)槲覀冚p松的可以在基于數(shù)據(jù)的復(fù)用和基于代碼的復(fù)用兩者之間切換。
物化視圖還在一定程度上采用基于代碼復(fù)用的方式實(shí)現(xiàn)了基于數(shù)據(jù)的復(fù)用。
(2) 實(shí)現(xiàn)ETL執(zhí)行驅(qū)動器
除了基于視圖進(jìn)行代碼復(fù)用，還可以自實(shí)現(xiàn)一個(gè)ETL執(zhí)行驅(qū)動器，由它來提供一些代碼復(fù)用的機(jī)制。比如dbt Easy SQL就是這樣一些開源的ETL執(zhí)行驅(qū)動器。
Easy SQL提供了模板來實(shí)現(xiàn)類似函數(shù)級別的復(fù)用，詳情可以參考這里。同時(shí)它也提供了基于文件的復(fù)用，通過Include指令可以將其他ETL文件包含到當(dāng)前文件，詳情可以參考這里。
除了使用這些開源工具，想要自實(shí)現(xiàn)一個(gè)這樣的驅(qū)動器也不復(fù)雜。如果我們的計(jì)算引擎是 Spark，那么我們可以使用Spark的DataFrame API，進(jìn)行一些開發(fā)就可以完成。
如果有足夠的研發(fā)投入，基于自實(shí)現(xiàn)ETL執(zhí)行驅(qū)動器的方式可以做得非常智能，達(dá)到甚至超過數(shù)據(jù)庫視圖和物化視圖的效果。一個(gè)可以考慮的方向是，程序可以自動分析所有ETL執(zhí)行過程，然后用算法識別可以有較多復(fù)用的中間結(jié)果，然后自動將中間結(jié)果保存到某處。在后續(xù)ETL執(zhí)行時(shí)，自動從中間結(jié)果取數(shù)據(jù)，而不是重新計(jì)算。
目前市場上還未見到此類智能的ETL執(zhí)行驅(qū)動器出現(xiàn)，不過，在我看來，這是一個(gè)不錯(cuò)的研究方向。
在實(shí)際項(xiàng)目中，如何選擇復(fù)用方式呢？有以下建議可以參考：
我最近和一個(gè)做進(jìn)口貿(mào)易的朋友聊天，發(fā)現(xiàn)了一件很有意思的事：
他們公司進(jìn)口國外高端儀器，并幫助銷售公司處理競標(biāo)、合同簽訂、物流、海關(guān)、進(jìn)口貿(mào)易政策符合、維保等復(fù)雜的事務(wù)。我很好奇，為什么銷售公司不自己處理這些事務(wù)，反而出售給其他公司呢？向他請教后，獲得了很多啟示。
國內(nèi)工業(yè)起步較晚，雖然現(xiàn)在已成為世界工廠，但很多核心生產(chǎn)設(shè)備仍需要進(jìn)口。這個(gè)市場是一個(gè)萬億級的大市場。這個(gè)業(yè)務(wù)有什么特點(diǎn)呢？
那么，如何組織這種業(yè)務(wù)呢？
銷售是必須的，但其他事務(wù)是否必須自己做？這值得思考。因?yàn)殇N售量不大，但其他事務(wù)特別復(fù)雜。如果培養(yǎng)一個(gè)專業(yè)團(tuán)隊(duì)來做這些事，由于銷售量不大，團(tuán)隊(duì)工作勢必不會飽和。如果減少團(tuán)隊(duì)人員數(shù)量，這些事務(wù)又難以做得專業(yè)，容易出紕漏。
在市場嘗試和調(diào)整之后，專門做進(jìn)口貿(mào)易的企業(yè)就誕生了。他們負(fù)責(zé)產(chǎn)品銷售之外的大部分事務(wù)，包括競標(biāo)、合同簽訂、物流、海關(guān)、進(jìn)口貿(mào)易政策符合、稅收、維保方式設(shè)計(jì)等。他們通常是一個(gè)非常專業(yè)的團(tuán)隊(duì)，可負(fù)責(zé)各個(gè)領(lǐng)域不同產(chǎn)品的進(jìn)口貿(mào)易業(yè)務(wù)。
于是，海外產(chǎn)品研發(fā)公司、國內(nèi)產(chǎn)品銷售公司和國內(nèi)進(jìn)口貿(mào)易公司的模式就在市場上慢慢形成并穩(wěn)定下來了。這種模式提高了整個(gè)行業(yè)的效率和質(zhì)量，也是進(jìn)口貿(mào)易企業(yè)得以存在的原因。
從進(jìn)口貿(mào)易企業(yè)的興起中可以看到業(yè)務(wù)的重構(gòu)和演變，即，通過合理的抽取和拆分提升了整體的效率。
在應(yīng)用軟件開發(fā)中，我們常常僅設(shè)計(jì)一條持續(xù)集成流水線，在流水線中運(yùn)行所有的測試，接著將所有代碼打包成一個(gè)大的產(chǎn)品包，然后部署到測試或產(chǎn)品環(huán)境中。
在數(shù)據(jù)應(yīng)用中，是不是也需要這樣做呢？這樣做的好處是可以將產(chǎn)品環(huán)境的制品與代碼倉庫中的版本對應(yīng)。其劣勢其實(shí)也很多，比如，修改一個(gè)局部的代碼，就不得不運(yùn)行所有的測試，然后運(yùn)行流水線中所有耗時(shí)的步驟，可能還需要進(jìn)入手工測試的環(huán)節(jié)，最后才能發(fā)布到線上。效率非常低下。
這一問題在數(shù)據(jù)應(yīng)用中更是被放大了。因?yàn)閿?shù)據(jù)應(yīng)用通常涉及數(shù)百個(gè)指標(biāo)計(jì)算ETL，這些ETL的自動化測試只能用緩慢的集成測試來覆蓋，這就導(dǎo)致流水線中的測試步驟耗時(shí)很長。在我們的項(xiàng)目中，常常需要跑半小時(shí)到一小時(shí)才能跑完。
這就如同做進(jìn)口高端儀器銷售的公司，如果自己來做進(jìn)口貿(mào)易相關(guān)業(yè)務(wù)，不僅耗時(shí)特別長，而且出紕漏的可能性大（業(yè)務(wù)質(zhì)量低）。
有沒有更好的做法？既然只修改了某一個(gè)ETL，為什么不能就只部署和測試這個(gè)ETL？聯(lián)想到前面進(jìn)口貿(mào)易業(yè)務(wù)的抽取和拆分，是不是可以對流水線進(jìn)行抽取和拆分呢？即，做以ETL為單位的持續(xù)集成流水線。
在數(shù)據(jù)應(yīng)用開發(fā)場景中，這也是具備可行性的。原因在于，相比應(yīng)用軟件代碼中的一個(gè)一個(gè)類或代碼文件，ETL間幾乎沒有依賴。不同的ETL代碼通常有不同的入口，存在于一個(gè)獨(dú)立的文件。可以認(rèn)為一個(gè)ETL就是一個(gè)獨(dú)立的數(shù)據(jù)應(yīng)用。
事實(shí)上，如果以ETL為單位進(jìn)行持續(xù)集成和部署，還不用擔(dān)心自己的部署會影響到其他的線上指標(biāo)計(jì)算ETL，這也在一定程度上增強(qiáng)了安全性。
看起來，在數(shù)據(jù)應(yīng)用開發(fā)領(lǐng)域，以ETL為單位的持續(xù)集是順理成章的事。
對比一下微服務(wù)實(shí)踐，還可以發(fā)現(xiàn)，這一實(shí)踐與微服務(wù)中推薦的為每一個(gè)服務(wù)搭建一條持續(xù)集成流水線的實(shí)踐幾乎是等同的。
如何實(shí)現(xiàn)以ETL為單位的持續(xù)集成呢？
如果基于Jenkins，可以在流水線上面加一個(gè)參數(shù)，如“ETL文件路徑”，在運(yùn)行流水線時(shí)，可以指定這個(gè)參數(shù)，讓流水線僅針對指定的ETL運(yùn)行測試與部署。
如果覺得在Jenkins上面實(shí)施以ETL為單位的持續(xù)集成較為麻煩，也可以團(tuán)隊(duì)自主開發(fā)一個(gè)專用的數(shù)據(jù)持續(xù)集成流水線。如果僅實(shí)現(xiàn)基本的功能，其實(shí)也并不復(fù)雜。
需要注意的是，一旦以ETL為單位進(jìn)行持續(xù)集成了，就需要有一種方式記錄每一個(gè)ETL對應(yīng)的代碼倉庫里面的版本號，方便版本追溯。實(shí)現(xiàn)方式有多種，比如，可以在部署ETL的時(shí)候，在生產(chǎn)環(huán)境寫入一個(gè)該ETL對應(yīng)的版本文件。
本文介紹了什么是敏捷數(shù)據(jù)工程， 并分析了幾個(gè)有效的實(shí)踐。如果能靈活的在數(shù)據(jù)項(xiàng)目中應(yīng)用，將有效提升我們的數(shù)據(jù)產(chǎn)品交付質(zhì)量。
在數(shù)據(jù)開發(fā)領(lǐng)域，目前敏捷的應(yīng)用還處于前期探索階段，還有很多值得深入的方向，比如自動化的ETL測試、較短的單ETL文件、端到端數(shù)據(jù)能力的團(tuán)隊(duì)等等。希望和大家一起探索！
本文鏈接：http://www.tebozhan.com/showinfo-26-90662-0.html敏捷的數(shù)據(jù)工程實(shí)踐
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號