【產業趨勢】AI & Big Data的演變趨勢(上)

TAcc+持續觀察新興科技產業脈動，協助新創團隊發展更具競爭力的戰略佈局。我們將持續針對以下領域，為您送上產業情報：AI (Big data) 、IoT、Healthcare (Digital health, Biotech, Medical device) 、Cybersecurity、App。

TAcc+新創分析師許雅音

Big Data的定義及處理方式演變

在過去20年中，數據(data)產生的數量和速度發生了驚人的變化，平均每一天，全世界所產生的數據達到了2.5 Exabytes (10¹⁸) ，10的18次方有多少呢?是達到了百萬兆等級的天文數字，這些數據除了來自於網路世界(包含各式各樣的社交媒體、影音串流平台，及線上購物平台等)，也來自物理世界，如波音747飛機上所裝的5000個感測器，每秒鐘能夠產生10Gigabtye(10⁹)的數據，更別提歐洲的強子對撞機，每秒鐘能夠產生1 Petabyte(10¹⁵)的數據。

為什麼數據的累積速度會愈來愈快呢? 隨著網路的普及，人與人之間的社群互動產生大量的數據，IoT的發展，機器裝上感測器就能隨時隨地產生數據，種種的加乘，令數據呈現指數級的上升趨勢，大數據（Big Data）在我們的生活裡已經掀起滔天巨浪。

2012年Gartner對大數據的定義是包含3個V，分別是Volume（容量）、Velocity（速度）和Variety（多樣性），也就是數據的數量大、累積速度快，而且滿足多樣性。相較於傳統數據，大數據的資料特性包含：資料來源多元、種類繁多，大多是非結構化資料，而且更新速度非常快，導致資料量大增。雖然近年來進化為10個V，但本質上還是以原本的3V為基礎做延伸；以量化的定義而言，數據的數量大於1TB(Terabyte, 10¹²)就能定義為大數據。

1. 從Big Data到AI的Process

數據從誕生到真正運用在商業上，其流程分為4個階段（如圖1），包含：產生數據(Data Generated)數據存儲(Data Stored)數據處理(Data Processing)可行的洞見(Actionable Insights)，前2個階段屬於大數據的範疇，後2個階段則是AI的範疇。

整體而言，在數據呈指數上升的現代，產生出的數據分為結構化(Structured)數據與非結構化(Unstructured)數據，結構化數據例如分類好的數據、文字等，非結構化數據則是圖像、影音檔案等。面對如此大量且種類繁多的數據，需要透過有足夠大的記憶空間將這些數據儲存起來，除了儲存之外，也要考慮到將來是否能以簡便的方式找到這些數據(Accessibility,易取性)。

儲存了大量的數據，並且能夠輕易地萃取出數據後，就該來考慮如何處理、運用這些數據，因為數據的數量實在太大，無法靠人工進行分析，此時，具備超強運算能力的電腦晶片CPU/GPU和具有學習能力的AI algorithms便派上用場，他們能夠透過數據處理，從大量且看似雜亂無章的數據中，偵測出數據的模型，藉由這個不斷精進準確度的模型，產生有價值的預測性資訊，讓政府或企業能夠透過這個資訊，得到可行的洞見，做出有價值的行動方案。

圖1、從Big Data到AI的轉變

資料來源: Overcoming Uphill Challenges for the New Generation Entrepreneurs

2. 如何處理如此龐大的數據？

在大數據的起步階段，面對如此大量且種類繁多的數據時，遇到了大數據的儲存和儲存後萃取出來的問題，特別是Google，在做搜尋引擎時，就發現了這個問題，因此Google著手開發了分佈式的數據存儲方式、大數據的計算方式，及大數據資料庫。

受到Google的啟發，Doug Cutting等人開始開發處理大數據的解決方式，並於2006年創立Hadoop。Hadoop能夠實現3大功能，包含大數據的存儲（HDFS, Hadoop Distributed File System）、大數據的運算（MapReduce），及資源管理與調度（YARN）。請參考圖2。

