目錄

• 1 基于Thrift的RPC框架的開發(fā)和維護(hù)
• • 項目介紹
  • RPC及實現(xiàn)RPC需要的技術(shù)
  • • 1 動態(tài)代理
    • 2 序列化和反序列化
    • 3 NIO通信組件
    • 4 注冊中心
  • 為什么使用RPC
  • • RPC和HTTP
  • Thrift簡介
  • Thrift整體架構(gòu)
  • Thrift 三大重要組件：Transport、Protocol和 Server
  • • 傳輸方式Transport
    • 傳輸協(xié)議Protocol（編碼方式）
    • • 二進(jìn)制協(xié)議 VS 文本協(xié)議
    • 服務(wù)模型Server（Java）
    • • 1 TSimpleServer模式
      • 2 TNonblockingServer模式
      • 3 THsHaServer模式（半同步半異步）
      • 4 TThreadPoolServer模式
      • 5 TThreadedSelectorServer模式
    • 服務(wù)模型Server（Python）
    • • 1 TSimpleServer
      • 2 TThreadPoolServer
• 2 數(shù)倉
• • 數(shù)據(jù)倉庫概念
  • 數(shù)倉分層概念
  • 數(shù)據(jù)倉庫的輸入數(shù)據(jù)源和輸出系統(tǒng)
  • 維、維度、維度表和事實表
  • • 0 來自知乎的一個簡單解釋
    • 1 維
    • 2 維度
    • 3 維度表
    • 4 事實表
    • 5 星型模式結(jié)構(gòu)示意圖
  • 數(shù)據(jù)湖 VS 數(shù)據(jù)倉庫
  • • 1 本質(zhì)區(qū)別
    • 2 存儲位置
    • 3 數(shù)據(jù)源
    • 4 用戶
    • 5 數(shù)據(jù)質(zhì)量
    • 6 數(shù)據(jù)模式
    • 7 敏捷擴展性
    • 8 應(yīng)用
• 2 基于Spring Boot的個人博客系統(tǒng)
• • 項目介紹
• 3 基于Servlet和JSP的網(wǎng)上書城
• • 0 項目介紹
  • 1 什么是Servlet
  • 2 Tomcat容器等級
  • 3 手工編寫一個Servlet
  • 4 測試題
  • 5 Servlet執(zhí)行流程
  • 6 Servlet生命周期
  • 7 Tomcat裝載Servlet的三種情況
  • 8 Servlet與JSP的區(qū)別
  • 9 Spring MVC和Servlet
  • 10 轉(zhuǎn)發(fā)和重定向的區(qū)別
  • Servlet是線程安全的嗎？
• 4 僵尸企業(yè)畫像及分類
• 5 降低汽油精制過程中的辛烷值損失模型
• 6 天然氣股份有限公司場站智能化分析及控制軟件開發(fā)
• • 異常檢測研發(fā)目標(biāo)
  • 異常檢測設(shè)計方案
  • • 單點檢測
    • 多點檢測

1 基于Thrift的RPC框架的開發(fā)和維護(hù)

項目介紹

公司項目整體架構(gòu)是基于分布式的：以Java集成各功能模塊作為客戶端，以Python提供機器學(xué)習(xí)算法支持作為服務(wù)端，以RPC保證高效穩(wěn)定通信。Thrift作為一種典型的CS結(jié)構(gòu)，且支持跨語言，故以此進(jìn)行RPC開發(fā)。在Thrift的技術(shù)選型上，使用TFramedTransport作為傳輸方式、TCompactProtocol作為傳輸協(xié)議（編碼方式），TForkingServer作為服務(wù)模型；同時，為了保證服務(wù)的穩(wěn)定性，客戶端啟用一個心跳機制來維護(hù)長連接，服務(wù)端建立一個管理進(jìn)程監(jiān)測維護(hù)各服務(wù)進(jìn)程。

分布式系統(tǒng)是由一組通過網(wǎng)絡(luò)進(jìn)行通信、為了完成共同的任務(wù)而協(xié)調(diào)工作的計算機節(jié)點組成的系統(tǒng)。

RPC及實現(xiàn)RPC需要的技術(shù)

RPC（Remote Procedure Call Protocol，遠(yuǎn)程過程調(diào)用協(xié)議）：是一種通過網(wǎng)絡(luò)從遠(yuǎn)程服務(wù)器上請求服務(wù)，而不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議；RPC使得客戶端在遠(yuǎn)程調(diào)用時，能夠像本地調(diào)用一樣方便，而感知不到遠(yuǎn)程調(diào)用的邏輯；

關(guān)鍵技術(shù)包括：通信協(xié)議、序列化、接口描述、服務(wù)框架、性能和語言支持等；

RPC可以使用TCP作為傳輸協(xié)議，也可以使用HTTP（如gRPC），但一般都是TCP；

RPC = socket + 動態(tài)代理

動態(tài)代理發(fā)生在服務(wù)調(diào)用方，RPC 框架需要解決的是：像調(diào)用本地接口一樣調(diào)用遠(yuǎn)程接口。于是如何組裝數(shù)據(jù)報文、如何經(jīng)過網(wǎng)絡(luò)傳輸發(fā)送至服務(wù)提供方，以及如何屏蔽遠(yuǎn)程接口調(diào)用的細(xì)節(jié)，便是動態(tài)代理需要做的工作。

1 動態(tài)代理

動態(tài)代理用于生成客戶端存根、服務(wù)端存根，當(dāng)調(diào)用 RPC 遠(yuǎn)程接口時，實際是調(diào)用了它的代理類，再由代理類使用 Socket 技術(shù)向遠(yuǎn)程接口發(fā)送請求信息;

一般這個代理過程可以使用 JDK 提供的原生代理方式，也可以使用開源的 CGLib 代理;

一個完整的RPC架構(gòu)包含5個核心組件，分別是：客戶端、客戶端存根、網(wǎng)絡(luò)傳輸模塊、服務(wù)端存根、服務(wù)端：

