數據挖掘基礎

數據挖掘的概念：

• 從數據中“淘金”，從大量數據(文本)中挖掘出隱含的、未知的、對決策有潛在的關系、模型和趨勢，并用這些知識和規則建立用于決策支持的模型，提供預測性決策支持的方法、工具和過程，這就是數據挖掘。

它是利用各種分析工具在大量數據中尋找其規律和發現模型與數據之間關系的過程，是統計學、數據技術和人智能智能技術的綜合。

數據挖掘的基本任務：

• 包括利用分類與預測、聚類分析、關聯規則、時序模式、偏差檢測、職能推薦等方法，幫助企業提取數據中蘊含的商業價值，提高企業的競爭力。

1 目標定義

• 任務理解
• 指標確認

針對具體的挖掘應用需求明確本次挖掘目標是什么?系統完成后能達到什么樣的效果?

2 數據采集

建模抽樣

抽樣數據的標準，一是相關性、二是可靠性、三是有效性。

抽樣的方式

• 隨機抽樣：比如按10%比例隨機抽樣
• 等距抽樣：比如按5%比例，一共100組，取20、40、60、80、100
• 分層抽樣：將樣本分若干層次，每個層次設定不同的概率。
• 從起始順序抽樣：從輸入數據集的起始處開始。
• 分類抽樣：依據某種屬性的取值來選擇數據子集。如按客戶名稱分類、按地址區域分類等。分類抽樣的選取方式就是前面所述的幾種方式，只是抽樣以類為單位。

質量把控

實時采集

3 數據整理

數據探索

對所抽樣的樣本數據進行探索、審核和必要的加工處理，是保證最終的挖掘模型的質量所必須的。

常用的數據探索方法主要包括兩方面：數據質量分析，數據特征分析。

• 數據質量分析：得主要任務是檢查原始數據中是否存在臟數據。包括缺失值分析、異常值分析、數據一致性分析。
• 數據特征分析：在質量分析后可通過繪制圖標、計算某種特征量等手段進行特征分析，

主要包括

• 分布分析：能揭示數據的分布特征和分布類型。可用直方圖、餅圖、條形圖等展示
• 對比分析：將兩個相互聯系的指標進行比較，從數據量上展示和說明研究對象規模的大小，水平的高低，速度的快慢，以及各種關系是否協調。比如，各部門的銷售金額的比較、各年度的銷售額對比。
• 統計量分析：用統計指標對定量數據進行統計描述，常從集中和離中趨勢兩個方面進行分析。平均水平的指標是對個體集中趨勢的度量，最廣泛是均值和中位數;反映變異程度的指標則是對個體離開平均水平的度量，使用較廣泛的是標準差(方差)、四分衛間距。
• 周期性分析：分析某個變量是否跟著時間變化而呈現出某種周期變化趨勢。
• 貢獻度分析：原理是帕累托法則(又稱20/80定律)
• 相關性分析：分析連續變量之間線性相關程度的強弱，并用適當的統計指標表示出來的過程稱為相關分析。判斷兩個變量是否具有線性相關關系的最直觀的方法是直接繪制散點圖。多元線性回歸。

數據清洗

數據清洗主要是刪除原始數據集中的無關數據、重復數據、平滑噪音數據，刷選調與挖掘主題無關的數據，處理缺失值，異常值等。

缺失值處理:刪除記錄、數據插補和不處理。

異常值處理：直接刪除、提油現有變量，進行填補。

數據變換

數據變換主要是對數據進行規范化處理，將數據轉換成“適當”形勢，以適用與挖掘任務與算法的需要。

常見的數據變換方法，簡單函數變換、規范化、連續屬性離散化，屬性構造，小波變換。

數據規約

數據規約產生更小但保持元數據完整性的新數據集。提高效率。主要包括屬性規約和數值規約。

數據集成

數據來源往往分布在不同的數據源中，數據集成就是將數據源合并存在一個一致性的數據存儲。

4 構建模型

樣本抽取完并經預處理，對本次建模進行確認，是分類、聚合、關聯規則、時序模式或者職能推薦，以便后續選用哪種算法進行模型構建。這一步是核心環節。

針對餐飲行業的數據挖掘應用，挖掘建模主要基于關聯規則算法的動態菜品智能推薦、基于聚類算法的餐飲客戶價值分析、基于分類與預測算法的菜品銷售預測、基于整體優化的新店選址。

• 模型發現
• 構建模型
• 驗證模型

5 模型評價

為了確保模型有效，需要對其進行測試評價，目的找出一個最好的模型。

為了有效判斷一個預測模型的性能表現，需要一組沒有參與預測模型建立的數據集，并在該數據集上評價預測模型的精準率。

• 設定評價標準
• 多模型對比
• 模型優化

6 模型發布

• 模型部署
• 模型重構

小結

