## 建構穩定高效的雲端基礎建設

### 架構與流程
建構雲端平台的第一步，便是思考主要客群的商業需求以及預算：

1. 我們系統的主要目標為提供「電商與零售業者」一個雲端基礎建設平台
- 提供穩定雲端基礎設施
- 提供客戶消費行為數據分析

2. 提供穩定雲端基礎設施
- 避免系統中斷的風險
- 因為電商所講求的是系統的即時性，因此避免系統中斷很重要
- 系統中斷的原因
- 人為錯誤
- 系統 Bug
- Single Point of Failure (大公司通常不應該發生此問題)
- 解決方式
- 異地同步備份部署
- 有一定的物理距離
- 資料同步複製到其他可用區域 (AZ) 中的備用執行個體
- 中斷發生會自動容錯移轉到備用複本
- 跨地區、跨機房、跨 Server 部署
- VxLAN
- Active-Active 架構
- 一台機器掛掉的話，直接導向另一台
- 每台都有持續運作，並非處於等待狀態
- Client 也要有自主修復功能
- AIOps：透過 AI、ML 方法，監控系統異常，透過程式自動執行 AutoScale 補救措施
- 透過 ML 做異常偵測 (Anomaly Detection)
- 將 IT Infrastructure 推向視覺化、自動化以及自我修復

- 解決流量突然暴增，導致硬體資源短時間不足的問題
- 因為電商常會有限時優惠或是直播活動，因此會有短時間內流量暴增的問題
- Router: Elastic Load Balance
- 彈性附載均衡
- 自動分攤流量至不同的 Server
- Server: Elastic Compute Cloud
- 比照 AWS EC2 架構設計
- 自動根據需求擴增 Server VM 數量
- 無須長期合約或預付款，且資源調整彈性高
- Data: Oracle Real Application Clusters (RAC)
- 在多個 Server 上運行同一個 DataBase
- 易於水平擴展
- 使系統達到高可用性

