1. 物件儲存
1.1. 物件儲存包含各種形狀和大小的物件
-
1.1.1. Amazon S3、Azure Blob Storage和Google Cloud Storage(GCS)是廣泛使用的物件儲存
-
1.1.2. 許多雲資料倉儲（以及越來越多的資料庫）利用物件儲存作為其儲存層，而云資料湖通常位於物件儲存上
-
1.1.3. 物件儲存是一個用於不可改變的資料物件的鍵值儲存
-
1.1.3.1. 物件不支援隨機寫入或追加操作
-
1.1.3.2. 它們作為位元組流被寫入一次
1.1.3.2.1. 在這個初始寫入之後，物件就變得不可改變了
1.1.3.2.2. 要改變一個物件中的資料或向其追加資料，我們必須重寫整個物件
-
-
1.1.4. 物件儲存通常支援透過範圍請求進行隨機讀取，但這些查詢的效能可能比從儲存在SSD上的資料中隨機讀取要差得多
-
1.1.5. 物件儲存不需要支援鎖或更改同步，允許跨大規模磁碟叢集儲存資料
- 1.1.5.1. 物件儲存支援在許多磁碟上進行效能極高的並行流寫入和讀取，這種並行性對工程師來說是隱藏的，他們可以簡單地處理流，而不是與單個磁碟進行通訊
1.2. 雲物件儲存
-
1.2.1. 雲物件儲存最吸引人的特點之一是它可以直接管理和使用
- 1.2.1.1. 物件儲存可以說是第一批“無伺服器”服務之一，工程師不需要考慮底層伺服器叢集或磁碟的特性
-
1.2.2. 典型的雲物件儲存將資料儲存在幾個可用區，極大地降低了儲存完全離線或以不可恢復的方式丟失的機率
-
1.2.2.1. 耐用性和可用性是內建於成本中的
-
1.2.2.2. 雲端儲存供應商以折扣價格提供其他儲存類別，以換取降低的耐用性或可用性
-
-
1.2.3. 雲物件儲存是分離計算和儲存的一個關鍵因素，允許工程師用短暫的叢集處理資料，並按需擴大和減少這些叢集
- 1.2.3.1. 大多陣列織將把資料處理轉移到雲中，使用物件儲存作為基本的儲存和服務層，同時在短暫的叢集上處理資料
1.3. 在物件儲存中，可用的儲存空間也是高度可擴充套件的，這是大資料系統的理想特徵
-
1.3.1. 儲存空間受到儲存提供商所擁有的磁碟數量的限制，但這些提供商處理的資料都是艾位元組的
-
1.3.2. 在雲環境中，可用的儲存空間幾乎是無限的
-
1.3.3. 公有云客戶對儲存空間的主要限制是預算
-
1.3.4. 工程師可以迅速為專案儲存大量的資料，而不需要提前幾個月為必要的伺服器和磁碟做計劃
1.4. 資料工程應用程式的物件儲存
-
1.4.1. 從資料工程的角度來看，物件儲存為大批次讀取和批次寫入提供了出色的效能
-
1.4.2. 物件儲存不適合每秒有許多小更新的事務工作負載，這些用例最好由事務資料庫或塊儲存系統來完成
-
1.4.3. 物件儲存對於低更新率的操作來說效果很好，每個操作都會更新大量的資料
-
1.4.4. 物件儲存現在是資料湖儲存的黃金標準
- 1.4.4.1. 在資料湖的早期，一次寫入，多次讀取(Write Once，Read Many，WORM)是操作標準，但這不是HDFS和物件儲存的侷限，而與管理資料版本和檔案的複雜性有很大關係
-
1.4.5. 物件儲存是這些結構化資料應用之外的任何格式的非結構化資料的理想儲存庫
-
1.4.6. 物件儲存可以存放任何二進位制資料，不受型別或結構的限制，並且經常在原始文字、影像、影片和音訊的ML管道中發揮作用
1.5. 物件尋找
-
1.5.1. 與檔案儲存不同，物件儲存不利用目錄樹來尋找物件
-
1.5.2. 物件儲存使用一個頂級的邏輯容器，並透過鍵來引用物件
1.6. 物件的一致性和版本管理
-
1.6.1. 物件儲存不支援原地更新或追加
-
1.6.2. 最終一致性的最終部分意味著，在足夠長的時間過去後，儲存叢集達到一個狀態，即只返回物件的最新版本
-
1.6.3. 物件版本與物件一致性密切相關
-
1.6.4. 物件的歷史版本通常具有與當前版本相同的相關儲存成本
-
1.6.5. 生命週期策略允許在滿足某些條件時自動刪除舊的物件版本
1.7. 儲存類別和層級
-
1.7.1. 雲供應商現在提供不同的儲存等級，以降低訪問量或降低耐用性為交換條件，對資料儲存定價進行折扣
-
1.7.2. 許多儲存層仍然使資料高度可用，但以高的檢索成本換取少的儲存成本
-
1.7.3. 在減少訪問的層級中，更進一步的是S3 Glacier的歸檔層級
-
1.7.3.1. 資料恢復需要12小時
-
1.7.3.2. 這種儲存類別是為那些將被儲存7～10年，每年只被訪問1～2次的資料而設計的
-
1.8. 物件儲存支援的檔案系統
-
1.8.1. 高速的事務寫入將使物件儲存的更新能力不堪重負
-
1.8.2. 將物件儲存作為一個本地檔案系統掛載，對於不經常更新的檔案來說是很好的
2. 快取和基於記憶體的儲存系統
2.1. RAM提供了出色的低延遲和高傳輸速度
-
2.1.1. 基於RAM的儲存系統一般專注於快取應用程式，呈現資料的快速訪問和高頻寬
-
2.1.2. 出於保留的目的，資料一般應被寫入更持久的介質中
2.2. 分散式記憶體快取系統(Memcached)是一個鍵值儲存，用於快取資料庫查詢結果、API呼叫響應等
-
2.2.1. Memcached使用簡單的資料結構，支援字串或整數型別
-
2.2.2. Memcached可以以非常低的延遲提供結果，同時也減輕了後端系統的負擔
2.3. Redis還建立了多種永續性機制，包括快照和日記
3. Hadoop分散式檔案系統
3.1. Hadoop分散式檔案系統基於谷歌檔案系統(Google File System，GFS)，最初是為了用MapReduce程式設計模型處理資料而設計的
3.2. Hadoop將大檔案分成塊，即大小小於幾百兆位元組的資料塊
3.3. Hadoop不是簡單的一個儲存系統
- 3.3.1. Hadoop將計算資源與儲存節點結合起來，以實現就地資料處理
3.4. HDFS仍然在各種應用程式和組織中廣泛使用
- 3.4.1. 純粹的MapReduce程式設計模型已經被淘汰了
3.5. HDFS是目前許多大資料引擎的關鍵成分
4. 流式儲存
4.1. 流資料與非流資料有不同的儲存要求
-
4.1.1. 在訊息佇列中，儲存的資料是時間性的，預計在一定時間後會消失
-
4.1.2. Kafka透過將舊的、不經常訪問的訊息推送到物件儲存中來支援無限期的資料保留
-
4.1.3. Kafka的競爭對手（包括Amazon Kinesis、Apache Pulsar和Google Cloud Pub/Sub）也支援長期資料保留
4.2. 重放允許流媒體系統返回一系列的歷史儲存資料
-
4.2.1. 重放是流式儲存系統的標準資料檢索機制
-
4.2.2. 重放可以用來在一個時間範圍內執行批處理查詢，也可以用來重新處理流管道中的資料
4.3. 事務資料庫是最早的實時查詢引擎，資料一經寫入就會被查詢
5. 索引、分割槽和聚類
5.1. 索引為特定欄位提供了一個表格圖，並允許極快地查詢個別記錄
-
5.1.1. 如果沒有索引，則資料庫將需要掃描整個表來找到滿足WHERE條件的記錄
-
5.1.2. 索引也可以應用於其他列，以滿足特定應用程式的需要
-
5.1.3. 使用索引，一個RDBMS可以每秒查詢和更新數千條記錄
5.2. 列式序列化
-
5.2.1. 列式序列化允許資料庫只掃描特定查詢所需的列，有時會極大地減少從磁碟上讀取的資料量
-
5.2.2. 按列排列的資料將相似的值放在一起，產生高壓縮率，而壓縮開銷最小，使得資料可以更快地從磁碟和網路上被掃描
-
5.2.3. 列式資料庫在事務用例（即當我們試圖非同步查詢大量的單獨行時）中的表現很差
-
5.2.4. 當必須掃描大量的資料（例如，用於複雜的資料轉換、聚合、統計計算或對大型資料集的複雜條件進行評估）時，它們的表現非常好
-
5.2.5. 列式資料庫允許快速的掃描速度，但儘可能減少掃描的資料量仍然是有幫助的
5.3. Snowflake微分割槽
-
5.3.1. Snowflake微分割槽，因為它是列儲存方法最近發展和演變的一個好例子
-
5.3.2. 微分割槽是指未壓縮的大小在50兆～500兆位元組之間的行集