• 客戶端（Client）：服務(wù)調(diào)用方；
• 客戶端存根（Client Stub）：存放服務(wù)端的地址信息，將客戶端的請求參數(shù)打包成網(wǎng)絡(luò)消息，再通過網(wǎng)絡(luò)傳輸發(fā)送給服務(wù)方；
• 網(wǎng)絡(luò)傳輸模塊（Network Service）：底層傳輸，可以是TCP或HTTP；
• 服務(wù)端存根（Server Stub）：接收客戶端發(fā)送過來的請求消息并進(jìn)行解包，然后再調(diào)用本地服務(wù)進(jìn)行處理；
• 服務(wù)端（Server）：服務(wù)的真正提供者；
  

2 序列化和反序列化

在網(wǎng)絡(luò)信息傳輸中，所有數(shù)據(jù)都會被轉(zhuǎn)換為字節(jié)碼進(jìn)行傳送；

RPC在調(diào)用的過程中，需要把接口的入?yún)⒑统鰠⑼ㄟ^序列化轉(zhuǎn)化成字節(jié)碼和反序列化為對象，也就是編碼和解碼操作；

比較常用的開源的序列化方式有JSON、Protobuf等，當(dāng)然也可以用Java自帶的序列化方式，但這個過程非常耗時，所以一般不會使用；

3 NIO通信組件

在RPC通信實現(xiàn)方案中，需要考慮并發(fā)性能問題，非常重要的一環(huán)是需要考慮I/O的選擇。傳統(tǒng)阻塞式的IO顯然是不合適的，因此需要非阻塞IO，即NIO；

但實現(xiàn)NIO通信比較復(fù)雜，也容易出錯，所以在RPC通信中一般都會選擇Netty作為NIO的通信組件；

4 注冊中心

在 NIO 的通信中，接口提供方需要把接口注冊到一個中心，在接口調(diào)用方調(diào)用服務(wù)時，需要從注冊中心獲取接口的提供方，其中最核心的信息就是IP+端口號;

拿到提供方信息后進(jìn)行 socket 連接操作，接下來就可以通信了;

注冊中心通常會選擇ZooKeeper，但也可以使用其他方式，如Redis;

注冊中心可以缺失，如果接口調(diào)用方知道接口提供方的IP+端口號，就可以直接調(diào)用，而不需要向注冊中心去查詢。直接調(diào)用的優(yōu)點就是直接且易于維護(hù)，缺點則是不夠靈活，如果服務(wù)的地址改變了，我們需要手動修改服務(wù)提供的地址，而不能動態(tài)地實時地去獲取；

為什么使用RPC

RPC要解決的兩個問題：

解決分布式系統(tǒng)中，服務(wù)之間的調(diào)用問題。

遠(yuǎn)程調(diào)用時，要能夠像本地調(diào)用一樣方便，讓調(diào)用者感知不到遠(yuǎn)程調(diào)用的邏輯。

RPC和HTTP

HTTP是RPC的一種；

HTTP是在接口不多、系統(tǒng)與系統(tǒng)交互較少的情況下，解決信息孤島初期使用的一種通信手段，接口可能返回一個JSON字符串或XML文檔，然后客戶端再去處理這個返回的信息。優(yōu)點就是簡單直接、開發(fā)方便；

如果一個系統(tǒng)內(nèi)部子系統(tǒng)較多、接口非常多，RPC框架的優(yōu)勢就顯示出來了：1 RPC用到了動態(tài)代理模式，能解耦服務(wù)；2 RPC調(diào)用是面向服務(wù)的封裝，針對服務(wù)的可用性和效率等都做了優(yōu)化（傳輸方式、傳輸協(xié)議、服務(wù)模型等），單純使用HTTP調(diào)用則缺少了這些特性；3 RPC框架一般都有注冊中心，有豐富的監(jiān)控管理、發(fā)布和下線接口等；4 長連接：不必每次通信都要像HTTP一樣去3次握手，減少了網(wǎng)絡(luò)開銷；

Thrift簡介

Thrift是用于實現(xiàn)RPC通信的一種框架，支持跨語言，包括C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, OCaml, Delphi等；

Thrift是一種典型的CS（客戶端/服務(wù)端）結(jié)構(gòu)，客戶端和服務(wù)端可以使用不同的語言開發(fā)。既然客戶端和服務(wù)端能使用不同的語言開發(fā)，就一定要有一種中間語言來關(guān)聯(lián)客戶端和服務(wù)端的語言，這種語言就是IDL（Interface Description Language）；

Thrift整體架構(gòu)

業(yè)務(wù)邏輯層是用戶實現(xiàn)的業(yè)務(wù)邏輯；

代碼框架層是根據(jù)Thrift定義的服務(wù)接口描述文件生成的客戶端和服務(wù)器端代碼框架；

數(shù)據(jù)讀寫操作層是根據(jù)Thrift文件生成代碼實現(xiàn)數(shù)據(jù)的讀寫操作；

以下是Thrift的傳輸協(xié)議、傳輸方式以及底層的IO通信，使用Thrift可以很方便地定義一個服務(wù)并且選擇不同的傳輸協(xié)議和傳輸方式；

Thrift 三大重要組件：Transport、Protocol和 Server

傳輸方式Transport

TSocket：阻塞型socket，用于客戶端，采用系統(tǒng)函數(shù)read和write進(jìn)行讀寫數(shù)據(jù)；

TNonblockingServerSocket：非阻塞型socket，用于服務(wù)端，accept到的socket類型都是TSocket；

TBufferedTransport和TFramedTransport：非阻塞有緩存，均繼承TBufferBase，調(diào)用下一層TTransport類進(jìn)行讀寫操作，結(jié)構(gòu)非常相似。但TFramedTransport以幀為傳輸單位，幀結(jié)構(gòu)為：4字節(jié)+傳輸字符串，4字節(jié)用來存儲傳輸字符串的長度，該字符串才是真正需要傳輸?shù)臄?shù)據(jù)，因此TFramedTransport每傳一幀都要比TBufferedTransport和TSocket多傳4字節(jié)；