- 大量數據的分散式儲存與運算
- 因為電商平臺通常會有大量客戶消費行為的資料，因此如何有效儲存與處理這些資料就變得格外重要
- 使用 Hadoop
- HDFS
* **scalable**: 當DataNode已滿，新增
* **reliable**: 當block有問題，藉由複製的block重新組合成完整檔案
* 由一台NameNode與至少一台的DataNode所組成
* 儲存資料：
1. 儲存到HDFS前，檔案拆成多個block
2. 同個block複製數等分再分散儲存到各DataNode
3. 紀錄檔案所屬block和位在那些DataNode，於NameNode上
4. 相同的block不會在同一個DataNode
* 讀取資料：
1. 某個Hadoop client需要讀取這個檔案
2. 跟NameNode發出請求
3. NameNode會根據這份清單回覆檔案的block位於哪幾台DataNode
4. Hadoop client再根據這份清單將各個block讀取出來，還原成一個完整個檔案
- YARN(Yet Another Resource Negotiator) 資源管理系統
* 出現的原因：在MapReduce中，jobTracker擔負起了太多的責任了，接收任務是它，資源排程是它，監控TaskTracker執行情況還是它。這樣實現的好處是比較簡單，但相對的，就容易出現一些問題，比如常見的單點故障問題。
* 用處：在Hadoop平台上執行MapReduce的應用程式，必須藉由Yarn監控與分配資源來確保Job可正常運作完畢
* 一個ResourceManager+多個NodeManager(數量和DataNode相同)
* RM:管理與裁決Hadoop叢集內資源的使用權
* NM: 監控Hadoop叢集內每台機器的資源使用情況(如memory, cpu, disk, network)，將資訊回報給ResourceManager
1. 某個分散式運算的Job/Application 被submit至Yarn上面運行
2. 這個Job/Application會被拆成數個tasks並且產生一個ApplicationMaster
3. AM會負責與RM請求需要運算的資源
4. RM會根據NM回報的消息，告知AM哪幾台機器有空閑的資源可以使用
5. tasks以Container的概念被分配到這些機器上
- MapReduce
* 撰寫分散式計算大量資料的 framework
* Map: 把需要運算的資料拆分為多個獨立區塊(chunk)，平行運算完後第一階段的運算結果儲存於檔案系統上(通常會是在HDFS內)
* Reduce: 把Map運算的結果進行第二次的運算，運算出最後的結果
* 因為運算過程會讀寫檔案，效能較慢，逐漸被Spark取代
* https://s4.itho.me/sites/default/files/files/iTcloud-網頁6-P111-600-1-1500.png
- MapReduce VS Spark
* spark 只能來和 mapreduce 進行比較，而不是整個hadoop，因為同為計算引擎
* spark 基於RDD(Resilient Distributed DataSet)作為核心，是一種具有容錯(tolerant)與高效能(efficient)的抽象資料結構。RDD 由一到數個的 partition組成， Spark程式進行運算時，partition會分散在各個節點進行運算，預設會被存放在記憶體內，所以可以快速分享各個partition的運算結果
- RDD也提供雲端需要的容錯機制。RDD可以指定成7種不同的儲存等級 (例如: 記憶體或是硬碟)，在Spark中， RDD可以從檔案中 (包括 HDFS 和 HBase) 創建或是從另一個RDD中產生，當進行完運算後，所產生的RDD也可以存回HDFS或是檔案。
* mapReduce 中間結果都是使用 hdfs 存儲，這意味著大量的磁碟io，磁碟io 讀寫是非常低效的，而 spark 中間結果放在記憶體中，記憶體放不下了會寫入本地磁碟，而不是HDFS。 spark 機制可以簡單有效地解決MapReduce在迭代計算時反覆讀取寫出磁碟的問題 ， 而當前機器學習的大多數算法都是迭代算法，因此spark 對於解決這一問題具有很大的應用價值。
* 跟傳統的 Hadoop 比較起來，Spark 在記憶體內執行程式的運算速度，做到比 Hadoop MapReduce 的運算速度快上100倍，即便是執行程式於硬碟時，Spark 也能快上10倍速度。
- Spark 提供之API
* Spark SQL
Spark SQL 是處理結構化資料所產生的元件，它允許使用者使用如同 Apache Hive 一樣透過 SQL 語法做資料查詢，除了提供 SQL 使用介面外，Spark SQL 也允許開發人員將 SQL 查詢與其他 RDD 所支援的資料處理方式一起使用。
* Spark Streaming
顧名思義，Spark Streaming 是一個在處理即時串流資料的元件，例如 web server 所產生的 log，或是服務狀態的變化，Spark Streaming 提供處理這類資料的 API。
* MLlib
Spark MLlib 提供了常見的 machine learning 函式庫，在 MLlib 裡面除了常見的分類分群和迴歸之外，也提供了模型評估和資料導入的功能。
* GraphX
這是用來在 Spark 處理圖像相關資料及進行分散式圖像處理的函式庫，GraphX 提供了很多處理圖像的操作，如subgraph 和 mapVertices 以及常見的圖形演算法。

