上期文章中開了個頭，描述了平台的初代架構。作為研發人員，能夠經歷從無到有的開發過程，同時看到平台的上線，給使用者的資料分析工作帶來了一定的效率提公升，真實的感受到了價值感和成就感。
然而隨著業務方面的新需求不斷的提出，平台需要接入的資料來源型別不斷增加，需要分析的網路規模不斷擴大。經過對資料量的評估，發現現有的單庫結構已經很難需求，於是，我們對資料庫模組進行一次架構公升級。
首先給出16年設計的平台架構圖：
參考了一些架構設計的概念，我覺得將平台架構按照分層理念來呈現，會更加的清晰。從底到上分為四層，依次為資料採集層，資料處理層，資料儲存層和業務層。每層基本的功能在上期已經介紹過，這裡就不再贅述。
這次的架構公升級的外在驅動力就是資料量的暴增，評估了單次批處理任務生成的資料記錄達到15億條。這麼巨大的資料量會導致load速度變得非常慢，而且後期的演算法根本無法順利執行。
遇到這樣的瓶頸，其實是所有使用單機單庫模式資料庫的通病。而單機單庫資料庫的瓶頸，不必多說，就是在硬碟讀寫，這是無法改變的現實。
垂直擴充套件沒有意思的話，何不做水平擴充套件，實現分庫分表，嘗試突破這個瓶頸。此時，mycat進入視線，乙個開源的能實現分庫分表的資料庫中介軟體。
引入了mycat之後，經過一段時間的磨合，load和演算法的處理速度得到了巨大的提公升，基本驗證了這個方向是沒錯的。
平台具備了處理大資料的能力之後，業務層面的演算法就井噴式的湧現出來了。經過一段時間的開發，給使用者推出了更多的分析功能。
經歷了這次的架構公升級，我的心得是業務需求和平台架構應該是相輔相成的。如果不是業務的需求，就不會有公升級架構的驅動力，過多的設計其實是一種浪費，而且團隊資源也是有限的。
EXCEEDDATA 工程大資料分析平台
在此背景下，整車廠研發部門關心的是 如何將企業內部的研發 實驗 測試 生產資料，社會使用者的用車資料，網際網路第三方資料等結合起來，將異構資料和同構資料整合到一起，並在此基礎上，實現業務系統 分析系統和服務系統的一體化 怎樣利用深度的駕駛員行為感知 智慧型的車輛預防性維護 與實時的環境狀態互動，通過...
大資料分析平台 專案2
注意的點 為什麼這麼寫？能不能加些其它的列操作？資料！什麼樣的資料！object模組下建立object main模組 建立usersession object類 思路 session的步長和時間 我從首頁進入到商品詳情到購物車 使用者到底跳轉了多少頁面就是步長 當這個資料統計之後 這個使用者在網頁中...
資料分析 pandas（二）
對時間型別的資料分析的前提就是將原本為字串的時間轉換為標準時間 類名稱說明 timestamp 表示某個時間點 period 表示單個時間跨度，某個時間段 timedelta 不同的單位時間，而非具體的某個時間 datetimeindex 一組timestamp構成的index，可以用來作為seri...