第一篇：基于數(shù)據(jù)倉庫的商業(yè)智能——CRM的本質(zhì)

基于數(shù)據(jù)倉庫的商業(yè)智能——CRM的本質(zhì)

在當今競爭日益激烈、信息日益膨脹的市場經(jīng)濟環(huán)境中，大家都希望能夠從浩如煙海的商務(wù)數(shù)據(jù)中發(fā)現(xiàn)帶來利潤的商機，商業(yè)智能已經(jīng)成為公司使用電子商務(wù)投資創(chuàng)造更大利潤的一個重要步驟，因此，越來越多的管理者開始借助商務(wù)智能技術(shù)來發(fā)現(xiàn)商務(wù)運營過程中存在的問題，找到有利的解決方案。與此同時，在信息技術(shù)領(lǐng)域，成功的數(shù)據(jù)倉庫正在為許多企業(yè)提供實實在在的投資回報，并且使企業(yè)以一種嶄新的更加細致的方式檢查企業(yè)的運營狀況。數(shù)據(jù)倉庫所提供的洞察力不僅使企業(yè)更加高效，而且使企業(yè)能夠?qū)蛻舻男枨笞龀龈杆贉蚀_的響應(yīng)。商業(yè)智能與數(shù)據(jù)倉庫技術(shù)的結(jié)合形成了增強企業(yè)競爭力的強大工具——客戶關(guān)系管理CRM。

一、數(shù)據(jù)倉庫與商業(yè)智能

數(shù)據(jù)倉庫與傳統(tǒng)的數(shù)據(jù)庫系統(tǒng)相比有著本質(zhì)的區(qū)別，數(shù)據(jù)庫是一種通用平臺，建立于嚴格的數(shù)學模型之上，用來管理企業(yè)數(shù)據(jù)，進行事務(wù)處理；而數(shù)據(jù)倉庫沒有嚴格的數(shù)據(jù)理論，更偏向于工程，是企業(yè)數(shù)據(jù)一個日積月累的建立過程，它的應(yīng)用對象是不同層次的管理者，它的數(shù)據(jù)源可能是多種數(shù)據(jù)庫，主要是進行大規(guī)模查詢和分析，因此要求有大量的歷史數(shù)據(jù)和匯總數(shù)據(jù)。數(shù)據(jù)倉庫之父W.H.inmon這樣定義：“數(shù)據(jù)倉庫是支持管理決策過程的、面向主題的、集成的、隨時間而變的、持久的數(shù)據(jù)集合?！?/p>

數(shù)據(jù)倉庫的特點之一是能夠整合來自于大量異構(gòu)系統(tǒng)的數(shù)據(jù)，包括外部數(shù)據(jù)。通過整合來自多個接觸渠道的客戶數(shù)據(jù)，數(shù)據(jù)倉庫向企業(yè)展示客戶的屬性、所有歷史行為記錄等信息。許多企業(yè)正在通過數(shù)據(jù)倉庫在客戶行為分析領(lǐng)域獲得豐厚的利潤，這個分析領(lǐng)域?qū)儆诳蛻絷P(guān)系管理(CRM)的一部分。正因為客戶關(guān)系分明一個企業(yè)成功的重要方面，因此本文對此進行討論。

意識到CRM是當務(wù)之急的事，這就需要一個橋梁——商業(yè)智能工具，不僅聯(lián)接分離的技術(shù)，而且通過進入商業(yè)的核心而使其與傳統(tǒng)的以技術(shù)為中心的競爭對手區(qū)別開來。商業(yè)智能工具可以集合、分析、管理這些智能元素用以探索、展示與挖掘客戶信息資產(chǎn)。企業(yè)以一個預先架設(shè)的橋梁開始，可以大大減少風險而且可以更快獲得成功，換句話說，一個預先架設(shè)的橋梁不僅僅是一系列有數(shù)據(jù)導人與數(shù)據(jù)標準化功能的設(shè)計和維護工具，更重要的是一個已完成的包含了行業(yè)特定數(shù)據(jù)模型與資產(chǎn)報告，只需裝入企業(yè)自己數(shù)據(jù)即可運行的分析型應(yīng)用系統(tǒng)。

二、企業(yè)客戶關(guān)系管理的發(fā)展

從中國目前的市場來看，數(shù)據(jù)倉庫/商業(yè)智能已經(jīng)浮出水面，從概念走到了實施的階段。在過去的十年中，已建立的企業(yè)業(yè)務(wù)多數(shù)都集中提高他們核心業(yè)務(wù)流程的效率上，然而，ERP(Enterprise Resource Planning企業(yè)資源計劃系統(tǒng))主要關(guān)注的是企業(yè)業(yè)務(wù)流程或者供應(yīng)鏈的效率，換言之，這種效率出自增加內(nèi)部控制、削減成本以及使消耗更少產(chǎn)出更多，然而，電子商務(wù)的出現(xiàn)預示著企業(yè)進人了新一輪的更新，客戶成為新的核心，企業(yè)關(guān)注的焦點跳出了企業(yè)自身的范圍，更多地以客戶為中心。

企業(yè)的CRM應(yīng)該是個企業(yè)與客戶關(guān)系的全面整合管理，通過CRM為維系并鞏固既有客戶，贏得并發(fā)展新客戶，同時增進客戶的忠誠度和利潤貢獻度。其核心內(nèi)容是發(fā)現(xiàn)“金牌”客戶、維系“利潤”客戶和分化、改造一般客戶。它具體可以分為四個方面：

● 客戶信息管理 ● 營銷管理 ● 銷售管理

● 服務(wù)管理與客戶關(guān)懷

具體而言，CRM系統(tǒng)使得公司能夠管理客戶相關(guān)的信息和數(shù)據(jù)；全面自動管理橫跨銷售、營銷與服務(wù)的前端辦公業(yè)務(wù)流程；優(yōu)化跨渠道的客戶交易與互動;并理解和響應(yīng)客戶的行為模式。

三、有效的商業(yè)智能解決方案的要求

專家在分析我國軟件市場發(fā)展趨勢時認為，在中國應(yīng)用軟件市場上，管理軟件的市場前景最為看好，其中，企業(yè)對CRM的潛在需求日益增加，并且企業(yè)對有效的商業(yè)智能解決方案的要求是：

(一)全面的解決方案

隨著IT企業(yè)持續(xù)不斷的并購行為的發(fā)生，反映信息系統(tǒng)中表現(xiàn)為對多種工具和技術(shù)平臺的使用，所以一個全面滲透的開放文化是很重要的，尤其是在與軟件工具的接口能力、技術(shù)平臺、可以訪問和支持的數(shù)據(jù)源。

(二)基本性能要求

為了與實際需要的解決方案保持一致，CRM必須基于特定行業(yè)的實踐和知識。特別地，它必須綜合：

● 能夠快速實施的、無須大量重新配置即可擴展的解決方案和框架。

● 數(shù)據(jù)模型、預格式化的報表與流程，符合最佳實踐行業(yè)準則，提供快速部署與加速投資回報的基礎(chǔ)。

● 軟件工具，允許業(yè)務(wù)人員根據(jù)需求進行分析的拓展商業(yè)智能，無須專門的專業(yè)IT人員進行干預。

(三)解決方案發(fā)布支持功能

正像一個預先設(shè)置的行業(yè)數(shù)據(jù)模型跨過了數(shù)據(jù)定義與收集階段，一個詳盡的實施框架可以節(jié)省出幾周的時間來做支持計劃，而經(jīng)驗是確保這個框架的完整性的最主要的成分。預定義的商業(yè)解決方案、發(fā)布計劃共同為企業(yè)提供了一個加速應(yīng)用發(fā)布的機會，從而加速了數(shù)據(jù)倉庫投資的回報。

第二篇：智能商業(yè)讀后感

智能商業(yè)讀后感

當閱讀完一本名著后，大家心中一定有不少感悟，讓我們好好寫份讀后感，把你的收獲和感想記錄下來吧。那么你會寫讀后感嗎？以下是小編為大家收集的智能商業(yè)讀后感，歡迎大家借鑒與參考，希望對大家有所幫助。

曾鳴教授是我做戰(zhàn)略的諸多老師之一，他關(guān)于戰(zhàn)略的論述，一度是我反復揣摩學習的教材。

阿里巴巴是一家以戰(zhàn)略見長的公司，能夠在這樣一家公司任參謀長，肯定得有幾把刷子。