圖2、簡易版Hadoop架構

資料來源: Geeksforgeeks

2.1 Hadoop的出現，解決了處理大數據過程中所遇到的「存儲」問題

Hadoop做為一個集「存儲」、「運算」、「資源管理與調度」於一身的分散式大數據處理平臺。在「存儲」部分，在Hadoop出現之前，傳統的數據儲存方式是「關係資料庫管理系統(Relational Database Management System：RDBMS)」，是指將一套能將數據透過邏輯架構，令其相互聯繫和存取的程式(參考圖3)。在傳統的存儲方式中，數據蒐集(Data Collection)之後，會進入到儲存網格(Storage Grid)存起來，未來，如果需要運算這些數據，則透過ETL的方式進行運算。ETL作為數據萃取出來的方式，是極為重要的一個步驟。何謂ETL?是指原始數據(Raw Data)一旦存儲進去後，如果要提取原始數據，需要經過Extract(萃取)、Transform(轉換成所需的格式)、Load(下載)此3個步驟，才能將原始數據提取出來進行分析。

但是傳統數據儲存方式所遇到的問題有3個，都出現儲存網格(Storage Grid)的部分。首先，如果想要搬運原始數據去進行運算，需要透過ETL的方式，但隨著數據的線性增加，這部分基礎設施所需要的成本竟是呈指數型上升，因此數據量愈大的公司，需要付出的成本是中小型公司的指數倍，受限於成本限制，數據資料庫很難規模化。其次，無法拿出高保真度的原始數據(Original High Fidelity Raw Data)，因為經過ETL，所拿出的數據都是經過轉換後的數據。最後，久而久之，因為轉成可以用的數據需要透過很多程序和步驟，大量數據只能放在磁帶(Tape)裡面，因此這些數據就漸漸隱沒在數據庫(數據庫墳墓)中，成了Dark Data(或稱為Data Death)。

圖3、傳統的數據儲存方式

資料來源: Overcoming Uphill Challenges for the New Generation Entrepreneurs

為了解決大數據存儲所遇到的問題，Hadoop出現了。想像一下，目前有一個影音檔案為100GB，但是欲儲存的硬碟空間僅有10GB，這時候要如何把檔案儲存起來呢？這時候使用Hadoop的HDFS就可以輕易的解決上述的問題(請參考圖4)。HDFS是個可擴充(scalable)且可靠(reliable)的分散式檔案系統，由一台NameNode(名稱節點塊)與至少一台的DataNode(數據節點塊)所組成。欲儲存的檔案來到HDFS前，檔案會被拆開成數等分小區塊，稱為block，並且會將同一個block複製成數等分(replication, 預設值是3份)再將這些block分散儲存到各個DataNode，待要讀取時，也會按其分類找到各個block，再拼湊回原本的檔案。

特別值得一提的是，由於檔案來到HDFS前，檔案會被拆開成數等分的block，此block又會複製成數等份，因此當有一個數據損毀時，由於HDFS分散式存儲的特性，還有其他複製好的數據能夠協助復原。

圖4、HDFS的運作方式

資料來源:本研究整理

2.2 Hadoop的出現，解決了處理大數據過程中所遇到的「運算」問題

在「運算」部分(請參考圖5)，MapReduce是一種程式運算模型，用於大規模數據集（大於1TB）的並行運算。舉例而言，我們要數圖書館中有多少本書，一開始我們會分配班上的同學去數相對應的書架，例如1號同學去數文學類書籍，2號同學去數科學類書籍，3號同學去數音樂類書籍等等，人愈多，數得愈快，這個階段就是Map。班上每位同學集合到圖書館大廳，把每個人計算出的數字，統計起來，這個階段就是Reduce，簡而言之，MapReduce就是「任務的分解」與「結果的匯總」。

圖5、MapReduce的運作方式

