標籤: 包裝設計

分類
發燒車訊

弗萊堡限定 建築節能標準 永遠走在最前面

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

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

【其他文章推薦】

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

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

※回頭車貨運收費標準

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

※超省錢租車方案

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

分類
發燒車訊

光陽 Ionex 車能網商業版正式登台，柯勝峯：下一步進軍印度市場

光陽工業（KYMCO）12 日正式在台發表 Ionex 車能網商業版，提供 4 大套裝方案，切入全球商用電動機車領域；董事長柯勝峯更宣布進軍印度這個全球最大二輪車市場，並且全面拓展中國市場。

隨著環保意識不斷提升，電動化成為現代交通工具最重要的轉變，有效落實城市永續經營的目標。其中，商用電動車扮演極為關鍵的角色，據統計全球約有 1.5 億輛機車，其中約 500 萬輛機車為商業用途，商用機車佔比雖低，但每日騎乘距離是一般機車的 7 倍，維修換車頻率則是一般機車的 2 倍，能源消耗佔比較整體機車多 2 成。因此採行電動車，能夠真正協助企業進行營運模式的發展與轉型。

Ionex 車能網商業版 4 套裝方案公開

Ionex 車能網商業版可針對任何企業或政府機構的特定需求，進行量身訂製並快速導入；主要向客戶提供「基礎設施」、「商用車隊」、「共享車輛」、「大眾運輸」4 個套裝方案，內容含括電動機車、抽取式電池、能源交換站、作業系統、管理軟體、手機 App 以及其他客製化服務等等，視需求做出調整，以展現 Ionex 車能網的系統彈性與發展能力：

  • 基礎設施套裝方案：提供欲建置能源基礎建設以對特定市場提供充電服務的企業或政府所設計。
  • 商用車隊套裝方案：為需要商用電動車隊的企業所設計，尤其適合具有配送服務的物流或零售等業者。
  • 共享車輛套裝方案：針對共享業者所設計，加速共享業者將電動車導入市場的時間。
  • 大眾運輸套裝方案：有效協助政府將共享電動車租賃服務導入大眾運輸網路，提升大眾運輸工具的使用率。

今日的發表會上更展示 2 款商用電動機車、以及 1 款電動輔助自行車。

進軍印度電動機車市場

目前在企業客戶方面，光陽已有大型零售的盒馬鮮生、車輛共享的騎電科技、能源服務的張飛充電；而在發展智慧城市，光陽與中國的江蘇常州市、福建寧德市、浙江衢州市、廣東深圳市合作。光陽更將在下週於印度首都新德里，正式宣布進軍印度市場，與當地的合作夥伴加速拓展 Ionex 車能網。

（合作媒體：。圖片來源：）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

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

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

分類
發燒車訊

光陽聯手印度電動車新創 22Motors，挺進世界最大機車市場

光陽（Kymco）日前宣布要進軍印度市場，現在揭曉將聯手印度電動車新創 22Motors。未來 22Motors 的 Flow scooter 車款將全面採用 Kymco Ionex 車能網，成為光陽插旗印度的夥伴。

2018 年以來電動機車市場就異常熱鬧，機車大廠光陽與 Gogoro 之間正面交鋒的態勢已經日漸明朗。雙方也各自找來友軍助陣，Gogoro 選擇和國產機車三雄之一的 Yamaha 結盟，光陽則在中國與阿里巴巴合作，如今又攜手印度的 22Motors。光陽這次與 22Motors 的合作也是著眼於印度政府在 2030 年前銷售新燃油車的調控政策，試圖在全球最大機車市場電動化的過程中搶得一席之地。

光陽指出印度新創電動車公司 22Motors 具有優異的技術能力，不僅解決了鋰離子電池開發和電池管理系統（BMS）等問題，還擁有高效率的快速充電系統，並開發 AI 和機器學習功能。光陽表示，在 3 月的 Ionex 東京發表會之後，22Motors 便前來積極接洽雙方的合作，打造一台會思考且有學習能力的 AI Scooter 智慧電動車。能夠跨足世界最大的機車市場無疑對光陽是一劑強心針，未來兩大陣營將會如何交手值得繼續觀察。

（合作媒體：。首圖來源：）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

※回頭車貨運收費標準

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

※超省錢租車方案

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

分類
發燒車訊

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

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

1 網絡詞彙總結

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