馬云是個“大忽悠”,能讓馬云欣賞并邀請加入阿里，斯人功力可見一斑。

剛巧，我主要的工作，也是戰(zhàn)略設(shè)計。于是乎，我就關(guān)注了“曾鳴書院”公眾號，下載了“湖畔”APP,也收聽了曾教授在得到的“智能商業(yè)二十講”.自曾老師宣布要寫這本書開始，我就一直關(guān)注著這本書的進程。先是得知這本書的英文版本已經(jīng)出了，無奈我英語差，不能先睹為快。后又獲悉這本書由中信出版集團出版，于是就在中信的購書小程序上預定了這本書。本以為這本書要等很久才能收到，沒想到才過幾天，就到手了。（截至目前，京東還沒上架這本書的中文版。）

書是昨天下午到的，剛到手，就一口氣看了一半。

這本書對我的幫助非常大。我就在做關(guān)于公司的戰(zhàn)略計劃，也在做公司的智能系統(tǒng)建設(shè)。這本書和我的很多想法不謀而合，讓我引以為豪；另外，這本書還講了很多我沒注意到的問題，給了我不少啟示。我是一邊看，一邊和公司的實踐比較驗證，偶有所感，就隨筆記錄。有些地方看得茅塞頓開，有些地方看得拍案叫絕，有些地方看得一陣后怕——怕什么？怕要是沒看到這本書，自己豈不是犯了大錯？

——真是開卷有益——尤其是開高人的卷！

《智能商業(yè)》這本書主要講的就是智能商業(yè)。曾教授說，這是未來的商業(yè)范式。

智能商業(yè)的落腳點在“智能”二字。這兩個字將智能商業(yè)與非智能商業(yè)區(qū)別開。意思是：符合智能商業(yè)邏輯的商業(yè)模式是智能商業(yè)，不符合這個邏輯的，是傳統(tǒng)商業(yè)；智能商業(yè)代表了未來，如果你的商業(yè)模式與智能商業(yè)無關(guān)，那么很可能你就與未來無關(guān)。

這倒不是危言聳聽。

那么，智能商業(yè)的智能主要體現(xiàn)在哪里呢？曾教授總結(jié)是：網(wǎng)絡(luò)協(xié)同+數(shù)據(jù)智能。

什么是網(wǎng)絡(luò)協(xié)同？我的理解是，你要用互聯(lián)網(wǎng)技術(shù)構(gòu)建一張網(wǎng)，將你的產(chǎn)品和服務(wù)搬到線上來（或者至少要有和線上交互的界面），然后把整個服務(wù)流程（產(chǎn)業(yè)鏈）的參與者也搬上來，讓參與者們在線上自主辦公、協(xié)同作業(yè)。當參與的角色足夠多，每個角色的用戶數(shù)足夠大，在線協(xié)同作業(yè)的頻率足夠高，這個協(xié)同網(wǎng)絡(luò)的包容性、自生性就足夠強。

像蜘蛛一樣先織一張網(wǎng)，然后把所有參與者一網(wǎng)打盡，這些參與者通過網(wǎng)絡(luò)協(xié)同作業(yè)，會不斷編織這張網(wǎng)，將網(wǎng)的深度和廣度都極大地延展。這是一張可以自生長的網(wǎng)，有多少用戶涌入，就有多少個節(jié)點，有多少個節(jié)點，這張網(wǎng)就有多大。這張網(wǎng)幾乎可以無限延伸。它不是物理世界，它是互聯(lián)網(wǎng)世界、信息化世界，是新的社群組織形態(tài)。

以上是我對協(xié)同網(wǎng)絡(luò)的粗淺理解。那么，什么又是數(shù)據(jù)智能呢？

我理解的數(shù)據(jù)智能是供給鏈智能化。

怎么講？

所有商業(yè)的原點，都是用戶需求，不同的生產(chǎn)力階段有不同的供給系統(tǒng)。這里面，用戶的需求是相對恒定的，是所有商業(yè)行為的目標，但是供應(yīng)能力不同，所能提供的解決方案就不同、方案的'成本不同、滿足用戶需求的程度也不同——很多需求不是說你有了解決方案用戶才有，而是因為你沒有解決方案所以這個問題一直得不到解決用戶也就不奢望解決了——另外，很多需求不是原生性需求，而是基于解決方案衍生出來的需求——比如手機貼膜不是原生性需求，手機才是原生性需求；或者說手機不是原生性需求，準確講，手機應(yīng)該是一種解決手段，用戶需要入網(wǎng)聯(lián)系進行信息互通才是需求——我們經(jīng)常犯的錯，就是錯把手段當需求，不能從原點出發(fā)去創(chuàng)新。

繞遠了。扯回來。

工業(yè)時代生產(chǎn)力的特征是批量生產(chǎn)、標準化。這時候能供給的是大批量的標準化產(chǎn)品。滿足的是用戶對產(chǎn)品的普遍需求，不是個性需求——記住個性需求是一直存在的，只是當時的供給能力只能滿足小部分人的個性定制需求。隨著工業(yè)化的不斷發(fā)展，標準產(chǎn)品進入了產(chǎn)能過剩的階段，用戶也進入了標準產(chǎn)品信息泛濫的時代，這時候的市場矛盾，變成了用戶個性化需求的增長和市場個性化定制能力薄弱之間的矛盾。本質(zhì)上講，是機械化工業(yè)生產(chǎn)形式無法滿足用戶個性化的需求。

這個矛盾成了我們這個時代亟需解決的問題。

怎么辦呢？答案就是數(shù)據(jù)智能。

數(shù)據(jù)智能是用互聯(lián)網(wǎng)技術(shù)重構(gòu)供給鏈系統(tǒng)，讓高效的柔性生產(chǎn)成為可能，從而滿足用戶個性化的定制需要。

如何滿足？

首先是萬物互聯(lián)，一切在線。也就是所謂的物聯(lián)網(wǎng)（IoT）。物聯(lián)網(wǎng)的意義在于所有產(chǎn)品都成了數(shù)據(jù)終端：既是數(shù)據(jù)輸入終端也是數(shù)據(jù)輸出終端，更是人機交互終端。在物聯(lián)網(wǎng)的前期，你至少要開發(fā)出一個界面，讓你的產(chǎn)品或服務(wù)能夠與用戶互動。這個環(huán)節(jié)，曾教授講叫產(chǎn)品化。

有了交互終端，第二步是一切行為數(shù)據(jù)化。所有的動作，行為，都可以成為數(shù)據(jù)的字節(jié)，被儲存下來。這個數(shù)據(jù)有類型的數(shù)據(jù)，更有個別的數(shù)據(jù)（數(shù)據(jù)庫建模時建的表單不同，數(shù)據(jù)類型就不同）。這些數(shù)據(jù)你不用它，它就毫無價值。但你只要用它，它就變成了財富。最重要的是這個財富不是消耗品，可以無限復制，越用越有用。

將用戶的一切行為數(shù)據(jù)化，這個在技術(shù)上并不難——只要聯(lián)網(wǎng)在線，用戶只要觸網(wǎng)，就會形成數(shù)據(jù)。只是一般人沒有注意到這個動作的意義，所以在系統(tǒng)開發(fā)的時候，沒有開發(fā)并迭代優(yōu)化這部分功能。

數(shù)據(jù)化以后，是建立算法。算法就是建立數(shù)據(jù)規(guī)則，程序指令。什么樣的數(shù)據(jù)觸發(fā)條件（輸入加上數(shù)據(jù)分析）會形成怎樣的輸出，這是算法邏輯。數(shù)據(jù)量不大，分析維度不多，這個事情就簡單。但當數(shù)據(jù)維度足夠豐富，數(shù)據(jù)量足夠大，算法足夠多，運算量足夠大，這時候，就不是人力能搞定的了，只能求助于機器運算。而且一般的機器作業(yè)還不行，得借助云計算的力量。

這樣耗心費力的運算，目的何在？目的在于給協(xié)同網(wǎng)絡(luò)的每個參與者更好的體驗，滿足其個性化需求，讓其可以高效決策高效作業(yè)。

協(xié)同網(wǎng)絡(luò)是一張橫向鋪開的網(wǎng)，網(wǎng)絡(luò)里的每個參與者都是這張網(wǎng)的服務(wù)對象，沒有數(shù)據(jù)智能的協(xié)作，這些參與者的作業(yè)是笨拙的，協(xié)同是低效的，有了數(shù)據(jù)智能，網(wǎng)絡(luò)的參與者才能真正受益，體現(xiàn)出智能商業(yè)的用戶價值