資料來源: Overcoming Uphill Challenges for the New Generation Entrepreneurs

2.3 Hadoop的出現，解決了處理大數據過程中的「資源管理與調度」問題

在「資源管理與調度」部分，Hadoop的YARN（Yet Another Resource Negotiator）是一個資源調度平台，負責為運算程式(如上述提到的MapReduce)分配資源和調度。簡述其最重要的兩個功能包含資源調度和資源隔離(請參考圖6)，通過RM(Resource Manager) 實現資源調度，而隔離則由各個NM(Node Manager) 實現。簡單來說，YARN的功能如同人體的大腦和神經元的運作，當人想完成一項任務(Task)時，會透過神經元提交任務到大腦(RM)內，這時候大腦(RM)就需要撥出一部分腦容量(NM)來執行任務，當同時處理任務愈多，大腦(RM)就需要發揮管理的能力，才能讓多樣任務分別得到適當的資源分類，以完成眾多任務。

圖6、簡化版YARN的運作流程

資料來源: 本研究整理

雖然Hadoop突破了傳統數據處理的架構，對處理大數據提供了跨越式的變革，但是，隨著對大數據處理需求的不斷擴大，及技術的不斷迭代升級，「存儲」、「運算」，及「資源管理與調度」3大功能都有其各自的演進。

2.4 隨著數據愈來愈多，「存儲」的演進方向

首先，存儲的演進方式分為3個階段：提升擴展性(Scalability)雲端(Cloud)能夠支援機器學習(Machine Learning)的即時(Real Time)快速存儲。

雖然Hadoop的發明，相較於傳統的RDBMS，令大數據的「存儲」得到了大幅的改善，但是HDFS仍有天生的侷限，也就是「一次寫入多次讀取」(write once read many)，這意味著一次只能有一個客戶端可以寫入文件。多個客戶端不能同時寫入HDFS文件。當NameNode(名稱節點塊)授予一個客戶機許可在DataNode (數據節點塊)上寫入數據時，該塊將被鎖定，直到完成寫入操作為止，因此也限制了Hadoop「存儲」的速度。因此Hadoop在「存儲」方面，不斷提升Scalability，主要是指Hadoop的分佈式文件系統HDFS仍然有提高擴展性的需求和空間。

接著，隨著網路的迅速發展，存儲迅速地走向Cloud，讓資料存儲不僅限於本地(Local)，而是可以透過Cloud隨時存取資料(例如AWS S3)。另一方面，隨著機器學習的興起，從數據存儲的角度來看，有別於傳統的大數據存儲模式，增加了貼近終端設備、即時(Real-time)存取等新場景。

2.5 隨著數據愈來愈多，「運算」的演進方向

其次探討運算，運算的演進方式同樣分為3個階段：MapReduce Apache SparkCloud Computing，Hadoop所發展的MapReduce是一種程式模型，能用於大數據的平行運算。詳細來說，是將HDFS處理好的檔案資料，搭配Map & Reduce函數，將資料片段傳送到計算機節點(這個過程稱為Mapping)，再由各個節點計算處理後再做整合(Reducing)，以達到分散運算的功能，但是由於MapReduce的所有運算過程都需要讀寫檔案(包含ExtractTransformLoad)，也就是原始數據(Raw Data)一旦存儲進去後，如果要提取原始數據，需要經過Extract(萃取)、Transform(轉換成所需的格式)、Load(下載)此3個步驟(ETL)，才能將原始數據提取出來進行分析，所以運算效率比較慢，因此其運算功能漸漸的被Apache Spark所取代。Apache Spark作為處理大數據的框架，其優點在於速度，其運算速度比MapReduce快10~100倍左右，有別於MapReduce的兩階段執行法，Apache Spark的DAG(Directed Acyclic Graph)能夠將任務更有效地分佈於多個階段，直接在群集中並行處理數據，而不像MapReduce需要將數據拖進拖出。

