在過去 30 年中，我們看到生成數據以滿足當前業務和用戶需求的設備及軟件的數量呈指數級增長。用戶隨時隨地可以用各種智能設備相互鏈接，并生產和消費各種類型的數據，由此觸發的協作 分析 決策又源源不斷地生成新的數據。
而數據格式越來越豐富多才，包含且不限于文本、流、音頻、視頻和元數據。 同時數據除了傳統關心型數據庫中的結構化、也有大量的非結構化的或聚合的半結構化數據類型。
還好云平臺為海量的，多種格式，不同結構的數據存儲和處理提供了全面豐富的技術支撐，可以安全地存儲、轉換、處理、分析和可視化各種數據格式。
貓老師說過，問題從來不是問題，使用什么樣的方法來解決問題，才是我們的問題。要利用好云平臺出來數據，我們需要從問自己四個問題
- 一共有那些數據類型
- 數據如何流動
- 數據處理過程是怎樣的
- 如何分析數據
當然了不同行業同時疊加不同應用場景，以上四個問題的答案顯然需要具體情況具體分析無窮無盡。今天在這里貓老師使用一些云端處理數據的最佳實踐，展現一下套路
數據的結構化類型
數據結構類型
結構化數據是完全符合表中的行和列架構（或者關系）的組織化數據。比如SQL里面的數據，這類數據量少，但是商業價值高
非結構化數據并不符合表結構，也沒有架構。指的就是文本文件，日志文件，音視頻文件等等，這類數據量特別大，產生速度極快，且價值低。
半結構化數據也具有組織性且有明確的屬性和值，但數據存在多樣性。比如JSON XML等等典型的互聯網數據，雖然也存放在某個表里，但是他們并不能存放在適用于結構化數據的關系型數據庫，因為關系型數據庫的ACID特性在某一個或者某幾個方面不適用這些數據類型
數據的流動過程
數據流動過程
如圖所示，處理數據的過程就是給非結構化數據做結構化出來，最終轉成結構化數據存放在關心型數據庫的過程，那么數據庫是數據的最終歸宿嗎，顯然不是，無論原始數據是什么格式形態最終都要被轉到 Excel 里，由表格表姐們一頓劈里啪啦的操作最終變成 PPT 各種曲線圖 餅圖，當然了數據庫也可以接BI系統，直接生成各種各樣的 dashboard 交付給高管。這是一種數據增值的過程，其實也是一種路徑依賴。對于數據這種流動，或者增值，往往企業需要構建一條管道，也就是常說的 pipeline 來溝通各個不同環節所涉及的產品，自動化地運行。
數據的處理過程：ETL 和 ELT
首先名詞解釋 E Extraction，數據提取，T Transformation 數據轉換，L 數據加載
ETL
傳統的模式，是ETL，就是加載-轉換-加載，因為在之前的傳統商業環境中，數據量不大，不像后續的社交網絡 IoT那么多洶涌澎湃的數據浪涌，且數據分析方式單一，所以可以四平八穩的，把數據按照后續處理的需求進行轉換再加載到數據庫當中。
ELT
但是到了互聯網年代，尤其是移動互聯網，只要企業親自處理互聯網的流量，就必須使用 ELT 了，ELT 以數據的原生格式提取和加載數據。 此更改減少了將數據加載到目標系統所需的時間。在轉換階段定義數據的結構，因此可以在多個下游系統中使用源數據 簡單來說就是數據先上車，如何轉換格式日后再曰。
數據的分析架構：Lambda 和 KAppa
Lambda
如果所面對的業務邏輯是設計一種穩健的機器學習模型來預測即將發生的事情，那么你應該優先考慮使用 Lambda 架構，因為它擁有批處理層和速度層來確保更少的錯誤。
Query = λ (Complete data) = λ (live streaming data) * λ (Stored data)
舉個天氣預報的例子，一方面我們有100多年來的氣象脫機資料幫我們算某一日的降水概覽，同時還要疊加氣象衛星 各個地面氣象站的實時信息才能實現較為精準的預報。
Kappa
如果所面對的業務邏輯是希望實時性比較高，而且客戶端又是根據運行時發生的實時事件來做出回應的，那么就應該優先考慮使用 Kappa 架構。
Query = K (New Data) = K (Live streaming data)
這方面的例子就是防電信欺詐，預先使用機器學習對電信欺詐的特征固化成模型，在交易當中發現異常的轉賬操作立即進行關于，這必須要在毫秒級做出判斷來不及再去比對歷史積累，必須要快。
這就是個人總結的基于云平臺進行數據處理和分析的一些基本套路，后續貓老師還會順著這個思路介紹相關產品和機器學習 人工智能方面的一些業界進展和最佳實踐，謝謝大家！