所以曾教授講，協(xié)同網(wǎng)絡(luò)和數(shù)據(jù)智能是構(gòu)成智能商業(yè)DNA的雙螺旋，缺一不可。有了這兩個螺旋，你的商業(yè)模式就是智能商業(yè)，沒有，就是傳統(tǒng)商業(yè)。最后贏的，不是新的，是先進的。智能商業(yè)代表的是先進的理念和先進的生產(chǎn)力。革故鼎新，變革的閥門早已開啟，唯有洞悉未來的發(fā)展趨勢，才能提前布局，捕捉未來。

未來還沒來，但是通往未來的因已經(jīng)種下。我們有幸生在這個時代，可以參與或見證這個時代的變革。想想二十多年前中國的互聯(lián)網(wǎng)什么樣，再想想現(xiàn)在中國的互聯(lián)網(wǎng)什么樣，你還會覺得未來很遙遠嗎？

面向未來，掌握事物發(fā)展的原理，因緣聚合的原理，這樣我們才有機會成為未來的開創(chuàng)者。

感謝曾教授！

第三篇：《智能商業(yè)》讀后感

讀《智能商業(yè)》有感

原創(chuàng)： 蕭翔峰

一口氣讀完了《智能商業(yè)》，很多過往經(jīng)歷的事情與書中內(nèi)容對照了起來，摘選其中部分與大家分享感悟。

網(wǎng)絡(luò)協(xié)同效應(yīng)

曾鳴用一句話講明白了滴滴今天為什么會出現(xiàn)美團入場后促手不及的局面——沒有網(wǎng)路協(xié)同效應(yīng)，單靠規(guī)模經(jīng)濟無法形成壟斷。

以前只知道打車是資本密集型行業(yè)，核心競爭力是資本；但是為什么是資本？并不明白。

原來是因為在線打車在需求端沒有形成網(wǎng)絡(luò)協(xié)同效應(yīng)，即使供給端的規(guī)模效應(yīng)強大，但司機和平臺只是簡單的分成關(guān)系，通過砸錢就可以讓用戶遷移了，也就不存在壁壘。所以美團打車的進攻策略還是通過城市逐步切入，給司機高于滴滴的補貼，粗暴有效。

回想當年在線音樂行業(yè)，網(wǎng)易云能崛起這么迅速，其實是個性化+歌單的模式，讓產(chǎn)品具備了協(xié)同效應(yīng)，用戶越多，體驗越好。而評論的互動又強化了協(xié)同，奠定了整個產(chǎn)品的獨特調(diào)性。這與當時酷狗、QQ 音樂、百度音樂等產(chǎn)品的分類目錄查找型體驗，是質(zhì)的差異。所以，網(wǎng)易云音樂的用戶在早期版權(quán)不受限時能迅速滾起來。但其后正版化+騰訊大力投入壟斷版權(quán)后，用戶的基礎(chǔ)需求（熱門歌曲）無法滿足，網(wǎng)易云音樂上漲的勢頭就被迅速壓制了。

數(shù)據(jù)智能

大數(shù)據(jù)、人工智能，這是時下的行業(yè)流行詞。過往也在想，在未來智能時代產(chǎn)品經(jīng)理的價值是什么？這次在《智能商業(yè)》里看到了一個很系統(tǒng)的闡述，給了自己很大的啟發(fā)。

產(chǎn)品是將“云上”的數(shù)據(jù)智能傳遞給用戶、為用戶帶來價值的通道。數(shù)據(jù)閉環(huán)靠產(chǎn)品互動實現(xiàn)，而產(chǎn)品體驗依賴于數(shù)據(jù)智能，數(shù)據(jù)和產(chǎn)品合二為一。一切的數(shù)據(jù)智能體系，都必須最終融合在功效直接、交互友好、價值明確的互聯(lián)網(wǎng)產(chǎn)品上，其智能的價值才真正的體驗出來?；ヂ?lián)網(wǎng)產(chǎn)品是一種包含了“云”的智能和“端”的體驗的完整互聯(lián)網(wǎng)服務(wù)。

因此，互聯(lián)網(wǎng)產(chǎn)品經(jīng)理作為負責定義、優(yōu)化互聯(lián)網(wǎng)服務(wù)的角色，價值會更大。在智能時代里，一個優(yōu)秀的互聯(lián)網(wǎng)服務(wù)，離不開產(chǎn)品經(jīng)理或?qū)嶋H的產(chǎn)品設(shè)計者，通過創(chuàng)造性的產(chǎn)品設(shè)計，既把數(shù)據(jù)智能的價值不折不扣地傳遞給用戶，又使用戶低成本、高頻度地進行反饋，從而使數(shù)據(jù)智能持續(xù)提升。

這其中，產(chǎn)品經(jīng)理的工作小到功能交互、大到定義產(chǎn)品場景，既包含前端（用戶側(cè)）的直接用戶體驗與交互，也包含后端（云）的數(shù)據(jù)智能引擎（例如推薦算法）的目標定義、指標優(yōu)化。一個同時具備前端、后端工作能力的產(chǎn)品經(jīng)理，是未來的標配。而純 APP 功能產(chǎn)品經(jīng)理的價值會繼續(xù)的下降，因為行業(yè)的配套中臺能力越來越成熟強大了。

未來的新產(chǎn)品，一定是針對某個用戶問題/場景，定義了全新的用戶體驗方式，同時啟動了數(shù)據(jù)智能的引擎，形成了數(shù)據(jù)、算法、產(chǎn)品的反饋閉環(huán)，進而持續(xù)提升用戶體驗。我們現(xiàn)在看到的字節(jié)跳動系產(chǎn)品，就是這一類產(chǎn)品的當下典型。

成為新智人

談到這，我們自己其實也是一家企業(yè)，以經(jīng)營自我、提升自我價值為商業(yè)目標的企業(yè)。但有多少人，在這個互聯(lián)大時代里，還是一個單點？離線的工作、學習著？不能具備協(xié)同效應(yīng)，沒有給自己建立數(shù)據(jù)輸入->輸出的反饋閉環(huán)的人，無法放大自己的價值，也會在未來更快的面臨職業(yè)上升天花板，這是未來協(xié)同的組織中對人的更高要求。

新的一年，把自己當做一個產(chǎn)品，找到自己的定位點，與所在的線去結(jié)網(wǎng)，建立所在面中的反饋閉環(huán)，在時代的大環(huán)境中繼續(xù)向前。

第四篇：《智能商業(yè)》讀后感

《智能商業(yè)》讀后感

原創(chuàng)： 李日白

曾鳴教授是我做戰(zhàn)略的諸多老師之一，他關(guān)于戰(zhàn)略的論述，一度是我反復揣摩學習的教材。

阿里巴巴是一家以戰(zhàn)略見長的公司，能夠在這樣一家公司任參謀長，肯定得有幾把刷子。

馬云是個“大忽悠”,能讓馬云欣賞并邀請加入阿里，斯人功力可見一斑。

剛巧，我主要的工作，也是戰(zhàn)略設(shè)計。于是乎，我就關(guān)注了“曾鳴書院”公眾號，下載了“湖畔”APP,也收聽了曾教授在得到的“智能商業(yè)二十講”.自曾老師宣布要寫這本書開始，我就一直關(guān)注著這本書的進程。先是得知這本書的英文版本已經(jīng)出了，無奈我英語差，不能先睹為快。后又獲悉這本書由中信出版集團出版，于是就在中信的購書小程序上預定了這本書。本以為這本書要等很久才能收到，沒想到才過幾天，就到手了。（截至目前，京東還沒上架這本書的中文版。）

書是昨天下午到的，剛到手，就一口氣看了一半。

這本書對我的幫助非常大。我就在做關(guān)于公司的戰(zhàn)略計劃，也在做公司的智能系統(tǒng)建設(shè)。這本書和我的很多想法不謀而合，讓我引以為豪；另外，這本書還講了很多我沒注意到的問題，給了我不少啟示。我是一邊看，一邊和公司的實踐比較驗證，偶有所感，就隨筆記錄。有些地方看得茅塞頓開，有些地方看得拍案叫絕，有些地方看得一陣后怕——怕什么？怕要是沒看到這本書，自己豈不是犯了大錯？

——真是開卷有益——尤其是開高人的卷！

