網(wǎng)上有很多關于賣pos機用戶數(shù)據(jù),數(shù)據(jù)倉庫的前世今生的知識，也有很多人為大家解答關于賣pos機用戶數(shù)據(jù)的問題，今天pos機之家(m.mxllmx.com)為大家整理了關于這方面的知識，讓我們一起來看下吧!
本文目錄一覽：
賣pos機用戶數(shù)據(jù)
數(shù)據(jù)倉庫的內容非常多，每一個子模塊拎出來都能講很久。這里沒法講太多細節(jié)，大致思考了三個備選議題：
數(shù)據(jù)倉庫的前世今生數(shù)據(jù)倉庫體系知識介紹數(shù)倉開發(fā)者的路在何方？既然是第一次分享，感覺還是跟大家普及下數(shù)倉的歷史比較好，最終選了今天的這個話題，主要是給大家做個科普。
“前世今生”，拆解下來，我會從起源、發(fā)展、變化、展望四部分來給大家做個介紹。
數(shù)倉的起源，主要介紹下數(shù)據(jù)倉庫概念誕生的大背景、大環(huán)境，數(shù)倉解決了實際場景中的什么問題，以及數(shù)倉的定義。
數(shù)倉的發(fā)展，我們主要介紹下數(shù)據(jù)倉庫在我們國內的發(fā)展歷程、在主要行業(yè)內的應用、我自己經(jīng)歷過的一些場景，以及當時產(chǎn)生的跟數(shù)據(jù)倉庫相關的幾個概念。
數(shù)倉的變化，隨著大數(shù)據(jù)時代的到來，人們對數(shù)據(jù)資產(chǎn)更加重視，數(shù)據(jù)賦能業(yè)務能做的事情其實是更多了。那么傳統(tǒng)數(shù)倉向大數(shù)據(jù)倉庫的演變，對數(shù)倉人的基礎能力要求有哪些變化呢？我會在第三部分給大家做個介紹。
目前為止，我們大致處在大數(shù)據(jù)倉庫的階段，并且已經(jīng)有很多人在不斷的做著新的嘗試，第四部分我會基于我所看到的，跟大家共同探討下數(shù)倉未來的演進方向。
做為科技進步的受益者，大家知道第一臺計算機是什么時候發(fā)明的嗎？
1946 年 2 月 14 日，誕生于美國的賓夕法尼亞大學。這臺計算機重達 30 噸，占地 160 平方米，耗電174 千瓦，耗資 45 萬美元，但每秒只能運行 5000 次加法運算。
第一代商用計算機，是 1951 年由雷明頓蘭德公司（現(xiàn) Unisys ）發(fā)售的，當時被美國人口普查部門用于人口普查。
但是當時的計算機太過笨重，成本高昂，且硬件損耗極大，比如里邊的發(fā)光管，沒幾分鐘就要燒壞一個。所以 1960 年，開發(fā)出來了第一款小型機，后續(xù)隨著技術進步單臺價格急劇下降，但性能卻急劇上升。當年PC 機的升級速度——壓根用不著像現(xiàn)在一樣，通過軟件降級舊手機的頻逼你升級，當時電腦各方面參數(shù)都是每 18 個月翻一番；或者說，每三年，新出的機器每個方面都是你的舊機器性能的 4 倍，六年 16 倍。當然，最近幾年更新?lián)Q代速度已經(jīng)開始降下來了。
講到這里了，那么有沒有人想過這樣一個問題：什么是信息化？
百度百科的解釋：
信息化是指培養(yǎng)、發(fā)展以計算機為主的智能化工具為代表的新生產(chǎn)力，并使之造福于社會的歷史過程。
通俗點講，就是以計算機網(wǎng)絡為依托，將線下的各種依賴人力腦力的業(yè)務流程，使用軟件工具實現(xiàn)，達到大幅度提高效率、節(jié)省人工的目的。
隨著計算機科學的快速發(fā)展，使信息化的落地逐漸成為可能。
一條線是數(shù)據(jù)庫技術的誕生發(fā)展與逐漸成熟。另一條線是各種 ERP、CRM、辦公自動化、財務系統(tǒng)、供應鏈等軟件解決方案的完善推廣，數(shù)據(jù)庫技術發(fā)展和各種軟件產(chǎn)品推動，共同促使信息化進程不斷的深入。
數(shù)據(jù)庫技術，經(jīng)過幾年的三大數(shù)據(jù)模型（層次模型、網(wǎng)狀模型、關系模型）角逐后，隨著 SQL 語言的誕生使關系模型最終勝出，最終誕生了強大的 DB2、Oracle、SQLServer 等關系型數(shù)據(jù)庫。。
這里簡單提一下，IBM 最早的層次模型數(shù)據(jù) IMS，全稱是信息管理系統(tǒng)（Information Management System），所以數(shù)據(jù)庫的誕生就是為了更方便的管理使用信息的 。
另外，說到信息化的普及，各種相關軟件供應商也功不可沒。SAP 當然還是世界第一的位置，當時的世界五百強公司 80% 都使用了他們的 ERP，也就是企業(yè)資源管理產(chǎn)品，Oracle 當時很牛吧，他們一開始自研但好像不怎么樣，最終還是買了 SAP 的產(chǎn)品。
SAP 直到 1994 年才引進中國，首先做的是自身產(chǎn)品的翻譯工作，后來跟埃森哲、IBM 等咨詢公司合作，快速打開了國內市場，同時也推進了國內的信息化進程。相關國內廠商起步稍晚，直到現(xiàn)在市場份額也小到可以忽略不計，08 年的統(tǒng)計 SAP 和 Oracle 都是百億級年收入，用友是一兩億吧好像是。
那時候國內的有才華的人也都更傾向于進外企，沒辦法那時候人家確實強、福利待遇也很好。
那時候的設備也基本上清一色進口：IBM 的小型機、Oracle/IBM/TD 的數(shù)據(jù)庫、EMC 的存儲設備。
信息化開展過程中，各種軟件工具存儲下來的數(shù)據(jù)，真實反應了業(yè)務開展過程中的各種信息，雖然會存在一些噪音或者缺失，人們還是開始嘗試從留存數(shù)據(jù)中尋找各種有用信息，用來了解業(yè)務現(xiàn)狀、分析潛在問題與機會、預測未來發(fā)展路徑等等。
了解現(xiàn)狀。主要是通過各種運營分析報表以及對應的圖標展示，報表主要是各種維度下的日周月季年匯總，圖標主要是占比分析、同比環(huán)比分析等。
輔助決策。經(jīng)典案例就是“啤酒尿布的故事”。上世紀 90 年代（大概 1993-1995 年之間吧），沃爾瑪嘗試將 Aprior 算法引入到 POS 機數(shù)據(jù)分析中（實際上是一種商品的關聯(lián)分析算法），當時發(fā)現(xiàn)跟尿布一起購買最多的商品竟然是啤酒，最后經(jīng)過進一步市場調研發(fā)現(xiàn)，美國的太太們經(jīng)常叮囑她們的丈夫下班后為小孩買尿布，而丈夫在買完尿布后又隨手帶回了他們喜歡的啤酒。后來，沃爾瑪把尿布與啤酒放到相鄰的貨架上從而實現(xiàn)了啤酒與尿布銷量的雙雙增長。
預測未來。通過對現(xiàn)有數(shù)據(jù)的分析挖掘，有時候是可以預測出通過改變某個變量后對結果的影響的。比如通過對商品價格的調整，會引起銷量的變化，最終通過合理的定價達到利潤或銷售額最大化的目的。這上邊我還列了一個我剛畢業(yè)時候做過的一個案例：廢水經(jīng)過污水處理廠處理后最終都會流到附近的某條河里，污水處理廠的出口會有水質檢測設備，每條河流上也會有若干個水質檢測站，因為水質的自然凈化因素，距離檢測站點越遠對水質檢測結果的影響越小。當時我們通過一個數(shù)學模型去預測想要保證某個檢測站點主要污染物含量達標，結合其上游臨近的若干個污水處理廠的距離，反推各個污水處理廠出口需保證的水質標準。
看了上邊的介紹我們了解到，合理的數(shù)據(jù)應用，是能夠給業(yè)務提供非常多的支撐作用的。但是隨著數(shù)據(jù)的深度使用，人們逐漸發(fā)現(xiàn)了一些問題，一句話描述就是：現(xiàn)有的數(shù)據(jù)存儲模式不好用了。
總結下來，主要有四類問題：
影響業(yè)務。大批量長時間跨度的數(shù)據(jù)運算、復雜的分析挖掘，往往會占用很多的計算資源，數(shù)據(jù)混亂。業(yè)務邏輯的變化，造成不同時間段的數(shù)據(jù)含義內容都會有差別，更要命的是沒有人會告訴你這些。數(shù)據(jù)缺失。業(yè)務庫基于性能和硬件成本考慮，都會把歷史數(shù)據(jù)歸檔并轉移到更廉價的存儲設備去。數(shù)據(jù)孤島。數(shù)據(jù)是業(yè)務開展過程中各個系統(tǒng)軟件產(chǎn)生并存儲下來的，系統(tǒng)軟件直接往往存在隔離，同時由于缺少統(tǒng)一規(guī)劃，同一主數(shù)據(jù)在不同系統(tǒng)內的定義描述編碼都不一致。大家可以腦補下阿里的 ID-Mapping ，其實是一個道理。接下來，我們本次分享的主角終于出場了！
事實上，在上世紀 70 年代已經(jīng)有人提出來需要單獨構建數(shù)據(jù)分析系統(tǒng)了，但是局限于技術發(fā)展一直無法落地（大家可以往前翻到第 4 頁 PPT，那時候的關系型數(shù)據(jù)還處于啟蒙階段。），直到后來 1991 年“數(shù)據(jù)倉庫之父”正式確立了數(shù)據(jù)倉庫基本概念，但直到那時候數(shù)據(jù)倉庫理論依然不太成熟。
數(shù)據(jù)倉庫的概念確立以后，有關數(shù)據(jù)倉庫的實施方法、實施路徑和架構等引發(fā)了諸多爭議。
第一階段：直接構建數(shù)據(jù)倉庫。1994 年前后，實施數(shù)據(jù)倉庫的公司大都以失敗告終（采用規(guī)范化的方式直接構建數(shù)據(jù)倉庫，對數(shù)倉構建者的能力要求過高，Inmon 老爺子當時有 30 年數(shù)據(jù)從業(yè)經(jīng)驗了，他行其他人能行嗎？）。
第二階段：直接構建數(shù)據(jù)集市。由于數(shù)據(jù)集市僅僅是數(shù)據(jù)倉庫的某一部分，實施難度大大降低，并且能夠滿足公司內部部分業(yè)務部門的迫切需求，在初期獲得了較大成功。但隨著數(shù)據(jù)集市的不斷增多，這種架構的缺陷也逐漸顯現(xiàn)：公司內部獨立建設的數(shù)據(jù)集市由于遵循不同的標準和建設原則，導致多個數(shù)據(jù)集市的數(shù)據(jù)混亂和不一致。
第三階段：靈者為先，兩種建模思想的融合。解決問題的方法只能是回歸到數(shù)據(jù)倉庫最初的基本建設原則上來。1998 年，Inmon 提出了新的 BI 架構 CIF（Corporation Information Factory，企業(yè)信息工廠），新架構在不同架構層次上采用不同的構件來滿足不同的業(yè)務需求。
大家看下右邊這個架構圖，展示的是 Inmon 1998 年提出的《企業(yè)信息工廠》。
來自多個不同數(shù)據(jù)源的數(shù)據(jù)，經(jīng) ETL 抽取清洗轉換后，將原子粒度數(shù)據(jù)以一種規(guī)范化的格式集成進企業(yè)數(shù)據(jù)倉庫中，直接對外提供數(shù)據(jù)服務。同時基于不同需求再往上構建數(shù)據(jù)集市，以部門級分析多維格式存儲。
這里有兩個重要的基礎概念，大家可以多多理解下：
數(shù)倉的定義：
面向主題。主要是給數(shù)據(jù)分類方便理解和管理。集成。匯總多個源端系統(tǒng)數(shù)據(jù)甚至是異構數(shù)據(jù)源，到一個統(tǒng)一的相互兼容的數(shù)據(jù)存儲內，使后續(xù)的分析關聯(lián)更加容易。相對穩(wěn)定。對數(shù)據(jù)的操作大多是 Insert，很少有 Update、Delete。反應歷史變化。存儲大量的歷史數(shù)據(jù),保留歷史所有數(shù)據(jù)的狀態(tài)，進而找出企業(yè)經(jīng)營管理中的規(guī)律。我覺得這里應該包含兩個層面：業(yè)務的歷史變化規(guī)律、維度數(shù)據(jù)的歷史變化。用于支持管理決策。這是構建數(shù)倉的目的。但是發(fā)展到現(xiàn)在，數(shù)倉已經(jīng)在別的很多地方開始發(fā)揮作用了。三范式：經(jīng)典的關系數(shù)據(jù)模型規(guī)范理論
屬性不可拆分。保證列的原子性。例如不能把學生的的學號、名稱、班級號都塞在一個字段里面每個屬性有且僅依賴于主鍵（主鍵的定義：能夠唯一確定一條數(shù)據(jù)的列或列組合）。屬性不能傳遞依賴于主鍵。如果有就分表。例如行政區(qū)劃的省市縣三層劃分必須建三張表，省市的名稱不能放到區(qū)縣的那張表里（當然這種情況下，維度建模通常是反三范式的）。范式建模理論是在數(shù)倉建設實踐中演變出來的，因為直接構建數(shù)據(jù)倉庫和直接構建數(shù)據(jù)集市都會存在一些問題。
大家請看上圖，原始數(shù)據(jù)通過 ETL ，轉換成維度指標的形式，以原子粒度存入維度數(shù)據(jù)倉庫，在此之上匯總成數(shù)據(jù)集市（數(shù)倉的主題區(qū)域）。為了保證數(shù)據(jù)集市間的兼容性，在數(shù)據(jù)集市之上抽離出來一套標準，就是總線架構。
這里也有兩個重要的基礎概念：
總線架構：類似于主數(shù)據(jù)管理，就是把維度和指標單獨抽離出來集中管理，各個數(shù)據(jù)集市只有使用權。
一致性維度：集中管理維度以及維度屬性。保證相同的維度在不同數(shù)據(jù)集市間的一致性。
一致性事實：集中管理指標的定義、單位、計算方法等。保證統(tǒng)一指標在不同數(shù)據(jù)集市間的含義是相同的。
維度建模過程：事實上是單張表的構建過程。一張表只說一件事情。但根據(jù)此方法建完所有表之后，對于維度完全相同的表是否需要合并，得根據(jù)實際情況來定，比如業(yè)務相近的就可以合起來。
到這里，我們基本上把數(shù)倉概念誕生的歷史背景、發(fā)揮的價值、怎么構建數(shù)據(jù)倉庫大致講完了。隨著歷史進程推進到上世紀九十年代中期，我們國內終于是參與進來了。
接下來，我繼續(xù)給大家介紹下數(shù)據(jù)倉庫引入我們國內后的發(fā)展狀況。
請看上邊這頁 PPT，我入行的時候，傳統(tǒng)數(shù)倉在國內其實已經(jīng)非常成熟了。但當時有數(shù)倉需求的企業(yè)并不多，因為大多數(shù) 2B 的中小公司不需要啊，他們數(shù)據(jù)量也不大，最多也就出幾張實時的業(yè)務報表，直連業(yè)務系統(tǒng)反而更合適些。
當時的數(shù)倉開發(fā)甚至大多數(shù)的數(shù)據(jù)從業(yè)者，基本都在電信、銀行、保險行業(yè)，以及大型央企民企。同時以電信、銀行居多。
傳統(tǒng)數(shù)倉，從技術棧上大致分為三類：數(shù)據(jù)庫+ETL工具+BI工具。并且都被國外企業(yè)所壟斷，上圖中我雖然列了 Kettle 這個開源軟件，但當時它的市場份額可以忽略不計。
由于數(shù)倉的技術棧，基本被外國企業(yè)把控，市場競爭中，外企也是通殺國內企業(yè)的。
請看上邊這張 PPT，從左到右，軟硬件提供商+解決方案提供商+外包公司，這些都是傳統(tǒng)數(shù)倉的主要參與者。大概場景是這樣的：解決方案提供商拿著外企的一眾產(chǎn)品簡單包裝以后，在國內接項目，然后帶著一大堆外包公司做實施。當然上邊的分界也不是特別明顯，華為也提供硬件、TD 也會做實施。
再往細分的話，華為亞信在電信行業(yè)做的比較出名，TD 主要是金融行業(yè)，IBM 埃森哲等咨詢公司在大型央企民企做的比較多。當然軟通當時也有保險事業(yè)部也會直接接一些項目，文思這兩年好像銀行項目接了很多，這兩年群里有人瘋狂招人的。雖然近些年大家吐槽外包的很多，但當時確實也養(yǎng)活了不少數(shù)倉從業(yè)者，因為第一第二梯隊畢竟能容納的人也有限，不去外包公司也沒別的選擇了。數(shù)倉項目通常也都是長期做的，所以也沒有現(xiàn)在說的這么差。
相信很多人都對數(shù)倉有所了解，那么大家有沒有仔細想過，什么是數(shù)倉？數(shù)倉的邊界在哪里？
數(shù)據(jù)管理大體可以分為四部分：集成、計算、存儲、應用。狹義的數(shù)倉只包含集成計算和存儲。但是沒有上層應用的數(shù)倉根本毫無意義，所以數(shù)據(jù)應用對數(shù)倉來說也是至關重要的。
基于以上的原因，我們在談項目的時候通常會提一些高大上的概念，比如我們要建設一個企業(yè)級的數(shù)據(jù)中心，我們要搭建一個數(shù)據(jù)平臺等等，其實實質上都是：數(shù)據(jù)倉庫+上層應用。
數(shù)據(jù)中心：就是把散落在組織各個地方的數(shù)集起來統(tǒng)一存儲、分發(fā)、應用。
運營分析系統(tǒng)：是在數(shù)據(jù)中心的基礎之上，根據(jù)業(yè)務需要做一些運營分析報表，直接服務于各個業(yè)務部門。
數(shù)據(jù)平臺：這個概念更大，在數(shù)據(jù)中心的基礎之上，考慮引入外部數(shù)據(jù)?；跀?shù)據(jù)平臺開放各種內外部賬戶，所有用戶都可以基于該平臺做數(shù)據(jù)交換或者數(shù)據(jù)買賣。
數(shù)據(jù)中臺：是最近幾年提出的概念，已數(shù)據(jù)倉庫和大數(shù)據(jù)技術平臺為底座，以能力復用為目標構建。
伴隨大數(shù)據(jù)時代的到來，帶來了數(shù)據(jù)技術架構的重大變革，同時賦予分析挖掘更大的能力。
比如華爾街根據(jù)民眾情緒拋售股票、谷歌根據(jù)網(wǎng)民搜索關鍵詞的變化提前預測流感。
這個時候人們的思維方式已經(jīng)開始慢慢發(fā)生變化了，同時數(shù)據(jù)倉庫已經(jīng)不僅僅局限于之前的分析挖掘了，數(shù)據(jù)開始更直接的參與到業(yè)務活動中來了。
互聯(lián)網(wǎng)、大數(shù)據(jù)、云計算，帶來了新的業(yè)務形態(tài)、新的開發(fā)氛圍。所有互聯(lián)網(wǎng)企業(yè)都開始認識到數(shù)據(jù)的重要價值，都開始構建自己的數(shù)倉或者數(shù)據(jù)集市了。
上邊這頁 PPT 提到的零散內容，相信互聯(lián)網(wǎng)從業(yè)者都深有體會吧？
大數(shù)據(jù)時代，數(shù)據(jù)倉庫相關技能反而更重要了。
數(shù)倉技能重要性提高的同時，對數(shù)倉從業(yè)者的能力要求，應該也是更高了。除了需要熟悉數(shù)倉理論、熟悉業(yè)務外，還需要足夠的開發(fā)功底，而且大數(shù)據(jù)組件太多了，根本學不過來。
我是從傳統(tǒng)數(shù)倉轉型過來了，之前基本沒寫過代碼，轉型大數(shù)據(jù)一開始根本沒有方向，甚至到后來我還學習了兩周的 Spring。
不過現(xiàn)在回頭看看，這才是最優(yōu)的學習路線：
通過 Hive 先入大數(shù)據(jù)的門，這個沒啥難度，都是 SQL 嘛。學習 Hadoop、Hive、Spark 等的基本原理，同時多多實踐。惡補 Java 基礎，多敲代碼。同時可以看看 Hadoop、Hive 源碼（網(wǎng)上源碼講解的太多了）。大數(shù)據(jù)計算組件看的差不多了，可以再學學大數(shù)據(jù)存儲組件，主要是一些 OLTP 組件，比如 CK 等等。離線計算掌握差不多了，可以再學習下流式計算，直接上手 Flink 就好了。數(shù)倉轉大數(shù)據(jù)的一點心得：
大數(shù)據(jù)組件千萬別貪多，抓住幾個主流的學透就好了。開發(fā)能力很重要，但不用啥都學，掌握 JavaSE 足夠了。基本盤是數(shù)據(jù)倉庫，一定要絕對精通。面試時候開發(fā)相關不一定會問，但數(shù)倉絕對少不了。最后，大家有沒有想過，數(shù)據(jù)倉庫的未來會是哪里呢？
只要數(shù)據(jù)還有價值，那么數(shù)倉就不會消亡，只會不斷進化。
數(shù)倉背后的這一套數(shù)據(jù)管理和應用的方法論，以及數(shù)倉從業(yè)者的數(shù)據(jù)思維，必將使其終身受益。
實時數(shù)倉，離我們已經(jīng)很近了，甚至很多企業(yè)已經(jīng)在做了，但是想要完全替代離線數(shù)倉，還是有很多路要走的，比如數(shù)據(jù)準確性、數(shù)據(jù)的更新插入問題、不可加累積數(shù)據(jù)的計算問題等。
批流一體方面，目前 Flink、Spark 都實現(xiàn)了公用一套計算框架。但是公用一套存儲還不太成熟，公用一套代碼還沒有實現(xiàn)。
數(shù)據(jù)湖概念，已經(jīng)提出好多年了，雖然阿里華為也在吹，但目前市面上還沒有出來真正意義上的方案。用網(wǎng)友的話說就是：我看好數(shù)據(jù)湖的未來，但不看好它的現(xiàn)在。
就像我 PPT 上總結的，數(shù)據(jù)湖還有很多問題沒有解決。就算以后數(shù)據(jù)湖普及了，那么核心數(shù)據(jù)還是要進數(shù)據(jù)倉庫的。因為數(shù)據(jù)湖里數(shù)據(jù)準確性很難保證，同時查詢性能、對計算資源的消耗，數(shù)據(jù)倉庫也是完敗數(shù)據(jù)湖的。
以上就是關于賣pos機用戶數(shù)據(jù),數(shù)據(jù)倉庫的前世今生的知識，后面我們會繼續(xù)為大家整理關于賣pos機用戶數(shù)據(jù)的知識，希望能夠幫助到大家！