TFileTransport：以文件形式進(jìn)行傳輸；

傳輸協(xié)議Protocol（編碼方式）

Thrift傳輸協(xié)議總體上可劃分為二進(jìn)制（binary）和文本（text）傳輸協(xié)議兩大類，一般在生產(chǎn)環(huán)境中使用二進(jìn)制類型的傳輸協(xié)議（相比于文本和JSON傳輸效率更高）。

TBinaryProtocol：使用二進(jìn)制編碼格式進(jìn)行數(shù)據(jù)傳輸，Thrift的默認(rèn)協(xié)議；

TCompactProtocol：壓縮的二進(jìn)制編碼格式，使用高效率的、密集的二進(jìn)制編碼格式進(jìn)行數(shù)據(jù)傳輸；

TJSONProtocol：使用JSON數(shù)據(jù)編碼格式進(jìn)行數(shù)據(jù)傳輸，在網(wǎng)絡(luò)中以文本方式傳輸，易于抓包分析和理解；

TDebugProtocol：使用text編碼格式進(jìn)行數(shù)據(jù)傳輸，可讀性強，常用于編碼人員測試；

二進(jìn)制協(xié)議 VS 文本協(xié)議

二進(jìn)制協(xié)議：沒有冗余字段、傳輸高效、方便解析（固定長度，并且可以直接比較字節(jié)），缺點就是定義的比較死，哪個位置有哪些東西，是什么意義都是定義死的，場景單一；

文本協(xié)議：直觀、描述性強、容易理解、便于調(diào)試，缺點就是冗余數(shù)據(jù)較多，不適宜傳輸二進(jìn)制文件（如圖片等），解析復(fù)雜（需要進(jìn)行字符串比較）；

應(yīng)用場景：1 高效傳輸和數(shù)據(jù)安全，使用二進(jìn)制協(xié)議；2 便于調(diào)試和命令較少（如即時通訊軟件），使用文本協(xié)議；

服務(wù)模型Server（Java）

1 TSimpleServer模式

TSimpleServer的工作模式下只有一個工作線程，循環(huán)監(jiān)聽新請求的到來并完成對請求的處理，它只是在簡單的演示時候使用；

TSimpleServer的工作模式采用最簡單的阻塞IO，實現(xiàn)方法簡潔明了，便于理解，但是一次只能接收和處理一個socket連接，效率比較低，主要用于演示Thrift的工作過程，在實際開發(fā)過程中很少用到它。

2 TNonblockingServer模式

TNonblockingServer也是單線程工作，但是該模式采用NIO的方式，所有的socket都被注冊到selector中，在一個線程中通過selector循環(huán)監(jiān)聽所有的socket；每次selector結(jié)束時，處理所有的處于就緒狀態(tài)的socket：對于監(jiān)聽到的socket產(chǎn)生一個新業(yè)務(wù)socket并將其注冊到selector中，對于有數(shù)據(jù)到來的socket進(jìn)行數(shù)據(jù)讀取操作，對于有數(shù)據(jù)發(fā)送的socket進(jìn)行數(shù)據(jù)發(fā)送操作。

TNonblockingServer模式優(yōu)點：

相比于TSimpleServer效率提升主要體現(xiàn)在IO多路復(fù)用上，TNonblockingServer采用非阻塞IO，同時監(jiān)控多個socket的狀態(tài)變化。

TNonblockingServer模式缺點：

TNonblockingServer模式在業(yè)務(wù)處理上還是采用單線程順序來完成，在業(yè)務(wù)處理比較復(fù)雜、耗時的時候，例如某些接口函數(shù)需要讀取數(shù)據(jù)庫執(zhí)行時間較長，此時該模式效率也不高，因為多個調(diào)用請求任務(wù)依然是一個接一個順序執(zhí)行。

3 THsHaServer模式（半同步半異步）

THsHaServer類是TNonblockingServer類的子類，TNonblockingServer模式中，采用一個線程來完成對所有socket的監(jiān)聽和業(yè)務(wù)處理，造成了效率的低下，THsHaServer模式的引入則是部分解決了這些問題。THsHaServer模式中，引入一個線程池來專門進(jìn)行業(yè)務(wù)處理。

THsHaServer的優(yōu)點：

與TNonblockingServer模式相比，THsHaServer在完成數(shù)據(jù)讀取之后，將業(yè)務(wù)處理過程交由一個線程池來完成，主線程直接返回進(jìn)行下一次循環(huán)操作，效率大大提升。

THsHaServer的缺點：

主線程需要完成對所有socket的監(jiān)聽以及數(shù)據(jù)讀寫的工作，當(dāng)并發(fā)請求數(shù)較多，且發(fā)送數(shù)據(jù)量較大時，監(jiān)聽socket上新連接請求不能被及時接收。

4 TThreadPoolServer模式

TThreadPoolServer模式采用阻塞socket方式工作，主線程負(fù)責(zé)阻塞式監(jiān)聽是否有新socket到來，業(yè)務(wù)處理交由一個線程池來處理。

TThreadPoolServer模式優(yōu)點：

線程池模式中，數(shù)據(jù)讀取和業(yè)務(wù)處理都交由線程池完成，主線程只負(fù)責(zé)監(jiān)聽新連接，因此在并發(fā)量較大時新連接也能夠被及時接收。線程池模式比較適合服務(wù)器端能預(yù)知最多有多少個客戶端并發(fā)的情況，這時每個請求都能被業(yè)務(wù)線程池及時處理，性能也非常高。

TThreadPoolServer模式缺點：

線程池模式的處理能力受限于線程池的工作能力，當(dāng)并發(fā)請求數(shù)大于線程池中的線程數(shù)時，新請求也只能排隊等待。

5 TThreadedSelectorServer模式

TThreadedSelectorServer模式是目前Thrift提供的最高級的模式，它內(nèi)部有如下幾個部分構(gòu)成：

一個AcceptThread線程對象，專門用于處理監(jiān)聽socket上的新連接；