《智能商業(yè)》這本書主要講的就是智能商業(yè)。曾教授說，這是未來的商業(yè)范式。

智能商業(yè)的落腳點在“智能”二字。這兩個字將智能商業(yè)與非智能商業(yè)區(qū)別開。意思是：符合智能商業(yè)邏輯的商業(yè)模式是智能商業(yè)，不符合這個邏輯的，是傳統(tǒng)商業(yè)；智能商業(yè)代表了未來，如果你的商業(yè)模式與智能商業(yè)無關(guān)，那么很可能你就與未來無關(guān)。

這倒不是危言聳聽。

那么，智能商業(yè)的智能主要體現(xiàn)在哪里呢？曾教授總結(jié)是：網(wǎng)絡(luò)協(xié)同+數(shù)據(jù)智能。

什么是網(wǎng)絡(luò)協(xié)同？我的理解是，你要用互聯(lián)網(wǎng)技術(shù)構(gòu)建一張網(wǎng)，將你的產(chǎn)品和服務(wù)搬到線上來（或者至少要有和線上交互的界面），然后把整個服務(wù)流程（產(chǎn)業(yè)鏈）的參與者也搬上來，讓參與者們在線上自主辦公、協(xié)同作業(yè)。當參與的角色足夠多，每個角色的用戶數(shù)足夠大，在線協(xié)同作業(yè)的頻率足夠高，這個協(xié)同網(wǎng)絡(luò)的包容性、自生性就足夠強。

像蜘蛛一樣先織一張網(wǎng)，然后把所有參與者一網(wǎng)打盡，這些參與者通過網(wǎng)絡(luò)協(xié)同作業(yè)，會不斷編織這張網(wǎng)，將網(wǎng)的深度和廣度都極大地延展。這是一張可以自生長的網(wǎng)，有多少用戶涌入，就有多少個節(jié)點，有多少個節(jié)點，這張網(wǎng)就有多大。這張網(wǎng)幾乎可以無限延伸。它不是物理世界，它是互聯(lián)網(wǎng)世界、信息化世界，是新的社群組織形態(tài)。

以上是我對協(xié)同網(wǎng)絡(luò)的粗淺理解。那么，什么又是數(shù)據(jù)智能呢？

我理解的數(shù)據(jù)智能是供給鏈智能化。

怎么講？

所有商業(yè)的原點，都是用戶需求，不同的生產(chǎn)力階段有不同的供給系統(tǒng)。這里面，用戶的需求是相對恒定的，是所有商業(yè)行為的目標，但是供應(yīng)能力不同，所能提供的解決方案就不同、方案的成本不同、滿足用戶需求的程度也不同——很多需求不是說你有了解決方案用戶才有，而是因為你沒有解決方案所以這個問題一直得不到解決用戶也就不奢望解決了——另外，很多需求不是原生性需求，而是基于解決方案衍生出來的需求——比如手機貼膜不是原生性需求，手機才是原生性需求；或者說手機不是原生性需求，準確講，手機應(yīng)該是一種解決手段，用戶需要入網(wǎng)聯(lián)系進行信息互通才是需求——我們經(jīng)常犯的錯，就是錯把手段當需求，不能從原點出發(fā)去創(chuàng)新。

繞遠了。扯回來。

工業(yè)時代生產(chǎn)力的特征是批量生產(chǎn)、標準化。這時候能供給的是大批量的標準化產(chǎn)品。滿足的是用戶對產(chǎn)品的普遍需求，不是個性需求——記住個性需求是一直存在的，只是當時的供給能力只能滿足小部分人的個性定制需求。隨著工業(yè)化的不斷發(fā)展，標準產(chǎn)品進入了產(chǎn)能過剩的階段，用戶也進入了標準產(chǎn)品信息泛濫的時代，這時候的市場矛盾，變成了用戶個性化需求的增長和市場個性化定制能力薄弱之間的矛盾。本質(zhì)上講，是機械化工業(yè)生產(chǎn)形式無法滿足用戶個性化的需求。

這個矛盾成了我們這個時代亟需解決的問題。

怎么辦呢？答案就是數(shù)據(jù)智能。

數(shù)據(jù)智能是用互聯(lián)網(wǎng)技術(shù)重構(gòu)供給鏈系統(tǒng)，讓高效的柔性生產(chǎn)成為可能，從而滿足用戶個性化的定制需要。

如何滿足？

首先是萬物互聯(lián)，一切在線。也就是所謂的物聯(lián)網(wǎng)（IoT）。物聯(lián)網(wǎng)的意義在于所有產(chǎn)品都成了數(shù)據(jù)終端：既是數(shù)據(jù)輸入終端也是數(shù)據(jù)輸出終端，更是人機交互終端。在物聯(lián)網(wǎng)的前期，你至少要開發(fā)出一個界面，讓你的產(chǎn)品或服務(wù)能夠與用戶互動。這個環(huán)節(jié)，曾教授講叫產(chǎn)品化。

有了交互終端，第二步是一切行為數(shù)據(jù)化。所有的動作，行為，都可以成為數(shù)據(jù)的字節(jié)，被儲存下來。這個數(shù)據(jù)有類型的數(shù)據(jù)，更有個別的數(shù)據(jù)（數(shù)據(jù)庫建模時建的表單不同，數(shù)據(jù)類型就不同）。這些數(shù)據(jù)你不用它，它就毫無價值。但你只要用它，它就變成了財富。最重要的是這個財富不是消耗品，可以無限復制，越用越有用。

將用戶的一切行為數(shù)據(jù)化，這個在技術(shù)上并不難——只要聯(lián)網(wǎng)在線，用戶只要觸網(wǎng)，就會形成數(shù)據(jù)。只是一般人沒有注意到這個動作的意義，所以在系統(tǒng)開發(fā)的時候，沒有開發(fā)并迭代優(yōu)化這部分功能。

數(shù)據(jù)化以后，是建立算法。算法就是建立數(shù)據(jù)規(guī)則，程序指令。什么樣的數(shù)據(jù)觸發(fā)條件（輸入加上數(shù)據(jù)分析）會形成怎樣的輸出，這是算法邏輯。數(shù)據(jù)量不大，分析維度不多，這個事情就簡單。但當數(shù)據(jù)維度足夠豐富，數(shù)據(jù)量足夠大，算法足夠多，運算量足夠大，這時候，就不是人力能搞定的了，只能求助于機器運算。而且一般的機器作業(yè)還不行，得借助云計算的力量。

這樣耗心費力的運算，目的何在？目的在于給協(xié)同網(wǎng)絡(luò)的每個參與者更好的體驗，滿足其個性化需求，讓其可以高效決策高效作業(yè)。

協(xié)同網(wǎng)絡(luò)是一張橫向鋪開的網(wǎng)，網(wǎng)絡(luò)里的每個參與者都是這張網(wǎng)的服務(wù)對象，沒有數(shù)據(jù)智能的協(xié)作，這些參與者的作業(yè)是笨拙的，協(xié)同是低效的，有了數(shù)據(jù)智能，網(wǎng)絡(luò)的參與者才能真正受益，體現(xiàn)出智能商業(yè)的用戶價值

所以曾教授講，協(xié)同網(wǎng)絡(luò)和數(shù)據(jù)智能是構(gòu)成智能商業(yè)DNA的雙螺旋，缺一不可。有了這兩個螺旋，你的商業(yè)模式就是智能商業(yè)，沒有，就是傳統(tǒng)商業(yè)。最后贏的，不是新的，是先進的。智能商業(yè)代表的是先進的理念和先進的生產(chǎn)力。革故鼎新，變革的閥門早已開啟，唯有洞悉未來的發(fā)展趨勢，才能提前布局，捕捉未來。

未來還沒來，但是通往未來的因已經(jīng)種下。我們有幸生在這個時代，可以參與或見證這個時代的變革。想想二十多年前中國的互聯(lián)網(wǎng)什么樣，再想想現(xiàn)在中國的互聯(lián)網(wǎng)什么樣，你還會覺得未來很遙遠嗎？

面向未來，掌握事物發(fā)展的原理，因緣聚合的原理，這樣我們才有機會成為未來的開創(chuàng)者。

感謝曾教授！

第五篇：ETL學習心得：探求數(shù)據(jù)倉庫關(guān)鍵環(huán)節(jié)ETL的本質(zhì)

