處理大數(shù)據(jù)的基礎(chǔ)架構(gòu)，OLTP和OLAP的區(qū)別，數(shù)據(jù)庫與Hadoop、Spark、Hive和Flink大數(shù)據(jù)技術(shù)

2022找工作是學歷、能力和運氣的超強結(jié)合體，遇到寒冬，大廠不招人，可能很多算法學生都得去找開發(fā)，測開
測開的話，你就得學數(shù)據(jù)庫，sql，oracle，尤其sql要學，當然，像很多金融企業(yè)、安全機構(gòu)啥的，他們必須要用oracle數(shù)據(jù)庫
這oracle比sql安全，強大多了，所以你需要學習，最重要的，你要是考網(wǎng)絡(luò)警察公務(wù)員，這玩意你不會就別去報名了，耽誤時間！
與此同時，既然要考網(wǎng)警之數(shù)據(jù)分析應(yīng)用崗，那必然要考數(shù)據(jù)挖掘基礎(chǔ)知識，今天開始咱們就對數(shù)據(jù)挖掘方面的東西好生講講 最最最重要的就是大數(shù)據(jù)，什么行測和面試都是小問題，最難最最重要的就是大數(shù)據(jù)技術(shù)相關(guān)的知識筆試

處理大數(shù)據(jù)的基礎(chǔ)架構(gòu)

處理大數(shù)據(jù)的基礎(chǔ)架構(gòu)主要有以下幾種：

分布式計算框架。
如Hadoop、Spark、Hive和Flink等，這些框架可以處理大規(guī)模的數(shù)據(jù)，并支持分布式存儲和計算。

分布式文件系統(tǒng)。
如HDFS（Hadoop Distributed File System）和Google File System等，這些系統(tǒng)可以存儲大規(guī)模的文件，并支持分布式訪問和讀取。

數(shù)據(jù)庫集群。
如MySQL集群、PostgreSQL集群等，這些集群可以提高數(shù)據(jù)處理效率和可用性，并支持分布式事務(wù)處理。

NoSQL數(shù)據(jù)庫。
如MongoDB、Cassandra和Redis等，這些數(shù)據(jù)庫可以處理半結(jié)構(gòu)化和非結(jié)構(gòu)化的數(shù)據(jù)，并支持高并發(fā)寫入和讀取。

云平臺。
如Amazon AWS、Google Cloud和阿里云等，這些云平臺可以提供虛擬化資源、彈性伸縮和自動化運維等功能，使得處理大數(shù)據(jù)更加靈活和高效。

這些基礎(chǔ)架構(gòu)可以相互組合和擴展，以適應(yīng)不同的大數(shù)據(jù)處理場景和需求。

之后我們一個個來學習上述提到的東西，形成一個大數(shù)據(jù)處理的框架，備考大數(shù)據(jù)類的試題

沖

Hadoop、Spark、Hive和Flink

小數(shù)據(jù)問題不大

OLTP是啥？

OLTP( On-Line Transaction Processing ) 聯(lián)機事務(wù)處理過程，
通常也可以成為面向交易的處理系統(tǒng)。

個人理解為主要場景針對用戶人機交互頻繁，數(shù)據(jù)量小，操作快速響應(yīng)的實時處理系統(tǒng)中。
Mysql以及Oracle等數(shù)據(jù)庫軟件可以理解為OLTP的工業(yè)應(yīng)用軟件體現(xiàn)。

OLAP( On-Line Analytical Processing)，聯(lián)機分析處理過程。
個人理解為主要場景針對大批量數(shù)據(jù)，實時性無要求，基于數(shù)倉多維模型，進行分析操作的系統(tǒng)中。
Hadoop體系中MapReduce、Hive、Spark、Flink等都可以進行為OLAP實現(xiàn)。

原來如此了，數(shù)據(jù)庫做不了大數(shù)據(jù)的分析類的問題

T是事務(wù)
A是分析

為什么要大數(shù)據(jù)？

06年寫Java的MapReduce程序，難理解

后來寫sql得了，很簡單


yarn出來就調(diào)度一把
美滋滋

docker現(xiàn)在聽說得很多：隔離空間
yarn是container集裝箱

只寫sql然后轉(zhuǎn)譯為hive那邊的Java

還有pyspark，寫Python很容易

相當于是兼容超級多的程序

批處理，這些是【離線一大批】

