架构之数据架构
數據平臺進化
實際上世界都是圍繞數據在轉，只是計算機、網絡的出現讓數據虛擬化、可視化、持久化、通信化。以前寫信，現在社交軟件通信；以前各地同一樣商品價格差，需要人去傳播，現在各大電商平臺已把此種情況規避；以前的有紙化辦公，升級到現在的全面電子化辦公；包括當前的AI、大數據，即將的5G、物聯網等，純軟件領域、軟硬結合領域，所有都離不開數據的支撐，而數據的重要不言而喻。所以構建數據平臺，對數據進行集中處理，規避"數據孤島"，讓數據實際價值落地，價值最大化，也顯得勢在必行。以下對各層面數據平臺做一次介紹。
1.傳統數據架構
如圖1，最簡單的數據架構就是只有業務數據庫，且所有業務表都在一個數據庫中，或者按需分成多個數據庫。沒有專門的統計分析表，頁面上顯示的統計分析數據都是從業務數據中讀取后計算出來的。一個數據庫服務器承擔所有增刪改查操作，對邏輯刪除的數據沒有分化處理。
圖1???????????????????????? ? ??????????????????????????? 圖2??????????????????????????????????????????????????????????????? 圖3
數據量越來越大，歷史業務數據增多，新業務數據激增，表結構越來越復雜，查詢和寫入頻率升高，高頻寫和長時間讀沖突越來越嚴重。而數據分析又要耗費大量計算資源，總不能眼睜睜看著單臺數據服務器掛掉吧？引入備份數據庫：
①解決了單點故障問題
②單數據庫服務器性能問題
③實現簡單的讀寫分離，分擔數據庫壓力
④備份數據可做歷史冷數據分化
圖2面對簡單查詢還是可以的，但是在轉換聚合等需要多表關聯、以及大數據量等業務復雜度高的情況下，其處理性能就不容樂觀了。
面圖2無法解決的問題，圖3這種T+n的預處理離線計算的架構就出現了，引入獨立的任務調度和計算引擎：計算壓力可以交給業務數據庫處理，也可交給ETL處理，結果數據庫中只保存已經處理好的數據，只負責讀的操作，展現性能初步解決。
但這種情況還有缺點：數據庫表結構實在太過復雜，每做一個分析，業務數據庫就要理一次業務邏輯、寫一段sql，還沒法進行歷史追溯，以及數據整理成果的復用。為了解決T+n計算架構的問題，才有以下的升級版的數據架構。
2.數據集市與數據倉庫
把業務庫數據整理成星型結構，保證了事實的積累和維度的追溯。自由選擇需要的維度和相關事實進行篩選計算，再也不用擔心每次寫sql都要去看“蜘蛛網”了。還有索引、結果表、分區分表等等黑科技來保證每次查旬需掃描的數據量最小，解決數據庫性能問題。當然這種架構方式的缺點也很明顯，不是企業內一致的數據（多系統，多主題數據不一致），就會產生信息孤島。當然，如果客戶企業就是很小，就一個系統，不用整合，一個數據集市足以的情況下采用這種方式也可以。常見情況是會在各個獨立的DW間建立一些對照表，可實現數據交換。如果多個DW間沒有物理隔絕，也可以形成EDW。
為了實現各個業務系統取數分析，或者做更多操作，就實現中心數據倉庫EDW從各個源系統收集數據，再將數據提供給各個數據集市和挖掘倉庫使用。這也被稱為企業信息工廠架構（CIF），一般情況下，大型企業會花費許多精力實現這類架構。
無論是以什么架構存在，數據展示的需求都必不可少。分析工具選擇必不可少，要在以上階段以一款工具涵蓋，那必然需要一款既可以做敏捷數據集市建模，又可以做數據展示分析的工具來處理。這種工具可對業務數據進行簡單、快速整合，實現敏捷建模節省時間，并且可以大幅度提升數據的展示速度，可對接前端的數據分析展示層，實現自由數據展示與OLAP分析，典型如各類BI分析工具。
數據分析也很考驗分析工具數據讀取、運算的性能，但擁有大數據量計算引擎的BI分析工具并不多。像FineBI與其高性能數據引擎在以上幾個階段均可在不同程度解決很多場景。
（1）業務數據庫階段，此階段已經陳述過，重點問題就是計算性能影響大，以及數據孤島問題。建立數倉的過程相對敏捷數據集市而言，時間還是久的。這個時候就看看建立個常規意義的數倉和數據展示需求誰更緊急啦，或者可能有的也沒建數據平臺的意識也說不準。此時快速的數據展示需求，就可以通過將數據放到FineBI的數據引擎中支撐實現。
（2）中間庫與完善數倉階段，此階段其實主要就是計算性能問題了，用戶的數據量級也一定挺大了。正好借助于FineBI的分布式引擎，完成數據加速計算工作。此引擎屬hadoop生態，核心計算引擎利用的spark，借助了alluxio作為內存加速計算，處理了大數據計算問題，也很好闡釋了“大數據”。這個在接下來的文章中也會說到，這里先埋個伏筆，暫不贅述。
此階段呢，肯定有一些響應時間要求較高的展示需求，多次作業同步可能帶來延遲影響。而FineBI的引擎擴展了kettle的插件，實現數據可以直接load到引擎中，倒是將麻煩的作業處理工作解決了。
4.數據湖
所謂的數據湖就是通過原始數據分類存儲到不同的數據池，然后在各個數據池中將數據整合轉化為容易分析的統一存儲格式進行存儲。這種方式極大的方便用戶對數據進行分析和利用，從而產生經濟效益。
數據池主要是用來存放數據的，一個數據池中主要包含這幾種數據：
1、原始數據池
原始數據池是單一數據湖，它的作用就是存儲大量的原始數據。不會對其進行任何處理，很難從中提取想要的數據并進行使用。
2、模擬數據池
模擬數據池專門負責存放模擬數據，它主要是由機械設備產生的數據，一般為測量的數據、溫度、濕度等。一般情況下都存儲在記錄或者日志磁帶當中。
3、應用數據池
應用數據主要是執行一個應用或者事務時產生的數據，比如銷售數據、支付數據、制造過程控制數據等。這種數據池專門負責存放應用數據。
4、文本數據池
文本數據池顧名思義是負責存放文本數據的，原始數據可能是一些不同來源、形式的文本數據。比如錄音、郵件，甚至是一些物理設備產生的數據。在此類數據池中，數據可以根據感情分類進行存儲，在數據池中需要預先設定不同情感的類別，然后新文本進入數據池時就會根據上下文語境確定情感色彩，找到相對應的類別，進行存儲。
5、文檔數據池
文檔數據池主要存儲來自應用數據池、模擬數據池、文本數據池中將來使用較小概率的數據。
實現數據湖
數據湖實現的常用手段是Hadoop。
hadoop參照：
https://blog.csdn.net/qq_36632174/article/details/102461023
https://blog.csdn.net/qq_36632174/article/details/102461682
在經過進化之后，會將數據群與程序、運算規則、顯示器和歷史記錄聯系在一起，完成數據湖的目標。數據湖把原始數據按照類別進行存儲，在各數據池中可將數據轉化為統一的可直接提取的格式，這種方式具有極大的商業價值，對大數據分析做出了極大貢獻。
數據湖存在問題：數據湖中很多數據永遠不會刪除，所需要的存儲空間架構龐大。而且數據湖其中一個數據池遭到破壞，所有的數據都可能會被訪問，具有較大安全隱患。
數據湖架構
解讀數據湖架構：
ODS（operational data store, staging area）存儲來自各業務系統（生產系統）的原始數據，即為數據湖。
CDM為經過整合、清洗的數據。其中的DWS匯總層，為面向主題的數據倉庫（狹義），用于BI報表出數
簡單來說，數據湖的定義就是原始數據保存區. 雖然這個概念國內談的少，但絕大部分互聯網公司都已經有了。國內一般把整個HDFS叫做數倉（廣義），即存放所有數據的地方。
數據湖的意義、與數據倉庫區別
數據湖和數倉，就是原始數據和數倉模型的區別。因為數倉（狹義）中的表，主要是事實表-維度表（下圖），主要用于BI、出報表，和原始數據是不一樣的。
為什么要強調數據湖呢？真正的原因在于，數據科學和機器學習進入主流了，需要用原始數據做分析，而數倉的維度模型則通常用于聚合。另一方面，機器學習用到的數據，也不止于結構化數據。用戶的評論、圖像這些非結構化數據，也都可以應用到機器學習中。
二者區別對比表：
除了以上區別外，還有以下幾點區別：
傳統數倉的工作方式是集中式的：業務人員給需求到數據團隊，數據團隊根據要求加工、開發成維度表，供業務團隊通過BI報表工具查詢。
數據湖是開放、自助式的（self-service）：開放數據給所有人使用，數據團隊更多是提供工具、環境供各業務團隊使用（不過集中式的維度表建設還是需要的），業務團隊進行開發、分析。也就是組織架構和分工的差別 —— 傳統企業的數據團隊可能被當做IT，整天要求提數，而在新型的互聯網/科技團隊，數據團隊負責提供簡單易用的工具，業務部門直接進行數據的使用。人人具備數據分析能力。
數據湖的意義
數據湖最大的意義，在于幫團隊做組織架構調整，鼓勵所有人了解、分析數據，降低出數類等"IT"型工作。當然，對傳統企業而言，也是引入機器學習、用戶畫像的必須基礎設施，。
數據湖面臨的挑戰
從傳統集中式的數倉轉為開放式的數據湖，并不簡單，會碰到許多問題：
1.數據發現：如何幫助用戶發現數據、了解有哪些數據
2.數據安全：如果管理數據的權限和安全？因為一些數據是敏感的、或者不應直接開放給所有人的（比如電話號碼、地址等）
3.數據管理：多個團隊使用數據，如何共享數據成果（比如畫像、特征、指標），避免重復開發
這也是目前各大互聯網公司都在改進的方向，比如，對于數據發現，目前的解決方案就是Data catalog, 典型的比如IBM Watson catalog （算是對傳統元數據管理的改進）. 對于機器學習方面的數據管理，可以看Airbnb的機器學習平臺Bighead中的實踐。
總結
- 上一篇： 默认smtp虚拟服务器,轻松架设自己的S
- 下一篇： 65nm工艺下MOM电容详解与蒙特卡洛仿