若干個SelectorThread線程對象專門用于處理業(yè)務(wù)socket的網(wǎng)絡(luò)I/O操作，所有網(wǎng)絡(luò)數(shù)據(jù)的讀寫均是由這些線程來完成；

一個負(fù)載均衡器SelectorThreadLoadBalancer對象，主要用于AcceptThread線程接收到一個新socket連接請求時，決定將這個新連接請求分配給哪個SelectorThread線程；

一個ExecutorService類型的工作線程池，在SelectorThread線程中，監(jiān)聽到業(yè)務(wù)socket中有調(diào)用請求過來，則將請求讀取之后，交給ExecutorService線程池中的線程完成此次調(diào)用的具體執(zhí)行；

TThreadedSelectorServer模式中有一個專門的線程AcceptThread用于處理新連接請求，因此能夠及時響應(yīng)大量并發(fā)連接請求；另外它將網(wǎng)絡(luò)I/O操作分散到多個SelectorThread線程中來完成，因此能夠快速對網(wǎng)絡(luò)I/O進(jìn)行讀寫操作，能夠很好地應(yīng)對網(wǎng)絡(luò)I/O較多的情況；TThreadedSelectorServer對于大部分應(yīng)用場景性能都不會差，因此，如果實在不知道選擇哪種工作模式，使用TThreadedSelectorServer就可以。

鏈接: Python服務(wù)端源碼解析.

服務(wù)模型Server（Python）

1 TSimpleServer

TSimpleServer的工作模式采用最簡單的阻塞IO，實現(xiàn)方法簡潔明了，便于理解，但是一次只能接收和處理一個socket連接，效率比較低。

源碼分析

設(shè)置TServerSocket的listen()方法啟動連接監(jiān)聽；

以阻塞的方式接受客戶端的連接請求，每進(jìn)入一個連接即為其創(chuàng)建一個TSocket對象（封裝socket連接）；

為客戶端創(chuàng)建輸入傳輸通道對象、輸出傳輸通道對象、輸入?yún)f(xié)議對象和輸出協(xié)議對象；

processor對象為服務(wù)模型創(chuàng)建之前創(chuàng)建的，用來處理具體的業(yè)務(wù)請求；

2 TThreadPoolServer

服務(wù)啟動時先創(chuàng)建好self.threads個線程，每個線程負(fù)責(zé)從隊列clients中獲取客戶端連接TSocket對象。而主線程負(fù)責(zé)accept客戶端的連接并創(chuàng)建TSocket對象，放入clients隊列。

3 TNonblockingServer
類似于Java版Thrift中的THsHaServer，思路是服務(wù)啟動時創(chuàng)建threads個線程負(fù)責(zé)處理task隊列中的任務(wù)消息。而主線程利用I/O多路復(fù)用技術(shù)將準(zhǔn)備好的可讀消息放入task隊列供業(yè)務(wù)線程處理，同時在處理結(jié)束后可寫時直接將結(jié)果返回給客戶端。

4 TForkingServer VS TProcessPoolServer

由于Python的GIL鎖，所以Python沒有真正的多線程，無法實現(xiàn)并行運作，多任務(wù)場景下效率低下，因此引入了兩個多進(jìn)程模型；

其中TForkingServer，服務(wù)端每次監(jiān)聽到client請求，會os.fork一個子進(jìn)程進(jìn)行業(yè)務(wù)處理；

TProcessPoolServer服務(wù)啟動時創(chuàng)建指定個數(shù)的進(jìn)程；

2 數(shù)倉

數(shù)據(jù)倉庫概念

1 概念

數(shù)據(jù)倉庫（Data Warehouse）通常指一個數(shù)據(jù)庫環(huán)境，而不是一件產(chǎn)品，它提供用戶用于決策支持的當(dāng)前的和歷史數(shù)據(jù)，這些數(shù)據(jù)在傳統(tǒng)的數(shù)據(jù)庫中通常不方便得到；

數(shù)據(jù)倉庫是一個面向主題的（Subject Oriented）、集成的（Integrated）、相對穩(wěn)定的（Non-Volatile）、反映歷史變化（Time Variant）的數(shù)據(jù)集合；

通常用于輔助決策支持；

2 特點

2.1 面向主題

操作型數(shù)據(jù)庫中的數(shù)據(jù)針對事務(wù)處理任務(wù)，各個業(yè)務(wù)系統(tǒng)之間彼此分離，而數(shù)據(jù)倉庫中的數(shù)據(jù)按照一定的主題域進(jìn)行組織；

主題是個抽象概念，指用戶使用數(shù)據(jù)倉庫進(jìn)行決策時所關(guān)心的重點領(lǐng)域，如顧客/供應(yīng)商/產(chǎn)品等；

一個主題通常與多個操作型數(shù)據(jù)庫相關(guān)；

2.2 集成

操作型數(shù)據(jù)庫通常與某些特定的應(yīng)用相關(guān)，數(shù)據(jù)庫之間相互獨立，且往往是異構(gòu)的；

而數(shù)據(jù)倉庫中的數(shù)據(jù)是在原有分散的數(shù)據(jù)庫數(shù)據(jù)作抽取、清理的基礎(chǔ)上經(jīng)過系統(tǒng)加工、匯總和整理得到的，因此必須消除源數(shù)據(jù)中的不一致性，以保證數(shù)據(jù)倉庫內(nèi)的信息是關(guān)于整個企事業(yè)單位一致的全局信息；

即存放在數(shù)據(jù)倉庫中的數(shù)據(jù)應(yīng)使用一致的命名規(guī)則、格式、編碼結(jié)構(gòu)和相關(guān)特性來定義；

2.3 相對穩(wěn)定

操作型數(shù)據(jù)庫中的數(shù)據(jù)通常實時更新，數(shù)據(jù)根據(jù)需要及時發(fā)生變化；

數(shù)據(jù)倉庫中的數(shù)據(jù)主要用作決策分析，涉及的數(shù)據(jù)操作主要是查詢和定期更新，一旦某個數(shù)據(jù)加載到數(shù)據(jù)倉庫以后，一般情況下將作為數(shù)據(jù)檔案長期保存，幾乎不再做修改和刪除操作；