特別值得一提的是，過去採用的ETL方式，現在已逐步轉變成ELT（參考圖7），也就是順序變成ExtractLoadTransform，在這個過程中，數據萃取及下載之後，將通過數據倉庫(Data Warehouse)進行基本的轉換，與過去ETL的差異在於，ELT已不需要數據暫存，主要優勢在於可以保存任何類型的數據(即使這些數據尚未進行Transform)，也可以隨時隨地訪問所有數據，而複雜的Transform，則待需要使用該數據時，再透過工具(Transform Tool如DBT、Dataform、Matillion)進行Transform即可。如此一來，便能夠節省開發人員和BI分析師處理數據的時間（參考圖8）。

圖7、ETL與ELT的差異

資料來源: 本研究整理

圖8、ELT的處理流程

資料來源: Overcoming Uphill Challenges for the New Generation Entrepreneurs

隨著Cloud的興起，也將運算搬到Cloud上面，例如AWS的Amazon Redshift、Microsoft的Azure Synapse Analytics，及Google的BigQuery。以Amazon Redshift為例，其速度在某些方面又比Apache Spark提升不少，提升主因在於Amazon Redshift具有MPP(大規模並行處理，Massively Parallel Processing)架構，允許高度的並行查詢。在定位上，Amazon Redshift除了和Apache Spark一樣有快速數據處理的功能，也涵蓋了分析型數據庫的功能，能夠更快速更有效率的處理大量數據。

2.6 隨著數據愈來愈多，「資源管理與調度」的演進方向

最後，需要深入討論的則是資源管理與調度，其分為3個階段，YARN→Docker→Kubernetes，這些開發的軟體，可以視為根據數據量多寡的階段來選擇不同工具使用，彼此間並沒有取代關係。YARN是一個資源管理系統，用來管理分散式運算應用程式所使用的資源，因此在Hadoop上執行MapReduce應用程式時，就需藉由YARN監控和分配資源，來確保正常運作。容器(Container)是YARN在處理資源的抽象概念，在這邊我們可以理解為是一個封裝袋，如圖9中，Node Manager內部的4個容器。容器將CPU核數、內存空間、程式等這些計算資源封裝起來，在運作上，容器由Node Manager 啟動和管理，並被它所監控，並且容器是由Resource Manager 進行調度。詳細運作方式請參考圖9。

圖9、YARN的運作方式

資料來源: 本研究整理

但隨著大數據的進展，YARN的負擔愈來愈重，多任務進行時，不同容器之間，會搶占計算資源，造成重要任務延滯，因此為了能夠更精確的分配資源，這時候，Docker(2013年)出現了，它創造了一個標準化的容器製造流程，讓應用程式具有相同的封裝方式、啟動方式、存取方式，也就是Docker創造出來的容器，不用修改就能在任何支援Docker的平臺上執行。舉例而言，就如同一個個、一模一樣、整齊劃一的貨櫃(Docker創造出的標準化容器)，很容易被運送到輪船上、整齊的被排放一樣。更值得一提的是，個別的貨櫃可以視作獨立的空間，即使層層重疊，也能夠不受其他貨櫃干擾的獨立運行多個應用，同時保持各個獨立系統的安全性。

Docker的原理是只需要關注程序本身，不用再安裝一套操作系統和相應環境，舉例而言，就像上文舉例的貨櫃一樣，我們把一台汽車（好比開發好的應用APP），打包放到貨櫃裡，它通過輪船可以輕而易舉的從上海碼頭（Cent OS7.2環境）運送到紐約碼頭（Ubuntu14.04環境）。而且運輸期間，汽車（APP）沒有受到任何的損壞（文件沒有丟失），在另外一個碼頭卸貨後，依然可以正常的在馬路上奔馳（啟動正常）。參考圖10。

圖10、遠洋輪船的貨櫃(Docker)運輸示意圖

資料來源: Wpgdadatong

整體而言， Docker主要目的就是「標準化」容器的製造，讓容器之間彼此獨立。

