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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。