數據分析從零開始 - (4) 檔案儲存

數據分析的各階段，都有可能需要儲存檔案。而資料的來源，也有可能是已經存在某處的檔案。

(非檔案儲存？參考註1)

越重要的資料，就得更重視儲存的方式。而越是大量複雜的資料，就勢必要對資料存儲做好預先的規劃。

雲端儲存 - 巨量資料

近年來流行的Cloud Storage，通常是將資料以網路上傳(註2)至某個雲端服務公司。最典型的例子是Amazon提供的S3服務。AWS S3因為使用者眾，以至於其的S3 rest http介面，甚至演變成某種標準。許多類似的服務，或者儲存廠商，會以「相符S3 rest api標準」當作重要的功能或賣點！(註3)

顯而易見，雲端儲存具有管理上的優點。理論上，不用擔心備份，擴充，網路，電力，硬體更換...等等營運上的問題。

然而，巨量資料雲端儲存也有幾個顯而易見的缺點

1. 錢：雲端儲存的費用並不便宜。單以S3為例，2016年的每1T資料光是「存著」的費用，一年就高達276美金，相當於8832台幣。這還未計算上傳下載等操作費用。倘若要進行「長期保存」其費用相當驚人。也因此雲端儲存商針對長期保存的檔案也提供比較便宜的方案。然而，仍然是某種成本。然而，自行巨量儲存也要考慮費用，特別是

2. 營運：單純僅只使用雲端儲存，對整體營運的好處有限。並且，企業還是需要自行考慮檔案的有效使用問題。

3. 移轉：儲存到雲端之後，一旦量變大，很難轉換營運商。

雲端儲存 - 少量資料

至於極少量資料，例如10G之內。無論是企業或者是個人，都可以取得幾乎免費的儲存空間。

但也因為是免費空間，不太可能保證資料不會遺失。可是非常適用於新創公司，或者SOHO族。

最好是利用兩個以上的雲端儲存服務，儲存重要的檔案。

例如：利用googledrive + yandex.disk 儲存重要的檔案。這樣幾乎可以確保檔案不會因為單一基礎建設有問題，而導致重要檔案遺失。(註4)

實際作法：

(1) 尋找適當的工具或API，用以一次性整合這兩個雲端儲存

(2) 設定自動化方式，或者撰寫自動化程式

(3) 定時執行自動化備份，同時備份兩份到不同的雲端服務

Yandex disk的範例程式(參考這裡)

自行儲存 - 巨量資料

企業組織非常有可能需要自行處理檔案儲存。無論是因為技術因素或者法律因素。

傳統上儲存會用硬體商的解決方案，近年來多了分散式檔案系統可以考慮。

自行儲存，一樣要考慮錢(費用)，營運。

1. 錢(費用)

    - 硬體費用：必須考慮長期硬體維護的費用
    - 軟體費用：授權或者購買維護
    - 人的費用：必須使用假設的最大值！

2. 營運

    - 如何讓其他系統使用
    - 有問題的時候怎麼辦
    - 備份與災難復原 


傳統巨量檔案資料，是購買netapp之類的硬體解決方案，配合網路架構，讓企業的巨量資料有集中管理的地方。2000年之後，分散式檔案系統因為效率和成本的關係，慢慢變成另一個可行的選項。

早期使用分散式檔案系統管理者，要跨越比較高的技術門檻，這幾年分散式檔案系統日漸成熟，管理也越趨方便。常見的有：(在這頁wiki上有詳盡的清單。)

(1) glusterfs
(2) ceph
(3) HDFS
(4) mooseFs
(5) mogilefs
(6) GridFS
(7) Lustrefs


這些分散式檔案系統各具特色，大部分都可以無償取得使用權。然而，有些需要額外的知識或技能才有辦法長期維護。

因此，如果可預期的資料量，以及資料存取技術與成本，小於硬碟技術的成長。使用分散式檔案系統不見得有利。

硬碟的技術符合約略的摩爾定律。在1996年，每1G的硬碟約127美金，2006年，每1G的硬碟價格為0.3美金，但是在2016年，每1G的硬碟價格已經小於0.03美金。（參考這裡）

除了價格逐年降低之外，存取速度也是逐年增長。如果預期資料成長量並不高，其實單就更換更換同價格的硬體設備搞不好也就夠了。

然而，巨量資料的增長往往遠超過預期，尤其近年來大資料分析蔚為風潮的情況下，盡可能保留資料便於未來使用成為企業組織對資訊科技的期待。也因此，使用分散式檔案儲存的組織越來越多。

選用分散式檔案系統，必須考慮：

(1) 使用目的和環境條件
(2) 營運計畫
(3) 實際測試


考慮雖然需要詳盡，但是這些「考慮」都是為了配合實際運作。因此，按照上述的考量，擬定可以「每日」有進展的「逐步」前進的計畫，是讓分散式系統成功運作的最好作法。

舉個例子：

(1) 使用目的和環境條件：要能夠簡單擴增(scale-out)，並且能利用現有已經存在的NAS/SAN，而且非常容易營運與維護。檔案不需要striping，存取效能一般即可。

(2) 營運計劃摘要：一開始預計使用12台機器，共48顆硬碟。未來一年可能擴增到20台機器，80顆以上硬碟。總資料量可能成長為120TB。僅有一位開發維運人員(devops)。

(3)實際測試：實際分別以4台VM測試過glusterfs, mogilefs, ceph, Lustrefs。其中以mogilefs最為簡單使用。

自行儲存 - 少量資料

少量檔案的儲存，仍然附著在其他系統上。例如email上的附件，版本控制系統，wiki上的附件等等。

大部分的組織，很少著重於少量資料的整體計畫。大多數僅只為「安全性」的規範。例如客戶資料不得外洩之類。實務上，完全依賴個人行為。

現在，大部分的作業系統，都已經可以對其下的檔案做全文檢索(例如mac finder)，而也都支援某種程度的備份功能。

摘要

	巨量資料	少量資料
雲端儲存	錢, 營運, 移轉	考慮  (1) 自動化
自行儲存	(1) 傳統NAS  (2)分散式檔案系統	考慮  (1) 傳統備份  (2) 全文檢索

---

註1：非檔案儲存有傳統的RDB(例如Mysql, Oracle), Document DB(例如Lotus Notes), 有比較新潮的nosql (HDFS, mongodb, couchbase)。 這目前不在本文的討論範圍

註2：通常是指http。不過由於ftp在2000年之前應用範圍真的太廣，所以還是有不少雲端公司會額外提供ftp介面。

註3：參考這裡 -> http://www.s3-client.com/s3-compatible-storage-solutions.html

註4：為何選擇這兩者？google當然是不用說，因為它的基礎建設相當完整。而yandex則號稱為俄羅斯的google，很明顯由於是俄羅斯最大search engine，大概不會和google採用重複的基礎建設，因此選用兩個截然不同的廠商，可以降低風險。