本章從一個知名餐飲企業經營過程中存在的困惑出發，引出數據挖掘的概念、基本任務、建模過程。

針對建模過程，簡要分析了定義挖掘目標、數據取樣、數據塔索、數據預處理以及挖掘建模的各個算法概述和模型評價。

如何幫助企業從數據中洞察商機、提取價值，這是現階段幾乎所有企業都關心的問題。通過發生在身邊的案例，由淺入深引出深奧的數據挖掘理論，讓讀者感悟數據挖掘的非凡魅力。點贊

個人看完這一章，對于數據挖掘的落地有了一個大概得了解，我們選擇、使用、學習這些大數據的技術應該是結果導向的，這里會讓人更清晰去選擇技術，使用技術。

Hadoop基礎

大數據技術，是指從各種類型的數據中，快速獲得由價值信息的能力。適用大技術的技術，包括大規模并行處理(MPP)數據庫，數據挖掘，分布式文件系統，分布式數據庫，云計算平臺，互聯網和可擴展的存儲系統。

大數據特點4V

• 數據量大(Volume)
• 數據類型復雜(Variety)
• 數據處理速度快(Velocity)
• 數據真實性高(Veracity)

當前，Hadoop已經成為了事實上的標準。

Hadoop除了社區版，還有其他廠商發行的版本。

• Cloudera：最成型的發行版本，擁有最多的部署案例;
• Hortonworks：100%開源的Apache Hadoop唯一提供商。
• MapR：
• Amazon Elastic Map Reduce(EMR)：這是一個托管的解決方案。

生態系統

Hadooop生態系統主要包括:Hive、HBase、Pig、Sqoop、Flume、Zookeeper、Mahout、Spark、Storm、Shark、Phoenix、Tex、Ambari

Hive[haɪv]:數據倉庫系統

用于Hadoop的一個數據倉庫系統，它提供了類似SQL的查詢語言，通過使用該語言， 可以方便地進行數據匯總，特定查詢以及分析存放在Hadoop兼容文件系統中的大數據。

hive基于hdfs構建了數據倉庫系統，它以hdfs作為存儲，依賴于數據庫(嵌入式的數據庫derby或者獨立的數據mysql或oracle)存儲表schema信息，并完成基于sql自動解析創建mapreduce任務(由于mapreduce計算效率比較差，目前官方推薦的是底層計算模型采用tez或者spark)。

所以hive可以理解為：hdfs原始存儲+DB Schema信息存儲+SQL解析引擎+底層計算框架組成的數據倉庫。

Hbase:分布式數據庫

一種分布式、可伸縮的、大數據庫存儲庫，支持隨機、實施讀/寫訪問。

Pig:工作流引擎

Pig是一種編程語言，它簡化了Hadoop常見的工作任務。Pig可加載數據、表達轉換數據以及存儲最終結果。Pig內置的操作使得半結構化數據變得有意義(如日志文件)。同時Pig可擴展使用Java中添加的自定義數據類型并支持數據轉換。

sqoop[skup]:數據庫ETL工具

為高效傳輸批量數據而設計的一種工具，其用于Apache Hadoop和結構化數據存儲庫如關系數據庫之間的數據傳輸。

Flume:日志收集

一種分布式、可靠的、可用的服務，其用于高效搜集、匯總、移動大量日志數據

ZooKeeper[ˈzu:ki:pə(r)]：協同服務管理

一種集中服務、其用于維護配置信息，命名，提供分布式同步，以及提供分組服務。

HDFS:分布式數據存儲系統

hdfs是大數據系統的基礎，它提供了基本的存儲功能，由于底層數據的分布式存儲，上層任務也可以利用數據的本地性進行分布式計算。hdfs思想上很簡單，就是namenode負責數據存儲位置的記錄，datanode負責數據的存儲。使用者client會先訪問namenode詢問數據存在哪，然后去datanode存儲;寫流程也基本類似，會先在namenode上詢問寫到哪，然后把數據存儲到對應的datanode上。所以namenode作為整個系統的靈魂，一旦它掛掉了，整個系統也就無法使用了。在運維中，針對namenode的高可用變得十分關鍵。

Mahout[məˈhaʊt]:算法集

一種基于Hadoop的機器學習和數據挖掘的分布式計算框架算法集，實現了多重MapReduce模式的數據挖掘算法。

spark:計算模型

一種開源的數據分析集群計算框架，建立于HDFS紙上。于Hadoop一樣，用于構建大規模、低延時的數據分析應用。它采用Scala語言實現，使用Scala作為應用框架。

spark是現在大數據中應用最多的計算模型，它與java8的stream編程有相同的風格。封裝了很多的計算方法和模型，以延遲執行的方式，在真正需要執行的時候才進行運算。既可以有效的做計算過程的容錯，也可以改善我們的編程模型。