即數(shù)據(jù)倉庫中通常有大量的查詢操作及少量定期的更新操作；

2.4 反映歷史變化

操作型數(shù)據(jù)庫主要關(guān)心當(dāng)前某一時間段內(nèi)的數(shù)據(jù)，而數(shù)據(jù)倉庫中的數(shù)據(jù)通常包含較久遠(yuǎn)的歷史數(shù)據(jù)；

因此數(shù)倉中通常包括一個時間維，以便研究趨勢和變化；

數(shù)倉系統(tǒng)通常記錄了一個單位從過去某一時期到目前的所有時期的信息，通過這些信息，可以對單位的發(fā)展歷程和未來趨勢作出定量分析和預(yù)測；

數(shù)據(jù)集市則是一種微型的數(shù)據(jù)倉庫，通常有更少的數(shù)據(jù)，更少的主題區(qū)域，更少的歷史數(shù)據(jù)，部門級的，一般只能為某個局部范圍內(nèi)的管理人員服務(wù)；

數(shù)據(jù)倉庫是企業(yè)級的，能為整個企業(yè)各個部門的運行提供決策支持手段；

數(shù)倉分層概念

ods：operation data store原始數(shù)據(jù)層，數(shù)據(jù)保持原貌不做處理；

dwd：data warehouse detail明細(xì)數(shù)據(jù)層，結(jié)構(gòu)和粒度與原始表保持一致，對ods層數(shù)據(jù)進(jìn)行清洗（去除空值，臟數(shù)據(jù)）；

dws：data warehouse service數(shù)據(jù)服務(wù)層，數(shù)據(jù)輕度匯總；

ads：application data store 數(shù)據(jù)應(yīng)用層，為各種統(tǒng)計報表提供數(shù)據(jù)；

數(shù)倉為什么要分層

把復(fù)雜問題簡單化：把一個復(fù)雜的任務(wù)分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單，并且方便定位問題；

減少重復(fù)開發(fā)：通過中間層數(shù)據(jù)，能夠極大地減少重復(fù)計算，增加一次計算結(jié)果的復(fù)用性；

隔離原始數(shù)據(jù)：使真實數(shù)據(jù)與統(tǒng)計數(shù)據(jù)解耦開；

數(shù)據(jù)倉庫的輸入數(shù)據(jù)源和輸出系統(tǒng)

輸入系統(tǒng)：埋點產(chǎn)生的用戶行為數(shù)據(jù)、JavaEE后臺產(chǎn)生的業(yè)務(wù)數(shù)據(jù)；

輸出系統(tǒng)：報表系統(tǒng)、用戶畫像系統(tǒng)、推薦系統(tǒng)；

維、維度、維度表和事實表

0 來自知乎的一個簡單解釋

1 維

維是關(guān)于一個組織想要記錄的視角或觀點。

參考: 維的百度百科.

2 維度

維度是對數(shù)據(jù)進(jìn)行分析時采取的一個角度。比如分析產(chǎn)品銷售情況，可以按類別來分析，也可以按區(qū)域來分析，于是類別和區(qū)域就構(gòu)成了兩個維度；

每個維度可以有子維度；

3 維度表

維度表是對每個維至少使用一個表來存放維的層次、成員類別等維的描述信息；

維度表和事實表通過主鍵和外鍵聯(lián)系在一起，形成星型，也稱為“星型模式”；

對層次復(fù)雜的維，為避免冗余數(shù)據(jù)占用過大的存儲空間，可以使用多個表描述，即“雪花型模式”；

維度表示例（產(chǎn)品維度表）：Prod_ID,Product_Name,Category,Color,Size,Price

特性：

記錄數(shù)少，上千左右；

大多是文字信息；

信息具有層次結(jié)構(gòu)；

只有一個主鍵；

信息可修改；

4 事實表

事實表用來存儲數(shù)據(jù)和維關(guān)鍵字，是依據(jù)某些維度數(shù)據(jù)聚合后生成的結(jié)果表；

事實表示例：

特性：

大量數(shù)據(jù)行，存儲TB級；

主要是數(shù)值，少量文字或多媒體；

有和維度表連接的外鍵；

主要是靜態(tài)數(shù)據(jù)和聚集數(shù)據(jù)；

5 星型模式結(jié)構(gòu)示意圖

數(shù)據(jù)湖 VS 數(shù)據(jù)倉庫

1 本質(zhì)區(qū)別

數(shù)據(jù)湖和數(shù)據(jù)倉庫是存儲大數(shù)據(jù)的兩種不同策略；

最本質(zhì)的區(qū)別是：數(shù)據(jù)倉庫中存儲的都是結(jié)構(gòu)化數(shù)據(jù)，需要提前設(shè)計好模式（schema）；而數(shù)據(jù)湖可以存儲結(jié)構(gòu)化和非結(jié)構(gòu)化的數(shù)據(jù)，無法預(yù)先定義好結(jié)構(gòu)；

2 存儲位置

數(shù)據(jù)倉庫要有結(jié)構(gòu)，大部分都是基于關(guān)系型模型；

而數(shù)據(jù)湖通常位于分布式存儲如Hadoop或類似的大數(shù)據(jù)存儲中；

3 數(shù)據(jù)源

數(shù)據(jù)倉庫的數(shù)據(jù)很多時候是從OLTP應(yīng)用的結(jié)構(gòu)化數(shù)據(jù)庫中提取的，用于支持內(nèi)部的業(yè)務(wù)部門（銷售、市場、運營等）進(jìn)行業(yè)務(wù)分析；

數(shù)據(jù)湖的數(shù)據(jù)來源可以是結(jié)構(gòu)化的，也可以是非結(jié)構(gòu)化的，例如：業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫、IOT設(shè)備、社交媒體、移動APP等；

4 用戶

