直接進入 Hadoop 還是使用 SQLite/Postgres 作為 Hadoop/Spark 的墊腳石？
在我們的組織中，有些人正在努力設置
Hadoop很多安全限制等。從進展速度來看，這似乎很複雜，特別是考慮到安全限制、存在的大量數據源等。我在另一部分組織，並且在我們的團隊中，目前生成的數據量並沒有高到需要，Hadoop或者Spark，至少在很長一段時間內是這樣。我還在建構一個需要適當數據庫的小型應用程序。根據粗略計算，我較小部門中的一個小組每年生成大約 25GB 的數據（圖像、日誌文件、xlsx、ppts）等，大約 10mb 的數值數據儲存在 excel 工作簿中. 現在所有這些都儲存在平面文件中（帶有數字數據、圖像、日誌文件的 Excel 文件），因為我們所做的很多工作都是非正常的（我所在的組織主要是研究組織）並且每天都在變化今天。所以很多時候我們必須手動檢查圖像，因為沒有辦法對我們正在尋找的那種特徵進行任何自動圖像分析。總的來說，在我所在組織的所有組中，我們每年可能生成約 10TB 的數據（假設 200 個組，以及 2 倍的乘數以說明每年數據量的增長，20 年內為 200TB），其中大部分它們駐留在平面文件系統中。
我們使用 Excel 模板，人們在其中輸入數字數據，然後多人可以同時訪問數據並生成報告。
目前，我要解決的主要問題如下：
- 我們使用的 Excel 工作簿一次只能由 1 個使用者訪問，因此會導致很多衝突
- 如果我們儲存大於> 10mb的Excel文件，因為它儲存在網路上，打開工作簿變得很痛苦，所以我需要選擇一個不太複雜的數據庫，以便我可以在合理的時間內展示原型。
- 儲存在數據庫和/或文件系統中的連結數據（數字數據和 blob 數據）需要能夠轉換到
hadoop/spark分佈式數據庫。我正在考慮以下路線：
- 只需移動到 Excel 工作簿上的網路共享，以便多個使用者可以獨立開始訪問工作簿，而無需徵求打開工作簿的人的許可（使用舊版共享）：https ://www.presentationpoint.com/blog/multiple-users -excel-2016-數據表/。二進制數據將儲存在文件系統中，而數值數據將儲存在 Excel 中。
- 接下來，不是使用共同創作（OneDrive），而且因為我們必須開始使用適當的數據庫，我將在 excel 中創建一個宏，使用者幾乎可以點擊該宏來推送使用者生成的數字數據（以及指向二進制數據的連結） ) 到數據庫中。二進制數據仍將駐留在文件系統上，但可能會將其複製到第二個數據庫（
Database2），以便將來可以將其轉換為分佈式數據庫。在 Postgres 或 SQLite 之間進行選擇，（傾向於 SQLite，用於原型設計的各個組，因為它似乎被廣泛使用，擁有一個龐大的社區，可能錯誤/維護成本低）。每個組（總共約 200 個）將維護自己的 PostgreSQL/Sqlite 數據庫，直到分佈式數據庫準備就緒。- 在 veeeeeeeeeeeeeeeeeery 非常長期的未來，當我們必須擴展到 （假設我們在 5 年內達到 SQLite 限制）時，我們可以從該數據庫中提取數據並使用一些轉換器
Hadoop/Spark將其推送到 （ https://stackoverflow.com/a /28240430/4752883，https://stackoverflow.com/a/40677622/4752883） _ _Hadoop/Spark選擇 SQLlite 而不是 PostgreSQL 的原因是 SQLite 本身支持大約 140TB 的數據儲存。SQLite 似乎支持多個並髮使用者（https://stackoverflow.com/questions/5102027/can-sqlite-support-multiple-users）。Postgres 有更多的功能，但需要更多的資源和維護。我認為從長遠來看，我們可能不得不使用 Hadoop/Spark，因為數據量肯定會增長，但 Hadoop 的管理和管理要復雜得多，尤其是考慮到安全性考慮等。
問題
- 這種方法的缺點是什麼（我不關心什麼）？
- 有些人告訴我直接跳到 Hadoop，有些人告訴我只使用 SQL 類型的數據庫，直到我們真正開始需要更多數據。如果您正在嘗試選擇一個數據庫，同時確定可能在幾年後您可能需要 Hadoop，那麼在這種情況下，您會選擇 Hadoop 還是 SQL 類型的數據庫來執行第 2 步？
Hadoop是一個錯誤。你只談論比特的“數量”，根本沒有說你將如何使用它們“25GB 的數據（圖像、日誌文件、xlsx、ppts）”。RDBMS、Hadoop 和 Spark 都構成了糟糕的文件系統。如果您想要的是文件系統，請使用文件系統——查看 ZFS。這有真正的具體原因。由於這些原因，我建議檢查一下
現在讓我們假設您正在生成 25 GB 的實際關係數據，而不是 blob——您沒有理由使用任何水平映射/縮減架構。20 多年後，您將擁有 750 GB 的數據。這很容易被 PostgreSQL 處理。特別是與
PARTITIONS.tldr; 將 blob 移動到文件系統，並使用 PostgreSQL。這種工作負載不需要 Hadoop 或 Spark，唯一可以預料到的就是第三方工具更少，開發和集成難度大大增加，並且缺乏您現在可能使用的基本過渡能力。
如果我們儲存的數據多於 > 10mb，因為它儲存在網路上，打開工作簿會變得很痛苦，所以我需要選擇一個不太複雜的數據庫，以便我可以在合理的時間內展示原型。
使用更好的網路文件系統並對此進行調查。沒有辦法這應該很慢。也因為您使用 Excel 簽入他們的共享工作簿功能