Spark是一款很棒的執行引擎，我們可以看到大部分的Spark應用，是作為Hadoop分布式文件系統HDFS的上層應用。

( Spark 典型的取代了已經過時的MapReduce引擎，與Hadoop YARN (Yet Another Resource Negotiator，另一種資源協調者)或者分布式計算框架Mesos一起工作，有時候同時與兩者一起作為一個計劃進行)

但是Cutting強調：“還有許多事情Spark是做不到的。”比如：它不是一個全文本搜索引擎;是Solr在Hadoop里扮演著這個角色。它可以運行SQL查詢對抗Spark，但是它沒有被設計成一個交互式查詢系統，對此，Cutting提出，Impala可以實現交互查詢。

如果你只是要需要進行streaming 編程或者batch 編程，那么你需要一個執行引擎，Spark就是很棒的一個。但是人們想做的事情遠不止于此，他們想實現交互式SQL(結構化查詢語言)，他們想實現搜索，他們想做各種涉及系統的實時處理，如Kafka(一種高吞吐量的分布式發布訂閱消息系統)…我認為那些認為Spark就是整個堆的人是確實存在的少數情況。

Storm:

一個分布式、容錯的實時計算系統。

Shark[ʃɑ:k]:SQL查詢引擎

Hive on Spark，一個專門為Spark打造的大規模數據倉庫系統，兼容Apache Hive。無需修改現有的數據或者查詢，就可以用100倍的速度執行Hive SQL。Shark支持Hive查詢語言、元存儲、序列化格式及自定義函數，與現有Hive部署無縫集成，是一個更快、更強大的替代方案。

Phoenix:

一個構建在Apache HBase之上的一個SQL中間層，完全使用Java編寫，提供了一個客戶端可嵌入的JDBC驅動。

Tez:

一個機遇Hadoop YARN之上的DAG計算框架。它把Map/Reduce過程拆分成若干個子過程。同時可以把多個Map/Reduce任務組合成一個較大的DAG任務，減少Map/Reduce之間的文件存儲。同時合理組合其子過程，減少任務的運行時間。

Amari:安裝部署工具

一個供應、管理和監視Apache Hadoop集群的開源框架，它提供一個直觀的操作工具和一個健壯的Hadoop Api,

MapReduce:

說穿了就是函數式編程，把所有的操作都分成兩類，map與reduce，map用來將數據分成多份，分開處理，reduce將處理后的結果進行歸并，得到最終的結果。

ChuKwa:

YARN[jɑ:n]：Hadoop 資源管理器

Hadoop HDFS

HDFS被設計成適合在通用硬件上的分布式文件系統。具有如下特點

具有高度容錯性的系統。設計用來部署在低廉的硬件上，提供高吞吐量，適合那些有超大數據集的應用程序，放寬了POSIX的要求這樣可以實現以流的形式(streaming access)訪問文件系統中的數據。

HDFS采用master/slave。一個集群由一個NameNode和多個DataNodes組成。

• Active Namenode：主 Master(只有一個)，管理 HDFS 的名稱空間，管理數據塊映射信息;配置副本策略;處理客戶端讀寫請求。
• Secondary NameNode：NameNode 的熱備;定期合并 fsimage 和 fsedits，推送給 NameNode;當 Active NameNode 出現故障時，快速切換為新的 Active NameNode。
• Datanode：Slave(有多個);存儲實際的數據塊;執行數據塊讀 / 寫。
• Client：與 NameNode 交互，獲取文件位置信息;與 DataNode 交互，讀取或者寫入數據;管理 HDFS、訪問 HDFS。

Hive

概念

Hive最初是Facebook面對海量數據和機器學習的需求而產生和發展的，是建立在Hadoop上數據倉庫基礎架構，它可以將結構化的數據文件映射為一張數據庫表，并提供簡單的SQL查詢功能。

Hive作為數據倉庫，提供一系列工具，可以用來進行數據提取轉化加載(ETL)，這是一種可以存儲、查詢和分析存儲在Hadoop中的大規模數據的機制。

Hive定義了簡單的類SQL查詢語言，成為HQL，它允許熟悉SQL用戶查詢數據。

特點

• 支持索引，加快數據查詢。
• 不同的存儲類型，如純文本文件、HBase中的文件。
• 將元數據保存在關系數據庫中，大大減少了在查詢過程中執行語義檢查的時候。
• 可以直接使用存儲在Hadoop文件系統中的數據。
• 內置大量用戶函數UDF來操作時間、字符串和其他的數據挖掘工具，支持用戶擴展UDF函數來完成內置函數無法實現的操作。
• 類SQL的查詢方式，將SQL查詢轉換為MapReduce的Job在Hadoop集群上執行

Hive并不能夠在大規模數據集上實現低延遲快速的查詢，不能提供實時的查詢和基于行級的數據更新操作。比如幾百MB的數據集上執行查詢一般有分鐘級的時間延遲。所以它不適合低延遲的應用。最佳應用在大數據集的批處理作業，如網絡日志分析。

