這邊的 SA 是 System Administrtor 還是 System Analysist 都是可以的, 因為一個系統分析, 必然要對系統架構與管理有點熟悉, 若是不熟的話, 我很難想像這個資料探勘的 SA 如何在不了解 SA 下做 Data Mining 的 SA.

利用系統的特性與限制, 設計出合用的系統, 並將之架構與實作起來, 必須要了解很多效能調校的事情, 當然就一個系統分析師而言, 也必須了解這些環節的特色來設計才能夠設計出一個好的系統.
因此, 要從幾點方面來思考...

1. 因為 Data Mining 須要大量運算, 不可能只靠一台機器去計算的, 所以一定要設計成 Cluster 或 Cloud Computing, 因此要了解如何運作這樣的系統以及設計出這樣的環節, 而能夠不會互相搶資源, 共用資源, 避免造成瓶頸, 避免死結或 Race Condition, 讓大家達到最高的效用與效能, 這似乎不是那麼簡單就做到的.

2. 機器一多, 就會面臨到一定會有個環節可能會出問題, 而資料探勘的運算跟其他系統不一樣, 很多系統若沒算失敗大不了重算就好, 但 Data Mining 的一次計算可能是超過好幾天, 可能是上週或上月, 說要停下來重算就來不及了, 所以要設計成若停下來或某個掛掉, 若 Bring Up 恢復之後可以繼續計算, 承接既有的計算結果, 而不用重算, 要設計出這樣的環節可能比一設計一個完美的環節困難四倍以上.

3. 因為在這種複雜的系統, 資料儲存與傳遞是相當重要的, 也就是在 Storage 儲存設備以及 API/SQL 之間的 Connection 連結或計算單元的資料傳遞都須要設計好, 有些可能是用 SAN, 有些可能是用 Dump, 有些可能是用 Replication, 要依資料的特性以及使用方式與儲存方式設計最好的方式, 而不是用一個 "巨大成本的資料倉儲 Data Warehouse" 就來企圖解決一切, 說不定是無法達成或不切實際的.

4. 在效能調校中, 要了解記憶體, CPU, I/O, 流量等等的瓶頸, 效能及效用, 也要看每個程式及資料庫在資源的使用狀況是否有空間或已經達到極限, 若是達到極限要如何提高可用性, 或者可能是換一種系統, 包含檔案系統, 資料庫系統, 甚至是語言的特性與調校, 這些往往是程式設計師與 DBA 對系統不了解而無法了解去調整.

5. 在 SA 中, 有時要面臨 PM, Marketing 對資料探勘的不了解, 要請演算法的人去發想出一個系統可以執行的架構, 找出資料庫與程式設計師的平衡點, 達到企劃人的要求, 事實上即使是上線之後, 往往須要的調整更多, 也要看系統當時的負荷, 以及使用的狀況, 這些都是要花很多心力的.

聽起來 SA 的確是在 Data Mining 中扮演很吃重的角色, 理論上大部份的調校都是要對系統了解才能做, 才能做可行性分析, 所以最好他也能夠對 DBA 與 Programming 有一定的熟悉.

下一個就是要寫主導者該注意的事項.