我從零開始構建MySQL資料處理系統（用Python）學到這7個教訓！

作者：Galina Olejnik

在撰寫這篇文章之前，我首先需要說的是，我並不認為自己是一名優秀的資料科學家或機器學習工程師。但我有一些有趣且不可思議的（對我而言）工作經歷，我僅僅是想分享從中學到的一些見解。

我是一名自然語言處理/機器學習科學家，而我不認為具有良好的電腦科學背景就能夠成功地在這個領域工作。我所認識的傑出研究人員可能由於某些原因而不具有熟練的技能，無法成為實時開發和儲存庫團隊的一部分。所以，我仍然想分享它們，也許有人會發現這些資訊很有用。

我希望人們會喜歡我所講的故事。

（1）處理異常是至關重要的

當我第一次嘗試連線到儲存在谷歌雲上的這個特定MySQL資料庫時，曾遇到許多不同的錯誤。當設定代理時，對很多代理進行了體驗。問題是，在程式碼開發的第一階段，最好是處理所有的錯誤，特別是與連線有關的錯誤，如果需要的話，引發這些錯誤，否則呼叫Exchange語句。

這聽起來很簡單，但在我的例子中，可能有環境變數，其中有UNIX套接字名稱和節點環境名稱，它們的值可能不正確，資料庫憑據也可能不正確，我可以擁有它所有的東西。我在處理這些例子期間花費幾個小時，但節省了很多時間，我很高興將這段時間用於這個階段的專案開發。

（2）適當的抽象類是無價的

在處理抽象類時，你需要記住的最重要的事情是，可能需要花費大量時間和注意力來定義它，並且也確實需要它。我的儲存庫的結構基於這樣一個事實，即我必須建立許多.csv檔案，這些檔案具有非常相似的模式（唯一鍵）。事實上，我有很多類似的提取器、演算法、資料後置處理器等工具，所有這些都被簡化為基本抽象類，這使得下一個模組的建立更加容易。

當你編寫第n個模組時，可以意識到你的類已經完成了，並且明白編譯過程中沒有定義的建構函式和一些方法已經實現了，因此不需要為它們煩惱。

（3）靈活的儲存庫結構總是最好的

有時它可能看起來有點難看（例如，在一個資料夾中有1個檔案），但如果看到需要更改一些關鍵模組（例如文字前處理器）並且這樣做，只需更改1-2個檔案，那就很好了。

我並不是一名軟體架構師，所以很難說出這個領域的優點和錯誤，但我認為元件的高度碎片化和獨立性總是良好的。我自己開發的repoI有大量的小資料夾，並且引向它們比嘗試使整個架構更加容易（也許更漂亮）。

（4）資料科學模型的測試是值得的

我沒有足夠的時間來完成涵蓋所有案例的完美測試。我仍然提到這一點的原因是，如果你沒有那麼明顯的ML/NLP模型行為，最好至少為了自己而進行測試。

我沒有很多NLP/ML演算法（其中大部分演算法都很簡單），但如果沒有實施哪怕最簡單的測試的話，它們的其他部分就無法支援。此外，在更好的模型理解方面，測試通常是有用的，這是因為通過斷言語句，當希望在頭腦中重新整理演算法時，一些演算法概念可能變得更加清晰。

（5）使資料庫符合第三正規化

有時這可能是人們討論的一部分，但是如果不使所有3個語句完全適用於資料庫，就無法編寫有效的資料處理系統。如果沒有它們，一些不明顯的查詢問題經常發生，甚至無法找到問題所在。

這裡有一個簡短而簡單的SQL NF指南，我認為最好多看幾遍。（ https://www.geeksforgeeks.org/database-normalization-normal-forms/ ）

（6）記錄錯誤

在實現記錄時，通常不會檢視收到三年所有的警告和錯誤，但有些錯誤可能不可重複，而且日誌記錄幫助理解發生了什麼事。我是在我的本地機器上實施的，當伺服器上的某些東西沒有工作時，通過檢視類似的案例，可以節省幾個小時的時間。

（7）除非資料庫非常簡單，否則不需要物件關係對映（ORM）

在這個專案工作的很長一段時間裡，我真的很擔心需要用物件關係對映（ORM）重寫所有內容。但是我錯了。

實際上，像SQLAlchemy和Peewee這樣的東西適合小型的簡單資料庫，但是它們不適合像複雜資料庫（有時它需要4個分組和5個連線來編寫一個查詢）。它們很優雅，有時非常簡單和美觀，但無論如何，如果你只使用聯結器API，就不能擁有儘可能多的控制權。我決定使用MySQL Connector，因為用物件關係對映（ORM）編寫所有內容可能會使棘手的事情變得更加複雜。

結論

這個註釋與ML/ NLP演算法解釋及其效能討論無關，但我仍然認為它很有用。我希望在開始研究這個專案之前已經知道了上面描述的所有陳述，但也確定，只有花費一些時間來修復bug，並尋找實際問題之後，它們中的一些問題才會變得清晰易懂。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31509949/viewspace-2212923/，如需轉載，請註明出處，否則將追究法律責任。