標籤: 台北網頁設計

  • 一起玩轉微服務(3)——微服務架構設計模式

    一起玩轉微服務(3)——微服務架構設計模式

    一、聚合器微服務設計模式

    這是一種最常見也最簡單的設計模式,效果如下圖所示。
    聚合器調用多個服務實現應用程序所需的功能。它可以是一個簡單的Web頁面,將檢索到的數據進行處理展示。它也可以是一個更高層次的組合微服務,對檢索到的數據增加業務邏輯後進一步發布成一個新的微服務,這符合DRY原則。另外,每個服務都有自己的緩存和數據庫。如果聚合器是一個組合服務,那麼它也有自己的緩存和數據庫。

    二、代理微服務設計模式

    這是聚合模式的一個變種,如下圖所示。
    在這種情況下,客戶端並不聚合數據,但會根據業務需求的差別調用不同的微服務。代理可以僅僅委派請求,也可以進行數據轉換工作。每個微服務都有自己獨立的緩存和數據庫系統,彼此獨立。

    三、鏈式微服務設計模式

    這種模式在接收到請求後會產生一個經過合併的響應,如下圖所示:
    在這種情況下,服務A接收到請求後會與服務B進行通信,類似地,服務B會同服務C進行通信。所有服務都使用同步消息傳遞。在整個鏈式調用完成之前,客戶端會一直阻塞。
    因此,服務調用鏈不宜過長,以免客戶端長時間等待。

    四、分支微服務設計模式

    這種模式是聚合器模式的擴展,允許同時調用兩個微服務鏈,如下圖所示:
    每個調用鏈分別調用自己的服務。當某個調用出現問題時,互相之間不會造成影響。

    五、數據共享微服務設計模式

    自治是微服務的設計原則之一,就是說微服務是全棧式服務。但在重構現有的“單體應用(monolithic application)”時,SQL數據庫反規範化可能會導致數據重複和不一致。
    因此,在單體應用到微服務架構的過渡階段,可以使用這種設計模式,如下圖所示:
    在這種情況下,部分微服務可能會共享緩存和數據庫存儲。不過,這隻有在兩個服務之間存在強耦合關係時才可以。對於基於微服務的新建應用程序而言,這是一種反模式。
     

    六、異步消息傳遞微服務設計模式

    雖然REST設計模式非常流行,但它是同步的,會造成阻塞。因此部分基於微服務的架構可能會選擇使用消息隊列代替REST請求/響應,如下圖所示:
    各個服務之間通過異步的消息隊列進行交互,當服務出現問題時,不會造成阻塞,隊列會幫助緩存消息,直到消費服務開始工作。

     

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

    ※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

    ※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

    南投搬家公司費用需注意的眉眉角角,別等搬了再說!

    ※教你寫出一流的銷售文案?

  • 大數據篇:一文讀懂@數據倉庫

    大數據篇:一文讀懂@數據倉庫

    大數據篇:一文讀懂@數據倉庫

    1 網絡詞彙總結

    • 人工智能層的:智慧地球、智慧城市、智慧社會
    • 企業層面的:数字互聯網,数字經濟、数字平台、数字城市、数字政府;
    • 平台層面的:物聯網,雲計算,大數據,5G,人工智能,機器智能,深度學習,知識圖譜
    • 技術層面的:數據倉庫、數據集市、大數據平台、數據湖、數據中台、業務中台、技術中台等等

    挑重點簡介

    1.1 數據中台

    1. 數據中台是聚合和治理跨域數據,將數據抽象封裝成服務,提供給前台以業務價值的邏輯概念。

    2. 數據中台是一套可持續“讓企業的數據用起來”的機制,一種戰略選擇和組織形式,是依據企業特有的業務模式和組織架構,通過有形的產品和實施方法論支撐,構建一套持續不斷把數據變成資產並服務於業務的機制。

    3. 數據中台連接數據前台和後台,突破數據局限,為企業提供更靈活、高效、低成本的數據分析挖掘服務,避免企業為滿足具體某部門某種數據分析需求而投放大量高成本、重複性的數據開發成本。

    4. 數據中台是指通過數據技術,對海量數據進行採集、計算、存儲、加工,同時統一標準和口徑。數據中台把數據統一之後,會形成標準數據,再進行存儲,形成大數據資產層,進而為客戶提供高效服務。

    5. 數據中台,包括平台、工具、數據、組織、流程、規範等一切與企業數據資產如何用起來所相關的。

    可以看出,數據中台是解決如何用好數據的問題,目前還缺乏一個標準,而說到數據中台一定會提及大數據,而大數據又是由數據倉庫發展起來的。

    1.1.1 數據倉庫(Data WareHouse)

    1. 數據倉庫,按照傳統的定義,數據倉庫是一個面向主題的、集成的、非易失的、反映歷史變化(隨時間變化),用來支持管理人員決策的數據集合。

    為企業所有決策制定過程,提供所有系統數據支持的戰略集合

    • 面向主題

    操作型數據庫的數據組織面向事務處理任務,各個業務系統之間各自分離,而數據倉庫中的數據是按照一定的主題域進行組織。

    主題是一個抽象的概念,是數據歸類的標準,是指用戶使用數據倉庫進行決策時所關心的重點方面,一個主題通常與多個操作型信息系統相關。每一個主題基本對應一個宏觀的分析領域。

    例如,銀行的數據倉庫的主題:客戶

    客戶數據來源:從銀行儲蓄數據庫、信用卡數據庫、貸款數據庫等幾個數據庫中抽取的數據整理而成。這些客戶信息有可能是一致的,也可能是不一致的,這些信息需要統一整合才能完整體現客戶。

    • 集成

    面向事務處理的操作型數據庫通常與某些特定的應用相關,數據庫之間相互獨立,並且往往是異構的。而數據倉庫中的數據是在對原有分散的數據庫數據抽取、清理的基礎上經過系統加工、匯總和整理得到的,必須消除源數據中的不一致性,以保證數據倉庫內的信息是關於整個企業的一致的全局信息。

    具體如下:

    1:數據進入數據倉庫后、使用之前,必須經過加工與集成。

    2:對不同的數據來源進行統一數據結構和編碼。統一原始數 據中的所有矛盾之處,如字段的同名異義,異名同義,單位不統一,字長不一致等。

    3:將原始數據結構做一個從面嚮應用到面向主題的大轉變。

    • 非易失即相對穩定的

    操作型數據庫中的數據通常實時更新,數據根據需要及時發生變化。數據倉庫的數據主要供企業決策分析之用,所涉及的數據操作主要是數據查詢,一旦某個數據進入數據倉庫以後,一般情況下將被長期保留,也就是數據倉庫中一般有大量的查詢操作,但修改和刪除操作很少,通常只需要定期的加載、刷新。

    數據倉庫中包括了大量的歷史數據。

    數據經集成進入數據倉庫后是極少或根本不更新的。

    • 隨時間變化即反映歷史變化

    操作型數據庫主要關心當前某一個時間段內的數據,而數據倉庫中的數據通常包含歷史信息,系統記錄了企業從過去某一時點(如開始應用數據倉庫的時點)到目前的各個階段的信息,通過這些信息,可以對企業的發展歷程和未來趨勢做出定量分析和預測。企業數據倉庫的建設,是以現有企業業務系統和大量業務數據的積累為基礎。數據倉庫不是靜態的概念,只有把信息及時交給需要這些信息的使用者,供他們做出改善其業務經營的決策,信息才能發揮作用,信息才有意義。而把信息加以整理歸納和重組,並及時提供給相應的管理決策人員,是數據倉庫的根本任務。因此,從產業界的角度看,數據倉庫建設是一個工程,是一個過程

    數據倉庫內的數據時限一般在5-10年以上,甚至永不刪除,這些數據的鍵碼都包含時間項,標明數據的歷史時期,方便做時間趨勢分析。

    1. 數據倉庫,並不是數據最終目的地,而是為數據最終的目的地做好準備:清洗、轉義、分類、重組、合併、拆分、統計等等

    通過對數據倉庫中數據的分析,可以幫助企業,改進業務流程、控制、成本、提高產品質量等

    1. 主要解決問題:數據報表,數據沉澱,數據計算Join過多,數據查詢過慢等問題。

    防止煙囪式開發,減少重複開發,開發通用中間層數據,減少重複計算;

    將複雜問題簡單化,將複雜任務的多個步驟分解到各個層次中,每一層只處理較少的步驟,使單個任務更容易理解;

    可進行數據血緣追蹤,便於快速定位問題;

    整個數據層次清晰,每個層次的數據都有職責定位,便於使用和理解。

    1. 主要價值體現:企業數據模型,這些模型隨着前端業務系統的發展變化,不斷變革,不斷追加,不斷豐富和完善,即使系統不再了,也可以在短期內快速重建起來,這也是大數據產品能夠快速迭代起來的一個重要原因

    總結:數據倉庫,即為企業數據的模型沉澱,為了能更快的發展大數據應用,提供可靠的模型來快速迭代。本文也主要為了講解數據倉庫

    • 數倉硬件架構圖
    • 數倉功能架構圖
    • 數倉流程架構圖1
    • 數倉流程架構圖2
    • 實時數倉流程架構圖

    1.1.2 大數據平台(DATA Platform)

    1. 大數據平台則是指以處理海量數據存儲、計算及流數據實時計算等場景為主的一套基礎設施,包括了統一的數據採集中心、數據計算和存儲中心、數據治理中心、運維管控中心、開放共享中心和應用中心。

    2. 大數據平台的建設出發點是節約投資降低成本,但實際上無論從硬件投資還是從軟件開發上都遠遠超過數據倉庫的建設,大量的硬件和各種開源技術的組合,增加了研發的難度、調測部署的周期、運維的複雜度,人力上的投入已是最初的幾倍;還有很多技術上的困難也非一朝一夕能夠突破。

    3. 首先是數據的應用問題,無論是數據倉庫還是大數據平台,裡面包含了接口層數據、存儲層數據、輕度匯總層、重度匯總層、模型層數據、報表層數據等等,各種各樣的表有成千上萬,這些表有的是中間處理過程,有些是一次性的報表,不同表之間的數據一致性和口徑也會不同,而且不同的表不同的字段對數據安全要求級別也不同。

    4. 此外還要考慮多租戶的資源安全管理,如何讓內部開發者快速獲取所需的數據資產目錄,如何閱讀相關數據的來龍去脈,如何快速的實現開發,這些在大數據平台建設初期沒有考慮周全。

    5. 另外一個問題是對外應用,隨着大數據平台的應用建設,每一個對外應用都採用單一的數據庫加單一應用建設模式,獨立考慮網絡安全、數據安全、共享安全,逐漸又走向了煙囪似的開發道路。

    總結:大數據平台,即為數據一站式服務,提供可視化的數據展示,提取,計算任務安排,資源管理,數據治理,安全措施,共享應用等等。

    • 平台數據流向圖
    • 平台流程架構圖

    1.1.3 數據中台(Data Middle Platform)

    1. 數據中台要解決什麼?數據如何安全的、快速的、最小權限的、且能夠溯源的被探測和快速應用的問題。

    2. 數據中台不應該被過度的承載平台的計算、存儲、加工任務,而是應該放在解決企業邏輯模型的搭建和存儲、數據標準的建立、數據目錄的梳理、數據安全的界定、數據資產的開放,知識圖譜的構建。

    3. 通過一系列工具、組織、流程、規範,實現數據前台和後台的連接,突破數據局限,為企業提供更靈活、高效、低成本的數據分析挖掘服務,避免企業為滿足具體某部門某種數據分析需求而投放大量高成本、重複性的數據開發成本。

    總結:厚平台,大中台,小前台;沒有基礎厚實笨重的大數據平台,是不可能構建數據能力強大、功能強大的數據中台的;沒有大數據中台,要迅速搭建小快靈的小前台也只是理想化的。

    • 中台架構圖
    • 阿里數據中台架構圖

    2 數據庫的”分家”

    隨着關係數據庫理論的提出,誕生了一系列經典的RDBMS,如Oracle,MySQL,SQL Server等。這些RDBMS被成功推向市場,併為社會信息化的發展做出的重大貢獻。然而隨着數據庫使用範圍的不斷擴大,它被逐步劃分為兩大基本類型:

    1. 操作型數據庫(OLTP)

    主要用於業務支撐。一個公司往往會使用並維護若干個數據庫,這些數據庫保存着公司的日常操作數據,比如商品購買、酒店預訂、打車下單、外賣訂購等;

    1. 分析型數據庫(OLAP)

    主要用於歷史數據分析。這類數據庫作為公司的單獨數據存儲,負責利用歷史數據對公司各主題域進行統計分析;

    • 總結

    那麼為什麼要”分家”?在一起不合適嗎?能不能構建一個同樣適用於操作和分析的統一數據庫?

    答案是NO。一個顯然的原因是它們會”打架”……如果操作型任務和分析型任務搶資源怎麼辦呢?再者,它們有太多不同,以致於早已”貌合神離”。接下來看看它們到底有哪些不同吧。

    因為主導功能的不同(面向操作/面向分析),兩類數據庫就產生了很多細節上的差異。就好像玩LOL一个中單一個ADC,肯定有很多行為/觀念上的不同

    2.1 OLAP 和 OLTP簡介

    數據處理大致可以分成兩大類:

    聯機事務處理OLTP(on-line transaction processing):是傳統的關係型數據庫的主要應用,主要是基本的、日常的事務處理,例如銀行交易。系統強調數據庫內存效率,強調內存各種指標的命令率,強調綁定變量,強調併發操作。

    聯機分析處理OLAP(On-Line Analytical Processing):是數據倉庫系統的主要應用,支持複雜的分析操作,側重決策支持,並且提供直觀易懂的查詢結果。 系統則強調數據分析,強調SQL執行市場,強調磁盤I/O,強調分區等。

    2.2 定義差別

    對比內容 操作型數據庫(OLTP) 分析型數據庫(OLAP)
    數據內容 當前值 歷史的、存檔的、歸納的、計算的數據
    數據目標 面向業務操作程序,重複處理 面向主題域,分析應用,支持決策
    數據特性 動態變化,按字段更新 靜態、不能直接更新,只能定時添加、刷新
    數據結構 高度結構化、複雜,適合操作計算 簡單,適合分析
    使用頻率 中到低
    數據訪問量 每個事務只訪問少量記錄 有的事務可能需要訪問大量記錄
    對響應時間的要求 以秒為單位計算 以秒、分鐘、甚至小時為計算單位

    2.3 定位差別

    對比屬性 OLTP OLAP
    代表 Mysql Hive
    讀特性 每次查詢只返回少量數據 對大量數據進行匯總
    寫特性 隨機、低延遲寫入用戶的操作 批量導入
    用戶 操作人員 決策人員
    DB設計 面嚮應用 面向主題
    數據 當前的,最新的細節,二維表 歷史的,聚集的,多維表
    工作單位 事務性保證 複雜查詢
    用戶數 上千個 上百萬個
    DB大小 100MB-GB 100GB-TB以上
    時間要求 具有實時性 對時間的要求不嚴格
    主要應用 數據庫:WEB項目 數據倉庫:分析師,挖掘師

    2.4 組成差別

    對比內容 操作型數據庫(OLTP) 分析型數據庫(OLAP)
    數據時間範圍差別 只會存放一定天數的數據 存放的則是數年內的數據
    數據細節層次差別 存放的主要是細節數據 也有匯總需求,但匯總數據本身不存儲而只存儲其生成公式。
    這是因為操作型數據是動態變化的,因此匯總數據會在每次查詢時動態生成。
    存放的既有細節數據,又有匯總數據,對於用戶來說,重點關注的是匯總數據部分。
    因為匯總數據比較穩定不會發生改變,而且其計算量也比較大(因為時間跨度大),因此它的匯總數據可考慮事先計算好,以避免重複計算。
    數據時間表示差別 通常反映的是現實世界的當前狀態 既有當前狀態,還有過去各時刻的快照。
    可以綜合所有快照對各個歷史階段進行統計分析

    2.5 技術差別

    對比內容 操作型數據庫(OLTP) 分析型數據庫(OLAP)
    數據更新差別 允許用戶進行增,刪,改,查 規範是只能進行查詢
    數據冗餘差別 減少數據冗餘,避免更新異常 沒有更新操作。因此,減少數據冗餘也就沒那麼重要了

    2.6 功能差別

    對比內容 操作型數據庫(OLTP) 分析型數據庫(OLAP)
    數據讀者差別 使用者是業務環境內的各個角色,如用戶,商家,進貨商等 只被少量用戶(高級管理者)用來做綜合性決策
    數據定位差別 是為了支撐具體業務創建的,因此也被稱為”面嚮應用型數據庫” 是針對各特定業務主題域的分析任務創建的,因此也被稱為”面向主題型數據庫”

    2.7 OLTP數據庫三範式介紹

    • 定義:範式可以理解為設計一張數據表的表結構,符合的標準級別。 規範和要求
    • 優點:關係型數據庫設計時,遵照一定的規範要求,目的在於降低數據的冗餘性。
      • 十幾年前,磁盤很貴,為了減少磁盤存儲。
      • 以前沒有分佈式系統,都是單機,只能增加磁盤,磁盤個數也是有限的
      • 一次修改,需要修改多個表,很難保證數據一致性
    • 缺點:範式的缺點是獲取數據時,需要通過 Join 拼接出最後的數據。

    目前業界範式有:第一範式(1NF)、第二範式(2NF)、第三範式(3NF)、巴斯-科德範式 (BCNF)、第四範式(4NF)、第五範式(5NF)。

    2.7.1 函數依賴

    學號 姓名 系名 班主任 課名 分數
    001 張三 古文系 李白 文言文 89
    001 張三 古文系 李白 古詩詞 78
    001 張三 古文系 李白 現代漢語 65
    002 李四 古文系 李白 文言文 45
    002 李四 古文系 李白 古詩詞 78
    002 李四 古文系 李白 甲骨文 98
    003 王五 數學系 牛頓 高等數學 88
    003 王五 數學系 牛頓 數學基礎 88
    1. 完全函數依賴:

    通過 AB 能推出 C,但是 AB 單獨得不到 C,那麼可以說:C 完全依賴於 AB

    (學號,課名)推出 分數,但是 單獨用學號 推不出 分數,那麼可以說:分數 完全依賴於(學號,課名)

    1. 部分函數依賴:

    通過 AB 能推出 C,通過 單獨的A 或者 單獨的B 也能推出 C,那麼可以說:C 部分依賴於 AB

    (學號,課名)推出 姓名,而還可以通過 學號 直接推出 姓名,那麼可以說:姓名 部分依賴於(學號,課名)

    1. 傳遞函數依賴:

    通過 A 得到 B,通過 B 得到 C,但是通過 C 不能得到 A,那麼可以說:C 傳遞依賴於 A

    通過 學號 推出 系名,系名 推出 系主任,但是 系主任 不能推出 學號,那麼可以說:系主任 專遞依賴於 學號

    2.7.2 三範式區分

    2.7.2.1 第一範式:屬性不可切割
    • 不符合第一範式表設計
    ID 商品 商家ID 用戶ID
    001 5台電腦 小米_001 00001

    如上表格不符合第一範式,商品列中的數據不是原子數據項,是可以進行分割的。

    • 符合第一範式表設計
    ID 商品 數量 商家ID 用戶ID
    001 電腦 5 小米_001 00001

    1NF是所有關係數據庫的最基本要求

    2.7.2.2 第二範式:不能存在”部分函數依賴”
    • 不符合第二範式表設計
    學號 姓名 系名 班主任 課名 分數
    001 張三 古文系 李白 文言文 89
    001 張三 古文系 李白 古詩詞 78
    001 張三 古文系 李白 現代漢語 65
    002 李四 古文系 李白 文言文 45
    002 李四 古文系 李白 古詩詞 78
    002 李四 古文系 李白 甲骨文 98
    003 王五 數學系 牛頓 高等數學 88
    003 王五 數學系 牛頓 數學基礎 88

    如上表格不符合第二範式,比如:這張表主鍵(學號,課名),分數完全依賴於(學號和課名),但是姓名並不完全依賴於(學號和課名)

    • 符合第二範式表設計
    學號 課名 分數
    001 文言文 89
    001 古詩詞 78
    001 現代漢語 65
    002 文言文 45
    002 古詩詞 78
    002 甲骨文 98
    003 高等數學 88
    003 數學基礎 88
    學號 姓名 系名 班主任
    001 張三 古文系 李白
    002 李四 古文系 李白
    003 王五 數學系 牛頓
    2.7.2.3 第三範式:不能存在”傳遞函數依賴”
    • 不符合第三範式表設計
    學號 姓名 系名 班主任
    001 張三 古文系 李白
    002 李四 古文系 李白
    003 王五 數學系 牛頓

    如上表格不符合第三範式,比如:學號–>系名–>系主任,但是系主任推不出學號

    • 符合第三範式表設計
    學號 姓名 系名
    001 張三 古文系
    002 李四 古文系
    003 王五 數學系
    系名 班主任
    古文系 李白
    古文系 李白
    數學系 牛頓

    2.8 OLAP典型架構

    OLAP有多種實現方法,根據存儲數據的方式不同可以分為ROLAP、MOLAP、HOLAP

    名稱 描述 細節數據存儲位置 聚合后的數據存儲位置
    ROLAP(Relational OLAP) 基於關係數據庫的OLAP實現 關係型數據庫 關係型數據庫
    MOLAP(Multidimensional OLAP) 基於多維數據組織的OLAP實現 數據立方體 數據立方體
    HOLAP(Hybrid OLAP) 基於混合數據組織的OLAP實現 關係型數據庫 數據立方體
    1. ROLAP(Relational Online Analytical Processing)

    ROLAP架構並不會生成實際的多維數據集,而是使用雪花模式以及多個關係表對數據立方體進行模擬,它的OLAP引擎就是將用戶的OLAP操作,如上鑽下鑽過濾合併等,轉換成SQL語句提交到數據庫中執行,並且提供聚集導航功能,根據用戶操作的維度和度量將SQL查詢定位到最粗粒度的事實表上去

    這種架構下的查詢沒有MOLAP快速。因為ROLAP中,所有的查詢都是被轉換為SQL語句執行的。而這些SQL語句的執行會涉及到多個表之間的JOIN操作,沒有MOLAP速度快,往往都是通過內存計算實現。(內存的昂貴大家是知道的)

    1. MOLAP(Multidimensional Online Analytical Processing)

    MOLAP架構會生成一個新的多維數據集,也可以說是構建了一個實際數據立方體。事先將匯總數據計算好,存放在自己特定的多維數據庫中,用戶的OLAP操作可以直接映射到多維數據庫的訪問,不通過SQL訪問。(空間換時間,典型代表Kylin)

    在該立方體中,每一格對應一個直接地址,且常用的查詢已被預先計算好。因此每次的查詢都是非常快速的,但是由於立方體的更新比較慢,所以是否使用這種架構得具體問題具體分析。

    1. HOLAP(Hybrid Online Analytical Processing)

    這種架構綜合參考MOLAP和ROLAP而採用一種混合解決方案,將某些需要特別提速的查詢放到MOLAP引擎,其他查詢則調用ROLAP引擎。上述MOLAP和ROLAP的結合。它提供了更大的靈活度,MOLAP提供提供了更加快速的響應速度。但是帶來的問題是,數據裝載的效率非常低,因為其實就是將多維的數據預先填好,但是隨着數據量過大維度成本越高,容易引起“數據爆炸”。

    2.9 OLAP數據立方體(Data Cube)

    OLAP(online analytical processing)是一種軟件技術,它使分析人員能夠迅速、一致、交互地從各個方面觀察信息,以達到深入理解數據的目的。從各方面觀察信息,也就是從不同的維度分析數據,因此OLAP也稱為多維分析

    很多年前,當我們要手工從一堆數據中提取信息時,我們會分析一堆數據報告。通常這些數據報告採用二維表示,是行與列組成的二維表格。但在真實世界里我們分析數據的角度很可能有多個,數據立方體可以理解為就是維度擴展后的二維表格。下圖展示了一個三維數據立方體:

    更多時候數據立方體是N維的。它的實現有兩種方式。其中星形模式就是其中一種,該模式其實是一種連接關係表與數據立方體的橋樑。但對於大多數純OLAP使用者來講,數據分析的對象就是這個邏輯概念上的數據立方體,其具體實現不用深究。對於這些OLAP工具的使用者來講,基本用法是首先配置好維表、事實表,然後在每次查詢的時候告訴OLAP需要展示的維度和事實字段和操作類型即可。

    最常見的五大操作:切片,切塊,旋轉,上卷,下鑽。

    2.9.1 切片和切塊(Slice and Dice)

    在數據立方體的某一維度上選定一個維成員的操作叫切片,而對兩個或多個維執行選擇則叫做切塊。下圖邏輯上展示了切片和切塊操作:

    2.9.2 旋轉(Pivot)

    旋轉就是指改變報表或頁面的展示方向。對於使用者來說,就是個視圖操作,而從SQL模擬語句的角度來說,就是改變SELECT後面字段的順序而已。下圖邏輯上展示了旋轉操作:

    2.9.3 上卷和下鑽(Rol-up and Drill-down)

    上卷可以理解為”無視”某些維度;下鑽則是指將某些維度進行細分。下圖邏輯上展示了上卷和下鑽操作:

    2.9.4 Cube 和 Cuboid

    Cube(或 Data Cube),即數據立方體,是一種常用於數據分析與索引的技術;它可以對原始數據建立多維度索引。通過 Cube 對數據進行分析,可以大大加快數據的查詢效率。

    Cuboid 特指在某一種維度組合下所計算的數據。 給定一個數據模型,我們可以對其上的所有維度進行組合。對於 N 個維度來說,組合的所有可能性共有 2 的 N 次方種。對於每一種維度的組合,將度量做 聚合運算,然後將運算的結果保存為一個物化視圖,稱為 Cuboid。

    所有維度組合的 Cuboid 作為一個整體,被稱為 Cube。所以簡單來說,一個 Cube 就是許多按維度聚合的物化視圖的集合。

    下面來列舉一個具體的例子:

    假定有一個電商的銷售數據集,其中維度包括 時間(Time)、商品(Item)、地點(Location)和供應商(Supplier),度量為銷售額(GMV)。

    • 那麼所有維度的組合就有 2 的 4 次方 =16 種
      • 一維度(1D) 的組合有[Time]、[Item]、[Location]、[Supplier]4 種
      • 二維度(2D)的組合 有[Time,Item]、[Time,Location]、[Time、Supplier]、[Item,Location]、 [Item,Supplier]、[Location,Supplier]6 種
      • 三維度(3D)的組合也有 4 種
      • 零維度(0D)的組合有 1 種
      • 四維度(4D)的組合有 1 種

    3 數據倉庫的演進

    4 數據倉庫主要用途

    大家應該已經意識到這個問題:既然分析型數據庫中的操作都是查詢,因此也就不需要嚴格滿足完整性/參照性約束以及範式設計要求,而這些卻正是分析型數據庫精華所在。這樣的情況下再將它歸為數據庫會很容易引起大家混淆,畢竟在絕大多數人心裏數據庫是可以關係型數據庫畫上等號的。

    • 那麼為什麼不幹脆叫”面向分析的存儲系統”呢?

    這就是關於數據倉庫最貼切的定義了。事實上數據倉庫不應讓傳統關係數據庫來實現,因為關係數據庫最少也要求滿足第1範式,而數據倉庫里的關係表可以不滿足第1範式。也就是說,同樣的記錄在一個關係表裡可以出現N次。但由於大多數數據倉庫內的表的統計分析還是用SQL,因此很多人把它和關係數據庫搞混了。

    4.1 支持數據提取

    數據提取可以支撐來自企業各業務部門的數據需求。

    由之前的不同業務部門給不同業務系統提需求轉變為不同業務系統統一給數據倉庫提需求,避免煙囪式開發

    4.2 支持報表系統

    基於企業的數據倉庫,向上支撐企業的各部門的統計報表需求,輔助支撐企業日常運營決策。

    4.3 支持數據分析

    從許多來自不同的企業業務系統的數據中提取出有用的數據並進行清理,以保證數據的正確性,然後經過抽取、轉換和裝載,即ETL過程,合併到一個企業級的數據倉庫里,從而得到企業數據的一個全局視圖;

    在此基礎上利用合適的查詢和分析工具、數據挖掘工具、OLAP工具等對其進行分析和處理(這時信息變為輔助決策的知識);

    最後將知識呈現給管理者,為管理者的決策過程提供支持 。

    4.4 支持數據挖掘

    數據挖掘也稱為數據庫知識發現(Knowledge Discovery in Databases, KDD),就是將高級智能計算技術應用於大量數據中,讓計算機在有人或無人指導的情況下從海量數據中發現潛在的,有用的模式(也叫知識)。

    Jiawei Han在《數據挖掘概念與技術》一書中對數據挖掘的定義:數據挖掘是從大量數據中挖掘有趣模式和知識的過程,數據源包括數據庫、數據倉庫、Web、其他信息存儲庫或動態地流入系統的數據。

    4.5 支持數據應用

    物聯網基於位置數據的旅遊客流分析及人群畫像

    通信基於位置數據的人流監控和預警

    銀行基於用戶交易數據的金融畫像應用

    電商根據用戶瀏覽和購買行為的用戶標籤體系及推薦系統

    徵信機構根據用戶信用記錄的信用評估

    出行基於位置數據的車流量分析,調度預測

    5 數據集市

    數據集市可以理解為是一種”小型數據倉庫”,它只包含單個主題,且關注範圍也非全局。

    數據集市可以分為兩種,一種是獨立數據集市(independent data mart),這類數據集市有自己的源數據庫和ETL架構;另一種是非獨立數據集市(dependent data mart),這種數據集市沒有自己的源系統,它的數據來自數據倉庫。當用戶或者應用程序不需要/不必要/不允許用到整個數據倉庫的數據時,非獨立數據集市就可以簡單為用戶提供一個數據倉庫的”子集”。

    • 簡單理解:
      • 數據集市:部門級別的數據倉庫,能為某個局部範圍內的管理人員提供服務。
      • 數據倉庫:企業級別的數據倉庫,能為企業各個部門的運行提供決策支持。

    6 建模的基本概念

    6.1 關係建模

    上圖為web應用中的一個建模片段,遵循三範式建模,可以看出,較為鬆散、零碎, 物理表數量多,而數據冗餘程度低。由於數據分佈於眾多的表中,這些數據可以更為靈活地 被應用,功能性較強。關係模型主要應用與 OLTP 系統中,為了保證數據的一致性以及避免 冗餘,所以大部分業務系統的表都是遵循第三範式的。

    6.2 維度建模

    維度建模(dimensional modeling)是專門用於分析型數據庫、數據倉庫、數據集市建模的方法

    上圖為維度模型建模片段,主要應用於 OLAP 系統中,通常以某一個事實表為中心進行表的 組織,主要面向業務,特徵是可能存在數據的冗餘,但是能方便的得到數據。

    關係模型雖然冗餘少,但是在大規模數據,跨表分析統計查詢過程中,會造成多表關聯,這會大大降低執行效率。所以通常我們採用維度模型建模,把相關各種表整理成兩種: 事實表和維度表兩種

    6.3 維度建模的三種模式

    1. 星形模式

    星形模式(Star Schema)是最常用的維度建模方式

    可以看出,星形模式的維度建模由一個事實表和一組維表成,且具有以下特點:

    1. 維表只和事實表關聯,維表之間沒有關聯;
    2. 每個維表的主碼為單列,且該主碼放置在事實表中,作為兩邊連接的邏輯外鍵;
    3. 以事實表為核心,維表圍繞核心呈星形分佈;
    1. 雪花模式

    雪花模式(Snowflake Schema)是對星形模式的擴展,每個維表可繼續向外連接多個子維表。(三範式代表作)

    星形模式中的維表相對雪花模式來說要大,而且不滿足規範化設計。雪花模型相當於將星形模式的大維表拆分成小維表,滿足了規範化設計。然而這種模式在實際應用中很少見,因為這樣做會導致開發難度增大,而數據冗餘問題在數據倉庫里並不嚴重。

    1. 星座模式

    星座模式(Fact Constellations Schema)也是星型模式的擴展。

    前面兩種維度建模方法都是多維表對應單事實表,但在很多時候維度空間內的事實表不止一個,而一個維表也可能被多個事實表用到。在業務發展後期,星座模式將作為最主要的維度建模。

    6.4 維度表和事實表

    1. 維度表(dimension)

    表示對分析主題所屬類型的描述。比如”昨天早上張三在京東花費200元購買了一個皮包”。那麼以購買為主題進行分析,可從這段信息中提取三個維度:時間維度(昨天早上),地點維度(京東), 商品維度(皮包)。通常來說維度表信息比較固定,且數據量小。

    1. 事實表(fact table)

    表示對分析主題的度量。比如上面那個例子中,200元就是事實信息。事實表包含了與各維度表相關聯的邏輯外鍵,並通過JOIN方式與維度表關聯。事實表的度量通常是數值類型,且記錄數會不斷增加,表規模迅速增長。

    1. 事實維度舉例

    昨天我去菜市場買了一隻蝙蝠,然後我就被隔離了。

    • 事實:訂單==>買蝙蝠這個事

    • 維度:

      • 時間==>昨天
      • 用戶==>我
      • 商品==>蝙蝠
      • 地理==>菜市場

    6.4.1 維度表

    維度表:一般是對事實的描述信息。每一張維表對應現實世界中的一個對象或者概念。 例如:用戶、商品、日期、地區等。

    常用於一個客觀世界的維度描述,往往列比較多。

    審視數據的角度

    • 維表的特徵:
      • 維表的範圍很寬(具有多個屬性、列比較多)
      • 跟事實表相比,行數相對較小:通常< 10 萬條
      • 靜態表示的,名詞性質的表

    6.4.2 事實表

    事實表用於正確的記錄既定的已經發生的事實,常用於存儲ID和度量值,各種維度外鍵

    事實表中的每行數據代表一個業務事件(下單、支付、退款、評價等)。“事實”這 個術語表示的是業務事件的度量值(可統計次數、個數、件數、金額等),例如,訂單事件中的下單金額。

    每一個事實表的行包括:具有可加性的數值型的度量值、與維表相連接的外鍵、通常具 有兩個和兩個以上的外鍵、外鍵之間表示維表之間多對多的關係。

    • 事實表的特徵:
      • 非常的大
      • 內容相對的窄:列數較少
      • 經常發生變化,每天會新增加很多
      • 動態表示的,動詞性質的表
    1. 事務型事實表(每天導入新增)
      • 以每個事務或事件為單位,例如一個銷售訂單記錄,一筆支付記錄等,作為事實表裡的 一行數據。一旦事務被提交,事實表數據被插入,數據就不再進行更改,其更新方式為增量 更新
    2. 周期型快照事實表(每日全量)
      • 周期型快照事實表中不會保留所有數據,只保留固定時間間隔的數據,例如每天或者 每月的銷售額,或每月的賬戶餘額等
    3. 累積型快照事實表(每天導入新增及變化)
      • 累計快照事實表用於跟蹤業務事實的變化。例如,數據倉庫中可能需要累積或者存儲 訂單從下訂單開始,到訂單商品被打包、運輸、和簽收的各個業務階段的時間點數據來跟蹤 訂單聲明周期的進展情況。當這個業務過程進行時,事實表的記錄也要不斷更新。

    6.5 數據分層

    • 為什麼分層:
      • 簡單化:把複雜的任務分解為多層來完成,每層處理各自的任務,方便定位問題。
      • 減少重複開發:規範數據分層,通過中間層數據,能夠極大的減少重複計算,增加結果復用性。
      • 隔離數據:不論是數據異常還是數據敏感性,使真實數據和統計數據解耦。

    下面列舉常見電商表的分層結構

    6.5.1 ODS層

    • 保持數據原貌不做任何修改,起到備份數據的作用。
    • 數據採用壓縮,減少磁盤存儲空間(例如:原始數據 100G,可以壓縮到 10G 左 右)
    • 創建分區表,防止後續的全表掃描

    6.5.2 DWD層

    DWD 層需構建維度模型,一般採用星型模型,呈現的狀態一般為星座模型。

    • 維度建模一般按照四個步驟: 選擇業務過程→聲明粒度→確認維度→確認事實

    • 選擇業務過程

      • 在業務系統中,挑選我們感興趣的業務線,比如下單業務,支付業務,退款業務,物流 業務,一條業務線對應一張事實表。
    • 聲明粒度

      • 數據粒度指數據倉庫的數據中保存數據的細化程度或綜合程度的級別。

      • 聲明粒度意味着精確定義事實表中的一行數據表示什麼,應該盡可能選擇最小粒度,以 此來應各種各樣的需求。

      • 典型的粒度聲明如下:

        • 訂單中,每個商品項作為下單事實表中的一行,粒度為每次下單
        • 每周的訂單次數作為一行,粒度就是每周下單。
        • 每月的訂單次數作為一行,粒度就是每月下單
    • 確定維度

      • 維度的主要作用是描述業務是事實,主要表示的是“誰,何處,何時”等信息。
    • 確定事實

      • 此處的“事實”一詞,指的是業務中的度量值,例如訂單金額、下單次數等。
      • 在 DWD 層,以業務過程為建模驅動,基於每個具體業務過程的特點,構建最細粒度的 明細層事實表。事實表可做適當的寬表化處理。
    事實/維度 時間 用戶 地區 商品 優惠卷 活動 編碼 度量
    訂單 件數/金額
    訂單詳情 件數/金額
    支付 次數/金額
    加入購物車 件數/金額
    收藏 個數
    評價 個數
    退款 件數/金額
    優惠卷領用 個數

    6.5.3 DWS層

    • 統計各個主題對象的當天行為,服務於 DWT 層的主題寬表,以及一些業務明細數據, 應對特殊需求(例如,購買行為,統計商品復購率)。

    6.5.4 DWT層

    • 以分析的主題對象為建模驅動,基於上層的應用和產品的指標需求,構建主題對象的全 量寬表。(就是按照維度來決定分析者的角度,如用戶->什麼時間->下了什麼單,支付了什麼,加入購物車了什麼)

    6.5.5 ADS層

    對系統各大主題指標分別進行分析。

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

    網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    ※想知道最厲害的網頁設計公司"嚨底家"!

    ※別再煩惱如何寫文案,掌握八大原則!

    ※產品缺大量曝光嗎?你需要的是一流包裝設計!

  • JPS/JPS+ 尋路算法

    JPS/JPS+ 尋路算法

    目錄

    • 概念
      • 強迫鄰居(Forced Neighbour)
      • 跳點(Jump Point)
    • JPS 尋路算法(Jump Point Search)
      • 實現原理
      • 示例過程
    • JPS+(Jump Point Search Plus)
      • 預處理
      • 示例過程
    • 總結
    • 參考

    概念

    JPS(jump point search)算法實際上是對A* 尋路算法的一個改進,因此在閱讀本文之前需要先了解A*算法。A* 算法在擴展節點時會把節點所有鄰居都考慮進去,這樣openlist中點的數量會很多,搜索效率較慢。

    若不了解A*算法,可以參考博主以前寫的一篇文章 A* 尋路算法 – KillerAery – 博客園

    例如在無遮擋情況下(往往會有多條等價路徑),而我們希望起點到終點實際只取其中一條路徑,而該路徑外其它節點可以沒必要放入openlist(不希望加入沒必要的鄰居)。

    其次我們還希望直線方向上中途的點不用放入openlist,如果只放入每段直線子路徑的起點和終點,那openlist又可以少放很多沒必要的節點:

    可以看到 JPS 算法搜到的節點總是“跳躍性”的,這是因為這些關鍵性的節點都是需要改變行走方向的拐點,因此這也是 Jump Point 命名的來歷。

    在介紹JPS等算法具體實現前,我們必須先掌握下面的概念。

    強迫鄰居(Forced Neighbour)

    強迫鄰居:節點 x 的8個鄰居中有障礙,且 x 的父節點 p 經過x 到達 n 的距離代價比不經過 x 到達的 n 的任意路徑的距離代價小,則稱 n 是 x 的強迫鄰居。

    看定義也許十分晦澀難懂。直觀來說,實際就是因為前進方向(父節點到 x 節點的方向為前進方向)的某一邊的靠後位置有障礙物,因此想要到該邊靠前的空位有最短的路徑,就必須得經過過 x 節點。

    可能的情況見圖示,黑色為障礙,紅圈即為強迫鄰居:

    (左圖為直線方向情況下的強迫鄰居,右圖為斜方向情況下的強迫鄰居)

    跳點(Jump Point)

    跳點:當前點 x 滿足以下三個條件之一:

    • 節點 x 是起點/終點。
    • 節點 x 至少有一個強迫鄰居。
    • 如果父節點在斜方向(意味着這是斜向搜索),節點x的水平或垂直方向上有滿足條件a,b的點。

    節點y的水平或垂直方向是斜向向量的拆解,比如向量d=(1,1),那麼水平方向則是(1,0),並不會往左搜索,只會看右邊,如果向量d=(-1,-1),那麼水平方向是(-1,0),只會搜索左邊,不看右邊,其他同理。

    下圖舉個例子,由於黃色節點的父節點是在斜方向,其對應分解成向上和向右兩個方向,因為在右方向發現一個藍色跳點,因此黃色節點也應被判斷為跳點:

    JPS 尋路算法(Jump Point Search)

    實現原理

    JPS 算法和A* 算法非常相似,步驟大概如下:

    1. openlist取一個權值最低的節點,然後開始搜索。(這些和A*是一樣的)
    2. 搜索時,先進行 直線搜索(4/8個方向,跳躍搜索),然後再 斜向搜索(4個方向,只搜索一步)。如果期間某個方向搜索到跳點或者碰到障礙(或邊界),則當前方向完成搜索,若有搜到跳點就添加進openlist。

    跳躍搜索是指沿直線方向一直搜下去(可能會搜到很多格),直到搜到跳點或者障礙(邊界)。一開始從起點搜索,會有4個直線方向(上下左右),要是4個斜方向都前進了一步,此時直線方向會有8個。

    1. 若斜方向沒完成搜索,則斜方向前進一步,重複上述過程。

    因為直線方向是跳躍式搜索,所以總是能完成搜索。

    1. 若所有方向已完成搜索,則認為當前節點搜索完畢,將當前節點移除於openlist,加入closelist。
    2. 重複取openlist權值最低節點搜索,直到openlist為空或者找到終點。

    下面結合圖片更好說明過程2和3:首先我們從openlist取出綠色的節點,作為搜索的開始,先進行直線搜索,再斜向搜索,沒有找到任何跳點。

    斜方向前進一步后,重複直線搜索和斜向搜索過程,仍沒發現跳點。

    斜方向前進兩步后,重複直線搜索和斜向搜索過程,仍沒發現跳點。

    斜方向前進了三步后(假設當前位置為 x),在水平直線搜索上發現了一個跳點(紫色節點為強迫鄰居)。

    於是 x 也被判斷為跳點,添加進openlist。斜方向結束,綠色節點的搜索過程也就此結束,被移除於openlist,放入closelist。

    示例過程

    下面展示JPS算法更加完整的過程:
    假設起點為綠色節點,終點為紅色節點

    重複直線搜索和斜向搜索過程,斜方向前進了3步。在第3步判斷出黃色節點為跳點(依據是水平方向有其它跳點),將黃色跳點放入openlist,然後斜方向搜索完成,綠色節點移除於openlist,放入closelist。

    對openlist下一個權值最低的節點(即黃色節點)開啟搜索,在直線方向上發現了藍色節點為跳點(依據是紫色節點為強迫鄰居),類似地,放入openlist。

    由於斜方向還沒結束,繼續前進一步。最後一次直線搜索和斜向搜索都碰到了邊界,因此黃色節點搜索完成,移除於openlist,放入closelist。

    對openlist下一個權值最低的節點(原為藍色節點,下圖變為黃色節點)開啟搜索,直線搜索碰到邊界,斜向搜索無果。斜方繼續前進一步,仍然直線搜索碰到邊界,斜向搜索無果。

    由於斜方向還沒結束,繼續前進一步。

    最終在直線方向上發現了紅色節點為跳點,因此藍色節點先被判斷為跳點,只添加藍色節點進openlist。斜方向完成,黃色節點搜索完成。

    最後openlist取出的藍色節點開啟搜索,在水平方向上發現紅色節點,判斷為終點,算法完成。

    回憶起跳點的第三個判斷條件(如果父節點在斜方向,節點x的水平或垂直方向上有滿足條件a,b的點),會發現這個條件判斷是最複雜的。在尋路過程中,它使尋路多次在水平節點上搜到跳點,也只能先添加它本身。其次,這也是算法中需要使用到遞歸的地方,是JPS算法性能瓶頸所在。

    JPS+(Jump Point Search Plus)

    JPS+ 本質上也是 JPS尋路,只是加上了預處理來改進,從而使尋路更加快速。

    預處理

    我們首先對地圖每個節點進行跳點判斷,找出所有主要跳點:

    然後對每個節點進行跳點的直線可達性判斷,並記錄好跳點直線可達性:

    若可達還需記錄號跳點直線距離:

    類似地,我們對每個節點進行跳點斜向距離的記錄:

    剩餘各個方向如果不可到達跳點的數據記為0或負數距離。如果在對應的方向上移動1步后碰到障礙(或邊界)則記為0,如果移動n+1步後會碰到障礙(或邊界)的數據記為負數距離-n

    最後每個節點的8個方向都記錄完畢,我們便完成了JPS+的預處理過程:

    以上預處理過程需要有一個數據結構存儲地圖上每個格子8個方向距離碰撞或跳點的距離。

    示例過程

    做好了地圖的預處理之後,我們就可以使用JPS+算法了。大致思路與JPS算法相同,不過這次有了預處理的數據,我們可以更快的進行直線搜索斜向搜索

    在某個搜索方向上有:

    • 對於正數距離 n(意味着距離跳點 n 格),我們可以直接將n步遠的節點作為跳點添加進openlist
    • 對於0距離(意味着一步都不可移動),我們無需在該方向搜索;
    • 對於負數距離 -n(意味着距離邊界或障礙 n 格),我們直接將n步遠的節點進行一次跳點判斷(有可能滿足跳點的第三條件,不過得益於預處理的數據,這步也可以很快完成)。

    如下圖示,起始節點通過已記錄的向上距離,直接將3步遠的跳點添加進openlist,而不再像以前需要迭代三步(還每步都要判斷是否跳點):

    其它過程也是類似的:

    總結

    可以看到 JPS/JPS+ 算法里只有跳點才會被加入openlist里,排除了大量不必要的點,最後找出來的最短路徑也是由跳點組成。這也是 JPS/JPS+ 高效的主要原因。

    JPS

    • 絕大部分地圖,使用 JPS 算法都會比 A* 算法更快,內存佔用也更小(openlist里節點少了很多)。
    • JPS 在跳點判斷上,要盡可能避免遞歸的深度過大(或者期待一下以後出現避免遞歸的算法),否則在超大型的地圖裡遞歸判斷跳點可能會造成災難。
    • JPS 也可以用於動態變化的地圖,只是每次地圖改變都需要再進行一次 JPS 搜索。
    • JPS 天生擁有合併節點(亦或者說是在一條直線里移除中間不必要節點)的功能,但是仍存在一些可以繼續合併的地方。
    • JPS 只適用於 網格(grid)節點類型,不支持 Navmesh 或者路徑點(Way Point)。

    JPS+

    • JPS+ 相比 JPS 算法又是更快上一個檔次(特別是避免了過多層遞歸判斷跳點),內存佔用則是每個格子需要額外記錄8個方向的距離數據。
    • JPS+ 算法由於包含預處理過程,這讓它面對動態變化的地圖有天生的劣勢(幾乎是不可以接受動態地圖的),因此更適合用於靜態地圖。
    • JPS+ 預處理的複雜度為 \(O(n)\) ,n 代表地圖格子數。
    算法 性能 內存佔用 支持動態地圖 預處理 支持節點類型
    A* 中等 支持 網格、Navmesh、路徑點
    JPS 偏小 支持 網格
    JPS+ 非常快 中等 不支持 有,\(O(n)\) 網格

    綜上,JPS/JPS+ 是A*算法的優秀替代者,絕大部分情況下更快和更小的內存佔用已經足夠誘人。在GDC 2015 關於 JPS+ 算法的演講中,Steve Rabin 給出的數據甚至是比A* 算法快70~350倍。

    參考

    [1] 從頭理解JPS尋路算法 – 簡書 by ElephantKing

    [2] JPS+: Over 100x Faster than A* | GDC 2015

    [3] JPS+ with GoalBounding C++實現,和上面GDC2015的演講人是同一個人 Steve Rabin。

    [4] 一個在線可視化的JPS實現附說明 A Visual Explanation Of Jump Point Search

    [5] JPS 算法原作者論文 github Harabor, Daniel Damir, and Alban Grastien. “Online Graph Pruning for Pathfinding On Grid Maps.” AAAI. 2011.

    博主其它相關文章:
    遊戲AI 系列文章 – KillerAery – 博客園
    遊戲AI之路徑規劃 – KillerAery – 博客園

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

    ※別再煩惱如何寫文案,掌握八大原則!

    ※教你寫出一流的銷售文案?

    ※超省錢租車方案

    FB行銷專家,教你從零開始的技巧

  • 02 . Ansible高級用法(運維開發篇)

    02 . Ansible高級用法(運維開發篇)

    自動化任務簡介

    假設我們要在10台linux服務器上安裝一個nginx服務,手動是如何做的?

    # 第一步, ssh登錄NUM(1,n)服務器
    # 第二步,輸入對應服務器密碼
    # 第三步,執行命令: yum install nginx 循環操作n=10
    # 第四步,執行命令: service nginx start
    # 第五步,退出登錄
    

    自動化任務執行的意義

    # 意義一, 提升運維工作效率,減少一份工作成本
    # 意義二, 提高準確度.
    

    自動化任務執行的應用

    # 應用一, 批量命令執行
    # 應用二, 定時程序任務執行
    # 應用三, 批量程序應用服務安裝
    # 應用四, 批量配置文件同步
    # 應用五, 批量代碼部署
    

    ansible配置

    ansible是python中的一套模塊,系統中的一套自動化工具,可以用作系統管理,自動化命令等任務

    ansible優勢
    # 1.ansible是python中的一套完整的自動化執行任務模塊
    # 2.ansible的play_book模式,不用yaml配置,對於自動化任務執行一目瞭然.
    # 3.自動化場景支持豐富
    
    ansible配置文件
    1. inventory
    # 該參數表示資源清單inventory文件的位置,資源清單就是一些Ansible需要連接管理的主機列表  
    # inventory = /root/ansible/hosts
    
    2. library
    # Ansible的操作動作,無論是本地或遠程,都使用一小段代碼來執行,這小段代碼稱為模塊,這個library參數就是指向存放Ansible模塊的目錄  
    # library = /usr/share/ansible
    
    3. forks
    # 設置默認情況下Ansible最多能有多少個進程同時工作,默認設置最多5個進程并行處理。具體需要設置多少個,可以根據控制主機的性能和被管理節點的數量來確定。  
    # forks = 5
    
    4. sudo_user
    # 這是設置默認執行命令的用戶,也可以在playbook中重新設置這個參數
    # sudo_user = root
    # 注意: 新版本已經做了修改,如ansible2.4.1下已經為:
    # default_sudo_user = root
    
    5. remote_port
    # 這是指定連接被關節點的管理端口,默認是22,除非設置了特殊的SSH端口,不然這個參數是不需要被修改的
    # remote_port = 22
    
    6. host_key_checking
    # 這是設置是否檢查ssh主機的秘鑰,可以設置為True或者False
    # host_key_checking = False
    
    7. timeout
    # 這是設置ssh連接的超時間隔,單位是秒
    # timeout = 20
    
    8. log_path
    # ansible系統默認是不記錄日誌的,如果想把ansible系統的輸出記錄到指定地方,需要設置log_path來指定一個存儲Ansible日誌的文件
    
    9. private_key_file
    # 在使用ssh公鑰私鑰登錄系統時使用的秘鑰路徑
    # private_key_file=/path/to/file.pem
    
    ansible.cfg
    [defaults]
    inventory = /tmp/hosts
    forks = 5
    default_sudo_user = root
    remote_port = 22
    host_key_checking = Falsetimeout = 20
    log_path = /var/log/ansible.log
    #private_key_file=/tmp/file.pem
    

    ansible安裝

    # 1. 通過系統的方式,yum,apt,get等
    # 2. 通過python的方式
    
    
    # (推薦)python ./setup.py install 
    easy_install ansible
    pip install ansible	
    

    Ansible基礎操作

    當我們將Ansible安裝好以後,可以通過一些命令開始深入了解Ansible了.
    我們最先展示的並非那強大的集配置,部署,自動化於一身的playbook.而是如何初始化.

    遠程連接概述

    在我們開始前要先理解Ansible如何通過SSH與遠程服務器連接是很重要的.
    Ansible1.3及之後的版本默認會在本地的OpenSSH可用時會嘗試用其遠程通訊,這會啟用ControlPersist(一個性能特性),Kerberos,和在~/.ssh/config中的配置選項如 Jump Host setup.然而,當你使用Linux企業版6作為主控機(紅帽企業版及其衍生版如CentOS),其OpenSSH版本可能過於老舊無法支持ControIPersist,在這些操作系統中,Ansible將會退回並採用paramiko(由Python實現的高質量OpenSSH庫).如果你希望能夠使用像是Kerberized SSH之類的特性,煩請考慮使用Fedora,OS X,或Ubuntu作為你的主控機直到相關平台上有更新版本的OpenSSH可供使用,或者啟用Ansible的”accelerated mode”.

    在Ansible1.2及之前的版本,默認將會使用paramiko,本地OpenSSH必須通過-c ssh或者配置文件中設定.

    我們偶爾會遇到不支持SFTP的設備,雖然很少見,但有概率中獎,可以通過ansible配置文件切換至scp模式來與之連接.

    說起遠程設備,Ansible會默認假定你使用SSH key(當然也推薦這種)但是密碼一樣可以,通過在需要的地方添加-ask-pass選項來啟用密碼驗證,如果使用了sudo特性,當sudo需要密碼時,也同樣適當的提供了-ask-sudo-pass選項.

    也許這是常識,但也值得分享:任何管理系統受益於被管理的機器在主控機附近運行.如果在雲中運行,可以考慮在使用雲中的一台機器來運行Ansible.

    作為一個進階話題,Ansible不止支持SSH來遠程連接.連接方式是插件化的而且還有許多本地化管理的選項諸如管理 chroot, lxc, 和 jail containers.一個叫做‘ansible-pull’的模式能夠反轉主控關係並使遠程系統通過定期從中央git目錄檢出 並 拉取 配置指令來實現背景連接通信

    第一條命令(公鑰認證)

    我們已經安裝ansible了,第一件事就是編輯或者創建/etc/ansible/hosts並在其中加入一個或多個遠程系統,我們的public SSH key必須在這些系統的authorized_keys中.

    # 我們現在ansible控制機上主機名解析
    tail /etc/hosts
    127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
    ::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
    121.36.43.223	node1
    120.77.248.31	node2
    116.196.83.113	master
    
    # 將解析過的主機名放到ansible配置文件裏面
    tail -2 /etc/ansible/hosts 
    node1
    node2
    
    # ansible控制機生成公鑰並傳給需要被控制的機器上
    ssh-copy-id node1
    ssh-copy-id node2
    # 因為考慮到安全問題,會有主機秘鑰的檢查,但如果在內網非常信任的服務器就沒必要了.
    sed -i 's/# *StrictHostKeyChecking *ask/StrictHostKeyChecking no/g' /etc/ssh/ssh_config
    
    # 然後我們就可以執行第一條命令來查看能ping通控制的所有節點.
    ansible all -m ping
    node1 | SUCCESS => {
        "ansible_facts": {
            "discovered_interpreter_python": "/usr/bin/python"
        }, 
        "changed": false, 
        "ping": "pong"
    }
    node2 | SUCCESS => {
        "ansible_facts": {
            "discovered_interpreter_python": "/usr/bin/python"
        }, 
        "changed": false, 
        "ping": "pong"
    }
    

    Ansible會像SSH那樣試圖用你的當前用戶名來連接你的遠程機器.要覆寫遠程用戶名,只需使用’-u’參數. 如果你想訪問 sudo模式,這裏也有標識(flags)來實現:

    ansible all -m ping -u bruce
    
    ansible all -m ping -u bruce --sudo
    
    ansible all -m ping -u bruce --sudo --sudo-user batman
    

    (如果你碰巧想要使用其他sudo的實現方式,你可以通過修改Ansible的配置文件來實現.也可以通過傳遞標識給sudo(如-H)來設置.) 現在對你的所有節點運行一個命令:

    ansible all -a "/bin/echo hello"
    node1 | CHANGED | rc=0 >>
    hello
    
    node2 | CHANGED | rc=0 >>
    hello
    

    公鑰認證

    Ansible1.2.1及其之後的版本都會默認啟用公鑰認證

    如果有個主機重新安裝並在“known_hosts”中有了不同的key,這會提示一個錯誤信息直到被糾正為止.在使用Ansible時,你可能不想遇到這樣的情況:如果有個主機沒有在“known_hosts”中被初始化將會導致在交互使用Ansible或定時執行Ansible時對key信息的確認提示.

    如果你想禁用此項行為並明白其含義,你能夠通過編輯 /etc/ansible/ansible.cfg or ~/.ansible.cfg來實現:

    [defaults]
    host_key_checking = False
    

    同樣注意在paramiko 模式中 公鑰認證 相當的慢.因此,當使用這項特性時,切換至’SSH’是推薦做法.

    密碼認證

    因為我們接下來要將存取的密碼放到主機清單甚至存到Mysql裏面,我們可以裝一個ssh_pass

    apt-get install sshpass
    

    我們將之前的公鑰.ssh目錄都刪掉,主機名解析不用管.

    注意,刪除.ssh目錄過後記得關閉主機秘鑰檢查.

    tail -3 /etc/hosts
    121.36.43.223	node1
    120.77.248.31	node2
    116.196.83.113	master
    
    tail -2  /etc/ansible/hosts 
    node1
    node2
    
    ansible all -m ping -k
    # 並不是真的ping,只是檢查客戶端的22號端口是否提供工作.不指定用戶默認root用戶
    # -k 輸入密碼
    # -m 指定模塊
    SSH password: 
    node1 | SUCCESS => {
        "ansible_facts": {
            "discovered_interpreter_python": "/usr/bin/python"
        }, 
        "changed": false, 
        "ping": "pong"
    }
    node2 | SUCCESS => {
        "ansible_facts": {
            "discovered_interpreter_python": "/usr/bin/python"
        }, 
        "changed": false, 
        "ping": "pong"
    }
    # 如果不想指定用戶名和密碼,避免ansible每次執行到相應主機都會要求輸入密碼.
    tail -2 /etc/ansible/hosts 
    node1 ansible_ssh_user='root' ansible_ssh_pass='youmen'
    node2 ansible_ssh_user='root' ansible_ssh_pass='youmen'  ansible_ssh_port=22
    
    ansible all -m ping
    node1 | SUCCESS => {
        "ansible_facts": {
            "discovered_interpreter_python": "/usr/bin/python"
        }, 
        "changed": false, 
        "ping": "pong"
    }
    node2 | SUCCESS => {
        "ansible_facts": {
            "discovered_interpreter_python": "/usr/bin/python"
        }, 
        "changed": false, 
        "ping": "pong"
    }
    

    Ansible常用模塊

    常用模塊

    模塊名 作用 用例
    command 默認模塊 ansible webserver -a “/sbin/reboot” -f 10
    shell 執行shell命令 ansible test -m shell -a “echo $HOSTNAME”
    filetransfer 文件傳輸 ansible test -m copy -a “src=/etc/hosts dest=/tmp/hosts”
    managingpackages 管理軟件包 ansible test -m yum -a “name=nginx state=present”
    user and groups 用戶和組 ansible test -m user -a “name=jeson password=123456”
    Deploying 部署模塊 ansible test -m git -a “repo=https://github.com/iopsgroup/imoocc dest=/opt/iops version=HEAD”
    managingservices 服務管理 ansible test -m service -a “name=nginx state=started”
    BackgroundOperatiions 後台運行 ansible test -B 3600 -a “/usr/bin/running_operation –do-stuff”
    gatheringfacts 搜集系統信息 ansible test -m setup

    playbook

    playbook由YAML語言編寫,YAML參考了其他多種語言,包括: XML,C語言,Python,Perl以及电子郵件格式RFC2822,Clark Evans在2001年5月首次發表了這種語言,另外Ingy dt Net與Oren-Kiki也是這語言的共同設計者.

    playbook的優勢

    # 1. 功能比adhoc更全
    # 2. 控制好依賴
    # 3. 展現更直觀
    # 4. 持久使用
    

    ansible-playbook執行常用命令參數:

    執行方式:ansible-playbook playbook.yml [options]

     -u REMOTE_USER, --user=REMOTE_USER  
    # ssh 連接的用戶名
     -k, --ask-pass    
    # ssh登錄認證密碼
     -s, --sudo           
    # sudo 到root用戶,相當於Linux系統下的sudo命令
     -U SUDO_USER, --sudo-user=SUDO_USER    
    # sudo 到對應的用戶
     -K, --ask-sudo-pass     
    # 用戶的密碼(—sudo時使用)
     -T TIMEOUT, --timeout=TIMEOUT 
    # ssh 連接超時,默認 10 秒
     -C, --check      
    # 指定該參數后,執行 playbook 文件不會真正去執行,而是模擬執行一遍,然後輸出本次執行會對遠程主機造成的修改
    
     -e EXTRA_VARS, --extra-vars=EXTRA_VARS    
    # 設置額外的變量如:key=value 形式 或者 YAML or JSON,以空格分隔變量,或用多個-e
    
     -f FORKS, --forks=FORKS    
    # 進程併發處理,默認 5
     -i INVENTORY, --inventory-file=INVENTORY   
    # 指定 hosts 文件路徑,默認 default=/etc/ansible/hosts
     -l SUBSET, --limit=SUBSET    
    # 指定一個 pattern,對- hosts:匹配到的主機再過濾一次
     --list-hosts  
    # 只打印有哪些主機會執行這個 playbook 文件,不是實際執行該 playbook
     --list-tasks   
    # 列出該 playbook 中會被執行的 task
    
     --private-key=PRIVATE_KEY_FILE   
    # 私鑰路徑
     --step    
    # 同一時間只執行一個 task,每個 task 執行前都會提示確認一遍
     --syntax-check  
    # 只檢測 playbook 文件語法是否有問題,不會執行該 playbook 
     -t TAGS, --tags=TAGS   
    # 當 play 和 task 的 tag 為該參數指定的值時才執行,多個 tag 以逗號分隔
     --skip-tags=SKIP_TAGS   
    # 當 play 和 task 的 tag 不匹配該參數指定的值時,才執行
     -v, --verbose   
    # 輸出更詳細的執行過程信息,-vvv可得到所有執行過程信息。
    
    使用場景

    yaml語法

    1. playbook配置
    ---
    - hosts: 39.108.140.0
      remote_user: root
      vars:
       touch_file: youmen.file
      tasks:
      - name: touch file
        shell: "touch /tmp/{{touch_file}}"
    

    yaml主要由三個部分組成:

    > hosts部分:
    # 使用hosts指示使用哪個主機或主機組來運行下面的tasks,
    # 每個playbook都必須指定hosts,hosts也可以使用通配符格式。
    # 主機或主機組在inventory清單中指定,可以使用系統默認的/etc/ansible/hosts,
    # 也可以自己編輯,在運行的時候加上-i選項,指定清單的位置即可。
    # 在運行清單文件的時候,--list-hosts選項會显示那些主機將會參与執行task的過程中。
    
    > remote_user:指定遠端主機中的哪個用戶來登錄遠端系統,
    # 在遠端系統執行task的用戶,可以任意指定,也可以使用sudo,
    # 但是用戶必須要有執行相應task的權限。
    
    > tasks:指定遠端主機將要執行的一系列動作。tasks的核心為ansible的模塊,
    # 前面已經提到模塊的用法。tasks包含name和要執行的模塊,name是可選的,
    # 只是為了便於用戶閱讀,不過還是建議加上去,模塊是必須的,同時也要給予模塊相應的參數。
    

    執行

    ansible-playbook -i /tmp/hosts --list-hosts ./f1.yaml
    ansible-playbook ./f1.yaml
    
    # 執行結果返回
    # 紅色: 表示有task執行失敗或者提醒的信息
    # 黃色: 表示執行了且改變了遠程主機狀態
    # 綠色: 表示執行成功
    

    yaml語法和數據結構

    yaml語法

    YAML格式是類似於JSON的文件格式,以便於人理解和閱讀,同時便於書寫,首先學習了解一下YAML的格式,對我們後面書寫playbook很有幫助.
    以下為playbook常用到的YAML格式

    # 大小寫敏感
    # 使用縮緊表示層級關係(只能空格不能使用tab)
    # yaml文件以"---"作為文檔的開始
    # 在同一行中,#之後的內容表示註釋,類似於shell,python和ruby.
    # YAML中的列表元素以"-"開頭,然後緊跟着一個空格,後面為元素內容,就像這樣
    - apple
    - orange
    等價於JSON的這種格式
    [
     "apple",
     "orange"
    ]
    
    # 同一個列表中的元素應該保持相同的縮進,否則會被當做錯誤處理.
    # play中hosts,variables,roles,tasks等對象的表示方法都是鍵值中間以":"分割表示,":"後面還要增加一個空格.
    
    變量定義方式

    變量名可以為字母,数字以及下劃線

    playbook里的變量

     1. playbook的yaml文件中定義變量賦值
    > 2. --exxtra-vars執行參數賦給變量
    > 3. 在文件中定義變量
    > 4. 註冊變量
    
    # register關鍵字可以存儲指定命令的輸出結果到一個自定義的變量中.
    ---
    - hosts: database
      remote_user: root
      vars:
        touch_file: youmen_file
      tasks:
        - name: get date
          command: date
          register: date_output
        - name: touch
          shell: "touch /tmp/{{touch_file}}"
        - name: echo  date_output
          shell: "echo {{date_output.stdout}}>/tmp/{{touch_file}}"
    
    數據結構

    yaml支持的數據結構
    字典

    {name:jeson}
    

    列表

    - Apple
    - Mango
    - Orange
    

    純量: 数字,布爾,字符串

    條件判斷
    循環
    循環類型 關鍵字
    標準循環 with_items
    嵌套循環 with_nested
    遍歷字典 with_dict
    并行遍歷列表 with_together
    遍歷列表和索引 with_indexed_items
    遍歷文件列表的內容 with_file
    遍歷目錄文件 with_fileglog
    重試循環 until
    查找第一個匹配文件 with_first_found
    隨機選擇 with_random_choice
    在序列中循環 with_sequence

    條件循環語句復用

    種類一, 標準循環

    ---
    - hosts: nginx
      tasks:
      - name: add serveral users
        user: name={{ item.name }} state=present groups={{ item.groups }}
        with_items:
          - { name: 'testuser1',groups: 'wheel' }
          - { name: 'testuser2',groups: 'root'  }
    

    種類二, 遍歷字典

    ---
    - hosts: nginx
      remote_user: root
      tasks:
        - name: add serveral users
          user: name={{ item.key }} state=present groups={{ item.value }}
          with_dict:
            { 'testuser3':'wheel','testuser4':'root' }
    

    種類三, 遍歷目錄中內容

    ---
    - hosts: nginx
      remote_user: root
      tasks:
       - file: dest=/tmp/aa state=directory
       - copy: src={{ item }} dest=/tmp/bb owner=root mode=600
         with_fileglob:
           - aa/*n
    
    條件語句結合循環語句使用場景
    ---
    - hosts: nginx
      remote_user: root
      tasks:
        - debug: msg="{{ item.key }} is the winner"
          with_dict: {'jeson':{'english':60,'chinese':30},'tom':{'english':20,'chinese':30}}
          when: item.value.english >= 10
    
    異常

    異常處理和相關操作

    異常處理

    1.忽略錯誤

    默認會檢查命令和模塊的返回狀態,遇到錯誤就中斷playbook的執行
    加入參數: ignore_errors: yes
    Example

    - hosts: nginx
      remote_user: root
      tasks:
        - name: ignore false
          command: /bin/false
          ignore_errors: yes
        - name: touch a file
          file: path=/tmp/test22 state=touch mode=0700 owner=root group=root
    

    2. tags標籤處理

    ---
    - hosts: nginx
      remote_user: root
      tasks:
        - name: get process
          shell: touch /tmp/change_test2
          changed_when: false
    

    打標籤

    意義: 通過tags和任務對象進行捆綁,控制部分或者指定的task執行

    # 打標籤
    # 	對一個對象打一個標籤
    # 	對一個對象打多個標籤
    # 	打標籤的對象包括: 單個task任務,include對象,roles對象等.
    

    標籤使用

    -t : 執行指定的tag標籤任務
    --skip-tags: 執行 --skip-tags之外的標籤任務
    
    1. 自定義change狀態
    ---
    - hosts: nginx
      remote_user: root
      tasks:
        - name: get process
          shell: ps -ef |wc -l
          register: process_count
          failed_when: process_count > 3
        - name: touch a file
          file: path=/tmp/test1 state=touch mode=0700 owner=root group=root
    
    roles角色和場景演練

    使用roles角色
    include的用法

    include_tasks/include: 動態的包含tasks任務列表執行
    

    什麼是roles

    是一種利用在大型playbook中的劇本配置模式,在這自己特定結構

    為什麼需要用到roles

    和面向對象開發思想相似
    利用於大型的項目任務中,盡可能的將公共的任務,變量等內容獨立

    劇本結構和設計思路
    ansible官方網站的建議playbook劇本結構如下:

    production        # 正式環境的inventory文件
    staging           #測試環境用得inventory文件
    group_vars/  	  # 機器組的變量文件
          group1        
          group2
    host_vars/   	 #執行機器成員的變量
          hostname1     
          hostname2
    ================================================
    site.yml               # 主要的playbook劇本
    webservers.yml         # webserver類型服務所用的劇本
    dbservers.yml          # 數據庫類型的服務所用的劇本
    
    roles/
          webservers/        #webservers這個角色相關任務和自定義變量
               tasks/
                   main.yml
               handlers/
                   main.yml
               vars/            
                    main.yml
            dbservers/         #dbservers這個角色相關任務和定義變量
                ...
          common/       	  # 公共的
               tasks/        
                    main.yml    
               handlers/    
                    main.yml    # handlers file.
               vars/            # 角色所用到的變量
                    main.yml    # 
    ===============================================
          templates/    #
                ntp.conf.j2 # 模版文件
          files/        #   用於上傳存放文件的目錄
                bar.txt     
                foo.sh     
          meta/         # 角色的依賴
                main.yml   
    
    場景演練

    Nginx工程方式的編譯安裝

    # 劇本分解
    ansible.cfg
      - files		#	存放上傳文件
        - index.html
        - nginx    # 系統init中,控制nginx啟動腳本
        - nginx-1.12.2.tar.gz  # nginx的安裝包文件
    
    production	  # 線上的主機配置文件
    roles		  # roles角色執行
      - apache
      - common
         tasks
           main.yml
         vars
    	main.yml
        meta
        nginx
          - handlers   通過notify觸發
            main.yml
          - tasks
    	  - basic.yml
    	  - main.yml
    	 - nginx.yml
          - vars
    	= main.yml
        tasks
    
    staging			線下測試環境使用的主機配置文件
      - templates		模板(配置,html)
        - nginx1.conf	nginx的自定義conf文件
    webserver.yaml		web服務相關主執行文件
    

    Ansible的核心類介紹

    核心類 用途 所在的模塊路徑
    DataLoader 用於讀取yaml,json格式的文件 ansible.parsing.dataloader
    Play 存儲執行hosts的角色信息 ansible.playbook.play
    TaskQueueManager ansible底層用到的任務隊列 ansible.executor.task_queue_manager
    PlaybookExecutor 核心累執行playbook劇本 ansible.executor.playbook_executor
    CallbackBase 狀態回調,各種成功失敗的狀態 ansible.plugins.callback
    InventoryManager 用於導入inventory文件 ansible.inventory.manager
    VariableManager 用於存儲各類變量信息 ansible.vars.manager
    Host,Group 用於操作單個主機或者主機組信息 ansible.inventory.host
    InventoryManager

    用來管理主機和主機組信息

    from ansible.parsing.dataloader import DataLoader
    from ansible.inventory.manager import InventoryManager
    
    # InventoryManager類
    loader = DataLoader()
    InventoryManager(loader=loader,sources=['youmen_hosts'])
    
    # 1. 添加主機到指定主機組 add_host()  
    # 2. 查看主機組資源get_groups_dict()  
    # 3. 獲取指定的主機對象get_host()
    
    # VariableManager類
    # loader: 實例對象
    # inventory: 調用InventoryManager返回的實例對象.
    VariableManager(loader=loader,inventory=inventory)
    
    # 查看主機變量方法 get_vars()
    # 設置主機變量方法set_host_variable()
    # 添加擴展變量extra_vars
    
    ad-hoc模式調用場景

    ansible -m command -a "ls /tmp" testgroup -i /etc/ansible/hosts -f 5

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※別再煩惱如何寫文案,掌握八大原則!

    網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    ※超省錢租車方案

    ※教你寫出一流的銷售文案?

    網頁設計最專業,超強功能平台可客製化

  • 多線程實例——遍歷文件夾分割文件識別文件內容

    多線程實例——遍歷文件夾分割文件識別文件內容

    需求:遍歷文件夾下的所有pdf文件,對每個pdf文件根據二維碼進行分割,再對分割后的文件的內容進行識別。

    可以拆分為以下幾個關鍵方法:

    1.GetFileList方法:遍歷文件,獲取源文件動態數組(這裏假設3個文件夾,每個文件夾下有3個文件,則源文件個數為9),耗時忽略不計

     1 static List<string> GetFileList(string strFilefolder)
     2         {
     3             List<string> list_file = new List<string>();
     4 
     5             for (int i = 0; i <= 2; i++)
     6             {
     7                 for (int j = 0; j <= 2; j++)
     8                     list_file.Add("File" + i + j);
     9             }
    10 
    11             return list_file;
    12         }

    View Code

    2.SplitProcess方法:分割原始pdf文件,識別二維碼(假設耗時500ms),將一個pdf文件分割為N(這裏假設個數為6)個子文件

     1 static void SplitProcess(string sourcefile)
     2         {
     3             Console.WriteLine("SplitFile Start:" + sourcefile + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));            
     4             for (int i = 0; i <= 5; i++)
     5             {
     6                 //模擬分割單個文件的過程,花費500ms
     7                 Thread.Sleep(500);
     8                 string split_file = sourcefile + i;
     9                 Console.WriteLine("file ready:" + split_file + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
    10                 RecognizeProcess(split_file);
    11             }
    12             Console.WriteLine("SplitFile Completed:" + sourcefile + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));            
    13         }

    View Code

    3.RecognizeProcess方法:識別子文件的內容:加載識別庫,設置識別參數,截取識別區域圖像,圖像處理(如縮放,降噪,灰度轉換等),識別(假設耗時5000ms

    1 static void RecognizeProcess(string split_file)
    2         {
    3             //模擬識別的過程,花費5000ms
    4             Thread.Sleep(5000);
    5             Console.WriteLine("ocrFile Completed:" + split_file + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
    6         }

    View Code

    單線程處理:

     1 static void Main(string[] args)
     2         {
     3             Console.WriteLine("Enter Main" + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
     4             string strFilefolder = "";
     5             OcrProcess(strFilefolder);
     6             Console.WriteLine("Main Completed" + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
     7             Console.ReadKey();
     8         }
     9 
    10         static void OcrProcess(string strFilefolder)
    11         {            
    12             List<string> list_sourcefile = GetFileList(strFilefolder);
    13             list_sourcefile.ForEach((sourcefile) =>
    14             {
    15                 Console.WriteLine(sourcefile + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
    16                 //這裏對文件進行分割
    17                 SplitProcess(sourcefile);
    18             });            
    19         }

    View Code

    這個單線程處理的執行結果我們可以預估一下,應該大於 9 * 6 * (0.5 + 5) = 297 秒。

    實際結果:

     …… 

     開始時間 2020-06-17 15:22:28 6104 結束時間 2020-06-17 15:27:26 1541 

    由於是線性處理,整個過程耗費的時間約5分鐘,所以必須要進行優化,所以考慮用多線程來提高效率。

    優化方向:

    1.多線程,使用Task并行對源文件進行分割 

     1 static void OcrProcess(string strFilefolder)
     2         {
     3             List<Task> tasks = new List<Task>();  
     4             List<string> list_sourcefile = GetFileList(strFilefolder);
     5             list_sourcefile.ForEach((sourcefile) =>
     6             {
     7                 Task task = Task.Factory.StartNew( () =>
     8                 { 
     9                     Console.WriteLine(sourcefile + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
    10                     //這裏對文件進行分割
    11                     SplitProcess(sourcefile);
    12                 });
    13                 tasks.Add(task);                
    14             });
    15             Task.WaitAll(tasks.ToArray());
    16         }

    View Code

     ……

     

    開始時間 2020-06-17 15:51:54 5458 結束時間 2020-06-17 15:52:35 3144 

    整個過程耗費的時間約41秒,優化效果明顯。

    2.每分割出來一個文件,開啟子線程,進行識別

     1 static void SplitProcess(string sourcefile)
     2         {
     3             List<Task> tasks = new List<Task>();
     4             Console.WriteLine("SplitFile Start:" + sourcefile + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));            
     5             for (int i = 0; i <= 5; i++)
     6             {
     7                 //模擬分割單個文件的過程,花費500ms
     8                 Thread.Sleep(500);
     9                 string split_file = sourcefile + i;
    10                 Console.WriteLine("file ready:" + split_file + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
    11                 Task task = Task.Factory.StartNew(() =>
    12                 {
    13                     RecognizeProcess(split_file);
    14                 });
    15                 tasks.Add(task);
    16             }
    17             Task.WaitAll(tasks.ToArray());
    18             Console.WriteLine("SplitFile Completed:" + sourcefile + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));            
    19         }

    View Code

      ……

     開始時間 2020-06-17 15:58:59 2591 結束時間 2020-06-17 15:59:28 9051 

    整個過程耗費的時間約29秒,運行時間進一步縮短。 

    然而,最後再思考一下,如果把多線程發揮到極致,理想狀態應該是多少秒執行完畢?

    以源文件sourcefile=File00為例,

    第一個分割子文件split_file=File000,ReadyTime 500ms,Ocr Completed Time 應該為5500ms

    第二個分割子文件split_file=File001,ReadyTime 1000ms,Ocr Completed Time 應該為6000ms 

    第三個分割子文件split_file=File002,ReadyTime 1500ms,Ocr Completed Time 應該為6500ms 

    第四個分割子文件split_file=File003,ReadyTime 2000ms,Ocr Completed Time 應該為7000ms

    第五個分割子文件split_file=File004,ReadyTime 2500ms,Ocr Completed Time 應該為7500ms

    第六個分割子文件split_file=File005,ReadyTime 3000ms,Ocr Completed Time 應該為8000ms

    File00 Split Completed!

    每一個源文件(sourcefile)被逐個分割為6個拆分子文件(split_file)並識別完成,都需要8000ms時間,如果使用線程同步的話,那麼後續源文件也同步被分割並識別完成。 

    所以,理想情況下,應該是8秒,而與29秒差距太大了,應該還有優化空間!

    3.怎麼優化?向什麼方向優化?我們不妨不用Task,回歸到Thread本身來試試。

    可是Thread運行時沒有Task.WaitAll()這樣的控制方法,因此,我們還要引入WaitHandle和ManualResetEvent來進行多線程管理。 

     1 class Program
     2     {
     3         static void Main(string[] args)
     4         {
     5             Console.WriteLine("Enter Main" + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
     6             string strFilefolder = "";
     7             OcrProcess(strFilefolder);
     8             Console.WriteLine("Main Completed" + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
     9             Console.ReadKey();
    10         }        
    11 
    12         static void OcrProcess(string strFilefolder)
    13         {            
    14             List<ManualResetEvent> split_waits = new List<ManualResetEvent>();
    15             List<string> list_sourcefile = GetFileList(strFilefolder);
    16             list_sourcefile.ForEach((sourcefile) =>
    17             {
    18                 Thread m_thread = new Thread(() =>
    19                 {
    20                     ManualResetEvent mre = new ManualResetEvent(false);
    21                     split_waits.Add(mre);
    22                     Console.WriteLine(sourcefile + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
    23                     //這裏對文件進行分割
    24                     SplitProcess(sourcefile);
    25                     mre.Set();
    26                 });
    27                 m_thread.Start();
    28             });
    29             WaitHandle.WaitAll(split_waits.ToArray());
    30         }
    31 
    32         static void SplitProcess(string sourcefile)
    33         {
    34             Console.WriteLine("SplitFile Start:" + sourcefile + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
    35             var ocr_waits = new List<EventWaitHandle>();
    36             for (int i = 0; i <= 5; i++)
    37             {
    38                 //模擬分割單個文件的過程,花費500ms
    39                 Thread.Sleep(500);
    40                 string split_file = sourcefile + i;
    41                 Console.WriteLine("file ready:" + split_file + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
    42                 ManualResetEvent mre_child = new ManualResetEvent(false);
    43                 ocr_waits.Add(mre_child);
    44                 Thread m_child_thread = new Thread(() =>
    45                 {
    46                     Console.WriteLine("m_child_thread enter:" + split_file + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
    47                     RecognizeProcess(split_file);                    
    48                     mre_child.Set();
    49                     Console.WriteLine("m_child_thread after set:" + split_file + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
    50                 });
    51                 m_child_thread.Start();
    52             }
    53             WaitHandle.WaitAll(ocr_waits.ToArray());
    54             Console.WriteLine("SplitFile Completed:" + sourcefile + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));            
    55         }
    56 
    57         static void RecognizeProcess(string split_file)
    58         {
    59             //模擬識別的過程,花費5000ms
    60             Thread.Sleep(5000);
    61             Console.WriteLine("ocrFile Completed:" + split_file + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
    62         }
    63 
    64         static List<string> GetFileList(string strFilefolder)
    65         {
    66             List<string> list_file = new List<string>();
    67             for (int i = 0; i <= 2; i++)
    68             {
    69                 for (int j = 0; j <= 2; j++)
    70                     list_file.Add("File" + i + j);
    71             }
    72             return list_file;
    73         }
    74     }

    View Code

      

      ……

    開始時間 2020-06-17 15:28:17 2397 結束時間 2020-06-17 16:28:27 9151 

    整個過程耗費的時間約10秒,運行時間與理論的8秒已經十分接近(因為Thread創建以及運行時需要切換上下文,Console.WriteLine都有一定的耗時,PC性能好的話應該更接近8秒),可以說目標已經達成。 

    Tips:

    ManualResetEvent初始狀態為false表示不將線程信號量初始值置為signal,線程會自動往下執行,執行Set()方法時,將線程信號量置為signal。

    WaitHandle.WaitAll(split_waithandle1,split_waithandle2); //一直等待,直到split_waithandle1,split_waithandle2信號量均被置為signal才會往下執行。

    不足之處:

    開啟Thread要受到系統的限制,所以本例線程數必須考慮操作系統線程最大值限制。

     

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※教你寫出一流的銷售文案?

    ※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

    ※回頭車貨運收費標準

    ※別再煩惱如何寫文案,掌握八大原則!

    ※超省錢租車方案

    ※產品缺大量曝光嗎?你需要的是一流包裝設計!

  • 印度學者:中國築壩正破壞喜馬拉雅生態

    摘錄自2018年8月27日中央社報導

    印度新德里政策研究中心戰略研究教授切拉尼(Brahma Chellaney)表示,喜馬拉雅生態系統日漸脆弱,雖然在這一地區大規模資源濫採的國家都應受到譴責,「但沒有一個國家像中國,對喜馬拉雅造成如此嚴重的破壞」。

    切拉尼撰文寫道,亞洲的未來與喜馬拉雅山的關係緊密,但人類卻大規模建設水壩且肆無忌憚地開採資源,破壞當地生態系統,其中中國透過築壩改造天然河流,卻有愈來愈多工程引水項目集中在國外,而非內部河流。以喜馬拉雅冰川地區來說,目前中國造壩已覆蓋近3/4的青藏高原。

    針對中國行徑,切拉尼還指出2點,一是中國想在青藏高原乾旱的北部和西北部製造人造雨,外界擔心此舉會吸走喜馬拉雅其他地區(西藏的降雨集中地)的水分;另一是中國大肆開發礦產資源,如開發銅礦的行動已汙染藏族的Pemako(隱藏的蓮花地)地區。

    本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※帶您來了解什麼是 USB CONNECTOR  ?

    ※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

    ※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!

    ※綠能、環保無空污,成為電動車最新代名詞,目前市場使用率逐漸普及化

    ※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

    ※教你寫出一流的銷售文案?

  • 載不動聖誕老人 瑞典夏季乾旱 部分馴鹿餓死

    環境資訊中心綜合外電;姜唯 編譯;林大利 審校

    本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※為什麼 USB CONNECTOR 是電子產業重要的元件?

    網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    ※台北網頁設計公司全省服務真心推薦

    ※想知道最厲害的網頁設計公司"嚨底家"!

    ※推薦評價好的iphone維修中心

  • 考量經濟 梅克爾反對歐盟拉高減碳目標

    摘錄自2018年8月27日中央社報導

    德國總理梅克爾今天(27日)表示,世界各地極端天候頻傳,充分證明氣候變遷已是事實。不過她反對為保護氣候拉高減少溫室氣體排放門檻,指此舉沒太大意義。

    路透社報導,北半球今夏的炙熱高溫,引發外界憂心氣候變遷的現象正加速發生,歐洲數十個國家都呼籲,減少溫室氣體排放量的速度,應要比原訂目標更快。

    歐洲聯盟(EU)執委會主管氣候行動與能源事務執委卡尼特(Miguel Arias Canete)呼籲將2030年之前溫室氣體減量目標,從40%提高至45%。

    但梅克爾(Angela Merkel)表示,加速減少有害的二氧化碳排放量恐適得其反,況且歐洲各國此際對達成原訂目標都很吃力,再要拉高門檻沒有道理。

    她說:「我對這些新提議尤其不怎麼高興。我認為應先堅守既定目標。我不認為一直設定新目標有任何意義。」

    本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

    台北網頁設計公司這麼多該如何選擇?

    ※智慧手機時代的來臨,RWD網頁設計為架站首選

    ※評比南投搬家公司費用收費行情懶人包大公開

    ※回頭車貨運收費標準

  • 德鐵挑戰氣候目標 2030年減碳50%、使用70%綠電

    環境資訊中心記者 陳文姿報導

    本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

    ※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

    南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

    ※教你寫出一流的銷售文案?

    ※超省錢租車方案

  • 世界水資源週上談淹水 WWF:自由流動的河很重要

    環境資訊中心綜合外電;姜唯 編譯;林大利 審校

    本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

    ※Google地圖已可更新顯示潭子電動車充電站設置地點!!

    ※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

    ※別再煩惱如何寫文案,掌握八大原則!

    網頁設計最專業,超強功能平台可客製化