[請益] 如何有效益的維護data loader

看板Soft_Job (軟體人)作者tinasfishs (Tina)時間1年前 (2022/11/22 01:03)推噓17(18推 1噓 76→)

留言95則, 19人參與討論串1/1

如題目前做的project架構長這樣 Loader1 Loader2 Loader3 ........... Loader30 Area 1 Area 2 Area 3 .... .... Area 10 就是同一個Loader 會算出結果給不同Area的人有分成前端跟後端，前後端都是我維護 (前端 .Net Framework java script MVC,會用到一點 jquery，其他大多套套件用現成的物件再加工，後端就純C# query DB用的工具是公版的不用自己寫，就負責input 要打的SQL跟DB，然後output datatable或是對DB做insert/delete/update....) Loader每支老闆認知都不算很大所以也是一人包辦XD Loader每支的邏輯也類似: Start--->會記錄log表示loader開始 Initial setting----> query一些接下來SQL會用到的config QueryRawData---->把上一個initial function的config帶下來在這裡組成SQL string 並且query進data table ProcessData--->對上一步的data 做運算然後轉換成可能只有一個kpi值的結果或是pre-sum過後的結果 (舉例來說query hourly的資料轉換成daily的資料) End---->只是記錄log表示上面的function都執行完了看似很穩定但loader卻需要不斷的更版原因是因為SQL全部都是寫死的，接水其他系統的資料 https://imgur.com/a/xjTfPfG 以這個圖為例，USER只看的到最終的TABLE，沒有太多空間可以彈性修改query的條件也沒有像左上角有彈性調整query資料的方法 (有config但是很少) 所以需求常常長得像這樣: "tinasfishs 啊你幫我改一下，我發現今天的KPI有錯，因為今天開始要加採計'AA' 這種類別，麻煩再幫我改" 原始SQL通常長這樣 SELECT COUNT(1) CNT FROM STORE_SALES WHERE 1=1 SELECT * FROM STOR_SALES WHERE 1=1 ( AND TYPE IN ('A','AB','BC',....'DZ','AA') AND SALE_DATE BETWEEN SYSDATE-3/24 AND SYSDATE-1/24 AND MT_CODE IN ('2','5') AND...... CASE WHEN .... )A, ( SELECT EMPLOYEE_DEG,EMPLOYEE_NAME FROM EMPLOYE_L WHERE AREA='AREA1' AND RES_PRODUCT NOT LIKE '%AAZc' .... .... ... )B, ( SELECT EMPLOYE_ID,EMPLOYEE_SHIFT FROM SHIFT_ARRANGE_LIST WHERE RECTIME>SYSDATE-5 AND AREA='AREA1' if (AREA=='AREA1' or AREA=='AREA2') { RECTIME<SYSDATE-1 } )C WHERE A.SALE_EMPLOYEE=B.EMPLOYEE_NAME AND B.EMPLOYEE_ID=C. EMPLOYEE_ID SQL通常都很長而且用sub-query，會把商業邏輯埋在hard-code的SQL裡面不能用SQL處理的邏輯則是在ProcessData那步處理假設綠色的地方是config，黃色的地方則是這次修改的部分重點是改後端的SQL都需要重新上code，雖然有提供公版的工具把SQL另外儲存只要呼叫那個外部工具就可以把SQL取得但前人為了開發方便當然全部都把SQL直接擺在程式裡然後複雜的是，同樣算這個KPI，各個AREA 的條件是不盡相同的用藍色字的地方就是舉例，沒有使用config而是用C# 的code 直接hard code 這兩個 area 需要加此條件所以也會衍生像是 "我們是AREA3，AREA1 跟 AREA2 看的那個條件我們從下禮拜開始也想跟著採計，你們可以重新上code嗎" 有爬文像是Stored procedure 之類的做法，歹勢對於這個架構完全不適用理論上像這樣各個area的條件有不少差異的情況下，應該是個別維護各area的loader 但這整套是寫在一起的...，每次上code為了維護版控也會在各area同步上同一套也就會發生改A壞B，假設area1跟area2 共用同一段SQL條件，答應area1刪掉其中一句之後，area2 就跑來說他們的KPI異常這個專案負責接水30幾支上游的TABLE，就有30幾支LOADER..而且還在逐漸增加中所以談需求跟開發的時候，根本也不是從 "為什麼要新增AA這個條件，除了改SQL有什麼更好的方式" 去切入因為那要去詢問上游以及user為什麼要新增這個條件太花時間而是 "幫我改SQL吧比較快"---> 所以從來都只在做改SQL這種很末端的工作一個禮拜大概有4-5個這樣的"假需求"---->我定義為只是改SQL，請user驗驗看是否符合他們期望 user有時候也不確定改了條件是否就會對，改了也不能上code 總是改了再測測了再改這樣的需求都做完了，才有時間去處理可能真的是loader本身的問題 ----->效能的問題啊、要新增一支新loader 與user談規格之類的....orz 談規格也是我一人，頂多再加0.5個PM PM也跟我想像會把規格談到不會讓日後充滿這些維護剛好相反最後規格談一談還是常常訴諸短解能夠hard code SQL就hard code，理想性的應該要跟上游負責系統的人看資料怎麼接軌的溝通過程完全沒有= = 我有堅持過想先看清資料流再做新需求也因為求時效性被打槍有被訓練得比較有警覺性，但一個SQL 至少20行，下面又有條件讓user高興改就改實在很難用很大的框架去處理這樣的事，SQL有記得拔出來放在另外存的地方不用重新上code就很不錯了 BTW SQL邏輯跟要接水什麼報表通常都是由USER提供 ----------- 有跟老闆溝通過像這樣接水別人資料的匯總型AP 應該要重構，或者是一支一支拿出來看有什麼可以enhance的但user常常會認知KPI錯誤就來說是系統問題，久而久之老闆也好像覺得是我的問題而沒有深究之所以KPI會錯誤，就是因為SQL在上code流程的不彈性，還有讓user在不能彈性重上CODE的情況下還是一再想修改SQL (不能彈性的原因是要重上code老闆都會看，跟他解釋這個是要改SQL就會被 question，但老闆也不看CODE也不會負責建議有建設性的方法，只會打高空問說可不可以不要改SQL--->問我的格局只能做到這樣...整個黑人問號) 私以為想修改SQL或是想改變KPI的算法，都應該是大家坐下來看data flow是什麼是不是只是加了一句SQL就可以改變但文化上大家也不太有耐心這樣梳理問題不太清楚老闆是否了解目前系統的設計是長這樣，總之在溝通上也覺得不太有救想問問有沒有維護或是開發過這種DATA LOADER的前輩可以分享一下心得的QQ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.25.93.94 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1669050189.A.15C.html

推

neo5277

11/22 01:29, 1年前 , 1^F

11/22 01:29, 1^F

推

neo5277

11/22 01:30, 1年前 , 2^F

11/22 01:30, 2^F

→

peter98

11/22 01:32, 1年前 , 3^F

11/22 01:32, 3^F