做數(shù)據(jù)倉庫系統(tǒng)，ETL是關(guān)鍵的一環(huán)。說大了，ETL是數(shù)據(jù)整合解決方案，說小了，就是倒數(shù)據(jù)的工具?；貞浺幌鹿ぷ鬟@么些年來，處理數(shù)據(jù)遷移、轉(zhuǎn)換的工作倒還真的不少。但是那些工作基本上是一次性工作或者很小數(shù)據(jù)量，使用access、DTS或是自己編個小程序搞定?？墒窃跀?shù)據(jù)倉庫系統(tǒng)中，ETL上升到了一定的理論高度，和原來小打小鬧的工具使用不同了。究竟什么不同，從名字上就可以看到，人家已經(jīng)將倒數(shù)據(jù)的過程分成3個步驟，E、T、L分別代表抽取、轉(zhuǎn)換和裝載。

其實ETL過程就是數(shù)據(jù)流動的過程，從不同的數(shù)據(jù)源流向不同的目標數(shù)據(jù)。但在數(shù)據(jù)倉庫中，ETL有幾個特點，一是數(shù)據(jù)同步，它不是一次性倒完數(shù)據(jù)就拉到，它是經(jīng)常性的活動，按照固定周期運行的，甚至現(xiàn)在還有人提出了實時ETL的概念。二是數(shù)據(jù)量，一般都是巨大的，值得你將數(shù)據(jù)流動的過程拆分成E、T和L。

現(xiàn)在有很多成熟的工具提供ETL功能，例如datastage、powermart等，且不說他們的好壞。從應(yīng)用角度來說，ETL的過程其實不是非常復雜，這些工具給數(shù)據(jù)倉庫工程帶來和很大的便利性，特別是開發(fā)的便利和維護的便利。但另一方面，開發(fā)人員容易迷失在這些工具中。舉個例子，VB是一種非常簡單的語言并且也是非常易用的編程工具，上手特別快，但是真正VB的高手有多少？微軟設(shè)計的產(chǎn)品通常有個原則是“將使用者當作傻瓜”，在這個原則下，微軟的東西確實非常好用，但是對于開發(fā)者，如果你自己也將自己當作傻瓜，那就真的傻了。ETL工具也是一樣，這些工具為我們提供圖形化界面，讓我們將主要的精力放在規(guī)則上，以期提高開發(fā)效率。從使用效果來說，確實使用這些工具能夠非常快速地構(gòu)建一個job來處理某個數(shù)據(jù)，不過從整體來看，并不見得他的整體效率會高多少。問題主要不是出在工具上，而是在設(shè)計、開發(fā)人員上。他們迷失在工具中，沒有去探求ETL的本質(zhì)。

可以說這些工具應(yīng)用了這么長時間，在這么多項目、環(huán)境中應(yīng)用，它必然有它成功之處，它必定體現(xiàn)了ETL的本質(zhì)。如果我們不透過表面這些工具的簡單使用去看它背后蘊涵的思想，最終我們作出來的東西也就是一個個獨立的job，將他們整合起來仍然有巨大的工作量。大家都知道“理論與實踐相結(jié)合”，如果在一個領(lǐng)域有所超越，必須要在理論水平上達到一定的高度

探求ETL本質(zhì)之一

ETL的過程就是數(shù)據(jù)流動的過程，從不同異構(gòu)數(shù)據(jù)源流向統(tǒng)一的目標數(shù)據(jù)。其間，數(shù)據(jù)的抽取、清洗、轉(zhuǎn)換和裝載形成串行或并行的過程。ETL的核心還是在于T這個過程，也就是轉(zhuǎn)換，而抽取和裝載一般可以作為轉(zhuǎn)換的輸入和輸出，或者，它們作為一個單獨的部件，其復雜度沒有轉(zhuǎn)換部件高。和OLTP系統(tǒng)中不同，那里充滿這單條記錄的insert、update和select等操作，ETL過程一般都是批量操作，例如它的裝載多采用批量裝載工具，一般都是DBMS系統(tǒng)自身附帶的工具，例如Oracle SQLLoader和DB2的autoloader等。

ETL本身有一些特點，在一些工具中都有體現(xiàn)，下面以datastage和powermart舉例來說。

1、靜態(tài)的ETL單元和動態(tài)的ETL單元實例；一次轉(zhuǎn)換指明了某種格式的數(shù)據(jù)如何格式化成另一種格式的數(shù)據(jù)，對于數(shù)據(jù)源的物理形式在設(shè)計時可以不用指定，它可以在運行時，當這個ETL單元創(chuàng)建一個實例時才指定。對于靜態(tài)和動態(tài)的ETL單元，Datastage沒有嚴格區(qū)分，它的一個Job就是實現(xiàn)這個功能，在早期版本，一個Job同時不能運行兩次，所以一個Job相當于一個實例，在后期版本，它支持multiple instances，而且還不是默認選項。Powermart中將這兩個概念加以區(qū)分，靜態(tài)的叫做Mapping，動態(tài)運行時叫做Session。

2、ETL元數(shù)據(jù)；元數(shù)據(jù)是描述數(shù)據(jù)的數(shù)據(jù)，他的含義非常廣泛，這里僅指ETL的元數(shù)據(jù)。主要包括每次轉(zhuǎn)換前后的數(shù)據(jù)結(jié)構(gòu)和轉(zhuǎn)換的規(guī)則。ETL元數(shù)據(jù)還包括形式參數(shù)的管理，形式參數(shù)的ETL單元定義的參數(shù)，相對還有實參，它是運行時指定的參數(shù)，實參不在元數(shù)據(jù)管理范圍之內(nèi)。

3、數(shù)據(jù)流程的控制；要有可視化的流程編輯工具，提供流程定義和流程監(jiān)控功能。流程調(diào)度的最小單位是ETL單元實例，ETL單元是不能在細分的ETL過程，當然這由開發(fā)者來控制，例如可以將抽取、轉(zhuǎn)換放在一個ETL單元中，那樣這個抽取和轉(zhuǎn)換只能同時運行，而如果將他們分作兩個單元，可以分別運行，這有利于錯誤恢復操作。當然，ETL單元究竟應(yīng)該細分到什么程度應(yīng)該依據(jù)具體應(yīng)用來看，目前還沒有找到很好的細分策略。比如，我們可以規(guī)定將裝載一個表的功能作為一個ETL單元，但是不可否認，這樣的ETL單元之間會有很多共同的操作，例如兩個單元共用一個Hash表，要將這個Hash表裝入內(nèi)存兩次。

4、轉(zhuǎn)換規(guī)則的定義方法；提供函數(shù)集提供常用規(guī)則方法，提供規(guī)則定義語言描述規(guī)則。

5、對數(shù)據(jù)的快速索引；一般都是利用Hash技術(shù)，將參照關(guān)系表提前裝入內(nèi)存，在轉(zhuǎn)換時查找這個hash表。Datastage中有Hash文件技術(shù)，Powermart也有類似的Lookup功能。

探求ETL本質(zhì)之二（分類）

昨在IT-Director上閱讀一篇報告，關(guān)于ETL產(chǎn)品分類的。一般來說，我們眼中的ETL工具都是價格昂貴，能夠處理海量數(shù)據(jù)的家伙，但是這是其中的一種。它可以分成4種，針對不同的需求，主要是從轉(zhuǎn)換規(guī)則的復雜度和數(shù)據(jù)量大小來看。它們包括

1、交互式運行環(huán)境，你可以指定數(shù)據(jù)源、目標數(shù)據(jù)，指定規(guī)則，立馬ETL。這種交互式的操作無疑非常方便，但是只能適合小數(shù)據(jù)量和復雜度不高的ETL過程，因為一旦規(guī)則復雜了，可能需要語言級的描述，不能簡簡單單拖拖拽拽就可以的。還有數(shù)據(jù)量的問題，這種交互式必然建立在解釋型語言基礎(chǔ)上，另外他的靈活性必然要犧牲一定的性能為代價。所以如果要處理海量數(shù)據(jù)的話，每次讀取一條記錄，每次對規(guī)則進行解釋執(zhí)行，每次在寫入一條記錄，這對性能影響是非常大的。

2、專門編碼型的，它提供了一個基于某種語言的程序框架，你可以不必將編程精力放在一些周邊的功能上，例如讀文件功能、寫http://rad.17luntan.com/ClickPortal/W...&alliedsiteid=0“);” onmouseout=“isShowAds = false;isShowAds2 = false;”>數(shù)據(jù)庫的功能，而將精力主要放在規(guī)則的實現(xiàn)上面。這種近似手工代碼的性能肯定是沒話說，除非你的編程技巧不過關(guān)（這也是不可忽視的因素之一）。對于處理大數(shù)據(jù)量，處理復雜轉(zhuǎn)換邏輯，這種方式的ETL實現(xiàn)是非常直觀的。

