數據分析與數據可視化實戰(zhàn)1第1章TPC-DS數據分析案例簡介目錄企業(yè)級數據分析環(huán)境的搭建結構化查詢語言SQL數據可視化基礎用戶數據分析與數據挖掘實戰(zhàn)第2章第3章第4章第5章第6章第7章數據分析與數據庫初步認識2供應鏈數據分析與數據挖掘實戰(zhàn)數據集簡介數據分析與挖掘技術有著很強的實踐性，僅僅停留在紙上談兵的階段是不夠的。本章介紹了將會貫穿全書始終的實戰(zhàn)案例——TPC-DS數據集，一個與真實情景高度相仿的企業(yè)級數據集。本章首先對TPC-DS數據集中的4個業(yè)務網絡結構進行了簡介，接下來對各數據表的關鍵字段語義和字段之間的關鍵數量關系進行了定義，最后由TPC-DS數據集引申到真實的企業(yè)級數據分析場景，探討了TPC-DS數據集數據分析任務背后的啟示以及挑戰(zhàn)，為后續(xù)的數據分析案例實戰(zhàn)進行鋪墊。本章學習目標包括以下幾點：1.理解TPC-DS數據集的業(yè)務網絡結構；2.掌握TPC-DS數據集各數據表的關鍵字段語義以及字段之間的關鍵數量關系；3.理解TPC-DS數據集對于企業(yè)級數據分析的啟示。本章要點/學習目標數據集結構解析啟示與挑戰(zhàn)本章內容1233TPC-DS數據集

TPC-DS數據集是事務性能管理委員會（TransactionProcessingPerformanceCouncil,TPC）發(fā)布的用戶數據庫評測的基準之一，是用于評測決策支持系統(tǒng)的標準測試集。TPC-DS是一個與真實場景非常接近的數據集。在教程中，我們將其視為一個快消行業(yè)龍頭企業(yè)的數據庫，主要通過門店（store）、目錄（catalog）以及網絡（website）三個渠道向世界各地的用戶提供產品。TPC-DS數據集共擁有7張事實表與17張維度表。4數據集結構解析門店銷售網絡（storesales網絡）5目錄銷售網絡（catalogsales網絡）6數據集結構解析網站銷售網絡（websitesales網絡）7數據集結構解析庫存網絡（inventory網絡）8數據集結構解析啟示與挑戰(zhàn)TPC-DS數據集是高度簡化的企業(yè)級數據庫，大型企業(yè)的實際情況會更加錯綜復雜。不同業(yè)務網絡所需要考慮的問題和思考問題的角度有很大的區(qū)別，供應鏈庫存網絡與三大銷售網絡的運營目標和運營方法論之間存在著天壤之別。門店銷售業(yè)務、目錄銷售業(yè)務與電商銷售業(yè)務雖然在業(yè)務上相似，但是其運營策略、促銷手段、用戶留存等方面也存在很大的區(qū)別。針對TPC-DS數據集所進行的分析是多角度的，涵蓋了從庫存到營銷到售后的整個價值鏈環(huán)節(jié)，主要包括了面向用戶分析以及面向產品分析兩個主要的分析維度。9本章小結TPC-DS是數據庫學術界和產業(yè)界使用的工業(yè)基準（Benchmark）數據集，有標準的數據表結構、數據生成器以及測試查詢，是數據庫產品性能測試的公共基準。TPC-DS數據集復雜性較高，與企業(yè)實際數據庫結構相似度較高，能夠較好地模擬企業(yè)真實的數據分析需求，其較為全面的維度也給了不同學科背景的用戶模擬不同分析場景提供了支持。本章以TPC-DS數據集作為貫穿始終的數據集，通過數據分析案例設計演示在企業(yè)數據集上的數據分析與數據可視化實現(xiàn)技術，為學習者建立模擬實戰(zhàn)環(huán)境，增強學習者數據分析技術的實際應用能力。1011ZStack協(xié)議棧開發(fā)3-2

Zstack協(xié)議棧工程解析Zstack協(xié)議棧工程解析