Hive支持的數據模型

• 表：存在在HDFS目錄底下，固定目錄
• 外部表：跟表差不多，指定目錄

分區：

• 桶：對指定的列計算其哈希值，根絕哈希值切分數據，目的是并行，每個桶對應一個文件。

Hbase

概念

Hbase是一個分布式、面向列的開源數據庫，利用HBASE技術可以在廉價PC服務器搭建大規模結構化存儲集群。它不是關系型數據庫，是一個適合非結構化的數據存儲數據庫。它利用Hadoop MapReduce來處理HBase中的海量數據，同時利用Zookeeper作為其協同服務。

采購LSM算法，后面繼續深入研究，這個算法，是在內存中對未排序的值進行，拆分排序，比如N個數，每M個拆分一次做排序，那么每次尋找的計算量應該是N/M*log2M

特點

• 線性和模塊化可擴展性
• 嚴格一致的讀取和寫入
• 表的自動配置和分片
• 支持RegionServers之間的自動故障轉移
• 方便的基類支持Hadoop的MapReduce作業與Apache HBase的表
• 易于使用的Java API的客戶端訪問
• 塊緩存和布魯姆過濾器實時查詢
• Thrift網管和REST-FUL Web服務支持XML、protobuf和二進制的數據編碼選項;
• 可擴展的基于JRuby(JIRB)的腳本;
• 支持監控信息通過Hadoop子系統導出到文件或Ganglia

Pig和Hive還為HBase提供了高層語言支持，這使得HBase上進行數據統計處理變得非常簡單。Sqoop則為HBase提供了RDBMS數據導入功能，使用傳統數據庫向HBase遷移變得很方便。

原理

 

HBase構建在HDFS之上，其組件包括 Client、zookeeper、HDFS、Hmaster以及HRegionServer。Client包含訪問HBase的接口，并維護cache來加快對HBase的訪問。Zookeeper用來保證任何時候，集群中只有一個master，存貯所有Region的尋址入口以及實時監控Region server的上線和下線信息。并實時通知給Master存儲HBase的schema和table元數據。HMaster負責為Region server分配region和Region server的負載均衡。如果發現失效的Region server并重新分配其上的region。同時，管理用戶對table的增刪改查操作。Region Server 負責維護region，處理對這些region的IO請求并且切分在運行過程中變得過大的region。

Hbase底層使用還是Hadoop的HDFS。同時包含3個重要組件，

• Zookeeper：為整個HBase集群提供協助的服務(信息傳輸);
• HMaster：監控和操作集群中所有的RegionServer;
• HregionServer：服務和管理分區(regions)。

**Region：**Hbase的Table中的所有行都按照row key的字典序排列。Table 在行的方向上分割為多個Region。、Region按大小分割的，每個表開始只有一個region，隨 著數據增多，region不斷增大，當增大到一個閥值的時候， region就會等分會兩個新的region，之后會有越來越多的 region。

 

 

Region是HBase中分布式存儲和負載均衡的最小單元。 不同Region分布到不同RegionServer上。

 

Region雖然是分布式存儲的最小單元，但并不是存儲 的最小單元。Region由一個或者多個Store組成，每個store保存一個 columns family。每個Strore又由一個memStore和0至多個StoreFile組成。memStore存儲在內存中，StoreFile存儲在HDFS上。

 

HBase和RDBMS的區別

HBASE設計的初衷是針對大數據進行隨機地、實時地讀寫操作。區別

 

HBase數據模型

傳統型數據庫以行的形式存儲數據，每行數據包含多列，每列只有單個值。在HBase中，數據實際存儲在一個“映射”中，并且“映射”的鍵(key)是被排序的。類似JavaScript Object(JSON)

HBase包含如下幾個概念：

1 Row key

一條記錄的唯一標示

2 column family

一列數據的集合的存儲體，作為列簇

3 Column qualifier

在列簇中的每個列數據的限定符，用于指定數據的屬性

4 Cell

實際存儲的數據，包含數據和時間戳

 

小結

這里介紹大數據數據庫HBASE的基礎概念,分析了HBase的原理，主要包括其與RDBMS的對比、訪問接口、數據模型等。最后結構HBase的架構圖介紹各個模塊組件，包括HMaster、HRegionServer、Zookeeper

大數據挖掘建模平臺

本章首先介紹常用的大數據平臺，采用開源的TipDM-HB大數據挖掘建模平臺。

SOA架構，面向服務架構，以為著服務接口、流程整合、資源可利用、管控。

挖掘建模

經過數據探索與數據預處理，得到了可以建模的數據。

根據挖掘目標和數據形式可以建立分類與預測、聚類分析、關聯規則、職能推薦等模型。