下面是流式計算【實時快速處理】

兩家很騷，后來倆都能處理了
各種技術(shù)你看看是不是穿起來了………………


你是做那一層呢？

kafka傳輸技術(shù)，快速

我們從傳輸開始學起

TB級別量的數(shù)據(jù)，后續(xù)可以對接很多大數(shù)據(jù)處理技術(shù)框架

有點厲害了

現(xiàn)有的消息模型？

半結(jié)構(gòu)化的東西

kafka是分布式消息系統(tǒng)

使得kafka有擴展性

offset不可重復(fù)

map消息

不給key那就隨機分配
否則分區(qū)

同樣的key，同樣的key放一起


follower就去復(fù)制數(shù)據(jù)，同步，保持數(shù)據(jù)的可恢復(fù)性
這樣的話，就不會丟失了

broker就是一臺服務(wù)器，負責讀寫

主分區(qū)由broker讀寫

kafka監(jiān)聽器

docker去部署kafka的內(nèi)外網(wǎng)監(jiān)聽端口

kafka的消息模型

處于性能和開銷的考慮
否則還要維護鎖，加鎖，減鎖
否則就會引入競爭，麻煩
最大化我們要提升性能和吞吐量


這種是一對一



不同分區(qū)之間的消費順序不知道
offset早的是先消費

你想要保證順序會設(shè)置key同

tcp？
ack確認信息

先讀信息，至少讀一次

給位置，最多讀一次，可以不讀

生產(chǎn)者api

生產(chǎn)者只大量生產(chǎn)，不管消費，現(xiàn)在就是中國緩沖區(qū)滿了，老百姓沒錢消費，導(dǎo)致生產(chǎn)過剩

需要通過一帶一路出去消費，這時候美國不樂意

物流系統(tǒng)？

就是網(wǎng)購系統(tǒng)，一次精確消費

我扣款那邊就要收款
我失敗他不能收款
我付款了，他不能允許說沒收到

這就是原子性

數(shù)據(jù)庫就這樣的特性

kafka序列化

前序、中序、后序序列化
跟買電腦一樣
一堆零件，你送到了，找?guī)煾蛋惭b

實際上

要卡主時間順序的

騷

注冊制

header標識一下

實際訂餐和菜品看不到

如果前面完不成，后面就gg
網(wǎng)絡(luò)延時導(dǎo)致的

異步重試順序如何保證

一會上菜，半天看不到，gg
消息積壓很惡心

不看所有信息，只看id

又有問題，看日志
有幾個商戶的訂單賊多，都放一個partition，怎么辦？

那按照用戶編號來放，這樣，某個訂單就走同一個partition

這樣好多了
后面呢？

促銷……

太騷了







哈哈哈技術(shù)太難了
消息積壓有不同的原因

單表存了太多的菜品


并發(fā)太大，倆請求同事查到，id不存在
同時插入，第二個就gg
加鎖？

Redis分布式鎖怎么說？
不行，消費著網(wǎng)絡(luò)超時gg

嘗試插入，不行就改key

主從服務(wù)器
有訂單，但是沒有菜
主從數(shù)據(jù)庫同步延時
就查不到數(shù)據(jù)
或者查不到最新數(shù)據(jù)

精確傳才行

kafka默認就是容易重復(fù)

不存在插入，存在就更新

公用數(shù)據(jù)庫和kafka系統(tǒng)

在不同環(huán)境中切換容易出錯
所以配置要搞清楚

cpu容易掛的話，gg

kafka是牛逼的，很少出問題，大多都是邏輯出了問題。

總結(jié)

提示：重要經(jīng)驗：

1）
2）學好oracle，即使經(jīng)濟寒冬，整個測開offer絕對不是問題！同時也是你考公網(wǎng)絡(luò)警察的必經(jīng)之路。
3）筆試求AC，可以不考慮空間復(fù)雜度，但是面試既要考慮時間復(fù)雜度最優(yōu)，也要考慮空間復(fù)雜度最優(yōu)。文章來源地址http://www.zghlxwxcb.cn/news/detail-716350.html

到了這里，關(guān)于處理大數(shù)據(jù)的基礎(chǔ)架構(gòu)，OLTP和OLAP的區(qū)別，數(shù)據(jù)庫與Hadoop、Spark、Hive和Flink大數(shù)據(jù)技術(shù)的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！