ETL，是英文 Extract-Transform-Load 的縮寫，用來描述将資料從來源端經過抽取(extract)、轉換(transform)、加載(load)至目的端的過程。ETL過程本質上是資料流動的過程，從不同的資料源流向不同的目标資料。
ETL的實作架構
但在資料倉庫中，ETL有幾個特點，
- 一是資料同步，它不是一次性倒完資料就拉到，它是經常性的活動，按照固定周期運作的，甚至現在還有人提出了實時ETL的概念。
- 二是資料量，一般都是巨大的，值得你将資料流動的過程拆分成E、T和L。
根據E、T、L三個步驟的實作環境，目前有ETL和ELT兩種架構。
ETL是建構資料倉庫的重要一環，使用者從資料源抽取出所需的資料，經過資料清洗,最終按照預先定義好的資料倉庫模型，将資料加載到資料倉庫中去。
ETL在轉化的過程中，主要展現在以下幾方面:
- 空值處理：可捕獲字段空值，進行加載或替換為其他含義資料，并可根據字段空值實作分流加載到不同目标庫。
- 規範化資料格式：可實作字段格式限制定義，對于資料源中時間、數值、字元等資料，可自定義加載格式。
- 拆分資料：依據業務需求對字段可進行分解。例，主叫号 861082585313-8148，可進行區域碼和電話号碼分解。
- 驗證資料正确性：可利用Lookup及拆分功能進行資料驗證。例如，主叫号861082585313-8148，進行區域碼和電話号碼分解後，可利用Lookup傳回主叫網關或交換機記載的主叫地區，進行資料驗證。
- 資料替換：對于因業務因素，可實作無效資料、缺失資料的替換。
- Lookup：查獲丢失資料 Lookup實作子查詢，并傳回用其他手段擷取的缺失字段，保證字段完整性。
- 建立ETL過程的主外鍵限制：對無依賴性的非法資料，可替換或導出到錯誤資料檔案中，保證主鍵唯一記錄的加載。
ETL架構的優勢：
- ETL可以分擔資料庫系統的負載（采用單獨的硬體伺服器）
- ETL相對于EL-T架構可以實作更為複雜的資料轉化邏輯
- ETL采用單獨的硬體伺服器。.
- ETL與底層的資料庫資料存儲無關.
ELT
在ELT架構中，ELT隻負責提供圖形化的界面來設計業務規則，資料的整個加工過程都在目标和源的資料庫之間流動，ELT協調相關的資料庫系統來執行相關的應用，資料加工過程既可以在源資料庫端執行，也可以在目标資料倉庫端執行（主要取決于系統的架構設計和資料屬性）。當ETL過程需要提高效率，則可以通過對相關資料庫進行調優，或者改變執行加工的伺服器就可以達到。一般資料庫廠商會力推該種架構，像Oracle和Teradata都極力宣傳ELT架構。
ELT架構的優勢：
- ELT主要通過資料庫引擎來實作系統的可擴充性（尤其是當資料加工過程在晚上時，可以充分利用資料庫引擎的資源）
- ELT可以保持所有的資料始終在資料庫當中，避免資料的加載和導出，進而保證效率，提高系統的可監控性。
- ELT可以根據資料的分布情況進行并行處理優化，并可以利用資料庫的固有功能優化磁盤I/O。
- ELT的可擴充性取決于資料庫引擎和其硬體伺服器的可擴充性。
- 通過對相關資料庫進行性能調優，ETL過程獲得3到4倍的效率提升一般不是特别困難。
ETL工具的特點
ETL本身特點在各類工具中都有所展現，下面以datastage和powermart舉例來說。
1、靜态的ETL單元和動态的ETL單元執行個體。 一次轉換指明了某種格式的資料如何格式化成另一種格式的資料，對于資料源的實體形式在設計時可以不用指定，它可以在運作時，當這個ETL單元建立一個執行個體 時才指定。對于靜态和動态的ETL單元，Datastage沒有嚴格區分，它的一個Job就是實作這個功能，在早期版本，一個Job同時不能運作兩次，所 以一個Job相當于一個執行個體，在後期版本，它支援multiple instances，而且還不是預設選項。Powermart中将這兩個概念加以區分，靜态的叫做Mapping，動态運作時叫做Session。
2、ETL中繼資料。中繼資料是描述資料的資料，他的含義非常廣泛，這裡僅指ETL的中繼資料。主要包括每次轉換前後的資料結構和轉換的規則。ETL中繼資料還包括形式參數的管理，形式參數的ETL單元定義的參數，相對還有實參，它是運作時指定的參數，實參不在中繼資料管理範圍之内。
3、資料流程的控制。 要有可視化的流程編輯工具，提供流程定義和流程監控功能。流程排程的最小機關是ETL單元執行個體，ETL單元是不能在細分的ETL過程，當然這由開發者來控 制，例如可以将抽取、轉換放在一個ETL單元中，那樣這個抽取和轉換隻能同時運作，而如果将他們分作兩個單元，可以分别運作，這有利于錯誤恢複操作。當 然，ETL單元究竟應該細分到什麼程度應該依據具體應用來看，目前還沒有找到很好的細分政策。比如，我們可以規定将裝載一個表的功能作為一個ETL單元， 但是不可否認，這樣的ETL單元之間會有很多共同的操作，例如兩個單元共用一個Hash表，要将這個Hash表裝入記憶體兩次。
4、轉換規則的定義方法。提供函數集提供常用規則方法，提供規則定義語言描述規則。
5、對資料的快速索引。一般都是利用Hash技術，将參照關系表提前裝入記憶體，在轉換時查找這個hash表。Datastage中有Hash檔案技術，Powermart也有類似的Lookup功能。
ETL産品分類
一般來說，我們眼中的ETL工具都是價格昂貴，能夠處理海量資料的家夥，但是這是其中的一種。它可以分成4種，針對不同的需求，主要是從轉換規則的複雜度和資料量大小來看。它們包括以下4類:
1、互動式運作環境。 你可以指定資料源、目标資料，指定規則，立馬ETL。這種互動式的操作無疑非常友善，但是隻能适合小資料量和複雜度不高的ETL過程，因為一旦規則複雜 了，可能需要語言級的描述，不能簡簡單單拖拖拽拽就可以的。還有資料量的問題，這種互動式必然建立在解釋型語言基礎上，另外他的靈活性必然要犧牲一定的性 能為代價。是以如果要處理海量資料的話，每次讀取一條記錄，每次對規則進行解釋執行，每次在寫入一條記錄，這對性能影響是非常大的。
2、專門編碼型的。 它提供了一個基于某種語言的程式架構，你可以不必将程式設計精力放在一些周邊的功能上，例如讀檔案功能、寫資料庫的功能，而将精力主要放在規則的實作上面。這 種近似手工代碼的性能肯定是沒話說，除非你的程式設計技巧不過關（這也是不可忽視的因素之一）。對于處理大資料量，處理複雜轉換邏輯，這種方式的ETL實作是 非常直覺的。
3、代碼生成器型的。 它就像是一個ETL代碼生成器，提供簡單的圖形化界面操作，讓你拖拖拽拽将轉換規則都設定好，其實他的背景都是生成基于某種語言的程式，要運作這個ETL 過程，必須要編譯才行。Datastage就是類似這樣的産品，設計好的job必須要編譯，這避免了每次轉換的解釋執行，但是不知道它生成的中間語言是什 麼。以前我設計的ETL工具大挪移其實也是歸屬于這一類，它提供了界面讓使用者編寫規則，最後生成C++語言，編譯後即可運作。這類工具的特點就是要在界面 上下狠功夫，必須讓使用者輕松定義一個ETL過程，提供豐富的插件來完成讀、寫和轉換函數。大挪移在這方面就太弱了，規則必須手寫，而且要寫成标準c++語 法，這未免還是有點難為最終使用者了，還不如做成一個專業編碼型的産品呢。另外一點，這類工具必須提供面向專家應用的功能，因為它不可能考慮到所有的轉換規 則和所有的讀寫，一方面提供插件接口來讓第三方編寫特定的插件，另一方面還有提供特定語言來實作進階功能。例如Datastage提供一種類Basic的 語言，不過他的Job的腳本化實作好像就做的不太好，隻能手工繪制job，而不能程式設計實作Job。
4、最後還有一種類型叫做資料集線器。顧名思義，他就是像Hub一樣地工作。将這種類型分出來和上面幾種分類在标準上有所差異，上面三種更多指ETL實作的方法，此類主要從資料處理角度。目前有一些産品屬于EAI（Enterprise Application Integration），它的資料內建主要是一種準實時性。是以這類産品就像Hub一樣，不斷接收各種異構資料源來的資料，經過處理，在實施發送到不同的目标資料中去。
雖然，這些類看似各又千秋，特别在BI項目中，面對海量資料的ETL時，中間兩種的選擇就開始了，在選擇過程中，必須要考慮到開發效率、維護方面、性能、學習曲線、人員技能等各方面因素，當然還有最重要也是最現實的因素就是客戶的意象。
ETL轉換過程
ETL探求之一中提到，ETL過程最複雜的部分就是T，這個轉換過程，T過程究竟有哪些類型呢？
宏觀輸入輸出
從對資料源的整個宏觀處理分，看看一個ETL過程的輸入輸出，可以分成下面幾類：
1、大小交。 這種處理在資料清洗過程是常見了，例如從資料源到ODS階段，如果資料倉庫采用次元模組化，而且次元基本采用代理鍵的話，必然存在代碼到此鍵值的轉換。如果 用SQL實作，必然需要将一個大表和一堆小表都Join起來，當然如果使用ETL工具的話，一般都是先将小表讀入記憶體中再處理。這種情況，輸出資料的粒度 和大表一樣。
2、大大交。 大表和大表之間關聯也是一個重要的課題，當然其中要有一個主表，在邏輯上，應當是主表Left Join輔表。大表之間的關聯存在最大的問題就是性能和穩定性，對于海量資料來說，必須有優化的方法來處理他們的關聯，另外，對于大資料的處理無疑會占用 太多的系統資源，出錯的幾率非常大，如何做到有效錯誤恢複也是個問題。對于這種情況，我們建議還是盡量将大表拆分成适度的稍小一點的表，形成大小交的類 型。這類情況的輸出資料粒度和主表一樣。
3、站着進來，躺着出去。 事務系統中為了提高系統靈活性和擴充性，很多資訊放在代碼表中維護，是以它的"事實表"就是一種窄表，而在資料倉庫中，通常要進行寬化，從行變成列，是以 稱這種處理情況叫做"站着進來，躺着出去"。大家對Decode肯定不陌生，這是進行寬表化常見的手段之一。窄表變寬表的過程主要展現在對窄表中那個代碼 字段的操作。這種情況，窄表是輸入，寬表是輸出，寬表的粒度必定要比窄表粗一些，就粗在那個代碼字段上。
4、聚集。 資料倉庫中重要的任務就是沉澱資料，聚集是必不可少的操作，它是粗化資料粒度的過程。聚集本身其實很簡單，就是類似SQL中Group by的操作，選取特定字段（次元），對度量字段再使用某種聚集函數。但是對于大資料量情況下，聚集算法的優化仍是探究的一個課題。例如是直接使用SQL的 Group by，還是先排序，在處理。
微觀規則
從資料的轉換的微觀細節分，可以分成下面的幾個基本類型，當然還有一些複雜的組合情況，例如先運算，在參照轉換的規則，這種基于基本類型組合的情況就不在此列了。ETL的規則是依賴目标資料的，目标資料有多少字段，就有多少條規則。
1、直接映射。原來是什麼就是什麼，原封不動照搬過來，對這樣的規則，如果資料源字段和目标字段長度或精度不符，需要特别注意看是否真的可以直接映射還是需要做一些簡單運算。
2、字段運算。資料源的一個或多個字段進行數學運算得到的目标字段，這種規則一般對數值型字段而言。
3、參照轉換。在轉換中通常要用資料源的一個或多個字段作為Key，去一個關聯數組中去搜尋特定值，而且應該隻能得到唯一值。這個關聯數組使用Hash算法實作是比較合适也是最常見的，在整個ETL開始之前，它就裝入記憶體，對性能提高的幫助非常大。
4、字元串處理。從資料源某個字元串字段中經常可以擷取特定資訊，例如身份證号。而且，經常會有數值型值以字元串形式展現。對字元串的操作通常有類型轉換、字元串截取等。但是由于字元類型字段的随意性也造成了髒資料的隐患，是以在處理這種規則的時候，一定要加上異常處理。
5、空值判斷。 對于空值的處理是資料倉庫中一個常見問題，是将它作為髒資料還是作為特定一種維成員？這恐怕還要看應用的情況，也是需要進一步探求的。但是無論怎樣，對于 可能有NULL值的字段，不要采用“直接映射”的規則類型，必須對空值進行判斷，目前我們的建議是将它轉換成特定的值。
6、日期轉換。在資料倉庫中日期值一般都會有特定的，不同于日期類型值的表示方法，例如使用8位整型20040801表示日期。而在資料源中，這種字段基本都是日期類型的，是以對于這樣的規則，需要一些共通函數來處理将日期轉換為8位日期值、6位月份值等。
7、日期運算。基于日期，我們通常會計算日差、月差、時長等。一般資料庫提供的日期運算函數都是基于日期型的，而在資料倉庫中采用特定類型來表示日期的話，必須有一套自己的日期運算函數集。
8、聚集運算。對于事實表中的度量字段，他們通常是通過資料源一個或多個字段運用聚集函數得來的，這些聚集函數為SQL标準中，包括sum,count,avg,min,max。
9、既定取值。這種規則和以上各種類型規則的差别就在于它不依賴于資料源字段，對目标字段取一個固定的或是依賴系統的值。
資料品質
“不要絕對的資料準确，但要知道為什麼不準确。”
這 是我們在建構BI系統是對資料準确性的要求。确實，對絕對的資料準确誰也沒有把握，不僅是系統內建商，包括客戶也是無法确定。準确的東西需要一個标準，但 首先要保證這個标準是準确的，至少現在還沒有這樣一個标準。客戶會提出一個相對标準，例如将你的OLAP資料結果和報表結果對比。雖然這是一種不太公平的 比較，你也隻好認了吧。
首先在資料源那裡，已經很難保證資料品質了，這一點也是事實。在這一層有哪些可能原因導緻資料品質問題？可以分為下面幾類：
1、資料格式錯誤。 例如缺失資料、資料值超出範圍或是資料格式非法等。要知道對于同樣處理大資料量的資料源系統，他們通常會舍棄一些資料庫自身的檢查機制，例如字段限制等。 他們盡可能将資料檢查在入庫前保證，但是這一點是很難確定的。這類情況諸如身份證号碼、手機号、非日期類型的日期字段等。
2、資料一緻性。同樣，資料源系統為了性能的考慮，會在一定程度上舍棄外鍵限制，這通常會導緻資料不一緻。例如在帳務表中會出現一個使用者表中沒有的使用者ID，在例如有些代碼在代碼表中找不到等。
3、業務邏輯的合理性。這一點很難說對與錯。通常，資料源系統的設計并不是非常嚴謹，例如讓使用者開戶日期晚于使用者銷戶日期都是有可能發生的，一個使用者表中存在多個使用者ID也是有可能發生的。對這種情況，有什麼辦法嗎？
建構一個BI系統，要做到完全了解資料源系統根本就是不可能的。特别是資料源系統在傳遞後，有更多元護人員的即興發揮，那更是要花大量的時間去尋找原因。以前曾經争辯過設計人員對規則描述的問題，有人提出要在ETL開始之前務必将所有的規則弄得一清二楚。我并不同意這樣的意見，倒是認為在ETL過程要有處理 這些品質有問題資料的保證。一定要正面這些髒資料，是丢棄還是處理，無法逃避。如果沒有品質保證，那麼在這個過程中，錯誤會逐漸放大，抛開資料源品質問 題，我們再來看看ETL過程中哪些因素對資料準确性産生重大影響。
1、規則描述錯誤。 上面提到對設計人員對資料源系統了解的不充分，導緻規則了解錯誤，這是一方面。另一方面，是規則的描述，如果無二義性地描述規則也是要探求的一個課題。規 則是依附于目标字段的，在探求之三中，提到規則的分類。但是規則總不能總是用文字描述，必須有嚴格的數學表達方式。我甚至想過，如果設計人員能夠使用某種 規則語言來描述，那麼我們的ETL單元就可以自動生成、同步，省去很多手工操作了。
2、ETL開發錯誤。即時規則很明确，ETL開發的過程中也會發生一些錯誤，例如邏輯錯誤、書寫錯誤等。例如對于一個分段值，開區間閉區間是需要指定的，但是常常開發人員沒注意，一個大于等于号寫成大于号就導緻資料錯誤。
3、人為處理錯誤。在整體ETL流程沒有完成之前，為了圖省事，通常會手工運作ETL過程，這其中一個重大的問題就是你不會按照正常流程去運作了，而是按照自己的了解去運作，發生的錯誤可能是誤删了資料、重複裝載資料等。
品質保證
ETL資料品質問題是無法根治的，隻能采取特定的手段去盡量避免，而且必須要定義出度量方法來衡量資料的品質是好還是壞。對于資料源的品質，客 戶對此應該更加關心，如果在這個源頭不能保證比較幹淨的資料，那麼後面的分析功能的可信度也都成問題。資料源系統也在不斷進化過程中，客戶的操作也在逐漸 規範中，BI系統也同樣如此。本文探讨一下對資料源品質和ETL處理品質的應對方法。
如何應對資料源的品質問題？記得在onteldatastage清單中也讨論過一個話題——“-1的處理”，在資料倉庫模型維表中，通常有一條-1記錄，表示“未知”，這個未知含義可廣了，任何可能出錯的資料，NULL資料甚至是規則沒有涵蓋到的資料，都轉成-1。這是一種處理髒資料的方法，但這也是一種掩 蓋事實的方法。就好像寫一個函數FileOpen(filename)，傳回一個錯誤碼，當然，你可以隻傳回一種錯誤碼，如-1，但這是一種不好的設計， 對于調用者來說，他需要依據這個錯誤碼進行某些判斷，例如是檔案不存在，還是讀取權限不夠，都有相應的處理邏輯。資料倉庫中也是一樣，是以，建議将不同的 資料品質類型處理結果分别轉換成不同的值，譬如，在轉換後，-1表示參照不上，-2表示NULL資料等。不過這僅僅對付了上回提到的第一類錯誤，資料格式 錯誤。對于資料一緻性和業務邏輯合理性問題，這仍有待探求。但這裡有一個原則就是“必須在資料倉庫中反應資料源的品質”。
對于ETL過程中産生的品質問題，必須有保障手段。從以往的經驗看，沒有保障手段給實施人員帶來麻煩重重。實施人員對于反複裝載資料一定不會陌生，甚至是最 後資料留到最後的Cube，才發現了第一步ETL其實已經錯了。這個保障手段就是資料驗證機制，當然，它的目的是能夠在ETL過程中監控資料品質，産生報 警。這個子產品要将實施人員當作是最終使用者，可以說他們是資料驗證機制的直接收益者。
首 先，必須有一個對品質的度量方法，什麼是高質什麼是低質，不能靠感官感覺，但這卻是在沒有度量方法條件下通常的做法。那經營分析系統來說，聯通總部曾提出 測試規範，這其實就是一種度量方法，例如名額的誤差範圍不能高于5%等，對系統本身來說其實必須要有這樣的度量方法，先不要說這個度量方法是否科學。對于 ETL資料處理品質，他的度量方法應該比聯通總部測試規範定義的方法更要嚴格，因為他更多将BI系統看作一個黑盒子，從資料源到展現的資料誤差允許一定的 誤差。而ETL資料處理品質度量是一種白盒的度量，要注重每一步過程。是以理論上，要求輸入輸出的名額應該完全一緻。但是我們必須正面完全一緻隻是理想， 對于有誤差的資料，必須找到原因。
在品質度量方法的前提下，就可以建立一個資料驗證架構。此架構依據總量、分量資料稽核方法，該方法在高的《資料倉庫中的資料稽核技術》一文中已經指出。作為補充，下面提出幾點功能上的建議：
1、提供前端。 将開發實施人員當作使用者，同樣也要為之提供友好的使用者界面。《稽核技術》一文中指出測試報告的形式，這種形式還是要依賴人為判斷，在一堆資料中去找規律。 到不如用OLAP的方式提供界面，不光是加上測試統計出來的名額結果，并且配合度量方法的計算。例如誤差率，對于誤差率為大于0的名額，就要好好查一下原 因了。
2、提供架構。 資料驗證不是一次性工作，而是每次ETL過程中都必須做的。是以，必須有一個架構，自動化驗證過程，并提供擴充手段，讓實施人員能夠增加驗證範圍。有了這 樣一個架構，其實它起到規範化操作的作用，開發實施人員可以将主要精力放在驗證腳本的編寫上，而不必過多關注驗證如何融合到流程中，如何展現等工作。為 此，要設計一套表，類似于DM表，每次驗證結果資料都記錄其中，并且自動觸發多元分析的資料裝載、釋出等。這樣，實施人員可以在每次裝載，甚至在流程過程 中就可以觀察資料的誤差率。特别是，如果資料倉庫的模型能夠統一起來，甚至資料驗證腳本都可以确定下來，剩下的就是規範流程了。
3、規範流程。 上回提到有一種ETL資料品質問題是由于人工處理導緻的，其中最主要原因還是流程不規範。開發實施人員運作單獨一個ETL單元是很友善的，雖然以前曾建議 一個ETL單元必須是"可重入"的，這能夠解決誤删資料，重複裝載資料問題。但要記住資料驗證也是在流程當中，要讓資料驗證能夠日常運作，就不要讓實施者 感覺到他的存在。總的來說，規範流程是提高實施效率的關鍵工作，這也是以後要繼續探求的。
中繼資料
對于中繼資料(Metadata)的定義到目前為止沒有什麼特别精彩的，這個概念非常廣，一般都是這樣定義，“中繼資料是描述資料的資料(Data about Data)”，這造成一種遞歸定義，就像問小強住在哪裡，答，在旺财隔壁。按照這樣的定義，中繼資料所描述的資料是什麼呢？還是中繼資料。這樣就可能有元元元...中繼資料。我還聽說過一種對中繼資料，如果說資料是一抽屜檔案，那麼中繼資料就是分類标簽。那它和索引有什麼差別？
中繼資料展現是一種抽象，哲學家從古至今都在抽象這個世界，力圖找到世界的本質。抽象不是一層關系，它是一種逐漸由具體到一般的過程。例如我->男人 ->人->哺乳動物->生物這就是一個抽象過程，你要是在軟體業混會發現這個例子很常見，面向對象方法就是這樣一種抽象過程。它對世界 中的事物、過程進行抽象，使用面向對象方法，建構一套對象模型。同樣在面向對象方法中，類是對象的抽象，接口又是對類的抽象。是以，我認為可以将“元”和 “抽象”換一下，叫抽象資料是不是好了解一些。
常聽到這樣的話，“xx上司的講話高屋建瓴，給我們後面的工作指引的清晰的方向”，這個成語“高屋建瓴”，站在10樓往下倒水，居高臨下，能砸死人，這是指 站在一定的高度看待事物，這個一定的高度就是指他有夠“元”。在設計模式中，強調要對接口程式設計，就是說你不要處理這類對象和那類對象的互動，而要處理這個 接口和那個接口的互動，先别管他們内部是怎麼幹的。
中繼資料存在的意義也在于此，雖然上面說了一通都扯到哲學上去，但這個詞必須還是要結合軟體設計中看，我不知道在别的領域是不是存在Metadata這樣的叫 法，雖然我相信别的領域必然有類似的東東。中繼資料的存在就是要做到在更高抽象一層設計軟體。這肯定有好處，什麼靈活性啊，擴充性啊，可維護性啊，都能得到 提高，而且架構清晰，隻是彎彎太多，要是從下往上看，太複雜了。很早以前，我曾看過backorifice的代碼，我靠，一個簡單的功能，從這個類轉到父類，又轉到父類，很不了解，為什麼一個簡單的功能不在一個類的方法中實作就拉到了呢？現在想想，還真不能這樣，這雖然使代碼容易看懂了，但是結構确是混亂 的，那他隻能幹現在的事，如果有什麼功能擴充，這些代碼就廢了。
市面上有一些中繼資料管理的東西，但是從應用情況就得知，用的不多。之是以玄乎，就是因為抽象層次沒有 厘清楚，關鍵就是對于中繼資料的分類（這種分類就是一種抽象過程）和中繼資料的使用。你可以将中繼資料抽象成0和1，但是那樣對你的業務有用嗎？必須還得抽象到 适合的程度，最後問題還是“度”。
資料倉庫系統的中繼資料作用如何？還不就是使系統自動運轉，易于管理嗎？要做到這一步，可沒必要将系統抽象到太極、兩儀、八卦之類的，業界也曾定義過一些中繼資料規範，向CWM、XMI等等，可以借鑒，不過俺對此也是不精通的說，以後再說。
參考部落格：
https://www.cnblogs.com/bolang100/p/6931845.html
https://www.cnblogs.com/Jesse-Li/p/8821893.html