在傳統it企業，專案的物理結構是什麼樣的呢？無論專案內部的如何複雜，都可分為「前台」和「後台」這兩部分。
什麼是前台？
什麼是後台？
後台並不直接面向使用者，而是面向運營人員的配置管理系統，比如商品管理、物流管理、錢包管理、訂單管理、店鋪管理、資料包表等等。後台為前台提供了一些簡單的配置和資料展示。
架構圖如下：
這樣的架構，俗稱，煙筒架構設計。
在傳統的前台-後台架構中，各個專案相對獨立，許多專案都在重**明同樣的輪子，即讓專案本身越來越臃腫，也讓開發效率越來越低。
這種時候，為提高開發效率，我們有必要整合出乙個中間組織，為所有的專案提供一些公共資源。而這個中間組織，就是人們所說的「中臺」。
阿里巴巴，現在的網際網路公司，無人不曉。
他們提出
共享業務事業部，就是阿里巴巴中臺（更確切說，是」業務中臺「）的雛形。
從共享服務架構圖可以看出：是企業」煙囪式「系統建設帶來的3大弊端：
1.重複功能建設
2.維護帶來的重複投資
3.打通煙囪式系統間互動的整合和協作成本高昂、不利於業務沉澱和持續發展。
共享服務架構的建設，擺脫了」煙囪式「系統建設方式帶來的一系列問題。
服務復用
降本增效，這裡的本包括人力成本、時間成本。
1.業務中臺
2.技術中臺
3.資料中臺
4.演算法中臺
業務中颱-架構圖
技術中颱-架構圖
資料中颱-架構圖
演算法中臺 - 架構圖
從0到1的階段，沒有必要搭建中臺。
從0到1的創業型公司，首要目的是生存下去，以最快的速度打造出產品，證明自身的市場價值。
這個時候，讓專案野蠻生長才是最好的選擇。如果不慌不忙地先去搭建中臺，恐怕中颱還沒搭建好，公司早就餓死了。
從1到n的階段，適合搭建中臺。
當企業有了一定規模，產品得到了市場的認可，這時候公司的首要目的不再是活下去，而是活的更好。
這個時候，趁著專案複雜度還不是特別高，可以考慮把各項目的通用部分下沉，組建中臺，以方便後續新專案的嘗試和舊專案的迭代。
從n到n+1的階段，搭建中臺勢在必行。
當企業已經有了很大的規模，各種產品、服務、部門錯綜複雜，這時候做架構調整會比較痛苦。
但是長痛不如短痛，為了專案的長期發展，還是需要盡早調整架構，實現平台化，以免日後越來越難以維護。
我對中颱的理解和企業數字中臺建設的思考
這裡帶有強烈的個人觀點說明和行業視角去闡述 中臺，自阿里提出的時候，就一直是乙個模糊的詞，沒有特別明確的界線，也沒有特別明確的定義。常常理解為介於前台和後台的平台，或者乙個可復用的平台。後來就發展到，前端也提出自已的定義，後端各種框架也提出自己的定義，大資料也提出自己的定義，低 廠商也定義自己的中颱...
資料倉儲 我理解的資料中臺
目錄概述 特點資料應用成熟度 核心 讓資料產生價值 與傳統數倉的區別 技術架構 建設思路 自上而下 自下而上 資料中臺不僅僅是乙個技術棧，還是一種經營理念 需要利用資料中臺理論提高企業的組織效率 協同效率 運營效率 不僅僅是業務和技術聚在一起，業務提需求，技術畫架構，然後開發實現，這樣一定做不好資料...
Numpy中axis我的理解
以前我理解axis 0代表行，axis 1代表列 但是這種含義在函式size 和max 中恰恰相反 其實不是這樣的，我們回到單詞axis本身，它的意思是 軸 沒錯軸就是代表乙個方向，像x軸，y軸，如圖所示 axis 0代表的就是x軸方向 axis 1代表的就是y軸方向 這樣函式size 和max 就...