使用高階程式語言編碼資料管道的時間
> good old "use the right tool for the job"
etl管道已經使用sql建立了幾十年，由於許多眾所周知的原因，它執行得很好（至少在大多數情況下）。
在大資料時代，工程師和公司瘋狂地採用新的處理工具來編寫其etl / elt管道（例如spark，beam，flink等），並開始編寫**來代替sql過程來提取，載入和轉換其龐大的（ 或很少-如此！）的資料量。
測試etl / elt管道的時代
由於現在可以將etl / elt管道實現為以高階程式語言（例如scala，j**a或python）編寫的（一系列）作業，因此，您的所有處理步驟都表示為可以結構化，設計和大部分**化的**。 所有這些都完全覆蓋了自動化測試，以建立可靠的開發和部署管道。 實際上，資料工程師現在可以利用在包括git，pull request，自動化測試，構建甚至部署在內的常見工具的環境中工作，從而告別了嵌入巨大sql查詢的視覺化工具，這些sql
查詢幾乎是無法測試，難以理解，難以維護且令人討厭的 由任何開發人員（參與傳統dwh開發的人員都可以聯絡）。
這種執行etl / elt的新方法最被低估的好處是，對於資料管道而言，自動化測試現在已成為現實，與世界上任何其他軟體一樣。
為了清楚起見，讓我們以一段偽**（類似於apache spark等資料處理框架）為例，它代表乙個簡單的管道：
foocollection inputrecords=// extract raw data from sourcebarcollection enrichmentrecords=// extract data from external tableoutcollection
outputrecords=inputrecords .cleanandnormalize .enrichwithbar(enrichmentrecords) .tobarcollectionoutputrecords.writeto(destination)
儘管管道非常簡單，但實際工作離此結構並不遙遠，並且可以立即看到：
· 該**易於閱讀且易於解釋；
· 可以將**拆分為易於測試的部分，並可以使用類，方法，函式，介面以及高階程式語言可以提供的所有常見結構來設計成具有高度可維護性和良好格式的**；
· 管道可以使用tdd方法實現。
簡而言之，整個專案可以圍繞乾淨，經過測試和可重用的**構建，從而使您的資料管道更強大，易於維護和部署。
處理"完整sql"樣式
如果您想用sql編寫上面的管道，那麼結果將是乙個很長的查詢，當語句，字串操作，聯接和型別轉換全部放在乙個不可維護的工作中時，將執行很多情況。
即使通過將工作分成多個部分來明智地將事情和職責分開，sql仍然無法擁有強大的自動化測試框架。 此外，根本無法實現型別安全，編譯時錯誤，編碼最佳實踐，測試驅動的方法等功能。
老實說，一些商業etl和資料整合工具提供了一些測試您的工作的方法（儘管很少使用，但這是另一回事了）。 問題在於它們是專有的，有時不是免費的，並且是受限制的解決方案，它們依賴於預先構建的運算子來提供資料和架構驗證，並且根據選擇的工具可能會有很大不同。
使用諸如scala或j**a之類的高階語言執行intead，執行單元和整合測試時，將一如既往地基於相同的實踐和規則，並且各個框架之間的差異可能很小，其優勢在於為您提供了無與倫比的健壯性和覆蓋範圍。
管理**的可怕影響
儘管開發人員和資料工程師退出了這一新趨勢（自從以hadoop為中心的解決方案開始應用於較新的基於雲和無伺服器的資料平台以來），但許多公司並沒有意識到新技術的數量以及對新的大資料生態系統進行編碼的過程 帶入並開始遭受（至少三個）常見問題的困擾：
· bi團隊內部缺乏技術知識；
· 就業市場上缺乏熟練的資料工程師；
· 大量的sql忍者很快就無法為新的大資料專案編寫etl / elt管道。
另外，由於許多大資料技術專注於提供"快速" sql引擎來查詢和管理儲存在hdfs，檔案系統和雲blob儲存上的資料，因此許多公司開始採用hive，drill，impala等工具，不僅用於資料探索和 分析，但將其作為新的etl / elt管道的核心。
這種體系結構的選擇主要是由那些不具備（也不想雇用）具有正確技能來處理這些技術的資料工程師的公司認可的，或者他們更喜歡依靠老式的而不是培訓其現有的雇員， sql專家，用於構建和管理其全新的資料湖。
不幸的是，當我擔任顧問時，我見過不止一家公司使用諸如apache hive之類的工具來實現複雜的etl / elt管道，該工具將sql查詢嵌入到資料整合工具中，該工具提供帶有分塊箭頭和"大資料聯結器"的經典gui。 在這種情況下，即使是穩固而嚴格的資料模型也不能阻止他們擁有未經測試且無法維護的系統，在此系統中，每項更改都是痛苦的發展，並且可以保證在某處（可能在生產中）破壞某些內容。
這些沒有編碼技能的gui和sql的趨勢是一種弊大於利的趨勢。
我只是介紹了批處理資料的用例，但是由於需要實施流傳輸解決方案，我覺得這些工具還不夠成熟，無法解決資料處理的最新挑戰。
tl; dr：大資料處理是否已結束sql時代？
明顯不是。 即使在大資料生態系統中，sql也是一種強大的資料分析和探索工具，如果您的etl / elt作業在讀取資料時使用下推式針對基於sql的引擎執行簡單查詢就可以了。 此外，還沒有一種萬能的解決方案：如果您要做的就是（非常）簡單的etl和資料整合，也許您仍然可以依靠某些在您選擇的引擎上執行虛擬sql查詢的塊。
但是，在進行複雜的資料轉換和處理時，最好使用記憶體和分布式處理引擎（例如spark，beam等）。在堅如磐石的開發中以高階程式語言編寫業務邏輯 由編寫良好**的最佳實踐支援的生態系統。
結果將是公司和工程師都將從中受益的強大，可擴充套件和可維護的技術堆疊。
沒有正確的技術技能不應成為未使用正確工具的原因。
不要在v for中使用v if
一 前言 以下 寫法，相信80 的初學者寫過，即使沒寫過，也應該見過！v for product in products key product.id v if product.price 50 li ul 使用 v if 來過濾 v for 迴圈的資料是乙個超級大錯誤！儘管這看起來很直觀，但它會導...
不要在標頭檔案中使用using namespace
在這裡，我毫不迴避地說了這句話 引用我再也不想在任何標頭檔案中看到 using namespace 了 作為乙個開發者 團隊領導者，我經常會去招聘新的專案成員，有時候也幫助其他組的人來面試應聘者。作為應聘流程之一，我經常要求應聘者寫一些 因此我檢查過相當多的 在最近提交的c 中，我注意到乙個趨勢，在...
不要在 render 方法中使用 HOC
官方介紹 react 的 diff 演算法 稱為協調 使用元件標識來確定它是應該更新現有子樹還是將其丟棄並掛載新子樹。如果從 render 返回的元件與前乙個渲染中的元件相同 則 react 通過將子樹與新子樹進行區分來遞迴更新子樹。如果它們不相等，則完全解除安裝前乙個子樹。例子 下面有兩個計數器，...