1、大數據機器平臺項目：
（1）對mapreduce的優化，一開始是按照常規思路在map中處理segy文件，經過shuffle后在reduce中將處理后的segy文件寫入數據庫中，開始一直按照常規思路在想怎么優化shuffle階段，包括增大環形內存緩沖區，減少溢寫次數等，后來過了一段時間了突然想到為什么非得需要reduce階段呢？我就嘗試直接在map處理完segy文件后直接將處理后的數據寫入數據庫，這樣就省去了shuffle和reduce階段，整個mapreduce性能也是有了一個較大的提升。
（2）設計大數據機器學習平臺的框架，因為之前沒有過這種架構設計的經驗，以前做項目的時候就是用ssm這些常用的框架，因為阿里也在做一個機器學習平臺的叫做PAI，我們去參加了阿里PAI平臺的技術分享會，學習了他們先進的設計架構。其實這個平臺模塊之間關系不是很緊密耦合度不高，因此還是比較適合做微服務的，再加上神經網絡分布式訓練需要dokcer和k8s，有了這些技術基礎，做微服務也是比較容易的，但是考慮到我們項目周期和人員有限，spark、k8s這一塊都需要投入比較多的時間，綜合考慮先基于springboot+vue來實現，后期轉springcloud也比較方便。
2、管道運行優化項目：
1、設計改進優化算法，常規做優化時最優點值和其余點的值差距還是比較大，但是在管道優化運行中，因為研究人員給出的調度方案一般也都是挺好的，所以最優解和其他解之間的差距就非常小，在解空間整體上就類似于一張紙被沙?？┝藥紫?#xff0c;因此我改進了優化算法，提出自適應合并策略，較好的解決了這個場景。雖然最后提升只是5%但是在這種差距很小的情況下，5%已經算是挺大的提升了。
2、交流溝通方面，因為這個這個項目是我們和圖靈科技合作，甲方是徐洲管道局，因為徐洲管道局那邊都是管道方面的專家，對計算機其實不是很了解，所以溝通起來就比較困難，其中有一個地方就是他們要求我們做離線的調度優化，就是他們的研究人員點一下之后我們給出調度計劃，，但我們和圖靈科技都以為他們是要求做實時的調度優化，就是油運輸過來后傳感器采集到數據程序自動給出最優調度計劃，每隔一小時自動優化一次。這就導致我們返工重做了一部分工作，我們這邊返工的還少，圖靈那邊重做的就比較多。因此這個問題的收獲就是在做項目的時候多建立一些小的時間節點，及時和甲方進行溝通，畢竟甲方是非計算機人員交流起來難免會有理解不同的地方，這樣的話能及時發現和對方理解不同的地方，及時修改方案，將損失降到最低，避免造成更大的損失。
?

總結

以上是生活随笔為你收集整理的项目难点总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。