挑重點簡介

1.1 數據中台

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

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

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

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

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

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

1.1.1 數據倉庫（Data WareHouse）

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

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

  • 面向主題

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

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

例如，銀行的數據倉庫的主題：客戶

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

  • 集成

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

具體如下：

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

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

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

  • 非易失即相對穩定的

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

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

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

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

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

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

  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層

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

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

【其他文章推薦】

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

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

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

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

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

分類
發燒車訊

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

需求：遍歷文件夾下的所有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月29日中廣新聞報導

法國和英國漁民為了扇貝捕撈，累積已久的怨恨，瞬間爆發，總共幾十艘漁船，在英吉利海峽上，先是叫罵，丟擲物品，接著彼此衝撞，英國漁船因為數量不敵法國，落荒而逃。英國漁民現在要求政府派軍艦護漁。

英國與法國漁民在英吉利海峽因為扇貝捕撈，引發衝突，導致關係緊張，由來已久，五年前，雙方達成協議，英國同意不使用大型漁船作業，來換取更多的漁權。不過法國有休漁政策，英國沒有，法國漁船每年5月中到10月不能捕撈，英國漁船則全年都可以作業，法國漁民覺得不公平，更讓他們火大的是，英國捕獲的扇貝，大約三分之一出口，其中多數銷到法國。 

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

【其他文章推薦】

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

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

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

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

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

分類
發燒車訊

澳洲政壇川普化 總理因支持減碳下台

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

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

【其他文章推薦】

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

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

※回頭車貨運收費標準

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

※超省錢租車方案

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

分類
發燒車訊

中油布局綠能轉型， 3 年內將擴建千個充電站

  中油董事長戴謙在 5 日表示，中油必須轉型朝向綠能目標發展，所以規劃自明年起將編列 20 億元預算，來增設千座電動車充電站。   中油新任董事長戴謙其農牧專業曾被外界質疑是否為董座的合適人選，不過其認為作為南科管理局局長展現的績效可被檢驗。如今上任滿一個月，已決定要宣布中油未來的轉型計畫，將配合政府政策，限縮燃煤，推廣電動機車。目前 Gogoro 全台已有 475 座機車充電站，其中有 109 座是與中油合作。   據《經濟日報》報導，戴謙強調，國營企業當然要支持國家政策，況且如果將來電動機車數量增多了，那中油要加油站做什麼。所以他認為，中油要面對轉型問題，未來成為「中油綠能站」，不只提供化石燃料，也要經營綠能市場，符合社會趨勢。目前中油擬定的做法是要先響應經濟部工業局推廣電池交換站（充電站）計畫，從明年起三年內，要在全台加油站點同時布建一千座充（換）電站，給電動機車充電。   中油副總畢淑蒨也出面說明細節表示，此計畫將以 20 億元預算逐年進行建設，第一年 160 座，第二年 390 座，第三年 450 座等進度來完成，而充電站與交換電池站建設比例大約為 1：9。針對現階段實施地點，畢淑蒨表示，明年將啟動示範場域評估可行性，目前大都會區以及空汙較為嚴重地區會是優先選項，特別的是還包含離島澎湖，這是因為行政院希望能將其打造位智慧及綠能的觀光島。   戴謙表示，雖然如此，但民眾不用擔心未來不會真的沒油可加，中油加油站會先採「加油、加電」雙軌併行，等到真的全台灣全面改用電動汽機車後，再轉型成純加電站。他還強調，中油轉型其電力供應不能光靠台電，未來將藉由社區民眾的綠能設備把電力輸送至中油加油站點裝設的儲能裝置，讓中油轉型成為社區的充換電基載中心，扮演公民電廠、社區貯能的節點角色。   （合作媒體：。首圖來源：中油）    

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

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

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

※聚甘新

分類
發燒車訊

BMW攜手Solid Power押寶全固態電池

  德國豪華車廠BMW與美國全固態電池領航企業Solid Power周一（12/18）宣布結盟，將合作開發下一世代電動車電池技術。   Solid Power在聲明稿上表示，BMW將在先進技術方面給予協助指導，務求全固態電池效能跨越高性能電動車的要求門檻。   全固態電池具高能量密度，且安全性高，有望取代傳統的液態鋰電池，成為新世代電動車的動力來源。值得一提的是，全固態電池的續航力也是高人一等。   研發低成本、高效能電池，是目前各大電動車廠的當務之急。Solid Power說其可回充式固態電池可免除加諸在鋰電池的安全設施，達成降低成本的目的，BMW顯然也看到潛力可期。   （本文內容由授權使用。首圖為電動車用鋰電池示意圖，來源：Kokam）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

