5.1　路線圖

本節討論數據科學家在數據遷移中的不同場景。

5.1.1　跨數據源聚合數據

傳統上，來自事務型數據庫的數據被聚合到數據倉庫中用于數據分析。今天，數據源的種類顯著增加，有結構化數據、半結構化數據和非結構化數據，包括事務型關系數據庫、行為數據、地理空間數據、服務器日志、物聯網傳感器數據等。對數據用戶來說，從這些數據源聚合數據難度較大。

更復雜的是，隨著應用程序設計的微服務范式（https://oreil.ly/2kHMq）的出現，數據源變得越來越孤立。在微服務范式中，開發人員可以選擇最適合其微服務的不同底層數據存儲和數據模型。在現實世界中，一個典型的數據用戶需要應對不同的數據孤島，并且通常需要跨團隊進行協調，管理產品交易數據、行為點擊流數據、營銷活動、賬單活動、客戶支持票據、銷售記錄等。在這種情況下，數據遷移服務的作用是在數據湖中自動聚合數據。

5.1.2　將原始數據遷移到專門的查詢引擎

越來越多的查詢處理引擎針對不同類型的查詢和數據工作負載進行了優化。例如，對于時間序列數據集的切片分析，數據被復制到專門的分析解決方案，如Druid（https://oreil.ly/hmCP4）和Pinot（https://oreil.ly/_hu7N）。簡化數據遷移可以為分析作業選擇更合適的分析工具。在基于云的架構中，查詢引擎越來越多地直接運行在數據湖上，減少了遷移數據的需求。

5.1.3　將處理過的數據遷移到服務存儲

考慮這樣一個場景，數據被處理后存儲為鍵-值對，需要由應用程序向數百萬個終端用戶提供服務。為了確保足夠的性能和可擴展性，需要根據數據模型和一致性需求選擇合適的NoSQL存儲作為服務存儲。

5.1.4　跨數據源進行探索性分析

在模型構建的初始階段，數據用戶需要探索大量的數據屬性。這些屬性在數據湖中可能并不都是可用的。探索階段不需要完整的表，而是需要快速原型設計的數據樣本。鑒于原型設計工作的迭代性，非常有必要將數據遷移自動化為頁面點擊可實現的功能。此場景是決定需要定期在數據湖中聚合哪些數據集的準備步驟。