3、代碼生成器型的，它就像是一個ETL代碼生成器，提供簡單的圖形化界面操作，讓你拖拖拽拽將轉(zhuǎn)換規(guī)則都設(shè)定好，其實他的后臺都是生成基于某種語言的程序，要運行這個ETL過程，必須要編譯才行。Datastage就是類似這樣的產(chǎn)品，設(shè)計好的job必須要編譯，這避免了每次轉(zhuǎn)換的解釋執(zhí)行，但是不知道它生成的中間語言是什么。以前我設(shè)計的ETL工具大挪移其實也是歸屬于這一類，它提供了界面讓用戶編寫規(guī)則，最后生成C++語言，編譯后即可運行。這類工具的特點就是要在界面上下狠功夫，必須讓用戶輕松定義一個ETL過程，提供豐富的插件來完成讀、寫和轉(zhuǎn)換函數(shù)。大挪移在這方面就太弱了，規(guī)則必須手寫，而且要寫成標準c++語法，這未免還是有點難為最終用戶了，還不如做成一個專業(yè)編碼型的產(chǎn)品呢。另外一點，這類工具必須提供面向?qū)＜覒?yīng)用的功能，因為它不可能考慮到所有的轉(zhuǎn)換規(guī)則和所有的讀寫，一方面提供插件接口來讓第三方編寫特定的插件，另一方面還有提供特定語言來實現(xiàn)高級功能。例如Datastage提供一種類Basic的語言，不過他的Job的腳本化實現(xiàn)好像就做的不太好，只能手工繪制job，而不能編程實現(xiàn)Job。

4、最后還有一種類型叫做數(shù)據(jù)集線器，顧名思義，他就是像Hub一樣地工作。將這種類型分出來和上面幾種分類在標準上有所差異，上面三種更多指ETL實現(xiàn)的方法，此類主要從數(shù)據(jù)處理角度。目前有一些產(chǎn)品屬于EAI（Enterprise Application Integration），它的數(shù)據(jù)集成主要是一種準實時性。所以這類產(chǎn)品就像Hub一樣，不斷接收各種異構(gòu)數(shù)據(jù)源來的數(shù)據(jù)，經(jīng)過處理，在實施發(fā)送到不同的目標數(shù)據(jù)中去。

雖然，這些類看似各又千秋，特別在BI項目中，面對海量數(shù)據(jù)的ETL時，中間兩種的選擇就開始了，在選擇過程中，必須要考慮到開發(fā)效率、維護方面、性能、學習曲線、人員技能等各方面因素，當然還有最重要也是最現(xiàn)實的因素就是客戶的意象。

探求ETL本質(zhì)之三（轉(zhuǎn)換）

ETL探求之一中提到，ETL過程最復雜的部分就是T，這個轉(zhuǎn)換過程，T過程究竟有哪些類型呢？

一、宏觀輸入輸出

從對數(shù)據(jù)源的整個宏觀處理分，看看一個ETL過程的輸入輸出，可以分成下面幾類：

1、大小交，這種處理在數(shù)據(jù)清洗過程是常見了，例如從數(shù)據(jù)源到ODS階段，如果數(shù)據(jù)倉庫采用維度建模，而且維度基本采用代理鍵的話，必然存在代碼到此鍵值的轉(zhuǎn)換。如果用SQL實現(xiàn)，必然需要將一個大表和一堆小表都Join起來，當然如果使用ETL工具的話，一般都是先將小表讀入內(nèi)存中再處理。這種情況，輸出數(shù)據(jù)的粒度和大表一樣。

2、大大交，大表和大表之間關(guān)聯(lián)也是一個重要的課題，當然其中要有一個主表，在邏輯上，應(yīng)當是主表Left Join輔表。大表之間的關(guān)聯(lián)存在最大的問題就是性能和穩(wěn)定性，對于海量數(shù)據(jù)來說，必須有優(yōu)化的方法來處理他們的關(guān)聯(lián)，另外，對于大數(shù)據(jù)的處理無疑會占用太多的系統(tǒng)資源，出錯的幾率非常大，如何做到有效錯誤恢復也是個問題。對于這種情況，我們建議還是盡量將大表拆分成適度的稍小一點的表，形成大小交的類型。這類情況的輸出數(shù)據(jù)粒度和主表一樣。

3、站著進來，躺著出去。事務(wù)系統(tǒng)中為了提高系統(tǒng)靈活性和擴展性，很多信息放在代碼表中維護，所以它的“事實表”就是一種窄表，而在數(shù)據(jù)倉庫中，通常要進行寬化，從行變成列，所以稱這種處理情況叫做“站著進來，躺著出去”。大家對Decode肯定不陌生，這是進行寬表化常見的手段之一。窄表變寬表的過程主要體現(xiàn)在對窄表中那個代碼字段的操作。這種情況，窄表是輸入，寬表是輸出，寬表的粒度必定要比窄表粗一些，就粗在那個代碼字段上。

4、聚集。數(shù)據(jù)倉庫中重要的任務(wù)就是沉淀數(shù)據(jù)，聚集是必不可少的操作，它是粗化數(shù)據(jù)粒度的過程。聚集本身其實很簡單，就是類似SQL中Group by的操作，選取特定字段（維度），對度量字段再使用某種聚集函數(shù)。但是對于大數(shù)據(jù)量情況下，聚集算法的優(yōu)化仍是探究的一個課題。例如是直接使用SQL的Group by，還是先排序，在處理。

二、微觀規(guī)則

從數(shù)據(jù)的轉(zhuǎn)換的微觀細節(jié)分，可以分成下面的幾個基本類型，當然還有一些復雜的組合情況，例如先運算，在參照轉(zhuǎn)換的規(guī)則，這種基于基本類型組合的情況就不在此列了。ETL的規(guī)則是依賴目標數(shù)據(jù)的，目標數(shù)據(jù)有多少字段，就有多少條規(guī)則。

1、直接映射，原來是什么就是什么，原封不動照搬過來，對這樣的規(guī)則，如果數(shù)據(jù)源字段和目標字段長度或精度不符，需要特別注意看是否真的可以直接映射還是需要做一些簡單運算。

2、字段運算，數(shù)據(jù)源的一個或多個字段進行數(shù)學運算得到的目標字段，這種規(guī)則一般對數(shù)值型字段而言。

3、參照轉(zhuǎn)換，在轉(zhuǎn)換中通常要用數(shù)據(jù)源的一個或多個字段作為Key，去一個關(guān)聯(lián)數(shù)組中去搜索特定值，而且應(yīng)該只能得到唯一值。這個關(guān)聯(lián)數(shù)組使用Hash算法實現(xiàn)是比較合適也是最常見的，在整個ETL開始之前，它就裝入內(nèi)存，對性能提高的幫助非常大。

4、字符串處理，從數(shù)據(jù)源某個字符串字段中經(jīng)?？梢垣@取特定信息，例如身份證號。而且，經(jīng)常會有數(shù)值型值以字符串形式體現(xiàn)。對字符串的操作通常有類型轉(zhuǎn)換、字符串截取等。但是由于字符類型字段的隨意性也造成了臟數(shù)據(jù)的隱患，所以在處理這種規(guī)則的時候，一定要加上異常處理。

5、空值判斷，對于空值的處理是數(shù)據(jù)倉庫中一個常見問題，是將它作為臟數(shù)據(jù)還是作為特定一種維成員？這恐怕還要看應(yīng)用的情況，也是需要進一步探求的。但是無論怎樣，對于可能有NULL值的字段，不要采用“直接映射”的規(guī)則類型，必須對空值進行判斷，目前我們的建議是將它轉(zhuǎn)換成特定的值。

6、日期轉(zhuǎn)換，在數(shù)據(jù)倉庫中日期值一般都會有特定的，不同于日期類型值的表示方法，例如使用8位整型20040801表示日期。而在數(shù)據(jù)源中，這種字段基本都是日期類型的，所以對于這樣的規(guī)則，需要一些共通函數(shù)來處理將日期轉(zhuǎn)換為8位日期值、6位月份值等。

