親愛的讀者，美好的一天！
對於任何一家其業務基於智慧負載服務交付模型或創建技術複雜產品的公司來說，建立用於收集和分析資料的 IT 平台的任務遲早都會出現。 建構分析平台是一項複雜且耗時的任務。 然而，任何任務都可以簡化。 在本文中，我想分享我使用低程式碼工具來幫助創建分析解決方案的經驗。 這些經驗是在 Neoflex 公司大數據解決方案方向的多個專案實施過程中獲得的。 自2005年以來，Neoflex的大數據解決方案方向一直致力於解決建構資料倉儲和資料湖的問題，解決優化資訊處理速度的問題以及研究資料品質管理的方法。
沒有人能夠避免有意識地累積弱和/或強結構化資料。 也許即使我們談論的是小型企業。 畢竟，在擴展業務時，有前途的企業家將面臨開發忠誠度計劃的問題，需要分析銷售點的有效性，會考慮有針對性的廣告，並對配套產品的需求感到困惑。 初步估計，這個問題可以「膝上」解決。 但隨著業務的成長，進入分析平台仍然是不可避免的。
然而，在什麼情況下資料分析任務會發展成「火箭科學」類問題呢？ 也許現在我們正在談論真正的大數據。
為了讓火箭科學變得更容易，你可以一塊一塊地吃掉大象。
您的應用程式/服務/微服務越離散和自治，您、您的同事和整個企業就越容易消化這頭大象。
幾乎我們所有的客戶都遵循這個假設，並根據 DevOps 團隊的工程實踐重建了環境。
但即使採用「單獨的、龐大的」飲食方式，我們也很有可能出現 IT 領域「過度飽和」的情況。 此時此刻值得停下來，呼氣並向旁邊看去 低程式碼工程平台.
當從直接編寫程式碼轉向在低程式碼系統的 UI 介面中「拖曳」箭頭時，許多開發人員都擔心自己的職業生涯會陷入死胡同。 但工具機的出現並沒有導致工程師的消失，而是將他們的工作提升到了一個新的水平！
讓我們找出原因。
物流、電信業、媒體研究、金融領域的數據分析總是與以下問題相關：
- 自動分析速度；
- 能夠在不影響主要數據生產流程的情況下進行實驗；
- 所準備資料的可靠性；
- 變更追蹤和版本控制；
- 資料來源、資料沿襲、CDC；
- 將新功能快速交付到生產環境；
- 還有一個臭名昭著的問題：開發和支援的成本。
即工程師擁有大量的高層任務，只有明確低階開發任務的意識，才能以足夠的效率完成這些任務。
開發者邁上新階梯的先決條件是業務的演進和數位化。 開發人員的價值也在改變：能夠沉浸在業務自動化概念中的開發人員嚴重短缺。
讓我們用低階和高階程式語言進行類比。 從低階語言到高階語言的過渡，就是從「用硬體的語言寫直接指令」到「用人的語言寫指令」的過渡。 也就是說，加入一些抽象層。 在這種情況下，從高階程式語言到低程式碼平台的過渡就是從「以人的語言指令」到「以商業語言的指令」的過渡。 如果有開發人員對此事實感到悲傷，那麼他們也許從使用陣列排序功能的 Java Script 誕生的那一刻起就一直在悲傷。 當然，這些功能可以透過相同高級編程的其他方式在背景進行軟體實現。
因此，低程式碼只是另一個抽象層次的表象。
使用低程式碼的應用經驗
低程式碼這個主題相當廣泛，但現在我想用我們的一個專案的例子來談談「低程式碼概念」的實際應用。
Neoflex 的大數據解決方案部門更專注於金融業務領域，建立資料倉儲和資料湖以及自動化各種報表。 在這個領域，低程式碼的使用早已成為一種標準。 在其他低程式碼工具中，我們可以提到用於組織 ETL 流程的工具：Informatica Power Center、IBM Datastage、Pentaho Data Integration。 或 Oracle Apex，它充當快速開發用於存取和編輯資料的介面的環境。 然而，低程式碼開發工具的使用並不總是涉及在明顯依賴供應商的商業技術堆疊上建立高度針對性的應用程式。
使用低程式碼平台，您還可以組織資料流的編排、建立資料科學平台或用於檢查資料品質的模組。
使用低程式碼開發工具的經驗應用範例之一是 Neoflex 與 Mediascope（俄羅斯媒體研究市場的領導者之一）之間的合作。 該公司的業務目標之一是產生數據，廣告商、網路平台、電視頻道、廣播電台、廣告代理商和品牌可以根據這些數據做出購買廣告的決策並規劃其行銷傳播。
媒體研究是一個技術含量很高的業務領域。 識別視訊序列、從分析觀看的設備收集數據、測量網路資源的活動 - 所有這些都意味著該公司擁有大量 IT 員工和建立分析解決方案的豐富經驗。 但資訊量、來源數量和種類的指數級增長迫使 IT 數據產業不斷進步。 擴展已經運行的 Mediascope 分析平台最簡單的解決方案可能是增加 IT 人員。 但更有效的解決方案是加快開發流程。 朝這個方向邁進的步驟之一可能是使用低程式碼平台。
在專案開始時，該公司已經擁有一個有效的產品解決方案。 然而，在 MSSQL 中實施該解決方案無法完全滿足擴充功能的期望，同時保持可接受的開發成本。
我們面前的任務確實雄心勃勃 - Neoflex 和 Mediascope 必須在不到一年的時間內創建一個工業解決方案，並在開始日期的第一季內發布 MVP。
選擇Hadoop技術棧作為建構基於低程式碼運算的新資料平台的基礎。 HDFS 已成為使用 parquet 檔案進行資料儲存的標準。 為了存取平台中的數據，使用了 Hive，其中所有可用的店面都以外部表的形式呈現。 將資料載入到儲存中是使用 Kafka 和 Apache NiFi 實現的。
這個概念中的Lowe-code工具用於優化建構分析平台中最耗費人力的任務－資料計算任務。
選擇低程式碼資料封包工具作為資料映射的主要機制。 Neoflex 數據報 是用於開發轉換和資料流的工具。
使用這個工具，您無需手動編寫 Scala 程式碼。 Scala 程式碼是使用模型驅動架構方法自動產生的。
這種方法的一個明顯優點是加快開發流程。 不過，除了速度之外，還有以下優點：
- 查看來源/接收器的內容和結構；
- 將資料流物件的起源追蹤到各個欄位（沿襲）；
- 部分執行轉換並查看中間結果；
- 執行前審查原始程式碼並進行調整；
- 自動驗證轉換；
- 自動資料下載1合1。
進入用於產生轉換的低程式碼解決方案的門檻非常低：開發人員需要了解 SQL 並具有使用 ETL 工具的經驗。 值得一提的是，程式碼驅動的轉換產生器並不是廣義的 ETL 工具。 低程式碼工具可能沒有自己的程式碼執行環境。 也就是說，產生的程式碼將在安裝低程式碼解決方案之前在叢集上已有的環境中執行。 這也許是低程式碼業力的另一個優點。 因為，與低程式碼團隊並行，「經典」團隊可以使用純 Scala 程式碼等方式實現功能。 將兩個團隊的改進引入生產將是簡單且無縫的。
也許值得注意的是，除了低程式碼之外，還有無程式碼解決方案。 從本質上講，這些是不同的東西。 低程式碼允許開發人員更多地干預生成的程式碼。 對於 Datagram，可以檢視和編輯產生的 Scala 程式碼；無程式碼可能無法提供這樣的機會。 這種差異不僅在解決方案的靈活性方面非常顯著，而且在資料工程師工作的舒適度和積極性方面也非常顯著。
解決方案架構
讓我們試著弄清楚低程式碼工具如何幫助解決優化開發資料運算功能的速度的問題。 首先我們來看看系統的功能架構。 這種情況的一個例子是媒體研究的資料生產模型。
我們案例中的資料來源非常異質且多樣化：
- 人數表（電視表）是軟體和硬體設備，用於讀取電視面板受訪者的使用者行為 - 參與研究的家庭中誰、何時以及觀看了什麼電視頻道。 所提供的資訊是連結到媒體包和媒體產品的廣播觀看間隔流。 在載入到資料湖階段的資料可以透過人口統計屬性、地理分層、時區和分析特定媒體產品的電視觀看所需的其他資訊來豐富。 所進行的測量可用於分析或規劃廣告活動、評估觀眾的活動和偏好以及編譯廣播網絡；
- 數據可以來自串流電視廣播的監控系統以及測量網路上視訊資源內容的觀看情況；
- Web 環境中的測量工具，包括以網站為中心和以使用者為中心的儀表。 資料湖的資料提供者可以是研究欄瀏覽器插件和具有內建 VPN 的行動應用程式。
- 數據還可以來自整合了線上問卷填寫結果和公司調查中電話訪談結果的網站；
- 透過從合作夥伴公司的日誌下載資訊可以進一步豐富資料湖。
從來源系統載入到原始資料的主要暫存的實作可以透過多種方式組織。 如果低程式碼用於這些目的，則可以根據元資料自動產生載入腳本。 在這種情況下，無需深入到開發來源到目標映射的層級。 要實現自動加載，我們需要建立與來源的連接，然後在加載介面中定義要載入的實體清單。 HDFS中的目錄結構將自動創建，並與來源系統上的資料儲存結構相對應。
然而，在這個專案的背景下，我們決定不使用低程式碼平台的這項功能，因為 Mediascope 公司已經獨立開始使用 Nifi + Kafka 組合製作類似的服務。
值得立即指出的是，這些工具不可互換，而是互補的。 Nifi 和 Kafka 能夠以直接連接（Nifi -> Kafka）和反向連接（Kafka -> Nifi）工作。 對於媒體研究平台，使用了捆綁包的第一個版本。
在我們的例子中，NayFi 需要處理來自來源系統的各種類型的資料並將它們傳送到 Kafka 代理程式。 在本例中，訊息使用 PublishKafka Nifi 處理器傳送到特定的 Kafka 主題。 這些管道的編排和維護是在視覺化介面中進行的。 Nifi工具以及Nifi+Kafka組合的使用也可以稱為低程式碼開發方式，降低了大數據技術的進入門檻，並加快了應用程式的開發進程。
專案實施的下一階段是將詳細資料轉換為單一語意層格式。 如果實體具有歷史屬性，則在相關分區的上下文中執行計算。 如果實體不是歷史實體，則可以選擇重新計算物件的全部內容，或完全拒絕重新計算該物件（由於缺乏變更）。 在此階段，為所有實體產生金鑰。 密鑰儲存在主物件對應的Hbase目錄中，其中包含分析平台中的密鑰與來源系統中的密鑰之間的對應關係。 原子實體的合併伴隨著分析資料初步計算結果的豐富。 資料計算的架構是Spark。 所描述的將資料引入單一語意的功能也是基於低程式碼資料封包工具的映射來實現的。
目標架構需要業務用戶透過 SQL 存取資料。 Hive 用於此選項。 當您在低程式碼工具中啟用「Registr Hive Table」選項時，物件會自動註冊到 Hive 中。
計算流程控制
資料封包有一個用於建立工作流程設計的介面。 可以使用 Oozie 調度程序啟動映射。 在串流開發人員介面中，可以建立並行、順序或依賴執行的資料轉換的方案。 支援 shell 腳本和 java 程式。 也可以使用 Apache Livy 伺服器。 Apache Livy 用於直接從開發環境執行應用程式。
如果公司已經擁有自己的流程編排器，則可以使用 REST API 將對應嵌入到現有流程中。 例如，我們在將 Scala 中的映射嵌入到用 PLSQL 和 Kotlin 編寫的編排器中方面擁有相當成功的經驗。 低程式碼工具的REST API包括根據映射設計產生可執行年份、呼叫映射、呼叫映射序列，當然還有向URL傳遞參數以運行映射等操作。
與 Oozie 一起，可以使用 Airflow 組織計算流程。 也許我不會詳細討論 Oozie 和 Airflow 之間的比較，但我會簡單地說，在媒體研究專案的工作背景下，選擇了 Airflow。 這次的主要論點是開發產品的更活躍的社群和更發達的介面+API。
Airflow 也很好，因為它使用深受喜愛的 Python 來描述計算過程。 而且整體來說，開源的工作流程管理平台並不多。 啟動和監控流程的執行（包括甘特圖）只會為 Airflow 的業力增加積分。
用於啟動低程式碼解決方案對應的設定檔格式已變為spark-submit。 發生這種情況有兩個原因。 首先，spark-submit 允許您直接從控制台執行 jar 檔案。 其次，它可以包含配置工作流程的所有必要資訊（這使得編寫產生 Dag 的腳本變得更容易）。
在我們的案例中，Airflow 工作流程中最常見的元素是 SparkSubmitOperator。
SparkSubmitOperator 允許您執行 jars - 帶有預先產生的輸入參數的打包資料報映射。
值得一提的是，每個 Airflow 任務都在單獨的執行緒中運行，並且不了解其他任務。 因此，任務之間的交互作用是使用控制運算子（例如 DummyOperator 或 BranchPythonOperator）進行的。
總而言之，資料封包低程式碼解決方案的使用與設定檔的通用化（形成 Dag）相結合，顯著加速並簡化了開發資料載入流的過程。
展示計算
也許分析資料生成過程中最具智力負擔的階段是建構展示的步驟。 在研究公司的資料計算流程之一的背景下，在此階段，資料被簡化為參考廣播，考慮到時區修正並連結到廣播網格。 也可以針對本地廣播網路（本地新聞和廣告）進行調整。 其中，該步驟根據觀看間隔的分析，將媒體產品連續觀看的間隔進行細分。 立即根據有關其重要性的資訊（計算校正因子）對觀看值進行「加權」。
準備展示的一個單獨步驟是資料驗證。 驗證演算法涉及許多數學科學模型的使用。 但是，使用低程式碼平台可以將複雜的演算法分解為許多獨立的視覺可讀映射。 每個映射都執行一項狹窄的任務。 因此，資料準備階段的中間調試、記錄和視覺化是可能的。
決定將驗證演算法離散化為以下子階段：
- 透過在 60 天內觀看該地區所有網路的內容，建立該地區電視網絡觀看依賴關係的回歸。
- 計算所有迴歸點和計算日的學生化殘差（實際值與迴歸模型預測值的偏差）。
- 一系列異常區域-網路對，其中結算日的學生化餘額超過正常值（由操作設定指定）。
- 重新計算在該區域觀看網路的每個受訪者的異常區域-電視網絡對的校正學生化殘差，確定該受訪者在從樣本中排除該受訪者的觀看時的貢獻（學生化殘差的變化量） 。
- 尋找那些被排除在外的候選人，使發薪日的學生化餘額恢復正常。
上面的例子證實了這樣的假設：資料工程師已經有太多的想法......而且，如果這確實是一名“工程師”而不是“程式設計師”，那麼他會擔心使用低程式碼工具時職業退化。最後必須撤退。
低程式碼還能做什麼？
無需在 Scala 中手動編寫程式碼即可進行批次和串流資料處理的低程式碼工具的應用範圍還不止於此。
在Datalake開發中使用低程式碼已經成為我們的標準。 可以說，基於Hadoop堆疊的解決方案遵循了基於RDBMS的經典DWH的發展路徑。 Hadoop 堆疊上的低程式碼工具可以解決資料處理任務和建置最終 BI 介面的任務。 此外，應該指出的是，BI不僅意味著資料的表示，還意味著業務使用者對資料的編輯。 我們在為金融部門建立分析平台時經常使用此功能。
除此之外，使用低程式碼，特別是資料報，可以解決追蹤資料流物件的起源的問題，原子性到各個欄位（沿襲）。 為此，低程式碼工具實作了與 Apache Atlas 和 Cloudera Navigator 的介面。 本質上，開發人員需要在Atlas字典中註冊一組對象，並在建立映射時引用註冊的對象。 當需要改進計算演算法時，追蹤資料來源或分析物件依賴關係的機制可以節省大量時間。 例如，在準備財務報表時，此功能可讓您更輕鬆地度過立法變更期間。 畢竟，我們越了解詳細層物件脈絡中的形式間依賴關係，我們就越少遇到「突然」的缺陷並減少返工的次數。
數據品質和低程式碼
Mediascope 專案上的低程式碼工具實現的另一項任務是資料品質類別任務。 研究公司專案實施資料驗證管道的一個特點是對主要資料計算流程的效能和速度沒有影響。 為了能夠編排獨立的資料驗證流程，使用了已經熟悉的 Apache Airflow。 當資料生產的每個步驟準備就緒時，DQ 管道的一個單獨部分並行啟動。
從數據在分析平台中開始的那一刻起就對其品質進行監控被認為是良好的做法。 有了有關元資料的信息，我們可以從資訊進入主層的那一刻起檢查是否符合基本條件 - 不為空、約束、外鍵。 此功能是基於數據報中自動產生的數據品質系列映射來實現的。 在這種情況下，程式碼產生也是基於模型元資料的。 在Mediascope專案中，介面是透過Enterprise Architect產品的元資料來實現的。
透過將低程式碼工具與 Enterprise Architect 配對，可以自動產生以下檢查：
- 使用「not null」修飾符檢查欄位中是否存在「null」值；
- 檢查主鍵是否有重複項；
- 檢查實體的外鍵；
- 根據一組字段檢查字串的唯一性。
為了對資料可用性和可靠性進行更複雜的檢查，創建了與 Scala Expression 的映射，該映射將 Zeppelin 分析師準備的外部 Spark SQL 檢查程式碼作為輸入。
當然，支票的自動產生必須逐步實現。 在所述項目的框架內，先前執行了以下步驟：
- Zeppelin 筆記本中實現的 DQ；
- 映射中內建 DQ；
- DQ 採用單獨的大規模映射的形式，包含針對單獨實體的一整套檢查；
- 通用參數化 DQ 映射，接受元資料和業務檢查的資訊作為輸入。
也許創建參數化檢查服務的主要優點是減少向生產環境交付功能所需的時間。 新的品質檢查可以繞過透過開發和測試環境間接交付程式碼的經典模式：
- 所有元資料檢查都是在 EA 中修改模型時自動產生的；
- 可以基於儲存物件上下文中下一條資料出現的預期時間的目錄來產生資料可用性檢查（確定某個時間點是否存在任何資料）；
- 業務資料驗證檢查由分析師在 Zeppelin 筆記本中創建。 從那裡它們被直接發送到生產環境中的 DQ 模組設定表。
直接將腳本交付生產環境不存在任何風險。 即使出現語法錯誤，對我們的最大威脅也只是無法執行一項檢查，因為資料計算流程和品質檢查啟動流程是相互分離的。
本質上，DQ 服務永久運行在生產環境中，並準備好在下一條資料出現時開始工作。
取而代之的是結論
使用低程式碼的優勢是顯而易見的。 開發人員不需要從頭開始開發應用程式。 擺脫額外任務的程式設計師可以更快地產生結果。 反過來，速度可以騰出更多時間來解決最佳化問題。 因此，在這種情況下，您可以依靠更好更快的解決方案。
當然，低程式碼並不是萬能的，魔法不會自行發生：
- 低程式碼產業正處於「做強」階段，尚無統一的產業標準；
- 許多低程式碼解決方案不是免費的，購買它們應該是一個有意識的步驟，並且應該對使用它們的經濟利益充滿信心；
- 許多低程式碼解決方案並不總是能很好地與 GIT/SVN 配合使用。 或如果產生的程式碼被隱藏則使用起來不方便；
- 在擴展架構時，可能需要對低程式碼解決方案進行細化——這反過來又會引發對低程式碼解決方案供應商的「依附和依賴」效應。
- 足夠的安全等級是可能的，但它非常耗費人力並且難以在低程式碼系統引擎中實現。 選擇低程式碼平台不應僅基於從其使用中尋求利益的原則。 選擇時，值得詢問有關存取控制和將身分資料委派/升級到組織的整個 IT 環境層級的功能可用性的問題。
然而，如果您知道所選系統的所有缺點，並且使用它的好處占主導地位，那麼您就可以放心地轉向小程式碼。 此外，向它的過渡是不可避免的——就像任何進化都是不可避免的一樣。
如果低程式碼平台上的一名開發人員比兩名沒有低程式碼的開發人員更快完成工作，那麼這將使公司在各個方面都處於領先地位。 低程式碼解決方案的進入門檻低於「傳統」技術，這對解決人員短缺問題有正面作用。 使用低程式碼工具時，可以加快職能團隊之間的交互，並更快地就所選資料科學研究路徑的正確性做出決策。 低階平台可以推動組織的數位轉型，因為所產生的解決方案可以被非技術專家（特別是業務用戶）理解。
如果您的期限緊迫、業務邏輯繁重、缺乏技術專業知識，並且需要加快上市時間，那麼低程式碼是滿足您需求的一種方法。
不可否認傳統開發工具的重要性，但在許多情況下，使用低程式碼解決方案是提高所解決任務效率的最佳方式。
來源： www.habr.com