chinesefreesexvideos高潮,欧美极品少妇性运交,久久久国产一区二区三区,99久久婷婷国产综合精品,成人国产一区二区三区

這是我的第36篇原創(chuàng)

之前分享過中臺(tái)，前兩天又分享了數(shù)據(jù)治理的相關(guān)內(nèi)容。有個(gè)同學(xué)嚷嚷著讓我說一下數(shù)據(jù)中臺(tái)。雖然我做過數(shù)據(jù)中臺(tái)，但是不算成功，寫起來總覺得不太自信。

既然朋友盛情邀請(qǐng)，那就把我的理解整理一下，給大家分享一下。

OK，Let's GO！

在數(shù)據(jù)領(lǐng)域，從業(yè)務(wù)方向上可以分為OLTP（聯(lián)機(jī)事務(wù)處理）和OLAP（聯(lián)機(jī)分析處理）兩個(gè)領(lǐng)域。這個(gè)名字很拗口，但是也很有意思。

OLTP就是你在本地操作，相對(duì)于單機(jī)而言，數(shù)據(jù)記錄在本地，就叫單機(jī)事務(wù)處理，在本機(jī)操作，數(shù)據(jù)記錄在服務(wù)器上，這叫聯(lián)機(jī)事務(wù)處理。

OLAP就是數(shù)據(jù)存在服務(wù)器上，你在本地調(diào)用數(shù)據(jù)進(jìn)行在線分析，這叫聯(lián)機(jī)分析處理。

OLTP的發(fā)展路徑其實(shí)就是數(shù)據(jù)庫(kù)的不斷演進(jìn)，從關(guān)系型數(shù)據(jù)庫(kù)從單機(jī)數(shù)據(jù)庫(kù)到高可用版本，到現(xiàn)在的分布式關(guān)系型數(shù)據(jù)庫(kù)。另外為了滿足各種場(chǎng)景下的數(shù)據(jù)存儲(chǔ)和查詢，還誕生了NoSQL、MPP、時(shí)序數(shù)據(jù)庫(kù)等一系列的數(shù)據(jù)庫(kù)，大數(shù)據(jù)行業(yè)就此拉開序幕。

OLAP的發(fā)展路徑也很有意思。一開始只是在業(yè)務(wù)數(shù)據(jù)庫(kù)中建個(gè)表，統(tǒng)計(jì)一下各種固定報(bào)表。后來需要分析的內(nèi)容越來越多，就開始不斷的向前發(fā)展，這樣也迎來了大數(shù)據(jù)分析師的黃金發(fā)展期。

最早的時(shí)候，是沒數(shù)據(jù)倉(cāng)庫(kù)什么事情的，OLAP的內(nèi)容也少，只有少量的固定報(bào)表，那時(shí)候都是開發(fā)人員在業(yè)務(wù)庫(kù)直接存儲(chǔ)的。

現(xiàn)在很多系統(tǒng)仍然是這樣的，比如你采購(gòu)一個(gè)erp、電商平臺(tái)等，自帶的絕大部分報(bào)表都與業(yè)務(wù)系統(tǒng)在一個(gè)數(shù)據(jù)庫(kù)中的。其實(shí)這個(gè)時(shí)候正式對(duì)應(yīng)系統(tǒng)架構(gòu)中的“單體架構(gòu)”。

隨著信息系統(tǒng)的不斷建設(shè)，管理者開始不太滿足于固定的寥寥幾張報(bào)表，他們期望看到更多細(xì)節(jié)，找到異常，發(fā)現(xiàn)問題。這時(shí)候，就必須要有一個(gè)信息系統(tǒng)去滿足他們的需求，DSS/BI系統(tǒng)就順應(yīng)而生，幾乎同時(shí)，數(shù)據(jù)倉(cāng)庫(kù)的概念也一并被提出。

1990年前后，現(xiàn)代化的BI和數(shù)據(jù)倉(cāng)庫(kù)幾乎同時(shí)誕生。這也無可厚非，這倆天生一對(duì)啊。BI就是OLAP的業(yè)務(wù)應(yīng)用體系，數(shù)倉(cāng)就是為了支撐BI而生的。數(shù)據(jù)倉(cāng)庫(kù)之父比爾·恩門（Bill Inmon）在1991年寫了一本書《建立數(shù)據(jù)倉(cāng)庫(kù)》。對(duì)，就是那個(gè)inmon、kimball建倉(cāng)方法論的inmon。

這時(shí)候，業(yè)務(wù)數(shù)據(jù)和分析數(shù)據(jù)開始分道揚(yáng)鑣，走上了不一樣的道路。業(yè)務(wù)數(shù)據(jù)處理(OLTP)向準(zhǔn)確、及時(shí)、一致的方向不斷邁進(jìn)；分析數(shù)據(jù)操作(OLAP)向歷史靜態(tài)、聚合、關(guān)聯(lián)、多維的方向發(fā)展。