※回頭車貨運收費標準

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

※超省錢租車方案

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

※聚甘新

分類
發燒車訊

一起玩轉微服務（4）——如何實施微服務

一、如何實施微服務

微服務是一種架構的理念，提出了微服務的設計原則，從理論為具體的技術落地提供了指導思想。
實施微服務需要具備以下條件：

  • 計算和存儲資源能否快速的分配
  • 是否具備快速部署的能力，因為微服務每個服務都比較微小，所以不管是測試環境還是生產環境都需要快速部署的能力
  • 基本的監控，包括CPU、內存、網絡等
  • 標準化的RPC

Spring Boot 是一套快速配置腳手架，可以基於 Spring Boot 快速開發單個微服務。
Spring Cloud 是一個基於 Spring Boot 實現的服務治理工具包；Spring Boot 專註於快速、方便集成的單個微服務個體；Spring Cloud 關注全局的服務治理框架。
Spring Boot / Cloud 是微服務實踐的最佳落地方案。
當然，微服務的設計還對運維提出了更高的要求，如何進行自動構建，如何進行自動發布，對於應用程序的質量管理以及遇到峰值時如何通過橫向擴展、彈性伸縮對於整個技術團隊都提出了更高的要求。

二、最流行6種微服務RPC技術

 

 

 

 

開源 RPC 框架有哪些呢？

 

一類是跟某種特定語言平台綁定的，另一類是與語言無關即跨語言平台的。
跟語言平台綁定的開源 RPC 框架主要有下面幾種。

  • Dubbo：國內最早開源的 RPC 框架，由阿里巴巴公司開發並於 2011 年末對外開源，僅支持 Java 語言。
  • Motan：微博內部使用的 RPC 框架，於 2016 年對外開源，僅支持 Java 語言。
  • Tars：騰訊內部使用的 RPC 框架，於 2017 年對外開源，僅支持 C++ 語言。
  • Spring Cloud：國外 Pivotal 公司 2014 年對外開源的 RPC 框架，僅支持 Java 語言

而跨語言平台的開源 RPC 框架主要有以下幾種。

  • gRPC：Google 於 2015 年對外開源的跨語言 RPC 框架，支持多種語言。
  • Thrift：最初是由 Facebook 開發的內部系統跨語言的 RPC 框架，2007 年貢獻給了 Apache 基金，成為 Apache 開源項目之一，支持多種語言。

三、rest

1. 什麼是REST

REST是一種架構風格，指的是一組架構約束條件和原則。滿足這些約束條件和原則的應用程序或設計就是 RESTful。REST規範把所有內容都視為資源，網絡上一切皆資源。

REST並沒有創造新的技術，組件或服務，只是使用Web的現有特徵和能力。 可以完全通過HTTP協議實現，使用 HTTP 協議處理數據通信。REST架構對資源的操作包括獲取、創建、修改和刪除資源的操作正好對應HTTP協議提供的GET、POST、PUT和DELETE方法。

REST與RPC比較

比較項        規範 REST RPC
通信協議 HTTP 一般使用TCP
性能 低 高
靈活度 高 低

高與低是對實現兩種規範框架的相對比較，但也不是絕對的，需要根據實際情況而定。

都是網絡交互的協議規範。通常用於多個微服務之間的通信協議。

2. REST與RPC應用場景

REST和RPC都常用於微服務架構中。

  • HTTP相對更規範，更標準，更通用，無論哪種語言都支持http協議。如果你是對外開放API，例如開放平台，外部的編程語言多種多樣，你無法拒絕對每種語言的支持，現在開源中間件，基本最先支持的幾個協議都包含RESTful。

RPC在微服務中的作用，RPC 框架作為架構微服務化的基礎組件，它能大大降低架構微服務化的成本，提高調用方與服務提供方的研發效率，屏蔽跨進程調用函數（服務）的各類複雜細節。讓調用方感覺就像調用本地函數一樣調用遠端函數、讓服務提供方感覺就像實現一個本地函數一樣來實現服務。

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

【其他文章推薦】

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

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

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

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

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

※聚甘新