㈠ 設計一個大數據實時分析平台要怎麼做呢
PetaBase-V作為Vertica基於億信分析產品的定製版，提供面向大數據的實時分析服務，採用無共享大規模並行架構（MPP），可線性擴展集群的計算能力和數據處理容量，基於列式資料庫技術，使 PetaBase-V 擁有高性能、高擴展性、高壓縮率、高健壯性等特點，可完美解決報表計算慢和明細數據查詢等性能問題。
大數據實時分析平台（以下簡稱PB-S），旨在提供數據端到端實時處理能力（毫秒級／秒級／分鍾級延遲），可以對接多數據源進行實時數據抽取，可以為多數據應用場景提供實時數據消費。作為現代數倉的一部分，PB-S可以支持實時化、虛擬化、平民化、協作化等能力，讓實時數據應用開發門檻更低、迭代更快、質量更好、運行更穩、運維更簡、能力更強。
整體設計思想
我們針對用戶需求的四個層面進行了統一化抽象：
統一數據採集平台
統一流式處理平台
統一計算服務平台
統一數據可視化平台
同時，也對存儲層保持了開放的原則，意味著用戶可以選擇不同的存儲層以滿足具體項目的需要，而又不破壞整體架構設計，用戶甚至可以在Pipeline中同時選擇多個異構存儲提供支持。下面分別對四個抽象層進行解讀。
1)統一數據採集平台
統一數據採集平台，既可以支持不同數據源的全量抽取，也可以支持增強抽取。其中對於業務資料庫的增量抽取會選擇讀取資料庫日誌，以減少對業務庫的讀取壓力。平台還可以對抽取的數據進行統一處理，然後以統一格式發布到數據匯流排上。這里我們選擇一種自定義的標准化統一消息格式UMS（Unified Message Schema）做為 統一數據採集平台和統一流式處理平台之間的數據層面協議。
UMS自帶Namespace信息和Schema信息，這是一種自定位自解釋消息協議格式，這樣做的好處是：
整個架構無需依賴外部元數據管理平台；
消息和物理媒介解耦（這里物理媒介指如Kafka的Topic, Spark Streaming的Stream等），因此可以通過物理媒介支持多消息流並行，和消息流的自由漂移。
平台也支持多租戶體系，和配置化簡單處理清洗能力。
2)統一流式處理平台
統一流式處理平台，會消費來自數據匯流排上的消息，可以支持UMS協議消息，也可以支持普通JSON格式消息。同時，平台還支持以下能力：
支持可視化／配置化／SQL化方式降低流式邏輯開發／部署／管理門檻
支持配置化方式冪等落入多個異構目標庫以確保數據的最終一致性
支持多租戶體系，做到項目級的計算資源／表資源／用戶資源等隔離
3)統一計算服務平台
統一計算服務平台，是一種數據虛擬化／數據聯邦的實現。平台對內支持多異構數據源的下推計算和拉取混算，也支持對外的統一服務介面（JDBC／REST）和統一查詢語言（SQL）。由於平台可以統一收口服務，因此可以基於平台打造統一元數據管理／數據質量管理／數據安全審計／數據安全策略等模塊。平台也支持多租戶體系。
4)統一數據可視化平台
統一數據可視化平台，加上多租戶和完善的用戶體系／許可權體系，可以支持跨部門數據從業人員的分工協作能力，讓用戶在可視化環境下，通過緊密合作的方式，更能發揮各自所長來完成數據平台最後十公里的應用。
以上是基於整體模塊架構之上，進行了統一抽象設計，並開放存儲選項以提高靈活性和需求適配性。這樣的RTDP平台設計，體現了現代數倉的實時化／虛擬化／平民化／協作化等能力，並且覆蓋了端到端的OLPP數據流轉鏈路。
具體問題和解決思路
下面我們會基於PB-S的整體架構設計，分別從不同維度討論這個設計需要面對的問題考量和解決思路。
功能考量主要討論這樣一個問題：實時Pipeline能否處理所有ETL復雜邏輯？
我們知道，對於Storm／Flink這樣的流式計算引擎，是按每條處理的；對於Spark Streaming流式計算引擎，按每個mini-batch處理；而對於離線跑批任務來說，是按每天數據進行處理的。因此處理范圍是數據的一個維度（范圍維度）。
另外，流式處理面向的是增量數據，如果數據源來自關系型資料庫，那麼增量數據往往指的是增量變更數據（增刪改，revision）；相對的批量處理面向的則是快照數據（snapshot）。因此展現形式是數據的另一個維度（變更維度）。
單條數據的變更維度，是可以投射收斂成單條快照的，因此變更維度可以收斂成范圍維度。所以流式處理和批量處理的本質區別在於，面對的數據范圍維度的不同，流式處理單位為「有限范圍」，批量處理單位為「全表范圍」。「全表范圍」數據是可以支持各種SQL運算元的，而「有限范圍」數據只能支持部分SQL運算元。
復雜的ETL並不是單一運算元，經常會是由多個運算元組合而成，由上可以看出單純的流式處理並不能很好的支持所有ETL復雜邏輯。那麼如何在實時Pipeline中支持更多復雜的ETL運算元，並且保持時效性？這就需要「有限范圍」和「全表范圍」處理的相互轉換能力。
設想一下：流式處理平台可以支持流上適合的處理，然後實時落不同的異構庫，計算服務平台可以定時批量混算多源異構庫（時間設定可以是每隔幾分鍾或更短），並將每批計算結果發送到數據匯流排上繼續流轉，這樣流式處理平台和計算服務平台就形成了計算閉環，各自做擅長的運算元處理，數據在不同頻率觸發流轉過程中進行各種運算元轉換，這樣的架構模式理論上即可支持所有ETL復雜邏輯。
2)質量考量
上面的介紹也引出了兩個主流實時數據處理架構：Lambda架構和Kappa架構，具體兩個架構的介紹網上有很多資料，這里不再贅述。Lambda架構和Kappa架構各有其優劣勢，但都支持數據的最終一致性，從某種程度上確保了數據質量，如何在Lambda架構和Kappa架構中取長補短，形成某種融合架構，這個話題會在其他文章中詳細探討。
當然數據質量也是個非常大的話題，只支持重跑和回灌並不能完全解決所有數據質量問題，只是從技術架構層面給出了補數據的工程方案。關於大數據數據質量問題，我們也會起一個新的話題討論。
3)穩定考量
這個話題涉及但不限於以下幾點，這里簡單給出應對的思路：
高可用HA
整個實時Pipeline鏈路都應該選取高可用組件，確保理論上整體高可用；在數據關鍵鏈路上支持數據備份和重演機制；在業務關鍵鏈路上支持雙跑融合機制
SLA保障
在確保集群和實時Pipeline高可用的前提下，支持動態擴容和數據處理流程自動漂移
彈性反脆弱
? 基於規則和演算法的資源彈性伸縮
? 支持事件觸發動作引擎的失效處理
監控預警
集群設施層面，物理管道層面，數據邏輯層面的多方面監控預警能力
自動運維
能夠捕捉並存檔缺失數據和處理異常，並具備定期自動重試機制修復問題數據
上游元數據變更抗性
?上游業務庫要求兼容性元數據變更
? 實時Pipeline處理顯式欄位
4)成本考量
這個話題涉及但不限於以下幾點，這里簡單給出應對的思路：
人力成本
通過支持數據應用平民化降低人才人力成本
資源成本
通過支持動態資源利用降低靜態資源佔用造成的資源浪費
運維成本
通過支持自動運維／高可用／彈性反脆弱等機制降低運維成本
試錯成本
通過支持敏捷開發／快速迭代降低試錯成本
5)敏捷考量
敏捷大數據是一整套理論體系和方法學，在前文已有所描述，從數據使用角度來看，敏捷考量意味著：配置化，SQL化，平民化。
6)管理考量
數據管理也是一個非常大的話題，這里我們會重點關注兩個方面：元數據管理和數據安全管理。如果在現代數倉多數據存儲選型的環境下統一管理元數據和數據安全，是一個非常有挑戰的話題，我們會在實時Pipeline上各個環節平台分別考慮這兩個方面問題並給出內置支持，同時也可以支持對接外部統一的元數據管理平台和統一數據安全策略。
以上是我們探討的大數據實時分析平台PB-S的設計方案。
㈡ 創建大數據項目的五大步驟
創建大數據項目的五大步驟
企業需要積極的提升他們的數據管理能力。這並非意味著他們應該制定繁瑣的流程和監督機制。明智的企業會配合他們的數據活動的生命周期制定靈活的流程和功能：根據業務需求啟動更輕更嚴格、更強大的功能，並根據需求的增加來提升質量或精度。
一些企業正在利用新興技術來應對新的數據源，但大多數企業仍然面臨著需要努力管理好他們已經掌握或者應當掌握的數據信息的困境，而當他們試圖部署大數據功能時，發現自己還需要面對和處理新的以及當下實時的數據。
為了能夠實現持久成功的大數據項目，企業需要把重點放在如下五個主要領域。
1、確立明確的角色分工和職責范圍。
對於您企業環境中的所有的數據信息，您需要對於這些數據信息所涉及的關鍵利益相關者、決策者有一個清晰的了解和把控。當數據信息在企業的系統傳輸過程中及其整個生命周期中，角色分工將發生變化，而企業需要對這些變化有一個很好的理解。當企業開始部署大數據項目之後，務必要明確識別相關數據的關鍵利益相關者，並做好這些數據信息的完善和迭代工作。
2、加強企業的數據治理和數據管理功能。
確保您企業的進程足夠強大，能夠滿足和支持大數據用戶和大數據技術的需求。進程可以是靈活的，並應充分考慮到業務部門和事務部門的需求，這些部門均伴有不同程度的嚴謹性和監督要求。
確保您企業的參考信息架構已經更新到包括大數據。這樣做會給未來的項目打好最好的使用大數據技術和適當的信息管理能力的基礎。
確保您企業的元數據管理功能足夠強大，能夠包括並關聯所有的基本元數據組件。隨著時間的推移，進行有序的分類，滿足業務規范。
一旦您開始在您企業的生產部門推廣您的解決方案時，您會希望他們長期持續的使用該解決方案，所以對架構功能的定義並監督其發揮的作用是至關重要的。確保您企業的治理流程包括IT控制的角色，以幫助企業的利益相關者們進行引導項目，以最佳地利用這些數據信息。其還應該包括您企業的安全和法務團隊。根據我們的經驗，使用現有的監督機制能夠達到最佳的工作狀態，只要企業實施了大數據應用，並專注於快速在進程中處理應用程序，而不是阻礙進程的通過。
3、了解環境中的數據的目的和要求的精度水平，並相應地調整您企業的期望值和流程。
無論其是一個POC，或一個已經進入主流業務流程的項目，請務必確保您對於期望利用這些數據來執行什麼任務，及其質量和精度處於何種級別有一個非常清晰的了解。這種方法將使得企業的項目能夠尋找到正確的數據來源和利益相關者，以更好地評估這些數據信息的價值和影響，進而讓您決定如何最好地管理這些數據信息。更高的質量和精度則要求更強大的數據管理和監督能力。
隨著您企業大數據項目的日趨成熟，考慮建立一套按照數據質量或精確度分類的辦法，這將使得數據用戶得以更好的了解他們所使用的是什麼，並相應地調整自己的期望值。例如，您可以使用白色、藍色或金色來分別代表原始數據、清理過的數據，經過驗證可以有針對性的支持分析和使用的數據。有些企業甚至進一步完善了這一分類方法：將數據從1到5進行分類，其中1是原始數據，而5是便於理解，經過整理的、有組織的數據。
4、將對非結構化的內容的管理納入到您企業的數據管理能力。
非結構化數據一直是企業業務運營的一部分，但既然現在我們已經有了更好的技術來探索，分析和這些非結構化的內容，進而幫助改善業務流程和工業務洞察，所以我們最終將其正式納入我們的數據管理是非常重要的。大多數企業目前都被困在了這一步驟。
資料庫中基本的、非結構化的數據是以評論的形式或者自由的形式存在的，其至少是資料庫的一部分，應該被納入到數據管理。但挖掘這些數據信息則是非常難的。
數字數據存儲在傳統的結構化資料庫和業務流程外，很少有許多的治理范圍分組和數據管理的實現，除了當其被看作是一個技術問題時。一般來說，除了嚴格遵守相關的安全政策，今天的企業尚未對其進行真正有效的管理。當您的企業開始大跨步實現了大數據項目之後，您會發現這一類型的數據信息迅速進入了您需要管理的范疇，其輸出會影響您企業的商業智能解決方案或者甚至是您企業的業務活動。積極的考慮將這些數據納入到您企業的數據管理功能的范圍，並明確企業的所有權，並記錄好這些數據信息的諸如如何使用、信息來源等等資料。
不要採取「容易的輕松路線」，單純依靠大數據技術是您企業唯一正式的非結構化數據管理的過程。隨著時間的推移，企業將收集越來越多的非結構化數據，請務必搞清楚哪些數據是好的，哪些是壞的，他們分別來自何處，以及其使用是否一致，將變得越來越重要，甚至在其生命周期使用這個數據都是至關重要的。
要保持這種清晰，您可以使用大數據和其他工具，以了解您企業所收集的數據信息，確定其有怎樣的價值，需要怎樣的管理，這是至關重要的。大多數進入您企業的大數據系統的非結構化數據都已經經過一些監控了，但通常是作為一個BLOB（binarylargeobject）二進制大對象和非結構化的形式進行的。隨著您的企業不斷的在您的業務流程中「發掘」出這一類型的數據，其變得更加精確和有價值。其可能還具有額外的特點，符合安全，隱私或法律和法規的元素要求。最終，這些數據塊可以成為新的數據元素或添加到現有的數據，但您必須有元數據對其進行描述和管理，以便盡可能最有效地利用這些數據。
5、正式在生產環境運行之前進行測試。
如果您的企業做的是一次性的分析或完整的一次性的試點，這可能並不適用於您的企業，但對大多數企業來說，他們最初的大數據工作將迅速發展，他們找到一個可持續利用他們已經挖掘出的極具價值的信息的需求。這意味著需要在您的沙箱環境中進行測試，然後才正式的在您的生產環境運。
㈢ 最近公司接到一個項目,數據實時監控大屏展示怎麼做,推薦一下
大數據看班，平台和拼控
㈣ 鐧句嚎綰у疄鏃跺ぇ鏁版嵁鍒嗘瀽欏圭洰錛屼負浠涔堜笉鐢℉adoop
銆銆1. Hadoop闆嗙兢鐨勬墿灞曟ф槸鍏朵竴澶х壒鐐癸紝Hadoop鍙浠ユ墿灞曡嚦鏁板崈涓鑺傜偣錛屽規暟鎹鎸佺畫澧為暱錛屾暟鎹閲忕壒鍒宸ㄥぇ鐨勯渶奼傚緢鍚堥傘
銆銆2. Hadoop鐨勬垚鏈鏄鍏跺彟涓澶т紭鍔匡紝鐢變簬Hadoop鏄寮婧愰」鐩錛岃屼笖涓嶄粎浠庤蔣浠朵笂鑺傜害鎴愭湰錛岀‖浠朵笂鐨勮佹眰涔熶笉楂樸傜洰鍓嶅幓IOE娼嫻侀庤岋紝浣庢垚鏈鐨凥adoop涔熸槸涓澶ф帹鎵嬨
銆銆3. Hadoop鐢熸佺兢媧昏穬錛屽叾鍛ㄨ竟寮婧愰」鐩涓板瘜錛孒Base, Hive錛孖mpala絳夌瓑鍩虹寮婧愰」鐩浼楀氥
銆銆
㈤ 大數據數倉項目架構
雲上數據倉庫解決方案： https://www.aliyun.com/solution/datavexpo/datawarehouse
離線數倉架構
離線數倉特點
基於Serverless的雲上數據倉庫解決方案
架構特點
實時數倉架構
[圖片上傳失敗...(image-ec3d9a-1629814266849)]
實時數倉架構特點
秒級延遲，實時構建數據倉庫，架構簡單，傳統數倉平滑升級
架構特點
數據倉庫的輸入數據源和輸出系統分別是什麼？
輸入系統：埋點產生的用戶行為數據、javaEE後台產生的業務數據、個別公司有爬蟲數據。
輸出系統：報表系統、用戶畫像系統、推薦系統
1）Apache：運維麻煩，組件間兼容性需要自己調研。（一般大廠使用，技術實力雄厚，有專業的運維人員）
2）CDH：國內使用最多的版本，但 CM不開源，但其實對中、小公司使用來說沒有影響（建議使用）10000美金一個節點 CDP
3）HDP：開源，可以進行二次開發，但是沒有CDH穩定，國內使用較少
伺服器使用物理機還是雲主機？
1）機器成本考慮：
（1）物理機：以128G內存，20核物理CPU，40線程，8THDD和2TSSD硬碟，單台報價4W出頭，惠普品牌。一般物理機壽命5年左右。
（2）雲主機，以阿里雲為例，差不多相同配置，每年5W
2）運維成本考慮：
（1）物理機：需要有專業的運維人員（1萬*13個月）、電費（商業用戶）、安裝空調
（2）雲主機：很多運維工作都由阿里雲已經完成，運維相對較輕松
3）企業選擇
（1）金融有錢公司和阿里沒有直接沖突的公司選擇阿里雲（上海）
（2）中小公司、為了融資上市，選擇阿里雲，拉倒融資後買物理機。
（3）有長期打算，資金比較足，選擇物理機。
根據數據規模大家集群
屬於 研發部 /技術部/數據部，我們屬於 大數據組 ，其他還有後端項目組，前端組、測試組、UI組等。其他的還有產品部、運營部、人事部、財務部、行政部等。
大數據開發工程師=>大數據組組長=》項目經理=>部門經理=》技術總監
職級就分初級，中級，高級。晉升規則不一定，看公司效益和職位空缺。
京東：T1、T2應屆生；T3 14k左右 T4 18K左右 T5 24k-28k左右
阿里：p5、p6、p7、p8
小型公司（3人左右）：組長1人，剩餘組員無明確分工，並且可能兼顧javaEE和前端。
中小型公司（3~6人左右）：組長1人，離線2人左右，實時1人左右（離線一般多於實時），組長兼顧和javaEE、前端。
中型公司（5 10人左右）：組長1人，離線3 5人左右（離線處理、數倉），實時2人左右，組長和技術大牛兼顧和javaEE、前端。
中大型公司（10 20人左右）：組長1人，離線5 10人（離線處理、數倉），實時5人左右，JavaEE1人左右（負責對接JavaEE業務），前端1人（有或者沒有人單獨負責前端）。（發展比較良好的中大型公司可能大數據部門已經細化拆分，分成多個大數據組，分別負責不同業務）
上面只是參考配置，因為公司之間差異很大，例如ofo大數據部門只有5個人左右，因此根據所選公司規模確定一個合理范圍，在面試前必須將這個人員配置考慮清楚，回答時要非常確定。
IOS多少人 安卓多少人 前端多少人 JavaEE多少人 測試多少人
（IOS、安卓） 1-2個人 前端1-3個人； JavaEE一般是大數據的1-1.5倍，測試：有的有，有的沒有。1個左右。 產品經理1個、產品助理1-2個，運營1-3個
公司劃分：
0-50 小公司
50-500 中等
500-1000 大公司
1000以上 大廠 領軍的存在
轉自： https://blog.csdn.net/msjhw_com/article/details/116003357