數(shù)據(jù)倉庫主要是對業(yè)務(wù)系統(tǒng)對大量業(yè)務(wù)數(shù)據(jù)進(jìn)行統(tǒng)計分析，所以會應(yīng)用數(shù)據(jù)分析的部門是數(shù)據(jù)倉庫的主要用戶，例如：銷售部、市場部、運營部、總裁辦等；

數(shù)據(jù)湖中的數(shù)據(jù)都是原始數(shù)據(jù)，是未經(jīng)整理的，更適合數(shù)據(jù)科學(xué)家，通過應(yīng)用模型、技術(shù)發(fā)掘數(shù)據(jù)中的價值，去解決企業(yè)中的業(yè)務(wù)問題；

5 數(shù)據(jù)質(zhì)量

數(shù)據(jù)倉庫非常重視數(shù)據(jù)質(zhì)量，數(shù)據(jù)都是經(jīng)過處理的，像數(shù)據(jù)中臺有很大一塊是數(shù)據(jù)質(zhì)量管理、數(shù)據(jù)資產(chǎn)管理等；

數(shù)據(jù)湖中數(shù)據(jù)可靠性較差，這些數(shù)據(jù)可能是任意狀態(tài)、任意形態(tài)的數(shù)據(jù)；

6 數(shù)據(jù)模式

數(shù)據(jù)倉庫在數(shù)據(jù)寫入前就要定義好模式（schema），例如：先建立模型、建立表結(jié)構(gòu)，然后導(dǎo)入數(shù)據(jù)，我們稱之為write-schema；

數(shù)據(jù)湖中的數(shù)據(jù)沒有沒有模式，直到用戶要訪問數(shù)據(jù)、使用數(shù)據(jù)才會建立schema，我們稱之為read-schema；

7 敏捷擴展性

數(shù)據(jù)倉庫的模式一旦建立，如果重新調(diào)整模式，往往代價很大，牽一發(fā)而動全身，所有相關(guān)的ETL程序可能都需要調(diào)整；

而數(shù)據(jù)湖非常靈活，可以根據(jù)需要重新配置結(jié)構(gòu)或者模式；

8 應(yīng)用

數(shù)據(jù)倉庫一般用于做批處理報告、BI、可視化等；

數(shù)據(jù)湖主要用于機器學(xué)習(xí)、預(yù)測分析、數(shù)據(jù)探索和分析；

2 基于Spring Boot的個人博客系統(tǒng)

項目介紹

• 項目介紹：個人博客系統(tǒng)包含前臺管理和后臺管理兩部分。前臺管理的核心功能包括：文章分頁展示、文章詳情查看、文章評論管理；后臺管理的核心功能包括：系統(tǒng)數(shù)據(jù)展示、文章發(fā)布、文章修改、文章刪除；同時，對系統(tǒng)前后臺用戶登錄管理進(jìn)行了統(tǒng)一實現(xiàn)。
• 軟件環(huán)境：前端使用Spring Boot支持的模板引擎Thymeleaf+jQuery完成頁面信息展示，后端使用Spring MVC+Spring Boot+MyBatis框架進(jìn)行整合開發(fā)。

3 基于Servlet和JSP的網(wǎng)上書城

0 項目介紹

• 項目介紹：網(wǎng)上書城包含面向用戶和面向管理員兩部分。面向用戶的部分包括：首頁、用戶注冊、購物、提交訂單、付款等模塊；面向管理員的部分包括：圖書管理、物流管理等模塊。
• 軟件環(huán)境：Servlet、JSP、Tomcat、MySQL等。

1 什么是Servlet

Servlet是一個Java類，是在服務(wù)器上運行以處理客戶端請求并作出響應(yīng)的程序。

2 Tomcat容器等級

Tomcat容器分四個等級，Servlet容器管理Context容器，一個Context對應(yīng)一個Web工程。

3 手工編寫一個Servlet

繼承HttpServlet；

重寫doGet()或doPost()方法；

在web.xml中注冊Servlet；

部署運行；

4 測試題

假設(shè)在helloapp應(yīng)用中有一個HelloServlet類，它在 web.xml文件中的配置如下:

<servlet> <servlet-name>HelloServlet</servlet-name> <servlet-class>org.javathinker.HelloServlet</servlet-class></servlet> <servlet-mapping> <servlet-name>HelloServlet</servlet-name> <url-pattern>/hello</url-pattern> </servlet-mapping>

那么在瀏覽器端訪問HelloServlet的URL是什么?

• 答：http://localhost:8080/helloapp/hello
• 解析：localhost是服務(wù)器主機名，也可以是IP地址127.0.0.1；8080是tomcat服務(wù)器的端口號；helloapp是web工程的上下文地址ContextRoot（一般情況下與web工程名一致）；最后是<url-pattern/>標(biāo)簽中的內(nèi)容。

5 Servlet執(zhí)行流程

6 Servlet生命周期

初始化階段：調(diào)用構(gòu)造方法創(chuàng)建Servlet實例，然后調(diào)用init()方法，在整個生命周期內(nèi)，init()只被調(diào)用一次；

響應(yīng)客戶端請求階段：調(diào)用service()方法。由service()方法根據(jù)提交方式選擇執(zhí)行doGet()或者doPost()方法；

終止階段：服務(wù)器關(guān)閉時，調(diào)用destroy()方法。在調(diào)用 destroy() 方法之后，servlet 對象被標(biāo)記為垃圾回收；

架構(gòu)圖

下圖展示了一個典型的 Servlet 生命周期方案。

第一個到達(dá)服務(wù)器的 HTTP 請求被委派到 Servlet 容器；

Servlet 容器在調(diào)用 service() 方法之前加載 Servlet；

然后 Servlet 容器處理由多個線程產(chǎn)生的多個請求，每個線程執(zhí)行一個單一的 Servlet 實例的 service() 方法；

7 Tomcat裝載Servlet的三種情況

Servlet容器啟動時自動裝載某些Servlet，實現(xiàn)它只需要在web.xml中的<Servlet></Servlet>之間添加如下代碼：<loadon-startup>1</loadon-startup>，數(shù)字越小優(yōu)先級越高；

Servlet容器啟動后，客戶端首次向Servlet發(fā)送請求；