一個(gè)典型的問題就是在業(yè)務(wù)數(shù)據(jù)庫(kù)中，你無法回答類似于一個(gè)訂單的選購(gòu)、下單、支付、發(fā)貨、完成的全流程各用了多少時(shí)間的問題。當(dāng)然，你可以通過冗余N個(gè)時(shí)間戳來解決，但是你無法將所有狀態(tài)變化的數(shù)據(jù)統(tǒng)統(tǒng)記錄下來。因?yàn)镺LTP是反應(yīng)當(dāng)前的情況。

而OLAP就可以通過全量表、拉鏈表等方式保存歷史狀態(tài)數(shù)據(jù)，從而對(duì)每個(gè)對(duì)象進(jìn)行歷史分析。

tips：除了拉鏈表之外，通常還有全量快照表、增量表和流水表，一共四種形式收集歷史數(shù)據(jù)，這四種情況下次開單篇聊。

數(shù)據(jù)倉(cāng)庫(kù)建設(shè)的目的就是為了進(jìn)行數(shù)據(jù)分析用的。原則上來說數(shù)據(jù)倉(cāng)庫(kù)中的數(shù)據(jù)是不允許修改的。所以你看HIVE根本就沒有update和delete的功能，很多人非常不理解其中的原因，其實(shí)這就是因?yàn)镠IVE就是為了數(shù)據(jù)倉(cāng)庫(kù)而生的。

數(shù)據(jù)倉(cāng)庫(kù)解決的核心問題其實(shí)就是上面說到的，解決歷史情況追蹤，解決數(shù)據(jù)分析能力、解決業(yè)務(wù)頻繁變化等一系列問題。

拿inmon老爺子的話來總結(jié)一下：

數(shù)據(jù)倉(cāng)庫(kù)（Data Warehouse）是一個(gè)面向主題的（Subject Oriented）、集成的（Integrated）、相對(duì)穩(wěn)定的（Non-Volatile）、反映歷史變化（Time Variant）的數(shù)據(jù)集合，用于支持管理決策(Decision Making Support)。

我有一篇文章，詳細(xì)解釋了數(shù)據(jù)倉(cāng)庫(kù)的完整建設(shè)路徑和細(xì)節(jié)，可以移步了解一下：《點(diǎn)擊查看：如何搭建一個(gè)數(shù)據(jù)倉(cāng)庫(kù)》

這個(gè)像什么？是不是很像系統(tǒng)架構(gòu)中的微服務(wù)？對(duì)不對(duì)？橫向分層，豎向切分領(lǐng)域。跟微服務(wù)的理念一樣一樣的。

數(shù)據(jù)倉(cāng)庫(kù)很好用，多維分析簡(jiǎn)直能滿足老板的一切需要。它能讓決策者從公司總體情況，一直下鉆到每個(gè)業(yè)務(wù)員的貢獻(xiàn)，極大的滿足了決策者的掌控欲，同時(shí)也給企業(yè)的決策帶來了堅(jiān)實(shí)的數(shù)據(jù)基礎(chǔ)。

但是，數(shù)據(jù)倉(cāng)庫(kù)也有其非常致命的弊端：所有數(shù)據(jù)必須經(jīng)過定義之后才能被使用，所有數(shù)據(jù)都經(jīng)過了ETL處理，所有數(shù)據(jù)都被聚合。

作為數(shù)據(jù)工作者的你，肯定能理解其中的含義。一旦數(shù)據(jù)被動(dòng)過，那就會(huì)造成信息丟失。

而在算法時(shí)代，這是不可接受的。

因此，在數(shù)據(jù)倉(cāng)庫(kù)發(fā)展了20年之后的2010年，Pentaho的創(chuàng)始人James Dixon提出了一個(gè)“數(shù)據(jù)湖”的概念。簡(jiǎn)單來說，數(shù)據(jù)湖其實(shí)可以理解為一個(gè)巨大的ODS層。

任何使用數(shù)據(jù)的同學(xué)都可以直接到數(shù)據(jù)湖中自由提取數(shù)據(jù)：

數(shù)據(jù)湖貌似非常完美，能解決一切問題，但是肯定哄不住專業(yè)的你。是的，數(shù)據(jù)湖說的好聽，是一個(gè)原生態(tài)的，任由你汲取的巨型數(shù)據(jù)源，說的不好聽，就是一個(gè)數(shù)據(jù)垃圾堆。不管你管理的多么好都無法改變這個(gè)事實(shí)。

你現(xiàn)在已經(jīng)找到了一個(gè)異常客戶，想找到這個(gè)客戶在公司業(yè)務(wù)流中的表現(xiàn)。我們應(yīng)該會(huì)通過CRM與其進(jìn)行溝通和跟進(jìn)；通過交易平臺(tái)與其發(fā)生交易；貨物是通過ERP進(jìn)行采購(gòu)的，通過WMS記錄貨物存儲(chǔ)信息的，通過TMS記錄貨物運(yùn)輸過程信息的。最后你是在微博中收到了他的抱怨信息，在客服中心的CallCenter接到投訴電話的。

