cow資料庫

1. 雲計算核心技術Docker教程：Docker存儲寫入時復制（CoW）策略

【點擊右上角加'關注'，全國產經信息不錯過】

寫時復制是一種共享和復制文件的策略，可最大程度地提高效率。如果文件或目錄位於映像的較低層中，而另一層（包括可寫層）需要對其進行讀取訪問，則它僅使用現有文件。另一層第一次需要修改文件時（在構建映像或運行容器時），將文件復制到該層並進行修改。這樣可以將I / O和每個後續層的大小最小化。這些優點將在下面更深入地說明。

共享可以提升較小的圖像

當您用於docker pull從存儲庫中下拉映像時，或者當您從本地尚不存在的映像中創建容器時，每個層都會被分別下拉，並存儲在Docker的本地存儲區域中，該區域通常/var/lib/docker/在Linux主機上。在此示例中，您可以看到這些層被拉出：

$ docker pull ubuntu:18.04

18.04: Pulling from library/ubuntu

f476d66f5408: Pull complete

8882c27f669e: Pull complete

d9af21273955: Pull complete

f5029279ec12: Pull complete

Digest: sha256:

Status: Downloaded newer image for ubuntu:18.04

這些層中的每一層都存儲在Docker主機的本地存儲區域內的自己的目錄中。要檢查文件系統上的各層，請列出的內容/var/lib/docker/。本示例使用overlay2 存儲驅動程序：

$ ls /var/lib/docker/overlay2

l

目錄名稱與層ID不對應（自Docker 1.10開始就是如此）。

現在，假設您有兩個不同的Dockerfile。您使用第一個創建名為的圖像acme/my-base-image:1.0。

# syntax=docker/dockerfile:1

FROM ubuntu:18.04

COPY . /app

第二acme/my-base-image:1.0層基於，但具有一些附加層：

# syntax=docker/dockerfile:1

FROM acme/my-base-image:1.0

CMD /app/hello.sh

第二個圖像包含第一個圖像的所有層，再加上帶有CMD指令的新層，以及一個可讀寫容器層。Docker已經具有第一個映像中的所有層，因此不需要再次將其拉出。這兩個圖像共享它們共有的任何圖層。

如果從兩個Dockerfile構建映像，則可以使用docker image ls和 docker history命令來驗證共享層的密碼ID是否相同。

1.創建一個新目錄cow-test/並更改到該目錄中。

2.在中cow-test/，創建一個hello.sh具有以下內容的新文件：

#!/bin/sh

echo "Hello world"

保存文件，並使其可執行：

chmod +x hello.sh

3.將上面第一個Dockerfile的內容復制到一個名為的新文件中 Dockerfile.base。

4.將上面第二個Dockerfile的內容復制到一個名為的新文件中 Dockerfile。

5.在cow-test/目錄中，構建第一個映像。不要忘記.在命令中包含final 。設置了PATH，它告訴Docker在哪裡尋找需要添加到映像中的任何文件。

$docker build -t acme/my-base-image:1.0 -f Dockerfile.base .

6.建立第二張鏡像。

$docker build -t acme/my-final-image:1.0 -f Dockerfile .

7.檢查鏡像的大小：

$docker image ls

8.檢出構成每個鏡像的圖層：

$docker history bd09118bcef6

請注意，除了第二個圖像的頂層以外，所有層都是相同的。所有其他層在兩個圖像之間共享，並且僅在中存儲一次/var/lib/docker/。實際上，新層根本不佔用任何空間，因為它不更改任何文件，而僅運行命令。

全國產經平台聯系電話：010-65367702，郵箱：[email protected]，地址：北京市朝陽區金台西路2號人民日報社

2. hudi流寫入如何保證事務

方法如下：
1. 項目背景
傳統數倉的組織架構是針對離線數據的OLAP（聯機事務分析）需求設計的，常用的導入數據方式為採用sqoop或spark定時作業逐批將業務庫數據導入數倉。隨著數據分析對實時性要求的不斷提高，按小時、甚至分鍾級的數據同步越來越普遍。由此展開了基於spark/flink流處理機制的（准）實時同步系統的開發。

然而實時同步數倉從一開始就面臨如下幾個挑戰：

小文件問題。不論是spark的microbatch模式，還是flink的逐條處理模式，每次寫入HDFS時都是幾M甚至幾十KB的文件。長時間下來產生的大量小文件，會對HDFS namenode產生巨大的壓力。
對update操作的支持。HDFS系統本身不支持數據的修改，無法實現同步過程中對記錄進行修改。
事務性。不論是追加數據還是修改數據，如何保證事務性。即數據只在流處理程序commit操作時一次性寫入HDFS，當程序rollback時，已寫入或部分寫入的數據能隨之刪除。
Hudi是針對以上問題的解決方案之一。以下是對Hudi的簡單介紹，主要內容翻譯自官網。

2. Hudi簡介
2.1 時間線（Timeline）
Hudi內部按照操作時刻（instant）對表的所有操作維護了一條時間線，由此可以提供表在某一時刻的視圖，還能夠高效的提取出延後到達的數據。每一個時刻包含：