但隨著開始使用容器愈來愈多，這時候，對每個容器的管理和編排變得非常困難。最終，需要對容器實施分組，以利對所有容器提供網絡、安全等服務。這時候，Kubernetes(2015年)應運而生，其誕生的主要目的就在於幫助使用者能夠輕鬆地管理和調度眾多容器。

作為自動化容器操作的開源平台，Kubernetes功能包括部署，調度和節點(Node)集群(Cluster)間的擴展。參考圖11，Kubernetes的架構由以下各個組件組成：Pod、Node (Cluster Master Node and Worker Node)、Cluster。Pod是架構中的最小單元，一個Pod 包含一個或多個容器(通常每個Pod 包含一個容器)。一個或多個Pod作為一個流程(Process)在Node上運行。Node是物理計算機或虛擬計算機。幾個Node可以組合成Cluster。

圖11、Kubernetes的基本架構

資料來源: Kubernetes Nodes, Pods, & Containers © Jeff Hale 2019

Cluster內的Worker node由Cluster Master node控制和監視。Cluster Master Node接收命令，並使用容器在各個Worker node上管理容器。Cluster Master Node考慮到可用資源和所需資源，並監視Worker node的利用率和操作狀態。

Kubernetes 與本地平台和各種Cloud模型兼容，例如私有雲、公共雲，及混合雲等，這為應用程序的開發和操作提供了極大的靈活性。

圖12、Kubernetes的工作原理

資料來源: Guru99

3. 整合型大數據處理平台Snowflake的誕生

在「存儲」、「運算」、「資源管理與調度」3大功能各自不斷的升級之際，2020年IPO了一家新創公司Snowflake，將上述3大功能整合起來，並開發了新的商業模式。

將上述的功能整合起來，就是2020年IPO的新創公司Snowflake最主要的貢獻。有些人會好奇，現在已經有 AWS、Azure、Google 3大巨頭Cloud平台，為什麼Snowflake 還可以生存？這牽涉到兩個層面，首先是「數據倉庫（Data warehouse）」到「數據湖（Data lake）」觀念的變革，其次則是計價模式的改變。

傳統數據資料庫的概念如圖13所示，就像是「停車場」，「車子」則是儲存在數據倉庫的文件，停車場的「車位」就是存儲空間，車子進出的「匝道系統」就是運算。

圖13、傳統數據資料庫概念圖

資料來源: 本研究整理

過去的處理存儲方式就是哪裡有空位，「車子」就停在上面，不管「車子」的型號和尺寸。後來為了節省空間，就把「車子」拆成各種零組件，把它們分門別類的存放在特定區域，這種儲存方式叫「關係型」儲存，這樣的停車場便是「關係型資料庫」。

圖14、關係型資料庫概念圖

資料來源: 本研究整理

但隨著數據用途的多樣化，數據格式也更加複雜，除了結構化資料，也包含圖片、聲音或影片等非結構化類型。這時便需要一種能同時保存結構化和非結構化數據的新型儲存架構，便是「數據倉庫（Data warehouse）」。

隨著人們對數據分析的調度「運算」開始遠超過對「存儲」的需求，導致對數據倉庫的需求激增。但是，對「存儲」和「運算」的需求並不是同比率增加的，如果同一個資料庫可能從一分鐘被調用數次瞬間增加到數百次，那「運算」速度就可能成了分析的瓶頸。就像在尖峰時段停車時，看到車子進出的「匝道系統」出入兩邊都大排長龍，司機繳費和升降欄杆都消耗了太多時間。

因此Snowflake 提供了兩個關鍵的功能，第一是將不同數據倉庫整合為一，第二則是使「存儲」與「運算」分離。第一點是Snowflake提供一個整合平台，讓我們能管理和取用AWS、Azure、Google 3大Cloud系統內的數據，讓數據科學家能夠隨時隨地調取任何格式的數據，Snowflake稱之為數據湖（Data lake），並且Snowflake 創建了一個統一入口，讓使用者能夠按照以往訪問關係型資料庫的語言，對背後所有的資料庫進行訪問，幾乎不改變原有使用習慣。