7、日期運算，基于日期，我們通常會計算日差、月差、時長等。一般數(shù)據(jù)庫提供的日期運算函數(shù)都是基于日期型的，而在數(shù)據(jù)倉庫中采用特定類型來表示日期的話，必須有一套自己的日期運算函數(shù)集。

8、聚集運算，對于事實表中的度量字段，他們通常是通過數(shù)據(jù)源一個或多個字段運用聚集函數(shù)得來的，這些聚集函數(shù)為SQL標準中，包括sum,count,avg,min,max。

9、既定取值，這種規(guī)則和以上各種類型規(guī)則的差別就在于它不依賴于數(shù)據(jù)源字段，對目標字段取一個固定的或是依賴系統(tǒng)的值。

探求ETL本質(zhì)之四（數(shù)據(jù)質(zhì)量）

“不要絕對的數(shù)據(jù)準確，但要知道為什么不準確。”

這是我們在構(gòu)建BI系統(tǒng)是對數(shù)據(jù)準確性的要求。確實，對絕對的數(shù)據(jù)準確誰也沒有把握，不僅是系統(tǒng)集成商，包括客戶也是無法確定。準確的東西需要一個標準，但首先要保證這個標準是準確的，至少現(xiàn)在還沒有這樣一個標準?？蛻魰岢鲆粋€相對標準，例如將你的OLAP數(shù)據(jù)結(jié)果和報表結(jié)果對比。雖然這是一種不太公平的比較，你也只好認了吧。

首先在數(shù)據(jù)源那里，已經(jīng)很難保證數(shù)據(jù)質(zhì)量了，這一點也是事實。在這一層有哪些可能原因?qū)е聰?shù)據(jù)質(zhì)量問題？可以分為下面幾類：

1、數(shù)據(jù)格式錯誤，例如缺失數(shù)據(jù)、數(shù)據(jù)值超出范圍或是數(shù)據(jù)格式非法等。要知道對于同樣處理大數(shù)據(jù)量的數(shù)據(jù)源系統(tǒng)，他們通常會舍棄一些數(shù)據(jù)庫自身的檢查機制，例如字段約束等。他們盡可能將數(shù)據(jù)檢查在入庫前保證，但是這一點是很難確保的。這類情況諸如身份證號碼、手機號、非日期類型的日期字段等。

2、數(shù)據(jù)一致性，同樣，數(shù)據(jù)源系統(tǒng)為了性能的考慮，會在一定程度上舍棄外鍵約束，這通常會導致數(shù)據(jù)不一致。例如在帳務(wù)表中會出現(xiàn)一個用戶表中沒有的用戶ID，在例如有些代碼在代碼表中找不到等。

3、業(yè)務(wù)邏輯的合理性，這一點很難說對與錯。通常，數(shù)據(jù)源系統(tǒng)的設(shè)計并不是非常嚴謹，例如讓用戶開戶日期晚于用戶銷戶日期都是有可能發(fā)生的，一個用戶表中存在多個用戶ID也是有可能發(fā)生的。對這種情況，有什么辦法嗎？

構(gòu)建一個BI系統(tǒng)，要做到完全理解數(shù)據(jù)源系統(tǒng)根本就是不可能的。特別是數(shù)據(jù)源系統(tǒng)在交付后，有更多維護人員的即興發(fā)揮，那更是要花大量的時間去尋找原因。以前曾經(jīng)爭辯過設(shè)計人員對規(guī)則描述的問題，有人提出要在ETL開始之前務(wù)必將所有的規(guī)則弄得一清二楚。我并不同意這樣的意見，倒是認為在ETL過程要有處理這些質(zhì)量有問題數(shù)據(jù)的保證。一定要正面這些臟數(shù)據(jù)，是丟棄還是處理，無法逃避。如果沒有質(zhì)量保證，那么在這個過程中，錯誤會逐漸放大，拋開數(shù)據(jù)源質(zhì)量問題，我們再來看看ETL過程中哪些因素對數(shù)據(jù)準確性產(chǎn)生重大影響。

1、規(guī)則描述錯誤。上面提到對設(shè)計人員對數(shù)據(jù)源系統(tǒng)理解的不充分，導致規(guī)則理解錯誤，這是一方面。另一方面，是規(guī)則的描述，如果無二義性地描述規(guī)則也是要探求的一個課題。規(guī)則是依附于目標字段的，在探求之三中，提到規(guī)則的分類。但是規(guī)則總不能總是用文字描述，必須有嚴格的數(shù)學表達方式。我甚至想過，如果設(shè)計人員能夠使用某種規(guī)則語言來描述，那么我們的ETL單元就可以自動生成、同步，省去很多手工操作了。

2、ETL開發(fā)錯誤。即時規(guī)則很明確，ETL開發(fā)的過程中也會發(fā)生一些錯誤，例如邏輯錯誤、書寫錯誤等。例如對于一個分段值，開區(qū)間閉區(qū)間是需要指定的，但是常常開發(fā)人員沒注意，一個大于等于號寫成大于號就導致數(shù)據(jù)錯誤。

3、人為處理錯誤。在整體ETL流程沒有完成之前，為了圖省事，通常會手工運行ETL過程，這其中一個重大的問題就是你不會按照正常流程去運行了，而是按照自己的理解去運行，發(fā)生的錯誤可能是誤刪了數(shù)據(jù)、重復裝載數(shù)據(jù)等。

探求ETL本質(zhì)之五（質(zhì)量保證）

上回提到ETL數(shù)據(jù)質(zhì)量問題，這是無法根治的，只能采取特定的手段去盡量避免，而且必須要定義出度量方法來衡量數(shù)據(jù)的質(zhì)量是好還是壞。對于數(shù)據(jù)源的質(zhì)量，客戶對此應(yīng)該更加關(guān)心，如果在這個源頭不能保證比較干凈的數(shù)據(jù)，那么后面的分析功能的可信度也都成問題。數(shù)據(jù)源系統(tǒng)也在不斷進化過程中，客戶的操作也在逐漸規(guī)范中，BI系統(tǒng)也同樣如此。本文探討一下對數(shù)據(jù)源質(zhì)量和ETL處理質(zhì)量的應(yīng)對方法。

如何應(yīng)對數(shù)據(jù)源的質(zhì)量問題？記得在onteldatastage列表中也討論過一個話題－“-1的處理”，在數(shù)據(jù)倉庫模型維表中，通常有一條-1記錄，表示“未知”，這個未知含義可廣了，任何可能出錯的數(shù)據(jù)，NULL數(shù)據(jù)甚至是規(guī)則沒有涵蓋到的數(shù)據(jù)，都轉(zhuǎn)成-1。這是一種處理臟數(shù)據(jù)的方法，但這也是一種掩蓋事實的方法。就好像寫一個函數(shù)FileOpen(filename)，返回一個錯誤碼，當然，你可以只返回一種錯誤碼，如-1，但這是一種不好的設(shè)計，對于調(diào)用者來說，他需要依據(jù)這個錯誤碼進行某些判斷，例如是文件不存在，還是讀取權(quán)限不夠，都有相應(yīng)的處理邏輯。數(shù)據(jù)倉庫中也是一樣，所以，建議將不同的數(shù)據(jù)質(zhì)量類型處理結(jié)果分別轉(zhuǎn)換成不同的值，譬如，在轉(zhuǎn)換后，-1表示參照不上，-2表示NULL數(shù)據(jù)等。不過這僅僅對付了上回提到的第一類錯誤，數(shù)據(jù)格式錯誤。對于數(shù)據(jù)一致性和業(yè)務(wù)邏輯合理性問題，這仍有待探求。但這里有一個原則就是“必須在數(shù)據(jù)倉庫中反應(yīng)數(shù)據(jù)源的質(zhì)量”。

對于ETL過程中產(chǎn)生的質(zhì)量問題，必須有保障手段。從以往的經(jīng)驗看，沒有保障手段給實施人員帶來麻煩重重。實施人員對于反復裝載數(shù)據(jù)一定不會陌生，甚至是最后數(shù)據(jù)留到最后的Cube，才發(fā)現(xiàn)了第一步ETL其實已經(jīng)錯了。這個保障手段就是數(shù)據(jù)驗證機制，當然，它的目的是能夠在ETL過程中監(jiān)控數(shù)據(jù)質(zhì)量，產(chǎn)生報警。這個模塊要將實施人員當作是最終用戶，可以說他們是數(shù)據(jù)驗證機制的直接收益者。