Servlet類文件被更新后，會自動重新裝載Servlet；

8 Servlet與JSP的區(qū)別

Servlet是一個Java類，是在服務(wù)器上運行以處理客戶端請求并作出響應(yīng)的程序；

JSP是一種動態(tài)頁面技術(shù)，它的主要目的是將表示邏輯從Servlet中分離出來；

SUN 公司推出 JSP 技術(shù)的同時，也推出了兩種 Web 應(yīng)用程序的開發(fā)模式。即 JSP+JavaBean 和 Servlet+JSP+JavaBean；

JSP+JavaBean 中 JSP 用于處理用戶請求，JavaBean 用于封裝和處理數(shù)據(jù)。該模式只有視圖和模型，一般把控制器的功能交給視圖來實現(xiàn)，適合業(yè)務(wù)流程比較簡單的 Web 程序。JSP+JavaBean 模式在一定程度上實現(xiàn)了 MVC，即 JSP 將控制層和視圖層合二為一，JavaBean 為模型層；

Servlet+JSP+JavaBean 中 Servlet 用于處理用戶請求，JSP 用于數(shù)據(jù)顯示，JavaBean 用于數(shù)據(jù)封裝，適合復(fù)雜的 Web 程序。Servlet+JSP+JavaBean很好地實現(xiàn)了MVC，即Servlet擔(dān)當(dāng)控制層，JSP為視圖層，JavaBean為模型層；

9 Spring MVC和Servlet

Spring MVC簡化了寫Servlet類，由一個前端調(diào)度器接收所有請求，后臺寫相應(yīng)的Controller就好，而Servlet就是一個請求一個映射一個Servlet。

10 轉(zhuǎn)發(fā)和重定向的區(qū)別

forward（轉(zhuǎn)發(fā)）

是服務(wù)器請求資源，服務(wù)器直接訪問目標(biāo)地址的URL，把那個URL的響應(yīng)內(nèi)容讀取過來，然后把這些內(nèi)容再發(fā)給瀏覽器，瀏覽器根本不知道服務(wù)器發(fā)送的內(nèi)容從哪里來的，因為這個跳轉(zhuǎn)過程是在服務(wù)器實現(xiàn)的，并不是在客戶端實現(xiàn)的，所以客戶端并不知道這個跳轉(zhuǎn)動作，所以它的地址欄還是原來的地址。

redirect（重定向）

是服務(wù)端根據(jù)邏輯,發(fā)送一個狀態(tài)碼,告訴瀏覽器重新去請求那個地址.所以地址欄顯示的是新的URL.

轉(zhuǎn)發(fā)是服務(wù)器行為，重定向是客戶端行為。

區(qū)別：

從地址欄顯示來說

forward是服務(wù)器請求資源，服務(wù)器直接訪問目標(biāo)地址的URL，把那個URL的響應(yīng)內(nèi)容讀取過來，然后把這些內(nèi)容再發(fā)給瀏覽器，瀏覽器根本不知道服務(wù)器發(fā)送的內(nèi)容從哪里來的，所以它的地址欄還是原來的地址；
redirect是服務(wù)端根據(jù)邏輯發(fā)送一個狀態(tài)碼，告訴瀏覽器重新去請求某個地址.，所以地址欄顯示的是新的URL；

從數(shù)據(jù)共享來說

forward：轉(zhuǎn)發(fā)頁面和轉(zhuǎn)發(fā)到的頁面可以共享request里面的數(shù)據(jù)；
redirect：不能共享數(shù)據(jù)；

從運用地方來說

forward：一般用于用戶登陸的時候,根據(jù)角色轉(zhuǎn)發(fā)到相應(yīng)的模塊；
redirect：一般用于用戶注銷登陸時返回主頁面和跳轉(zhuǎn)到其它網(wǎng)站等；

從效率來說

forward：高；
redirect：低；

Servlet是線程安全的嗎？

Servlet不是線程安全的，多線程的讀寫會導(dǎo)致數(shù)據(jù)不同步的問題。

4 僵尸企業(yè)畫像及分類

僵尸企業(yè)是指缺乏盈利能力卻能夠以低于市場最優(yōu)利率成本獲得信貸資源，依靠外界輸血而缺乏自生能力的企業(yè)。僵尸企業(yè)是我國經(jīng)濟結(jié)構(gòu)轉(zhuǎn)型時期面臨的一個棘手問題，既影響經(jīng)濟效率，也蘊含金融風(fēng)險，處理這一問題首先需要對僵尸企業(yè)進(jìn)行識別和分類；

項目最終目標(biāo)是要實現(xiàn)單個企業(yè)畫像和批量企業(yè)畫像的功能。單個畫像模塊主要描述對單個企業(yè)畫像信息的特征數(shù)據(jù)進(jìn)行分析；批量畫像模塊是在單個畫像的基礎(chǔ)上進(jìn)行的，用戶通過將批量數(shù)據(jù)導(dǎo)入系統(tǒng)中，然后進(jìn)行批量數(shù)據(jù)分析；

畫像算法采用了PCA+XGBoost算法。通過PCA（主成分分析）得到了特征項；接著，將根據(jù)特征項重新整理的數(shù)據(jù)放入XGBoost模型中進(jìn)行訓(xùn)練，不斷調(diào)整參數(shù)，使得驗證集有一個比較高的準(zhǔn)確率；

5 降低汽油精制過程中的辛烷值損失模型

辛烷值是反映汽油燃燒性能的最重要指標(biāo)，現(xiàn)有技術(shù)在對催化裂化汽油進(jìn)行脫硫和降烯烴過程中，普遍降低了汽油辛烷值。辛烷值每降低1個單位，相當(dāng)于損失約150元/噸。由于煉油工藝過程的復(fù)雜性以及設(shè)備的多樣性，它們的操作變量繁多（數(shù)百個）且之間具有高度非線性和相互強耦聯(lián)的關(guān)系，因此考慮用非線性的機器學(xué)習(xí)算法模型來建模；