第二點，雖然3大Cloud在「存儲」上能夠讓使用者以低成本、高效率隨時擴容和縮容，但在「運算」上，需要透過不同形式的轉換，因此成本還是高。回到「停車場」的例子，Snowflake 能夠精確計算「停車場」各個零組件被搬運、組裝以及道閘等候等每一個環節的時間。在計費模式上，通過對「存儲」和「運算」拆解，讓使用者的成本得以量化且可控。

在計費模式上，「存儲」的價格跟其他Cloud並無差異，但是「運算」的價格則被分成了八個等級，來做到非常細分的「按量收費」。以往使用Cloud時，到底消耗了多少「存儲」和多少「運算」資源，任何廠商都不會向客戶透露。但在 Snowflake 這裡，「存儲」是「存儲」，「運算」是「運算」，費用分得非常清楚。

4. 結論與未來Big Data趨勢分析

本篇文章介紹了大數據的緣起，及為了處理大數據，所提出的解決方案中的「存儲」、「運算」，及「資源管理與調度」的演進和整合的過程，其中，無論是「存儲」、「運算」，還是「資源管理與調度」，對於速度的要求，都成了演進的關鍵。

未來的數據處理趨勢，有3個重點，第一是大數據的整合，第二是加入AI的元素，第三則是打破大數據模式，運用小數據進行運算。

有關第一點的大數據整合，數據工程師在使用Cloud服務時，會分散性的使用作為數據倉庫(Data Warehouse)並提供運算服務的Cloud三大巨頭，AWS、Microsoft Azure，及Google Cloud，也就是某些數據用AWS處理、某些運算在Microsoft Azure上執行，某些則是需要用到Google Cloud的功能，因此整合成了勢不可擋的趨勢，造就了snowflake的異軍突起，未來也將逐漸誕生整合性的服務。

第二點是加入AI的元素，過去做數據分析，會使用Rule-based system和Machine Learning等方式，不一定會用AI來處理，但是隨著數據的量體不斷擴大，就會希望運用更聰明的方式去體現數據的價值，現在的趨勢是運用Real-Time Analytics和AI分析去體現數據的有效性，不再是像以前一樣，把數據存起來，久久分析一次；除此之外，AI特殊的應用也如雨後春筍一般冒出，例如人臉識別、與IoT結合的Data Streaming分析。

至於第三點是打破大數據模式，運用小數據進行運算，是運用更高效的AI運算能力，讓小數據也能夠體現大數據的價值。

回顧大數據的演化史到現今的趨勢，能夠發現，未來接過接力棒的產業正是AI。相較於過去的AI是依附著大數據才得以興起，用途多為分析數據，找出商業洞見；現在的AI則不一定要仰賴大數據，正在各個行業裡遍地開花。

參考資料

“Overcoming Uphill Challenges for the New Generation Entrepreneurs,” Gary Wang,2019~2021
“how read and write is done in parallel manner in hdfs,” MYCLOUDERA, 2018.
“What is Kubernetes, ”NET2,2021
“ETL vs ELT: 5 Critical Differences, ”XPlenty,2021
“Key Kubernetes Concepts, ” Towards Data Science,2019
“Container Security: Examining Potential Threats to the Container Environment, ” Trend Micro,2019
“Docker security checklists mitigate container cyberthreats, ” TechTarget,2021
“Hadoop vs. Spark: Comparing the two big data frameworks, ” TechTarget,2021
“Apache Spark vs. Amazon Redshift: Which is better for big data?, ” Intermix,2020
“Hadoop vs. Spark: Comparing the two big data frameworks, ” TechTarget,2021
“Apache Spark 簡介, ”ithome,2017
“Snowflake 2020 營收翻倍！, ” Stockfeel,2021