大數據平台組技術路線執行理念
寫在最前：自己是一個思維靈活人員，就是太靈活，視角很寬，看到了很多新東西就想要嘗試並學習、引入，但深入不夠，同時架構太大出問題機率直線升高，有明確的執行理念指導，是非常必要的，做任何決定前必須想到這個基本理念，切切。
0、精兵強將，穩扎穩打
解讀：不可盲目擴張人員，人多了管理成本增加，水平參差不齊，代碼質量無法掌控。慢一點沒關系，做一步回頭看兩步，
穩步向前。
1、足夠簡單，完全可控
解讀：盡量使用熟悉可控的軟件，盡量少。出問題可以自主檢查分析的。
2、穩定第一，運維優先
解讀：沒有成功先想着失敗，一旦要保證備份，監控先行，集中精力打造思考運維平台，一出故障就會受到嚴重質疑。
3、深度研究，謹慎擴展
解讀：對於使用的技術，一定要深研到底，不可淺嘗輒止。對於引入新技術棧，要慎之再慎。
=======================================================
選型：
1、選擇Golang,放棄 Java
理由：為了將服務分割成微服務，各業務模塊獨立編譯，彼此之間強制隔離，各部分代碼獨立成項目，一個可執行文件，獨立數據庫。
2、選擇postgresql，放棄mysql
理由：mysql在斷電等異常情況下表現不佳，同時，我們在數據倉庫中選型是GreenPlum,同樣是postgresql技術體系，雙線做戰不如統一技術路線。
3、選擇自主研發go-sso項目，放棄cas和xxl-sso
理由：統一技術棧，把所有技術細節抓在自己手中，整個框架可以先慢后快，不要出現不可控制的細節。
# go-sso * "/login" 登錄頁面 * "/Success" 登錄成功頁面 * "/serviceValidate" 驗證接口 * 使用全局攔截器進行授權攔截，即校驗cookie中的用戶名，與票據的正確性。（1：是不是存在，2：如果存在，那么是不是鑒權中心發放的密碼（DES自加自解）） * jwt-go 創建簽名 涉及到創建Token,和檢驗Token ## 使用 第三方直接點擊跳轉到 http://127.0.0.1:8080/login?service=http://www.xxxx.com.cn/ceo_data 賬戶密碼驗證成功后，會跳轉到service中，並帶上token 第三方系統只需要通過接口”/serviceValidate“ 驗證就可以判斷是否登錄，並且能得到用戶信息哦。
4、微服務的實現方案 rpcx
理由：選擇簡單，好用，基於golang，不支持其它語言。基於rpc通訊，性能高，符合選型的整體哲學。
5、選擇greenplum
理由：做為數據倉庫使用，系統日志采用也保存到這里，暫不上線ES。
6、ETL工具
DATAX,需要開發kafka的讀插件和寫插件。
7、spark或flink
理由：未來肯定會有流計算出現，目前的一期目標集中在greenplum，慢慢擴展。
8、推薦算法KNN等
需要不斷學習概念，抽取模型。
9、全部使用POST請求，不允許使用GET方式。【強制】
https://www.v2ex.com/amp/t/595188
10、PostgreSQL備份
https://www.cnblogs.com/python-gm/p/9723478.html
11、golang gin框架 使用swagger生成api文檔
https://www.cnblogs.com/Dong-Ge/p/11351559.html
12、全面禁止使JOIN，對，是全部禁止使用。
原因：
（1）以后分庫后，可能表都不在一個實例的機器上，比如資源表與人員表可能存在分布式的兩台機器上，沒法跨機器JOIN.
（2）JOIN在大表上性能差，無法使用緩存。
（3）在代碼層采用多次SQL查詢，調用服務RPC接口，調用MODEL層方法，ID IN ( REDIS緩存 ) 等方式進行改造。我將在自已動手的第一個基礎數據模塊中進行全面實踐，並整理出經驗分享給團隊所有成員。阿里的規則是不允許多於2張表，我再狠一點，直接禁止了，一了百了。
企業級數據倉庫實戰
https://www.bilibili.com/video/av63753220/?spm_id_from=333.788.videocard.6