- HBase + Hive (non relational, distributed database --> Splunk)
https://ithelp.ithome.com.tw/articles/10191431
* HBase是運作在 HDFS 之上的非關連式分散式資料庫 (non-relational, distributed database)
* random, realtime read/write access
* HBase的特點就是提供即時隨機讀寫(random, realtime read/write access)的功能:<br>當Aclient新增了一筆資料時，Bclient可以馬上讀取到最新資料並且可以修改
* 和Relational Database一起使用：<br>RDB當作HBase的metadata儲放處，或者是當作secondary index，較為複雜的relation先使用RDB查詢存在放HBase的資料主鍵(PK)，再使用PK從HBase取出raw data
* 以key-value方式儲存、輸入:<br>key即是資料的主鍵(PK)也是index，稱之為Rowkey，如果善用Rowkey當作查詢條件來搜尋，效能就會比fully scan方式快上很多
* bulk load的功能:<br>讓使用者不經過put(複製)機制，直接將資料轉換成HBase的儲存格式：HFile，避免使用put時觸發split與compact讓put效能越來越慢(一次將大批資料透過MapReduce的方式將資料存入)
- Hive
* Hbase本身無SQL查詢功能：<br>而Hive依賴MR(MapReduce)處理資料。有類SQL語言HiveQL，不完全支援SQL標準，如，不支援更新操作、索引和事務，其子查詢和連結操作也存在很多限制。
* Hive是建立在Hadoop之上的DatawareHOuse，由Facebook開發，在某種程度上可以看成是使用者程式設計介面，本身並不存儲和處理資料，依賴於HDFS存儲資料
* Hive把HQL語句轉換成MR任務後，採用批次處理的方式對海量資料進行處理。數倉存儲的是靜態資料，很適合採用MR進行批次處理。Hive還提供了一系列對資料進行提取、轉換、載入的工具，可以存儲、查詢和分析存儲在HDFS上的資料。
https://allaboutdataanalysis.medium.com/%E5%9F%BA%E6%96%BChadoop%E7%9A%84%E6%95%B8%E5%80%89hive%E5%9F%BA%E7%A4%8E%E7%9F%A5%E8%AD%98-ab063a310fd2
- HBase VS Hive
* hive適用於離線數據的分析，操作的是通用格式的（如通用的日誌文件）、被hadoop管理的數據文件，它支持類sql，比編寫MapReduce的java代碼來的更加方便，它的定位是數據倉庫，存儲和分析歷史數據。
* hbase適用於即時計算，採用列式結構的nosql，操作的是自己生成的特殊格式的HFile、被hadoop管理的數據文件，它的定位是資料庫，或者叫DBMS。

3. 提供客戶消費行為數據分析
- 讓電商平臺的技術或非技術人員更方便觀察客戶消費行為 (結合below的電商指標)
- 使用 Splunk
- 將 Hadoop 的資料導向至 Splunk 進行視覺化與分析
- 進行資料清洗 (看Splunk可不可以直接清洗，不行的話找別的工具)
- 資料分析 & 呈現指標數據 (使用電商指標舉例子)
- //
- 模型建立 (透過程式or直接點選，有無ML背景都可以使用)
- 模型管理 ( how to maintain models )
*https://iter01.com/347032.html*
- Splunk Dashboard 資料視覺化
* 採用可自一個或多個來源收集資訊並加以整合，以對資料準備進行自動化的工具。如此一來，可加速流程並減少出錯的機會。該工具還應能透過建議新資料集以納入檢視來增強分析，獲得更準確的結果
* 互動式的Dashboard
* 以GUI呈現以及使用 (ex.各式圖表、輸入參數、擷取部分資料)
* Splunk 用戶行為分析 (UBA) --> for 公司內部
* 以 "無人監督的機器學習" 為基礎的解決方案
* 查找用戶、端點設備和應用程序的未知威脅和異常行爲
* 不僅關注外部攻擊，也側重於內部威脅

4. 維運的挑戰與成本
- 提供穩定基礎設施的挑戰與成本
- 為了做異地備援，IT 基礎設施會需要跨地區部署，然而這樣一來就會增加營運成本
- 為了透過 AIOps 進行系統異常偵測 (Anomaly Detection)
- 如何有效提升模型準確率
- 如何降低程式發出錯誤告警的機率
- 應對流量暴增的挑戰
- 因為電商搶優惠都是幾秒鐘之內的事，因此如何預測流量高峰，並事先開好夠多的 Server 會是一大挑戰
- 如何決定開啟的 Server 數量
- Hadoop 應用於電商的挑戰
- 對於電商來說，有時候即時產出顧客行為的分析結果很重要，然而 Hadoop 很難做到即時的資料讀取與分析，因此分析結果的產出會有時間差，導致電商無法立刻進行決策，例如預估商品需求等，如此便會損失當下可能產生的商機
- 電商的資料有時會需要多執行緒同時寫入，然而 Hadoop 並不支援併發寫入

5. 深入研究
6. 課程心得與建議
7. 團隊分工

---