在“TexasInstruments\ZStack-CC2530-2.4.0-1.4.0\Projects\zstack\Samples”目錄下可以看到TI官方提供的3個關于ZStack協(xié)議棧的例程，分別是GenericApp、SampleApp和SimpleApp。本書所有的基于協(xié)議棧的項目均是在SimpleApp的基礎上進行修改而實現(xiàn)的。本節(jié)通過解析ZStack協(xié)議棧工程來介紹ZStack協(xié)議棧的工作原理及工作流程。

下面以ZigBee多點自組織網絡的開發(fā)為例來解析ZStack協(xié)議棧的工作原理及其工作流程，并對關鍵代碼進行解釋。

打開ZigBee多點自組織網絡開發(fā)項目后，在Workspace下拉框選項中可以看到3個子工程，分別是協(xié)調器、路由節(jié)點和終端節(jié)點，如圖3.9所示。通過選擇不同的子工程，就可以選擇不同的源文件和編譯選項。

ZigBee網絡中一般含有三類節(jié)點類型：協(xié)調器（負責建立ZigBee網絡、數據收發(fā)）、終端節(jié)點（數據采集、接收控制）和路由節(jié)點（在終端節(jié)點的基礎上增加了路由轉發(fā)的功能）。為了更容易理解ZStack協(xié)議棧的工作原理，這里先簡單介紹協(xié)調器、終端節(jié)點和路由節(jié)點在ZigBee網絡中的工作流程，如圖3.10所示。Zstack協(xié)議棧工程解析

打開ZigBee多點自組織網絡開發(fā)項目后，在Workspace下拉框選項中可以看到3個子工程，分別是協(xié)調器、路由節(jié)點和終端節(jié)點，如圖3.9所示。通過選擇不同的子工程，就可以選擇不同的源文件和編譯選項。

圖3.9子工程選項Zstack協(xié)議棧工程解析ZigBee網絡中一般含有三類節(jié)點類型：協(xié)調器（負責建立ZigBee網絡、數據收發(fā)）、終端節(jié)點（數據采集、接收控制）和路由節(jié)點（在終端節(jié)點的基礎上增加了路由轉發(fā)的功能）。為了更容易理解ZStack協(xié)議棧的工作原理，這里先簡單介紹協(xié)調器、終端節(jié)點和路由節(jié)點在ZigBee網絡中的工作流程，如圖3.10所示。

