183.17.230.*
2020-08-26 13:13:56 |
面對大數據，在數據和技術都失控的情況下，考慮如何強加對數據的控制和提高駕馭數據的能力都很可能是徒勞的。我們需要重新思考大數據平臺的設計哲學，而不是在傳統大型軟件設計的哲學下做加強和修補。
擁抱不**：
首先，我們必須承認我們的無知和無能，放棄去構建一個全知全能的平臺的理想。我們需要思考大數據平臺要管什么，更重要的是不管什么。
我們需要在該放手的地方就放手，我們需要接受甚至是擁抱某種程度的失控。我們很可能就沒有辦法把所有數據都非常好的管起來，只需要通過平臺，新手就很容易把數據情況搞清楚。我們很可能也無法提供完全統一設計風格、交互邏輯的功能界面。我們必須容忍一定的混亂，從而擁抱無限的可能和變化。
經驗與價值的沉淀：
還是先從數據來看，了解數據最便捷的途徑就是找到最了解這個數據的人進行直接溝通。最了解數據的人可能是數據的生產者，也可能是數據的處理者，甚至是消費者。很多情況下完全搞清楚，可能需要與所有相關方都進行溝通后才比較清楚。平臺的設計到底是要**這種直接溝通，還是讓這種溝通更**率呢？
因為**文檔化是不現實的，那么我們能夠考慮的是讓目前的方式效率更高。數據平臺能夠承擔的一個功能是更**的把數據的需求方和了解數據的人連接起來。原來我想找一個了解某個數據的人，都可能需要問好幾個人，而要了解清楚一個數據又可能需要找到好幾個人，這就需要不斷在線下反復的溝通。如果平臺能夠告訴我哪些人對這些數據最了解，這就可以提升相當多的效率。
當一個人一位對某個數據最了解，而被人問了很多次問到很煩的時候，他可以把自己對這個數據的總結的文檔和FQA放到平臺上。對這個數據關心的人也可以寫評論談自己對數據的理解和遇到的坑。當一個數據被使用的越多，那么平臺上就可以沉淀出越多關于這個數據的信息，包括最熟悉的人和各種對數據的描述和解讀，后來的使用者就越容易掌握這個數據。
我們可以想象，一個數據平臺，經過一段時間的沉淀，有些數據的相關文檔會變得十分豐富，而有些數據根本無人問津。當我們不追求**的控制后，最有價值的信息可能就自動涌現了。當然，當我們要使用一些鮮有人問津的數據時，就需要經歷一個比較痛苦的過程。但是只要平臺能把這個過程積累到的經驗沉淀下來，就是有價值的。
從標準化到社區化：
利用大數據是需要探索精神的，大數據平臺不應該是一條機械的流水線，把使用者變成一個個沒有聯系的隨時可以替換掉的零部件。因為我們不可能做成真正構建這樣**率的流水線。同時，我們幾乎無法用一套客觀的量化指標來衡量對數據的利用效率，我們必須寄希望于人的主動精神。
大數據平臺的設計哲學應該以人為中心，尊重人的價值，激勵人的探索和創新精神，讓對數據有激情的人能夠涌現出來，產生更大的聲音，同時鼓勵和便利人與人之間的溝通，從而提高總體的效率。總之，平臺設計思想應該從標準化轉為社區化。”
彈性與開放：
從技術上來看，我們需要盡可能的適應各種不同的功能和性能需求以及未來可能出現的技術演進。為了解決這個問題，我們需要的不是一個結構復雜包羅萬象的技術架構，因為越復雜的系統就越脆弱，就越難以進化。我們也不能綁定核心計算引擎就是Spark或者某幾種特定技術，否則這就不是一個能力**的數據平臺。
很多為自有業務設計的數據平臺是可以考慮業務特性來進行特化的。但是我們作為企業服務的提供商，需要考慮的是足夠的通用性和靈活性。我們在技術架構的設計哲學上，不應該執著于提供多少強大的功能，而是應該專注于能夠提供多少可能性和可擴展性。我們永遠無法知道明天客戶會有什么新需求，也無法知道會有什么新技術出現。
因此在技術架構上，應該以容器技術為基礎，實現彈性的資源管理，和對技術和功能的開放支持能力。在容器技術的支持下，可以做到不同計算資源的即開即用即回收，可以支持資源的動態智能調整。當一個任務需要Spark時就創建Spark集群，需要TensorFlow就創建TensorFlow集群，任務完成就可以把資源及時回收，任務過程中根據資源使用情況和任務完成要求，動態的增加或者減少資源。
這種架構下，我們不是將各種技術能力整合封裝成各種固定功能提供給使用者將他們的工作傻瓜化，而是向使用者賦能為其開放各種技術能力以及資源能力去創造無限的可能性。這種架構下很難提供統一的界面設計風格、交互邏輯，很多工作也需要使用者開發完成。
因為我們無法做到對所有的技術進行統一風格的封裝，而是把所有的技術直接暴露給了使用者，使用者必須自己使用這些技術來解決問題。當然這并不是說我們不需要做產品設計，只是產品設計的出發點不是創造一套獨立**的體系，而是應該著力于讓使用者更容易的將不同的技術方便的組織起來，同時減少在不同技術之間切換的麻煩。
同時，技術架構也需要考慮不同模塊之間如何組織的問題，這個問題遵循服務化的思路應該是已經形成共識，這里就不再過多展開。只是個人覺得在推行服務化之前，我們需要把服務接口的標準、服務總線的技術定下來。有好的服務基礎架構，新增、替換、升級不同的模塊就變得相對容易。從需求角度確定的功能和模塊不可能是****正確的，后續一定會面臨著重構和調整的問題。只有做好面對一切變化的準備，才能更好的面對各種不確定性。
適應而不是約束：
**，我想談談關于方法論的問題。產品設計方法論先行是對的，但是我們要深入思考什么才是**的方法論。關于數據挖掘的方法論已經存在十幾年了(CRISP-DM)，老實說我們在思考的數據科學的方法論并不會有本質性的改變。但我對這些方法論的感覺就是“如何把大象放進冰箱”，或者5步畫馬法。原則上都對，但是對實際工作的指導意義非常有限，因為魔鬼都在細節中。
其實面對大數據，不僅我們對數據和技術是失控的，實際上我們如何處理、應用數據的過程在很大程度上也是失控的。整個過程就像在走迷宮，工作步驟分形似的不斷展開。任何大的指導原則對于具體工作的指導意義就變得極為有限。
正因為如此，產品設計應該考慮的是如何適應這種Ad-hoc的工作狀態，而不是用一套流程把使用者束縛起來。我們可以提供一些機制便于使用者來梳理手頭的工作，但是盡可能不要去強制使用者遵守某種約束性很強的標準或者規范。
為什么像NoteBook這樣設計如此簡單的工具能夠流行起來，很重要的一點就是給使用者足夠自由的工作界面來做任何想做的事情，而且即寫即得，便于隨時修改策略，同時文檔可以根據需要隨時插在代碼之中。正是這種無結構的扁平性，使得用戶可以按照最合適的路徑去完成自己的工作，而不是在被設計好的過程中掙扎。
大數據平臺設計哲學的重構.中琛魔方大數據分析平臺(www.zcmorefun.com)表示我們首先必須承認理性的力量是有限的，我們不是無所不能的。面對著數據失控、技術失控和需求失控的問題，我們到底是要想盡一切辦法去控制，還是順應、包容甚至是欣賞這些失控。這是在我們智能數據平臺研發道路的起點上需要思考的問題。 |
您當前的位置: 首頁 > 行業貼吧 > 話題