目錄kudu 和其他儲存工具對比
設計乙個專案，分析其特點，設計方案，選取最佳處理方案
需求：做乙個類似物聯網的專案, 可能是對某個工廠的生產資料進行分析
1. 資料量大
- 有乙個非常重大的挑戰, 就是這些裝置可能很多, 其所產生的事件記錄可能也很大, 所以需要對裝置進行資料收集和分析的話, 需要使用一些大資料的元件和功能
2. 流式處理
- 因為資料是事件, 事件是乙個乙個來的, 並且如果快速檢視結果的話, 必須使用流計算來處理這些資料
3. 資料需要儲存
- 最終需要對資料進行統計和分析, 所以資料要先有乙個地方存, 後再通過視覺化平台去分析和處理
這樣的乙個流計算系統, 需要對資料進行什麼樣的處理呢?
1.要能夠及時的看到最近的資料, 判斷系統是否有異常
2.要能夠掃瞄歷史資料, 從而改進裝置和流程
所以對資料儲存層就有可能進行如下的操作
1.逐行插入, 因為資料是一行一行來的, 要想及時看到, 就需要來一行插入一行 -->隨機插入，oltp較擅長
2.低延遲隨機讀取, 如果想分析某台裝置的資訊, 就需要在資料集中隨機讀取某乙個裝置的事件記錄 -->oltp
3.快速分析和掃瞄, 資料分析師需要快速的得到結論, 執行一行 sql 等上十天是不行的 -->批量讀取和分析，dfs
總結一下需求實時處理
- spark streaming
- 大資料儲存, hdfs
- 使用 kafka 過渡資料(可以過渡實時流資料）
q. 但是這樣的方案有乙個非常重大的問題, 就是速度機器之慢, 因為 hdfs 不擅長儲存小檔案, 而通過流處理直接寫入 hdfs 的話, 會產生非常大量的小檔案, 掃瞄效能十分的差
# 上面方案的問題是大量小檔案的查詢是非常低效的，所以可以將這些小檔案壓縮合併起來
# 方案問題：
- 乙個檔案只有不再活躍時才能合併（外部正在使用）
- 不能將覆蓋的結果放回原來的位置（外部需要使用原來的檔案）
# 所以一般在流式系統中進行小檔案合併的話, 需要將資料放在乙個新的目錄中, 讓 hive/impala 指向新的位置, 再清理老的位置
# parquet檔案格式存放 離線大規模資料分析的吞吐量最高
# 因為 hbase（隨機讀寫插入效能好） 不擅長離線大批量資料分析, 所以在一定的條件觸發下, 需要將 hbase 中的資料寫入 hdfs 中的 parquet 檔案中, 以便支援離線資料分析, 但是這種方案又會產生新的問題
維護特別複雜, 因為需要在不同的儲存間複製資料
難以進行統一的查詢, 因為實時資料和離線資料不在同乙個地方
# 這種方案, 也稱之為 lambda, 分為實時層和批處理層, 通過這些這麼複雜的方案, 其實想做的就是一件事, 流式資料的儲存和快速查詢
kudu 聲稱在掃瞄效能上, 媲美 hdfs 上的 parquet. 在隨機讀寫效能上, 媲美 hbase. 所以將儲存層替換為 kudu, 理論上就能解決我們的問題了。
- 對於實時流式資料處理, spark, flink, storm 等工具提供了計算上的支援, 但是它們都需要依賴外部的儲存系統, 對儲存系統的要求會比較高一些, 要滿足如下的特點
- 支援逐行插入(機器生產的資料是逐條的）
- 支援更新（資料庫不斷更新）
- 低延遲隨機讀取（資料要能很快的讀取）
- 快速分析和掃瞄（離線大批量資料的掃瞄和分析）
# 先舉個栗子, 在電商**中, 經常見到乙個功能 - "我的訂單", 這個功能再查詢資料的時候, 是查詢的某乙個使用者的資料, 並不是批量的資料
# oltp 是傳統關係型資料庫的主要應用
用來執行一些基本的、日常的事務處理，比如資料庫記錄的增、刪、改、查等等
# oltp 需要做的事情是
快速插入和更新
精確查詢
#olap 則是分布式資料庫的主要應用
它對實時性要求不高，但處理的資料量大,通常應用於複雜的動態報表系統上
olap 和 oltp 的場景不同, olap 主要服務於分析型應用, 其一般是批量載入資料, 如果出錯了, 重新查詢即可
# 總結
oltp 隨機訪問能力比較強, 批量掃瞄比較差
olap 擅長大規模批量資料載入, 對於隨機訪問的能力則比較差
大資料系統中, 往往從 oltp 資料庫中 etl 放入 olap 資料庫中, 然後做分析和處理
# 行式一般用做於 oltp, 例如我的訂單, 那不僅要看到訂單, 還要看到收貨位址, 付款資訊, 派送資訊等, 所以 oltp 一般是傾向於獲取整行所有列的資訊
# 而分析平台就不太一樣, 例如分析銷售額, 那可能只對銷售額這一列感興趣, 所以按照列儲存, 只獲取需要的列, 這樣能減少資料的讀取量
傳統的關係型資料庫，如 oracle、db2、mysql、sql server 等採用行式儲存法(row-based)，在基於行式儲存的資料庫中，
資料是按照行資料為基礎邏輯儲存單元進行儲存的， 一行中的資料在儲存介質中以連續儲存形式存在。
列式儲存(column-based)是相對於行式儲存來說的，新興的 hbase、hp vertica、emc greenplum 等分布式資料庫均採用列式儲存。
在基於列式儲存的資料庫中， 資料是按照列為基礎邏輯儲存單元進行儲存的，一列中的資料在儲存介質中以連續儲存形式存在。
kudu 的儲存模型是有結構的表
oltp 中代表性的 mysql, oracle 模型是有結構的表
hbase 是看起來像是表一樣的 key-value 型資料, key 是 rowkey 和列簇的組合, value 是具體的值
kudu 採用了 raft 協議, 所以 kudu 的表中有唯一主鍵
關係型資料庫也有唯一主鍵
hbase 的 rowkey 並不是唯一主鍵
kudu 缺少跨行的 acid 事務
關係型資料庫大多在單機上是可以支援 acid 事務的
kudu 的隨機讀寫速度目標是和 hbase 相似, 但是這個目標建立在使用 ssd 基礎之上
kudu 的批量查詢效能目標是比 hdfs 上的 parquet 慢兩倍以內
hadoop 的設計理念是盡可能的減少硬體依賴, 使用更廉價的機器, 配置機械硬碟
kudu 的時代 ssd 已經比較常見了, 能夠做更多的磁碟操作和記憶體操作
hadoop 不太能發揮比較好的硬體的能力, 而 kudu 為了大記憶體和 ssd 而設計, 所以 kudu 對硬體的需求會更大一些
[參考文件] (file:///e:/big_data_files/dmp_systems/day01/kudu.html) 選擇正確的方案
在工作中，我們常常看到很多加班，有些是業務的需要，但大多數都可以有效控制的。首先，我們是否選對的方案？很多人工作是不考慮方案的，第一感的方法就做，常常做無用功。究其原因大約有三個 1 能力有限，只能想到一種方法 2 不願意思考多個方案。3 想到多個方案，但沒有能力評估，只好任選乙個熟悉的，而可能不是...
專案動畫方案
新年第一天上班，沒想到就立春了，俗話說，一年之計在於春，全新的 17 年開始啦，來，收拾下心情，投入到工作中，擼起袖子，就是幹！就在前幾天，airbnb 開源了乙個專案叫做 lottie，我個人覺得這個專案簡直碉堡了！怎麼樣？這些可不是簡單的移動 縮放 旋轉就搞得定的，可能有些人思考了之後大概有以下...
專案上線方案
一.小型專案上線 1.開發人員在個人電腦上搭建lamp環境測試開發好的 並且在辦公室或是idc機房的測試環境上通過，保證 的測試完全通過，保證專案的正確執行。2.上線最根本的原則就是對於使用者的使用體驗影響最小。不要直接上傳到伺服器中，而是先把 上傳到同個磁碟，使用mv命令，把上傳的 放入伺服器中。...