### 模型佈署和管理

### Map Reduce
https://s4.itho.me/sites/default/files/files/iTcloud-網頁6-P111-600-1-1500.png
### Spark, Hadoop
Hadoop 實質上是一個分佈式數據基礎設施: 它將巨大的數據集分派到一個由普通計算機組成的集群中的多個節點進行存儲，同時還會索引和跟踪這些數據。
Spark，則是那麼一個專門用來對那些分佈式存儲的大數據進行處理的工具，它並不會進行分佈式數據的存儲。
### Clean data by model(負責維護)
### Splunk Dashboard Visualization

---
Schema at read(先收不限資料的格式，讀取時才產生欄位
混合結構化、非結構化資料
end-to-end的資料分析(metric, trace,log)
異常預知
自動化問題處理流程

### Search & Monitor
* Data collection
* Troubleshooting outages & issues
* Real-time monitoring of performance
### Operational Visibility
* service-oriented view of IT environment
* E2E understanding of what drive services
* Monitoring KPIs and drill-down to specific issues
### Business Insights & ITM Integration
* Baseline of normal bussiness operations
* Tie back performance to business KPIs
* Provide insights to drive agility or experience
### Prediction & Automation
* Predict potential issues
* Recommend action based on prior behavior
* Identify points of continuous improvement

## splunk技術
* 即時與歷史資料的搜尋統計分析
* Business application data
* **Human Generated Data**
* Machine Generated Data 設備自動化過程
* 高度延展性的平行運作
* MapReduce --Divide and conquer
* 不需要connector取得設備端資料，直接連到設備
* 不需要Parser支援、事先定義schema、或是normalize再儲存
* 收集後再建index
* 搜尋提供分析、統計、報表、警示
* 基於企業管理資料的商業邏輯，並於搜尋後可呈現原始資料，或立即再進行統計分析，以提供報表或是視覺化的儀表板或警示
* 輸入時搭配萬用字元* 可特別搜尋相關關鍵字
* 串流效能架構 (Streaming Metrics Architecture) - SignalFx
* 2個資料庫: 中繼資料DB & 時間序列DB
* 獨立資料庫 --> 高擴展性
* 串流系統 --> 即時可見度

### 運作架構
1. Search Head 提供使用者查詢與統計機制
2. Indexer 提供索引建立與資料儲存
3. Forwarder 資料收集與傳送
三者都可以橫向擴充，透過多台電腦來分散處理，也可以全部集中在同一台電腦執行

考慮架構
1. 儲存歷史資料與即時資料
2. 指標關鍵字搜尋
3. 拉取相關資料，建立索引

---
#### 程式語言整合 點選/coding方式
4. 資料分析(專用指標計算，點選選)
5. 預測分析
* 歷史資料異常偵測(排除或處理)
* 模型管理(Model固定，只需輸入相同資料格式)
6. 視覺化 [https://www.oracle.com/tw/business-analytics/what-is-data-visualization/](https://www.oracle.com/tw/business-analytics/what-is-data-visualization/)
* 必須有即時可見度
* Splunk分為: 巨觀 & 微觀
* 巨觀: 整體公司平台的營運狀況
* 微觀: 個別小服務的健康檢測、KPI (ex.哪邊當掉or預測警訊)
* 互動式的Dashboard --> 以GUI呈現以及使用 (ex.各式圖表、輸入參數、擷取部分資料)

### 零售
1. 客戶行銷︰客戶購物習慣、購物交叉分析、購物喜好、購物經驗、店內行為分析
2. 營運︰定價、貨品擺設規劃、庫存最佳化、運輸最佳化
3. 線上銷售︰社群資訊分析、價格比較、線上零售

### 電商指標
1. CPM(Cost Per Mille Impression)
* 每 1000 個人看到你的廣告，你需要支付的廣告費用
2. CPC(Cost Per Click)
* 有人點擊你下的廣告時，你必須支付給廣告商的費用
3. CTR(Click Though Rate)
* 廣告被點擊的次數除以廣告曝光總量的百分比
* 下降時評估是否更換廣告素材、文案，或者是在商店頁面裡做一些圖文、排版的優化修改
4. CPA(Cost Per Action)
* 讓顧客完成行動，你所需要付出的費用
* action: 購買、註冊會員或是下載、填問卷
* 預先設定獲得一個轉換名單要花多少廣告費用
5. CVR(Conversion Rate)
* 訂單數/廣告點擊次數
* 但還是要注重訂單數
6. Bounce Rate
* 進入網站後的訪客，有多少比例是沒有進一步瀏覽就離站的指標
* 流量管道或是ta設定
* 觀察停留時間
7. 購物車放棄率
* 針對曝光廣告
* 放棄結帳、沒有放進購物車、沒有購物活動都考慮
8. 成本
* 商品成本 ( 含進貨 / 生產成本、包裝材費用等 )
* 網路開店成本 (承租開店平台，或架設網站的費用及維運費)
* 人事成本 ( 含支薪、獎金、教育費、辦公用品費等 )
* 行銷成本、庫存成本、物流送貨 / 退換貨成本、金流刷卡手續費成本
* 圓餅圖觀察每個成本佔營業收入
9. 毛利 = 營收 - 成本
* 各商品的競爭

* Unstructured Data
* 關鍵字
* 顧客詢問某商品販售或存貨時可增加叫貨量或考慮到商品列
* 包裝問題

### 資料清洗工具
* SAS Data Quality
* Oracle MDM
* 整理出統一格式的data

real time data
在線處理(Spark, Storm)

### HDFS(Hadoop Distributed File System) for 歷史資料
進一步用MapReduce(資料預處理 for log),Hive

* Name Node
* 管理(檔案讀取寫入..)
* 整個cluster只有一個(Single Point of Failure)
* 本身沒有High Availablity(掛掉後HDFS會Crash)
* 儲存所有檔案的Metadata(包含擁有者、權限、檔案各block位置)
* 將HDFS狀態存成Snapshot(檔名為fsimage)放置在NN local的硬碟中，並且將Metadata變更存在硬碟上的edit log檔案裡
* Metadata更新都會再Memory裡完成，只是更新紀錄會寫入edit log
1. 啟動的時候會讀取fsimage HDFS的狀態進Memory
2. 一一讀取edit log上所記錄的變更
3. 一步一步將Memory中的HDFS狀態在Memory中Roll Back達到狀態的更新
4. edit log檔案會被全新空白的edit log檔案覆蓋，舊的fsimage檔案也會被新的覆蓋
5. edit log會越來越長，接著下次NN重開的時候，就會超久
* Secondary NameNode
* 解決edit log問題
1. 期從NN那下載fsimage與edit log
2. 將這兩個合併
3. 傳回去給NN覆蓋，自己也保留一份備份
* 因為SN要執行這大量的Memory操作，所以建議Memory大小與NN相同
* SN進行的動作只是為NN建立一個還原點，所以如果NN掛掉，SN是無法取代NN執行的
* Backup Name Node
* 能就和NN完全一樣
* 也進行SN
1. 可以替NN建立還原點
2. 當NN掛掉的時候BN可以馬上起來接替NN進行動作，角色轉為NN，而原來的NN重新啟動後就會轉成BN
* 選擇性的存在(因為功能重複，但建議還是用BN取代SN以達到NN的HA)
* Data Node
* 資料儲存的節點
* 以Block為單位
* 一個檔案在HDFS上進行儲存時，會被按照固定大小(預設為64MB)分割成許多個Block，這些Block分別儲存在不同DN的硬碟上
* 檔案的資料分布在整個Cluster中
* DN會保持與NN的聯繫，所以當DN掛掉的時候，NN會知道這個DN已經死了
* NN發出指令後，DN對Block執行NN的指令，像複製, 刪除, 修改...

* Rack Awareness(備份位置選擇)
* 當datanode掛掉、找不到資料、資料毀損時，備份Block

* 容錯處理(Fault Tolerance)
* 對資料或節點發生錯誤時的處理