首先，必須有一個對質(zhì)量的度量方法，什么是高質(zhì)什么是低質(zhì)，不能靠感官感覺，但這卻是在沒有度量方法條件下通常的做法。那經(jīng)營分析系統(tǒng)來說，聯(lián)通總部曾提出測試規(guī)范，這其實就是一種度量方法，例如指標的誤差范圍不能高于5%等，對系統(tǒng)本身來說其實必須要有這樣的度量方法，先不要說這個度量方法是否科學。對于ETL數(shù)據(jù)處理質(zhì)量，他的度量方法應(yīng)該比聯(lián)通總部測試規(guī)范定義的方法更要嚴格，因為他更多將BI系統(tǒng)看作一個黑盒子，從數(shù)據(jù)源到展現(xiàn)的數(shù)據(jù)誤差允許一定的誤差。而ETL數(shù)據(jù)處理質(zhì)量度量是一種白盒的度量，要注重每一步過程。因此理論上，要求輸入輸出的指標應(yīng)該完全一致。但是我們必須正面完全一致只是理想，對于有誤差的數(shù)據(jù)，必須找到原因。

在質(zhì)量度量方法的前提下，就可以建立一個數(shù)據(jù)驗證框架。此框架依據(jù)總量、分量數(shù)據(jù)稽核方法，該方法在高的《數(shù)據(jù)倉庫中的數(shù)據(jù)稽核技術(shù)》一文中已經(jīng)指出。作為補充，下面提出幾點功能上的建議：

1、提供前端。將開發(fā)實施人員當作用戶，同樣也要為之提供友好的用戶界面?！痘思夹g(shù)》一文中指出測試報告的形式，這種形式還是要依賴人為判斷，在一堆數(shù)據(jù)中去找規(guī)律。到不如用OLAP的方式提供界面，不光是加上測試統(tǒng)計出來的指標結(jié)果，并且配合度量方法的計算。例如誤差率，對于誤差率為大于0的指標，就要好好查一下原因了。

2、提供框架。數(shù)據(jù)驗證不是一次性工作，而是每次ETL過程中都必須做的。因此，必須有一個框架，自動化驗證過程，并提供擴展手段，讓實施人員能夠增加驗證范圍。有了這樣一個框架，其實它起到規(guī)范化操作的作用，開發(fā)實施人員可以將主要精力放在驗證腳本的編寫上，而不必過多關(guān)注驗證如何融合到流程中，如何展現(xiàn)等工作。為此，要設(shè)計一套表，類似于DM表，每次驗證結(jié)果數(shù)據(jù)都記錄其中，并且自動觸發(fā)多維分析的數(shù)據(jù)裝載、發(fā)布等。這樣，實施人員可以在每次裝載，甚至在流程過程中就可以觀察數(shù)據(jù)的誤差率。特別是，如果數(shù)據(jù)倉庫的模型能夠統(tǒng)一起來，甚至數(shù)據(jù)驗證腳本都可以確定下來，剩下的就是規(guī)范流程了。

3、規(guī)范流程。上回提到有一種ETL數(shù)據(jù)質(zhì)量問題是由于人工處理導致的，其中最主要原因還是流程不規(guī)范。開發(fā)實施人員運行單獨一個ETL單元是很方便的，雖然以前曾建議一個ETL單元必須是“可重入”的，這能夠解決誤刪數(shù)據(jù)，重復裝載數(shù)據(jù)問題。但要記住數(shù)據(jù)驗證也是在流程當中，要讓數(shù)據(jù)驗證能夠日常運作，就不要讓實施者感覺到他的存在。總的來說，規(guī)范流程是提高實施效率的關(guān)鍵工作，這也是以后要繼續(xù)探求的。

探求ETL本質(zhì)之六（元數(shù)據(jù)漫談）

對于元數(shù)據(jù)（Metadata）的定義到目前為止沒有什么特別精彩的，這個概念非常廣，一般都是這樣定義，“元數(shù)據(jù)是描述數(shù)據(jù)的數(shù)據(jù)（Data about Data）”，這造成一種遞歸定義，就像問小強住在哪里，答，在旺財隔壁。按照這樣的定義，元數(shù)據(jù)所描述的數(shù)據(jù)是什么呢？還是元數(shù)據(jù)。這樣就可能有元元元...元數(shù)據(jù)。我還聽說過一種對元數(shù)據(jù)，如果說數(shù)據(jù)是一抽屜檔案，那么元數(shù)據(jù)就是分類標簽。那它和索引有什么區(qū)別？

元數(shù)據(jù)體現(xiàn)是一種抽象，哲學家從古至今都在抽象這個世界，力圖找到世界的本質(zhì)。抽象不是一層關(guān)系，它是一種逐步由具體到一般的過程。例如我->男人->人->哺乳動物->生物這就是一個抽象過程，你要是在軟件業(yè)混會發(fā)現(xiàn)這個例子很常見，面向?qū)ο蠓椒ň褪沁@樣一種抽象過程。它對世界中的事物、過程進行抽象，使用面向?qū)ο蠓椒?，?gòu)建一套對象模型。同樣在面向?qū)ο蠓椒ㄖ?，類是對象的抽象，接口又是對類的抽象。因此，我認為可以將“元”和“抽象”換一下，叫抽象數(shù)據(jù)是不是好理解一些。常聽到這樣的話，“xx領(lǐng)導的講話高屋建瓴，給我們后面的工作指引的清晰的方向”，這個成語“高屋建瓴”，站在10樓往下到水，居高臨下，能砸死人，這是指站在一定的高度看待事物，這個一定的高度就是指他有夠“元”。在設(shè)計模式中，強調(diào)要對接口編程，就是說你不要處理這類對象和那類對象的交互，而要處理這個接口和那個接口的交互，先別管他們內(nèi)部是怎么干的。

元數(shù)據(jù)存在的意義也在于此，雖然上面說了一通都撤到哲學上去，但這個詞必須還是要結(jié)合軟件設(shè)計中看，我不知道在別的領(lǐng)域是不是存在Metadata這樣的叫法，雖然我相信別的領(lǐng)域必然有類似的東東。元數(shù)據(jù)的存在就是要做到在更高抽象一層設(shè)計軟件。這肯定有好處，什么靈活性啊，擴展性啊，可維護性啊，都能得到提高，而且架構(gòu)清晰，只是彎彎太多，要是從下往上看，太復雜了。很早以前，我曾看過backorifice的代碼，我靠，一個簡單的功能，從這個類轉(zhuǎn)到父類，又轉(zhuǎn)到父類，很不理解，為什么一個簡單的功能不在一個類的方法中實現(xiàn)就拉到了呢？現(xiàn)在想想，還真不能這樣，這雖然使代碼容易看懂了，但是結(jié)構(gòu)確實混亂的，那他只能干現(xiàn)在的事，如果有什么功能擴展，這些代碼就廢了。

我從98年剛工作時就開始接觸元數(shù)據(jù)的概念，當時叫做元數(shù)據(jù)驅(qū)動的系統(tǒng)架構(gòu)，后來在QiDSS中也用到這個概念構(gòu)建QiNavigator，但是現(xiàn)在覺得元數(shù)據(jù)也沒啥，不就是建一堆表描述界面的元素，再利用這些數(shù)據(jù)自動生成界面嗎。到了數(shù)據(jù)倉庫系統(tǒng)中，這個概念更強了，是數(shù)據(jù)倉庫中一個重要的部分。但是至今，我還是認為這個概念過于玄乎，看不到實際的東西，市面上有一些元數(shù)據(jù)管理的東西，但是從應(yīng)用情況就得知，用的不多。之所以玄乎，就是因為抽象層次沒有分清楚，關(guān)鍵就是對于元數(shù)據(jù)的分類（這種分類就是一種抽象過程）和元數(shù)據(jù)的使用。你可以將元數(shù)據(jù)抽象成0和1，但是那樣對你的業(yè)務(wù)有用嗎？必須還得抽象到適合的程度，最后問題還是“度”。

數(shù)據(jù)倉庫系統(tǒng)的元數(shù)據(jù)作用如何？還不就是使系統(tǒng)自動運轉(zhuǎn)，易于管理嗎？要做到這一步，可沒必要將系統(tǒng)抽象到太極、兩儀、八卦之類的，業(yè)界也曾定義過一些元數(shù)據(jù)規(guī)范，向CWM、XMI等等，可以借鑒，不過俺對此也是不精通的說，以后再說