某大佬耗費三年時間整理的：大數據平臺基礎架構指南，成功靠它了

大數據平臺整體建設思想

別人的大數據平臺是怎樣的？

別人的大數據平臺是怎樣的呢?如果參加過一些大大小小的技術分享論壇或會議，你應該不難發現，在各種各樣新的諸如“XXX公司大數據平臺實踐無敵干貨分享”之類的PPT中，談到大數據平臺的技術組件時，多半都.會給出一個大同小異的系統架構圖。

在這個架構圖中，各種日志和DB數據采集組件、存儲和計算引擎、監控和調度系統，不管在實踐中真實的應用情況如何，反正在圖上所有組件一個都不缺，除了個別組件的增減替換，每家公司的大數據平臺看起來都沒有太大的區別。

所以，如果你要問大數據平臺的基礎架構圖長什么樣，不用自己畫，直接用HortonWorks公司的HDP發行版套件圖來展示，估計也沒啥大的不妥，如下圖所示。

服務意識和產品思想的培養

大 數據平臺團隊的職能定位

要談大數據平臺的服務化，要評估大數據平臺的服務水平，首先就得討論什么是大數據平臺的職能定位和服務對象范圍。很不幸的是，這也不是一一個有標準答案的問題。

●在有些公司，大數據團隊只負責基礎組件的開發和運維，為業務方提供SDK、組件套裝或集群形式的服務。

●在有些公司,基礎組件之上的工具、平臺等,都由專門的工具團隊負責, 層層分工，團隊之間交叉服務。

●在有些公司，不同的事業部團隊會自行在基礎平臺組件之上，各自垂直地構建獨立的業務系統，平臺基礎組件開發者服務于上層業務系統開發人員。

●在有些公司，大數據團隊從下到上全鏈路通吃，從集群運維一直負貴到最終具體終端業務數據的產出，對終端使用數據的用戶負責。

工作流(作業)調度系統

在大數據平臺的所有組件中，工作流調度系統(Workflow Scheduler)無疑是最重要的核心組件之一一，是任何一個稍微有點規模且不是簡單做做的大數據開發平臺都必不可少的重要組成部分。

根據具體語境、稱呼習慣和功能指代范圍的細微不同，工作流調度系統也常常被叫作作業調度系統(Job Scheduler)、任務調度系統、工作流作業調度系統，或者在約定場景下干脆被簡稱為調度系統。下文中我們也可能在不造成歧義的情況下，根據需要混用這幾種稱呼。

作為一個業務環境相對復雜的系統，工作流調度系統涉及的內容繁雜，針對的場景多種多樣，實現的方案千差萬別,是一個需要理論和實踐并重的系統。

安全與權限管控

大數據平臺的權限管理工作，聽起來不就是用戶和密碼管理這點事嗎?先找一個數據庫存儲兩者的映射關系，再找- -一個地方記錄每個人可以做什么事，最后在需要的時候驗證一下就好了。如果不討論各種加解密原理和算法，這個話題有什么值得一談的嗎?

實際上，如果真正接觸過這方面的工作內容，你很快就會發現，不論是在技術層面還是在產品層面，大數據平臺環境下的權限管理工作都是一一個讓人傷腦筋的燙手山芋。它不僅是一個技術問題，還是一一個業務問題，甚至還可能是一個人際溝通和權衡利益得失的哲學問題。

如何成為一 名糟糕的大數據平臺工程師

幸福的家庭都是一樣的，不幸的家庭各有各的不幸。

本來想從如何成為一一名優秀的大數據平臺開發工程師的角度入手，但仔細想了一下，從這個角度入手的話，這個話題就太簡單了!雖然我沒有被諸如Jeff Dean之類的大神附體，也不好意思自認為有資格指點江山。但是，講道理這件事，誰不會呢?

好比，炒股票，不就是低買高拋嗎?玩互聯網，不就是拉流量變現嗎?而要想成為一名優秀的大數據平臺開發工程師，只要做到深度與廣度并重，鉆研技術、理解產品、能搭架構、能解Bug，那就妥妥的了。

既然道理如此簡單，還需要多解釋嗎?而我們，大概不是輕松地碾壓了巴菲特，就是早已經順利地在風口起飛了!

是的，優秀的人都是類似的，說起來就太過無聊了。

本書總共10章的內容，從大數據的基礎平臺建設思想到大數據碼農的發展問題，沒有大局觀的人，是無法體會到這本書的真諦的！

限于篇幅過多，所以呢，小編就不一一給大家介紹了，剩下的靠大伙自己去發掘它的美與智慧。

所以呢，需要此【大數據平臺基礎架構指南】的伙伴，就可以轉發此文關注小編，私信小編“學習”來得到獲取方式把！

總之，人生就是一場解決問題的旅程，焦慮在所難免，但適度的危機感也未必是壞事。重要的是，不要讓焦慮過度影響你的判斷，盡量讓自己具備主動選擇未來的能力。

無論各位讀者將來是否從事大數據平臺開發工作，都真心祝愿各位在工作和生活中能直面問題，客觀冷靜地尋找解決方案，用正確的方法論和價值觀為自己贏得一個充實且有價值的人生。