時刻行為：對表操作的類型，包含：
commit：提交，將批次的數據原子性的寫入表；
clean： 清除，後台作業，不斷清除不需要的舊得版本的數據；
delta_commit：delta 提交是將批次記錄原子性的寫入MergeOnRead表中，數據寫入的目的地是delta日誌文件；
compacttion：壓縮，後台作業，將不同結構的數據，例如記錄更新操作的行式存儲的日誌文件合並到列式存儲的文件中。壓縮本身是一個特殊的commit操作；
rollback：回滾，一些不成功時，刪除所有部分寫入的文件；
savepoint：保存點，標志某些文件組為「保存的「，這樣cleaner就不會刪除這些文件；
時刻時間：操作開始的時間戳；
狀態：時刻的當前狀態，包含：
requested 某個操作被安排執行，但尚未初始化
inflight 某個操作正在執行
completed 某一個操作在時間線上已經完成
Hudi保證按照時間線執行的操作按照時刻時間具有原子性及時間線一致性。

2.2 文件管理
Hudi表存在在DFS系統的 base path（用戶寫入Hudi時自定義） 目錄下，在該目錄下被分成不同的分區。每一個分區以 partition path 作為唯一的標識，組織形式與Hive相同。

每一個分區內，文件通過唯一的 FileId 文件id 劃分到 FileGroup 文件組。每一個FileGroup包含多個 FileSlice 文件切片，每一個切片包含一個由commit或compaction操作形成的base file 基礎文件（parquet文件），以及包含對基礎文件進行inserts/update操作的log files 日誌文件（log文件)。Hudi採用了MVCC設計，compaction操作會將日誌文件和對應的基礎文件合並成新的文件切片，clean操作則刪除無效的或老版本的文件。

2.3 索引
Hudi通過映射Hoodie鍵（記錄鍵+ 分區路徑）到文件id，提供了高效的upsert操作。當第一個版本的記錄寫入文件時，這個記錄鍵值和文件的映射關系就不會發生任何改變。換言之，映射的文件組始終包含一組記錄的所有版本。

2.4 表類型&查詢
Hudi表類型定義了數據是如何被索引、分布到DFS系統，以及以上基本屬性和時間線事件如何施加在這個組織上。查詢類型定義了底層數據如何暴露給查詢。

| 表類型 | 支持的查詢類型 | | :-------------------- | :----------------------------- | | Copy On Write寫時復制 | 快照查詢 + 增量查詢 | | Merge On Read讀時合並 | 快照查詢 + 增量查詢 + 讀取優化 |

2.4.1 表類型
Copy On Write：僅採用列式存儲文件（parquet）存儲文件。更新數據時，在寫入的同時同步合並文件，僅僅修改文件的版次並重寫。

Merge On Read：採用列式存儲文件（parquet）+行式存儲文件（avro）存儲數據。更新數據時，新數據被寫入delta文件並隨後以非同步或同步的方式合並成新版本的列式存儲文件。

| 取捨 | CopyOnWrite | MergeOnRead | | :----------------------------------- | :---------------------- | :-------------------- | | 數據延遲 | 高 | 低 | | Update cost (I/O)更新操作開銷（I/O） | 高（重寫整個parquet） | 低（追加到delta記錄） | | Parquet文件大小 | 小（高更新（I/O）開銷） | 大（低更新開銷） | | 寫入頻率 | 高 | 低（取決於合並策略） |

2.4.2 查詢類型
快照查詢：查詢會看到以後的提交操作和合並操作的最新的錶快照。對於merge on read表，會將最新的基礎文件和delta文件進行合並，從而會看到近實時的數據（幾分鍾的延遲）。對於 on write表，當存在更新/刪除操作時或其他寫操作時，會直接代替已有的parquet表。
增量查詢：查詢只會看到給定提交/合並操作之後新寫入的數據。由此有效的提供了變更流，從而實現了增量數據管道。
讀優化查詢：查詢會看到給定提交/合並操作之後表的最新快照。只會查看到最新的文件切片中的基礎/列式存儲文件，並且保證和非hudi列式存儲表相同的查詢效率。
| 取捨 | 快照 | 讀取優化 | | :------- | :------------------------------------------------------ | :------------------------------------ | | 數據延遲 | 低 | 高 | | 查詢延遲 | 高（合並基礎/列式存儲文件 + 行式存儲delta / 日誌 文件） | 低（原有的基礎/列式存儲文件查詢性能） |

3. Spark結構化流寫入Hudi
以下是整合spark結構化流+hudi的示意代碼，由於Hudi OutputFormat目前只支持在spark rdd對象中調用，因此寫入HDFS操作採用了spark structured streaming的forEachBatch運算元。具體說明見注釋。

4. 測試結果
受限於測試條件，這次測試沒有考慮update操作，而僅僅是測試hudi對追加新數據的性能。

數據程序一共運行5天，期間未發生報錯導致程序退出。

kafka每天讀取數據約1500萬條，被消費的topic共有9個分區。

幾點說明如下

1 是否有數據丟失及重復

由於每條記錄的分區+偏移量具有唯一性，通過檢查同一分區下是否有偏移量重復及不連續的情況，可以斷定數據不存丟失及重復消費的情況。

2 最小可支持的單日寫入數據條數

數據寫入效率，對於cow及mor表，不存在更新操作時，寫入速率接近。這本次測試中，spark每秒處理約170條記錄。單日可處理1500萬條記錄。

3 cow和mor表文件大小對比

每十分鍾讀取兩種表同一分區小文件大小，單位M。結果如下圖，mor表文件大小增加較大，佔用磁碟資源較多。不存在更新操作時，盡可能使用cow表。

3. osg模型能在osgviewer中顯示，不能在vs中顯示

cow.osg模型具體放在什麼路徑下？
工程當前路徑下，則可以直接viewer.setSceneData(osgDB::readNodeFile("cow.osg"));
模型文件cow.osg正常放在osg庫的data文件夾下