圖3.10終端節(jié)點、路由節(jié)點和協(xié)調器在ZigBee網絡中的工作流程由圖3.10可知，終端節(jié)點、路由節(jié)點和協(xié)調器的工作流程基本相同，只有在執(zhí)行用戶任務時稍有不同。下面根據圖3.10來解析ZStack協(xié)議棧的工作流程。解析ZStack協(xié)議棧最簡單、最直接的方法就是從工程的入口，即main函數開始解析。Zstack協(xié)議棧工程解析1．ZStack協(xié)議棧OSAL調度關鍵代碼解析在工程的“ZMain”目錄下有一個ZMain.c文件，該文件中的main函數就是整個協(xié)議棧工程的入口，代碼解析如下。Zstack協(xié)議棧工程解析要想理解ZStack協(xié)議棧的工作原理，關鍵是要理解main函數中的osal_init_system()和osal_start_system()函數，其中osal_init_system()函數的代碼如下：Zstack協(xié)議棧工程解析在osal_init_system()函數中初始化了ZStack協(xié)議棧的核心功能，包括內存分配系統(tǒng)初始化、電源管理系統(tǒng)初始化、任務初始化和內存釋放等功能。對開發(fā)人員來講，最重要的是要理解其中的系統(tǒng)任務初始化函數osalInitTasks()，分析該函數的代碼可以發(fā)現(xiàn)，該函數初始化了7個系統(tǒng)任務，并為每個任務賦予了任務標識符taskIDZstack協(xié)議棧工程解析通過將上述各任務的初始化函數展開之后可以發(fā)現(xiàn)：macTaskInit()、nwk_init()、APS_Init()任務的初始化函數代碼不是開源的，TI公司將這些關鍵代碼封裝成庫，開發(fā)人員無法查看其中的代碼；Hal_Init()、MT_TaskInit()和SAPI_Init()等任務初始化函數的作用是對相應的任務信息進行注冊，并調用osal_set_event(uint8task_id,uint16event_flag)函數將各任務的事件添加到任務事件數組tasksEvents[]中。下面以SAPI_Init()函數為例來進行解析，代碼如下Zstack協(xié)議棧工程解析上述代碼的最后調用了osal_set_event(task_id,ZB_ENTRY_EVENT)函數，其作用是設置1個入口事件來啟動任務，該函數的代碼如下：Zstack協(xié)議棧工程解析通過上述代碼分析可知，osal_set_event()函數的關鍵是將事件存儲到任務事件數組中。解析完任務初始化代碼之后，再來解析啟動系統(tǒng)osal_start_system()函數的代碼，該函數的作用是輪詢各個任務，并執(zhí)行各任務的事件處理函數。Zstack協(xié)議棧工程解析將osal_start_system()函數展開之后，可以發(fā)現(xiàn)系統(tǒng)啟動之后進入了一個死循環(huán)，并循環(huán)調用osal_run_system()函數，代碼如下：Zstack協(xié)議棧工程解析展開osal_run_system()函數之后，可以發(fā)現(xiàn)該函數的主要作用是先遍歷任務事件數組，遍歷過程從優(yōu)先級最高的任務開始，在遍歷過程中會判斷該任務是否有未執(zhí)行完的事件，如果該任務有未執(zhí)行完的事件，則跳出while循環(huán)，然后調用(tasksArr[idx])(idx,events)進入該任務的事件處理函數；如果在遍歷中該任務的已經執(zhí)行完畢，即沒有事件，則繼續(xù)循環(huán)檢查下一個任務。當系統(tǒng)中的所有任務都執(zhí)行完成后，系統(tǒng)會自動進入睡眠狀態(tài)，以節(jié)約資源。代碼如下：Zstack協(xié)議棧工程解析Zstack協(xié)議棧工程解析通過對上述代碼的分析可知，關鍵的代碼在“events=(tasksArr[idx])(idx,events)”中，tasksArr數組存儲了各任務的事件處理函數，通過查看tasksArr數組的定義可以知道，系統(tǒng)定義了7個事件處理函數。Zstack協(xié)議棧工程解析在上面7個任務的事件處理函數中，只能查看Hal_ProcessEvent、MT_ProcessEvent、ZDApp_event_loop和SAPI_ProcessEvent函數的代碼，其余函數均被TI公司封裝成庫。系統(tǒng)調用(tasksArr[idx])(idx,events)其實就是調用Hal_ProcessEvent(idx,events)、MT_ProcessEvent(idx,events)、ZDApp_event_loop(idx,events)和SAPI_ProcessEvent(idx,events)等事件處理函數。下面以SAPI_ProcessEvent(idx,events)為例進行代碼解析，解析如下：Zstack協(xié)議棧工程解析Zstack協(xié)議棧工程解析Zstack協(xié)議棧工程解析由上述代碼可知，SAPI的事件處理函數可以處理SYS_EVENT_MSG、ZB_ALLOW_BIND_TIMER、ZB_BIND_TIMER、ZB_ENTRY_EVENT和ZB_USER_EVENTS事件。在這些事件中，開發(fā)人員只需要理解ZB_ENTRY_EVENT和ZB_USER_EVENTS事件的處理過程就可以了。ZB_ENTRY_EVENT事件為ZStack協(xié)議棧工程的入口事件，包括ZigBee入網的過程處理等；ZB_USER_EVENTS為用戶自定義事件，通過查看該事件的宏定義可得知該事件被宏定義為0xFF，說明用戶最多只能自定義8個用戶事件，但8個自定義事件對于開發(fā)者來講已經足夠了。Zstack協(xié)議棧工程解析在ZB_ENTRY_EVENT