社区首页 >专栏 >从数据到AI

从数据到AI

随风溜达的向日葵

发布于 2019-11-21 07:16:24

5500

文章被收录于专栏：技术墨客技术墨客

一篇关于數據倉庫建設、人工數據分析、AI數據分析的讲义

數據Data&信息Information

信息

信息是一個客觀存在物體的自然表現，比如說“I am a local villain.”，無論你用什麼語言、什麼方式表示他都是客觀存在的，而信息即是承載這些客觀實體的概念載體。雖然香濃知道20世紀中才提出了信息輪，但是信息自古就有，與算機系統的出現無關，比如遠古結繩記事、早期文明的甲骨文、中世紀文明的簡牘等等，但是直道現代才理論化。

我們的職業被簡稱為I.T行業，即 Information Technology，就是信息技術行業。實際上我們做的任何事情都是為信息服務的。

數據

數據是信息的一種載體，他是到了“信息化”時代出現的產物，在沒有所謂的數據之前，信息也會通過文字、數字在記載。

數據的基礎也就是整個IT行業的基礎——所有的信息都通過0/1來表示，通常就是1bit表示一個0/1的信息，四個bit表示一個字節（現在的Unicode或寬字節是8個bit）,通過這種確定性關係，所有的信息都可以通過0/1的組合來表達各種各樣的信息。

隨著數據的不斷累積和堆積在數據背後發現了驚人的統計規律，隨著這些統計規律的發展漸漸的出現了AI分析和數據分析。

數據&數據分析&AI

如下圖是建立數據分析工程的過程

分為幾個大的步驟：

建立數據倉庫。
進行數據分析和挖掘。
根據需要訓練AI模型。

數據倉庫的建立

聯機事物型系統&決策分析系統

在數據能力上，通常將系統的數據結構模型分為2類，聯機事物型、決策分析型。

聯機事物型系統是指用於日常信息業務的系統，通常情況下80%的IT軟件開發人員都在製作這一類系統。他的特點是：
1. 信息的在線性。
2. 信息強一致性同步。
3. 數據事物性。
4. 強調信息的原子性。
5. 強調信息的實時性。
6. 強調信息處理的健壯性。
決策分析型系統是通過數據的組合、分析、模擬、合成以實現一個決策分析的支持，其特點如下：
1. 信息可以離線。
2. 信息可以實時不同步，但是需要明確維度時間點。
3. 不考慮事物。
4. 信息的原子性無任何要求，但是需要根據具體的業務。
5. 無實時性要求，根據業務制定。
6. 信息的健壯性的要求依賴業務需求。

對於2種系統而言，可以拋開用代碼實現的業務系統直接考察數據庫。以MySql為例，通常情況下innodb是用於支持聯機事物系統的，而MyISam是支持決策分析系統的：

由於數據磁盤存儲的特性，無論是寫入數據還是查詢數據。聯繫型事物系統都是碎片化的，因此會直接導致磁盤存在大量的碎片，因此innodb的塊分區會很小，而且為了支持事物，會有專門的事物處理區塊和進程。相對而言MyISam的分塊會大很多，這種特性有利於大量的查詢和統計，同時MyISam的索引和碎片整理機制和Innodb有巨大的差別，更適合於大量數據查詢和跑批量統計。
當我們使用Innodb執行多個海量數據統計查詢時，會因為碎片化的磁盤高頻讀寫極導致IO效率快速下降，當數量達到一定規模時會影響本身的業務。而MyISam本身的大區塊模型會極大的降低數據讀寫頻率。
從數據結構設計來看，聯機業務系統強調原子性，因此必須按照嚴格的ER範式進行設計，對數據進行冗餘勢必影響代碼層面的業務功能。而決策分析型系統因為必須考慮數據的原子性（其不是數據的來源，僅是數據的“快照”），因此反範式設計通常是決策系統的要求。
從業務系統的代碼層面考慮，因為大量的數據可能會耗費大量的內存，因此其內存模型在兩者之間應該有所的區別。

數據演變的過程與總線化

蜘蛛網演化

在信息化建設的過程中，最經常遇到的問題就是多個信息系統的打通。比如財務系統（ERP）需要和資產管理系統打通（EAM）。每遇到這種要求我們的常規認知都是開發接口（例如J2EE的SOA規範）。但是這種方式都是解決了點對點的系統，當點對點的系統越來越多，逐漸變成一個巨大的網狀結構，每個結點都是一個系統，每個系統都有很多連接線連接到其他系統。這稱為蜘蛛網演化過程。隨著網化的過程逐漸加深，管理難度和系統間的數據同步問題也呈指數級提升。

數據總線

在業務系統和數據倉庫之前，通常還會建立一個數據總線。所有的系統對外連接只考慮到總線。總線需要嚴格的定義數據規範、數據格式、數據字典內容等等。例如EAM系統入庫了一支鉛筆，在某個時候會映射到業務數據庫上，隨後監控歸檔日誌發現了這個變更、然後定義一個[時間handle][系統][表][時間][字段信息體]的事件數據推送到總線上，總線會向定義了監聽模型的中間件推送相關的數據信息。所有的業務系統包括數據倉庫會根據總線信息來更新自身的數據。

數據倉庫&主題

通常情況下，一個數據倉庫都是依託一個數據主題進行建立的，例如訂單數據主題。在很多時候數據倉庫是指一個數據庫，有時候數據倉庫又是只一個具體的主題模型。

星形結構

事實表

數據倉庫的數據通常都是以星形結構，通常星形的中心表稱為事實表，是我們搭建倉庫進行數據分析的核心的核心。我們用來進行數據輸出的表都是以這個表作爲中心的。然後外鍵關聯的形式也是以這個表作爲核心。

靜態維度表

靜態維度表通常與事實表可以確立一對一的關係，而且在業務層面一經過確立就不會發生改變。比如訂單的創建日期維度，這個表通常是爲了滿足擴展性展示和分析而建立的。

緩慢變更維度表

在大部分業務關係中，相關聯的數據並無法和事實表建立一對一的關係，各自有各自的維度體系。比如訂單表與商戶信息表，此時的星形結構中使用緩慢變更維度表。

###星形結構案例

附加參考内容： https://www.jianshu.com/p/d4f469387aa9?utm_campaign=hugo&utm_medium=reader_share&utm_content=note&utm_source=weixin-friends&from=groupmessage

數據集市

有了數據倉庫和主題之後，我們就可以針對不同的需求建立數據集市，集市就是依託一個數據倉庫模型針對某個業務搭建的數據展示、分析案例。

通常在我們完成數據倉庫搭建過後，就可以依託數據倉庫的的星形結構輸出一個數據集市的視圖。然後通過視圖進行數據展示和分析。

數據集市的數據通常情況下以事實表為基礎，也就是說集市的每一行數據都會對應事實表的一行數據，只是在字段內容是會根據輸出內容的要求進行進行增減。
不排除數據集市的基礎數據不以事實表為基礎的情況，例如以商戶作為行數據，然後將對應的訂單金額數據匯總到每一行。但是如果某個數據倉庫主題大量的出現這種情況，需要考慮另外新建數據倉庫主題。