這個(gè)時(shí)候，你想怎么辦？各個(gè)系統(tǒng)都是獨(dú)立建設(shè)的，所有數(shù)據(jù)都在數(shù)據(jù)湖中，你就是沒辦法把他們串起來！而且，這還是一條業(yè)務(wù)線。公司通常都會(huì)有N條業(yè)務(wù)線，每個(gè)業(yè)務(wù)線的系統(tǒng)都統(tǒng)統(tǒng)單獨(dú)建立一遍，一個(gè)客戶與公司發(fā)生關(guān)系的系統(tǒng)越來越多。

這個(gè)時(shí)候，數(shù)據(jù)中臺(tái)就出現(xiàn)了。

圖片來自于阿里云數(shù)據(jù)中臺(tái)解決方案手冊(cè)

所以你可以看到，數(shù)據(jù)中臺(tái)解決的是什么問題：

這三點(diǎn)，共同組成了數(shù)據(jù)中臺(tái)的OneData的方法論體系。

OneID是最底層的數(shù)據(jù)打通，把各條業(yè)務(wù)線、各個(gè)業(yè)務(wù)系統(tǒng)的相同實(shí)體（如客戶）進(jìn)行統(tǒng)一識(shí)別。用戶端的感覺就是你用一個(gè)id，可以通行阿里系所有app。企業(yè)端的感覺就是無論用戶用什么客戶端，通過那個(gè)系統(tǒng)與企業(yè)發(fā)生關(guān)系，都能識(shí)別成為一個(gè)用戶；

OneModel是中間層數(shù)據(jù)的統(tǒng)一建模，這里其實(shí)就是數(shù)據(jù)倉(cāng)庫(kù)。只不過不是一個(gè)業(yè)務(wù)線的數(shù)據(jù)倉(cāng)庫(kù)，是整個(gè)企業(yè)，整個(gè)集團(tuán)的，統(tǒng)一的數(shù)據(jù)倉(cāng)庫(kù)。

OneService是業(yè)務(wù)層的統(tǒng)一服務(wù)提供，其實(shí)還是那一套，主數(shù)據(jù)、即席查詢、固定報(bào)表、多維分析等等。當(dāng)然會(huì)多一些算法層面的試探，也僅僅是試探而已。

我在之前的工作中，就曾建立數(shù)據(jù)中臺(tái)，主要工作內(nèi)容就是做商品id和用戶id的打通，進(jìn)行全局統(tǒng)一建模，提供統(tǒng)一的商品主數(shù)據(jù)的編碼工作和統(tǒng)一的數(shù)據(jù)輸出。

如果你看過我之前分享的《一口氣說透中臺(tái)--給你架構(gòu)師的視角-點(diǎn)擊查看》，就會(huì)發(fā)現(xiàn)，這不就是中臺(tái)架構(gòu)嗎？

如上圖所示，其實(shí)在上篇文章中，就已經(jīng)說清楚數(shù)據(jù)中臺(tái)是什么了。在數(shù)據(jù)層面進(jìn)行多條業(yè)務(wù)線的服務(wù)合并、標(biāo)準(zhǔn)化、統(tǒng)一化，統(tǒng)一抽象，這就是數(shù)據(jù)中臺(tái)。每個(gè)架構(gòu)都是要解決特定的問題的，數(shù)據(jù)中臺(tái)解決的核心問題就是全局統(tǒng)一，全局標(biāo)準(zhǔn)，全局打通。

所以，不要神話中臺(tái)，更不要神話數(shù)據(jù)中臺(tái)。你沒有這個(gè)問題，或者說當(dāng)前最緊急的問題不是中臺(tái)最擅長(zhǎng)解決的，那就不要跟風(fēng)建中臺(tái)。那樣會(huì)死的很慘的。

以上，與君共勉！

數(shù)據(jù)中臺(tái)還是太大了，一篇文章說不完。這樣吧，我把之前收集的市場(chǎng)上主流的三家數(shù)據(jù)中臺(tái)供應(yīng)商產(chǎn)品建設(shè)方案和一份咨詢公司數(shù)據(jù)中臺(tái)白皮書拿出來貢獻(xiàn)給大家。關(guān)注“大數(shù)據(jù)架構(gòu)師”公眾號(hào)，在后臺(tái)回復(fù)DATA即可獲取下載鏈接。這可都是辛苦獲得的內(nèi)部資料呀~~~

對(duì)了，上次分享了《數(shù)據(jù)治理體系的建設(shè)》，我特意準(zhǔn)備了國(guó)際流行的《DAMA-DMBOK數(shù)據(jù)管理知識(shí)體系》文件，后臺(tái)回復(fù)dama即可獲取下載鏈接。快去公眾號(hào)領(lǐng)取吧~~~