方案主要利用了機器學(xué)習(xí)技術(shù)來解決化工過程建模問題，先通過PCA降維尋找影響辛烷值損失值的最重要的30個變量，然后建立基于XGBoost的辛烷值損失預(yù)測模型，從而為汽油化學(xué)工藝提供參考；

6 天然氣股份有限公司場站智能化分析及控制軟件開發(fā)

異常檢測研發(fā)目標(biāo)

故障檢測系統(tǒng)將從以下幾個方面為天然氣儲運場站的生產(chǎn)和儲運提供技術(shù)支持：
（1）對場站安全態(tài)勢進(jìn)行全方位刻畫。目前，公司對場站的各種設(shè)備進(jìn)行了實時檢測，在生產(chǎn)過程中利用計算機控制系統(tǒng)收集了計量設(shè)備、分離設(shè)備和壓縮機組等生產(chǎn)設(shè)備的運行狀態(tài)，故障檢測系統(tǒng)將對這些數(shù)據(jù)進(jìn)行清洗、挖掘和分析，以實現(xiàn)對場站安全態(tài)勢的全方位刻畫；
（2）對場站安全態(tài)勢進(jìn)行預(yù)測。天然氣場站的儲運數(shù)據(jù)具有動態(tài)性、非線性和隨機性等復(fù)雜特性，故障檢測系統(tǒng)將結(jié)合機器學(xué)習(xí)、過程檢測等技術(shù)對數(shù)據(jù)進(jìn)行科學(xué)建模，預(yù)測可能出現(xiàn)的故障；
（3）降低場站事故發(fā)生率。在對安全態(tài)勢合理預(yù)測的基礎(chǔ)上，預(yù)知可能出現(xiàn)的故障，及時檢查清除故障，保證天然氣生產(chǎn)和儲運的平穩(wěn)運行，降低因天然氣運行設(shè)備老化、損壞、維護(hù)不及時等原因造成的事故發(fā)生率。

異常檢測設(shè)計方案

異常檢測系統(tǒng)的主要功能在于高效評價設(shè)備運行工況，預(yù)先發(fā)現(xiàn)運行故障，快速定位故障原因，為提高場站生產(chǎn)管理的安全級別提供決策依據(jù)。設(shè)計方案主要結(jié)合了機器學(xué)習(xí)、大數(shù)據(jù)管理、過程檢測等技術(shù)，此外還參考了天然氣領(lǐng)域的相關(guān)知識。

具體來說，就是對單個傳感器得到的數(shù)據(jù)和多個傳感器得到的數(shù)據(jù)采用不同的模型進(jìn)行處理。其中，使用LSTM模型對單點數(shù)據(jù)進(jìn)行處理，判斷該變量是否產(chǎn)生故障；使用BP神經(jīng)網(wǎng)絡(luò)對多點支路數(shù)據(jù)進(jìn)行故障檢測，判斷該多點支路是否有故障產(chǎn)生。

單點檢測

單點是指單個傳感器檢測點，單點異常檢測實際上是對一維時間序列上的異常點進(jìn)行檢測。

由于天然氣數(shù)據(jù)不是一個純粹的隨機時間序列，它的時間序列可能存在某種長期依賴關(guān)系，而LSTM模型可以捕捉到這種長期依賴關(guān)系，因此考慮建立LSTM模型進(jìn)行天然氣數(shù)據(jù)的單點故障檢測。

LSTM，即長短期記憶網(wǎng)絡(luò)，是為了解決一般的RNN（循環(huán)神經(jīng)網(wǎng)絡(luò)）存在的長期依賴問題而專門設(shè)計出來的，適合于處理和預(yù)測時間序列中間隔和延遲非常長的重要事件。

（1）數(shù)據(jù)預(yù)處理

• 首先從CSV文件中提取出需要進(jìn)行異常檢測的一維時間序列，然后對數(shù)據(jù)進(jìn)行z-score標(biāo)準(zhǔn)化，即0均值標(biāo)準(zhǔn)化，將數(shù)據(jù)變換為均值為0、標(biāo)準(zhǔn)差為1的標(biāo)準(zhǔn)正態(tài)分布。

（2）劃分訓(xùn)練集、驗證集和測試集

• 將處理后的數(shù)據(jù)按照7：2：1的比例將數(shù)據(jù)劃分為訓(xùn)練集、驗證集和測試集。

（3）設(shè)定模型參數(shù)

（4）訓(xùn)練模型

• 將處理后的數(shù)據(jù)加載到pandas的數(shù)據(jù)框架中，它將輸出 ( N, W, F ) 三維numpy數(shù)組，其中N表示訓(xùn)練數(shù)據(jù)中的序列數(shù)，W表示序列長度，F表示每個序列的特征數(shù)；然后將數(shù)組饋送進(jìn)LSTM模型中。

（5）通過模型進(jìn)行預(yù)測

• LSTM模型使用訓(xùn)練集數(shù)據(jù)的第一部分（滑動窗口大小）初始化一次訓(xùn)練窗口，預(yù)測出單個點的值，然后不斷移動滑動窗口去預(yù)測下一個點的值。以此類推，LSTM模型可以預(yù)測出一個完整的時間序列。

（6）異常檢測與判定

將預(yù)測出來的數(shù)據(jù)和真實的測試集數(shù)據(jù)進(jìn)行對比，比較數(shù)據(jù)的真實值是否在其預(yù)測值的三倍標(biāo)準(zhǔn)差內(nèi)，如果在，則表明該數(shù)據(jù)為正常數(shù)據(jù)，否則該數(shù)據(jù)為異常數(shù)據(jù)。

多點檢測

多點是指多個傳感器檢測點。

使用BP神經(jīng)網(wǎng)絡(luò)做多點故障檢測：通過研究實測數(shù)據(jù)，利用采集的壓力、溫度及時間點等數(shù)據(jù)在BP神經(jīng)網(wǎng)絡(luò)中進(jìn)行訓(xùn)練學(xué)習(xí)和預(yù)測評估。

總結(jié)

以上是生活随笔為你收集整理的项目整理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。