一、平臺側系統調研的原則
二、平臺側系統調研的步驟
三、平臺側調研需要注意的問題
四、如何進行用戶側系統調研
我們公司內部進行系統選型或者方案設計的時候經常會進行系統調研，我認為系統調研一般分為兩類：用戶視角的系統調研（只需使用）和平臺視角的系統調研（需要進行系統的維護和二次開發），下面我分別淺談下如何進行用戶視角的系統調研和平臺視角的系統調研。
（目前水平和視野有限， 有了新的理解後會不斷更新）
平臺側系統調研的原則
個人認為我們平臺側進行系統調研時應該原理為主，測試為輔。（測試和原理一樣都很重要，如同實驗物理和理論物理一樣，是相輔相成，不可分割的，但是在系統調研調研階段我認為我們應該更側重原理，調研時測試的目的應該是驗證或糾正我們對系統原理的理解），理由如下：
1.系統是動態發展的，而且許多系統開發迭代速度很快，所以基於某個固定版本去測試意義不是很大。（比如TiDB1.1 某些場景下的OLAP查詢相比1.0有幾倍提升；比如Palo最新版相比我2月份測試時最多有6倍的性能提升；比如我們自己開發的Kylin精確去重查詢，在多輪優化後，性能有數量級的提升）
2.測試環境的規模和測試場景有限，我們不可能測試出大規模集群下的性能瓶頸和擴展性問題，這隻能依靠原理推導。（比如Kylin查詢時加載字典導致的查詢可用性下降在只有幾個Cube時肯定不會暴露出來；比如Druid的Broker需要加載所有segment元數據的問題在小集群下也不會暴露；比如Clickhouse每次查詢需要訪問所有分區的缺陷在小規模測試也很難暴露出來）
3.只要我們理解了系統的架構，核心原理，我們就應該能夠推測出其適用場景，固有缺陷，擴展性問題。(比如香農定律就在理論上給出了信道編碼的極限，後人只是在不斷尋找無限逼近香農的理論邊界，提出工程上可行的方案；比如從圖靈機理論我們可以推測出目前人工智能的極限，人工智能只能解決世界上所有問題的極其微小的一部分，推理如下：
1.世界上有很多問題，其中只有一部分是數學問題；
2.在數學問題中，只有一小部分是有解的；
3.在有解的數學問題中，只有一部分是理想狀態的圖靈機可以解決的；
4.在後一類問題中，又只有一部分是今天實際的計算機可以解決的；
5.而人工智能可以解決的問題，又只是計算機可以解決問題的一部分。
平臺側系統調研的步驟
當我們確定調研的原則是原理為主，測試為輔後，可以按照以下步驟進行系統調研
1.先通過系統官方文檔，論文，公開資料，代碼進行系統原理的調研，掌握系統的核心架構和原理；
2.用該領域的標準測試集進行測試（比如OLAP領域的SSB和TPC-H測試）
多數時候這兩步已經足夠，如果測試結果優秀，從原理上我們也判斷該系統架構合理，可以滿足我們需求，能夠解決我們現有系統的不足和痛點，我們可以再進行第二次測試，第二次測試可以考慮以下幾點：
1.標準測試集沒有cover的場景
2.現有系統的痛點或者優勢場景
3.原理上推測出的調研系統可能的痛點或者優勢場景
4.原理上90%以上能夠推測出結果的測試場景（無需測試）
經過第二次測試後，我們此時就應該判斷我們是否需要上線該系統，具體可以從以下方面進行考慮：
1.運維管理成本
2.開發成本
3.社區的活躍度
4.業務需求的緊迫性
5.該系統離我們理想系統的距離和改造的成本
6.該系統在大規模集群下的可能瓶頸和問題
7.該系統的固有缺陷以及避免改缺陷的成本
如果我們已經決定上線該系統，我們可以再進行復雜的，詳細的測試，發現該系統使用，運維，功能上的更多細節問題。
平臺側調研需要注意的問題
1.如果調研的系統官方文檔，論文，公開資料已經足夠詳細，我們就沒有必要看代碼；
2.即使必須要看代碼，也不能限於代碼海洋中，糾結某些細節問題，因為調研時間有限，不可能搞清所有細節問題；
3.看代碼時，可以通過log，測試用例，debug 來加速我們對代碼結構的整體理解和把握；
4.看代碼時，儘可能帶著明確的問題和線索去看
5.對於某些重要的技術細節，我們可以先掌握What和Why，對於How我們可以在業餘時間或者真正需要使用到這種技術時再詳細調研，因為某個技術細節不會影響我們對一個系統整體架構，核心原理和未來極限的理解
6.調研新系統時應該和已知系統進行對比，思考為什麼不同系統在解決相同或者類似問題時採用了不同方案，不同方案之間的權衡是什麼
如何進行用戶側系統調研
用戶側系統調研相比平臺側就會簡單許多，我們不用考慮系統的維護和開發，我們也不用考慮系統都支持哪些場景。只要明確我們當前的需求場景目標系統能不能很好的Cover，一般而言我們可以從以下幾點去考慮：
1.目標系統在我們的需求場景下是否有成功案例
2.是否足夠易用
3.性能和QPS是否能滿足需求
4.是否可以提供SLA保證
一般而言，在公司內部，每個需求在平臺側都會有相應的一個或者幾個系統，平臺側也會給出每個系統的適用場景和特點，所以用戶側的調研就會簡單許多，調研的主要工作其實都是平臺側完成。
最後說一下，想要學習大數據的限時領取免費資料及課程
領取方法：
還是那個萬年不變的老規矩
1.評論文章，沒字數限制，一個字都行！
3.私信小編：“大數據開發教程”即可！
謝謝大家，祝大家學習愉快！（拿到教程後一定要好好學習，多練習哦!)
閱讀更多 微笑數據工程師 的文章
