大數據分析是什麼？資料規模判斷與大數據技術架構元件說明

大數據分析是什麼：定義與資料集合的差別

大數據分析（Big Data analytics）指的是對大量、高速、多來源的資料集進行收集、處理並取得深入解析的方法、工具與應用程式，涵蓋結構化、半結構化與非結構化資料（Azure 的巨量資料分析說明）。同一個詞裡的「大數據」講的是資料集合本身：規模巨大、類型多樣、生成速度快、價值密度相對低，用傳統資料處理工具無法在合理時間內捕獲、管理與處理（SAP 的定義頁）。兩者位置不同，資料是原料，分析與資料科學負責解讀，機器學習與 AI 再從中建立預測；判斷一批資料算不算大數據，看的是資料特性加上架構需求，容量只是其中一項（SAP）。

定義：分析活動與資料集合的分工

單一大型檔案或一座資料庫不等於大數據，它跟分析、AI、雲端儲存空間也不是同義詞（SAP）。該看的是資料進來的方式：企業系統、數位互動、連線裝置與感測器持續產生資料，要讀得動這些資料，得靠現代資料架構、雲端規模儲存、分散式處理與進階分析一起配合（SAP）。SAP 把判斷拆成數量、多樣性、傳遞速度，以及要以可靠方式管理有多困難；談架構時，可以從資料怎麼進來、放在哪裡、用什麼算這三題問起。

三種資料形式：結構化、半結構化、非結構化

SAP 的介紹把資料分成三種形式，差別在結構。結構化資料有預先定義的綱要，排得進資料列與資料欄，通常放在關聯式資料庫並用 SQL 查詢，財務交易、庫存紀錄與固定格式的感測器讀數都屬於這一類。非結構化資料不遵循固定格式，文字文件、電子郵件、影像、音訊、影片與社群貼文都算，要從中取出意義得靠自然語言處理或影像分析。半結構化資料介於兩者之間，沒有嚴格綱要但帶標籤或中繼資料，JSON、XML、記錄檔與含時間戳記的事件資料是常見例子。SAP 指出，大多數現代資料集都是這三種類型的混合，其中非結構化資料更難以用傳統資料庫儲存與分析。

3V／4V／5V：大數據特性的兩種讀法

核心 3V 是 Volume（數量）、Variety（多樣性）、Velocity（速度），來源多把這組說法歸給 Gartner；部分來源再加上 Veracity（真實性）成為 4V，Oracle 與 SAP 的頁面則把 Value（價值）一併列入，成為 5V。各版本並存，擴充項與順序並不一致。框架的用途是提供檢查角度，資料在哪一項先撐不住，架構就從那一層先補。

版本分歧與定義的演變有關。Gartner 在 2012 年把大數據改寫為「大量、高速、及／或多變的資訊資產」，並指出這類資產需要新型的處理方式，才能促成更強的決策能力與最佳化處理（CHCI 引述）。這個版本的重點在處理方式是否足夠，不只看資料本身的規模。

核心 3V：數量、多樣性、速度

數量講的是產生與儲存的資料總量，MKC 把單一資料集寫成從數 TB 到 PB 等級都有；Oracle 也寫有些組織處理的大數據高達數十 TB，有些甚至達到數百 PB，兩個來源給的範圍都比單一容量門檻寬。多樣性指格式與來源的範圍，同一批資料裡可能同時有交易紀錄、社群貼文與感測器讀數（Oracle）。速度則是接收與處理資料的速率，有時也含處理的速率，有些連網產品要求近乎即時的反應，最快的做法是把資料流直接送進記憶體（Oracle）。三者要一起看：就算資料量龐大，單憑結構化資料不一定符合大數據的條件，除非還需要高速處理或與其他資料類型整合（SAP）。

擴充的 Veracity 與 Value

真實性處理的是資料可不可靠。來源一多，錯誤、雜訊與缺失值跟著進來，分析前要先過濾，結果才有可信度（MKC、Solwen）。價值講的是資料能不能變成實際結果，資料本身有業務價值，但要先被發掘才發揮作用（Oracle）。實際使用時，可以逐項檢查自家資料在數量、多樣性、速度、真實性、價值裡哪一項最吃力，先補那一項，比計較要用 3V 還是 5V 更接近決定。

資料規模什麼時候需要大數據架構

判斷條件是資料量與複雜度超出試算表或關聯式資料庫能管理、分析的程度，這時需要的是分散式儲存與可擴充處理組成的架構（SAP、Azure）。量化說法有兩份：LargitData 把「一天內可生成 1TB 以上」寫成大數據的量化描述，換算約 128 個 8G 隨身碟；CHCI 也以「狹義來說」寫一天能生成 1TB 以上。SAP 則提醒，讓資料成為大數據的不只數量，還有多樣性、傳遞速度與管理難度，所以 1TB 在這裡只當成其中一種量化說法，不當成單一門檻。

量化說法：一天 1TB 以上從哪裡來

SAP 指出，機器與連線裝置透過感測器與系統日誌持續產生資料，這一類是推動資料量與資料成長速度的主要因素。Oracle 把速度定義為接收資料的速率，有時也含處理的速率，最快的做法是把資料流直接存入記憶體，其次才是寫進磁碟。LargitData 用按讚說明速度的量級：以用戶突破 20 億人的臉書為例，每人每天按一個讚，一天就是 20 億筆資料。

另一邊的情況：什麼時候用不著這一套

SAP 把成本與複雜性列為大數據的挑戰：若未妥善管理，儲存與處理成本可能快速增加，特別是在雲端環境中。資料來源單純、格式固定、更新頻率不高，而現有工具已經應付得來時，先評估這些成本，再決定要不要導入分散式架構。架構的分界不在資料看起來多不多，而在現有工具跑起來是否已經到極限。

儲存層先分開看：資料湖與資料倉儲

儲存層的兩種常見形式分工不同。資料湖以原生格式保存大量原始與非結構化資料，同一份資料留著給不同分析目的重複使用；資料倉儲保存的是從各來源抽取進來、結構化且預先定義的資料，主要供應營運用途（Azure、SAP）。兩者常搭配運作：要保留原始細節供日後重複分析，落在湖那一層；要供營運用途使用的結構化資料，落在倉儲那一層（Azure）。

規模判斷的口徑可以固定成四項：來源有幾類、更新頻率多快、單日寫入多少，以及現有工具跑一次要多久。四項放在同一種單位下比較，資料是否已超出傳統工具就會有答案；接著可以從判斷自家資料規模是否需要分散式架構開始，把這四項對回分層架構。

資料收集與儲存：資料湖、資料倉儲、分散式檔案系統與 Hadoop

收集層承接多來源資料，儲存層再把原始與處理後的資料分開安置。企業系統與交易、人員與社群互動、機器與連線裝置是三類主要來源，其中感測器與系統日誌持續產生資料，是推動資料量成長的主要因素（SAP）。進來的資料會先落到可擴充的儲存庫，例如資料湖或雲端儲存空間，並且保持在原始的詳細程度，方便日後重複用於不同分析（SAP）。Hadoop 在這一層提供分散式儲存與處理，在部分環境中被當成基礎或舊有元件使用（SAP）。

收集層：三類來源各自產生什麼資料

人員與社群互動產生的是行為、情緒與偏好的痕跡，社群活動、線上評論、網站互動與應用程式使用情形都落在這裡。企業系統與交易涵蓋銷售、財務、供應鏈與人力資源資料，流動速度快，而且常把結構化紀錄與備註、附件這類非結構化內容混在一起。機器與連線裝置透過感測器與系統日誌持續產生資料，製造設備、車輛、智慧電表與環境感測器都算，這一類是資料量與成長速度的主要來源（SAP）。

HDFS：切割、備份、分散存放

Hadoop 以 HDFS 分散式檔案系統存放資料，做法是把同一份檔案切成小份，每一小份製作多個備份後分別放到不同位置；即使部分資料損毀，也能用其他備份重製出完整內容（LargitData）。LargitData 認為，這種儲存技術可以突破巨量資料難以儲存的困境，同時確保資料的完整性。Hadoop 官方文件把設計目標寫得更清楚：一個 HDFS 實例可以由數百到數千台伺服器組成，每台存放一部分檔案系統資料，典型檔案大小在 GB 到 TB 級，等於針對大型檔案設計（Hadoop 官方 HDFS 設計文件）。

HDFS 是分散式檔案系統；HBase 與 Cassandra 則是分散式資料庫，HBase 是分散式、可擴充的大數據儲存庫，Cassandra 是 NoSQL 分散式資料庫，MKC 的整理把它們和分散式檔案系統列在同一層當作儲存選項（Apache HBase、Apache Cassandra 官方頁；MKC）。選型時把這三者的名字分清楚，才不會把資料庫當成檔案系統來規畫容量。

MapReduce：把處理交給多台機器分擔

MapReduce 負責把存在 HDFS 裡的資料調出來統計、處理後再回傳，整個系統由 HDFS 存資料、MapReduce 算資料，角色分得清楚（LargitData）。Hadoop 本身是開放原始碼生態系統，可以依需求擴大或縮小，因此被視為相對有彈性、成本可控的架構（Azure）。2005 年這類開源框架出現後，資料量才開始快速累積，Apache Spark 則在 2014 年推出 1.0.0 版，之後各式技術的組合持續變化（Oracle；Spark 官方發布公告）。

雲端運算接著改變了儲存與運算資源的取得方式。彈性儲存與彈性處理不再受固定基礎架構的限制，原本從集中式系統轉向分散式環境的過程因此加快（SAP）。Oracle 提到，雲端的彈性及可擴充性讓開發人員可以輕鬆啟動臨時叢集，針對資料子集進行測試。

運算與分析視覺化：批次、串流、Spark 與工具層

運算層分兩種節奏：批次處理一次算一批已經落地的資料，串流處理在資料到達時就開始算（SAP、Azure）。Spark 以記憶體內運算同時支援這兩種工作負載，本身不負責長期儲存，使用時通常要搭配 HDFS 這類系統（LargitData、Azure）。分析工具層再把結果整理成能讀的形式，資料採礦、預測分析與視覺化工具都掛在這一層。

批次與串流：兩種運算節奏的適用場合

批次運算適合已經累積、可以等一輪跑完的資料。Azure 指出，傳統資料處理以磁碟為基礎，記憶體內資料處理則使用 RAM，處理與傳輸速度因此大幅提升，讓組織能夠即時取得結果。串流運算把資料在到達時送進記憶體處理，即時詐欺偵測與設備監控屬於這類需求（Azure、Oracle）。Apache Spark 官方把定位寫成同時處理批次與即時串流工作負載，分散式處理框架也讓資料不必等排程就能分析（Spark 官方首頁；SAP）。要選哪一種，看的是資料的時效需求，跟資料量大小是兩件事。

Spark：記憶體內運算與不儲存的限制

Spark 把運算放在記憶體內進行，不像 Hadoop MapReduce 那樣在運算過程中反覆把資料在記憶體與處理器之間搬移，因此省下轉換的時間與能耗（LargitData）。LargitData 以「比 Hadoop MapReduce 快 100 倍」描述這個差距，這是該來源自述的比較值，換一組資料或版本就不一定沿用。限制在儲存：Spark 只負責分析，不負責存放，使用時仍要接上 HDFS 等儲存系統，這也是該來源認為 Hadoop 難以被完全取代的原因。

處理與清理：運算層裡最花時間的一段

運算不只跑模型。Azure 列出的準備程序裡，儲存的資料會先經過驗證、排序與篩選，改善後續查詢效能，接著才進入清除階段，把衝突、重複、無效或不完整的欄位與格式錯誤修掉。Oracle 的頁面提到另一個現實：在許多組織裡，資料科學家要花五成到八成的時間整理與準備資料，才有辦法有效使用。模型跑得快不快是一件事，資料能不能用是另一件事。

分析與視覺化工具層

分析層的工作是從大型資料集裡找出模式。資料採礦用演算法辨識資料之間的重要關係，範圍涵蓋結構化與非結構化資料；預測分析建立模型去推估未來的行為與結果（Azure、MKC）。視覺化把算完的數字轉成圖表、地圖與儀表板，Tableau 這類工具支援 Excel、txt、xml 等格式，操作以拖放為主，文字雲則用來呈現字詞出現的次數與比例（LargitData、MKC）。分析結果在這裡才變成非技術背景的人也能讀的東西（Solwen）。

工具層再往兩邊延伸。資料整合軟體把不同平台的資料連結、合併成一個整合中樞，供資料採礦、商業智慧報表與營運查詢集中取用（Azure）。即時分析這端，Azure 的即時串流解決方案例如 Azure Data Explorer，會串起端對端的串流管道，把跨平台資料即時儲存、處理並分析（Azure）。

把元件對回流程，多數來源共用的骨幹是取得、儲存、運算與視覺化，運算這段再含清理、轉換與分析（MKC、CHCI、Solwen）。也有來源寫成收集、處理、清除、分析四段，把清理獨立出來（Azure）。名稱不同，先後順序一致。

大數據分析四步流程與元件對照如何一起使用

流程是時間軸，分層是位置圖，兩者對得上才看得出來哪一層該換工具。取得、儲存、運算、視覺化是共同的骨幹，切分方式隨來源不同（MKC、Azure）。下表把收集、儲存、運算、分析依層列出口徑與代表元件，說明每一層在判斷什麼。

對照表：分層口徑與代表元件

架構層	這一層的口徑	代表元件	可以判斷什麼	不能推論什麼
收集	承接企業系統與交易、人員與社群互動、機器與連線裝置的資料，含持續進來的感測器讀數與日誌	企業應用程式介接、問卷與網路表單、感測器與系統日誌	來源是否夠廣、更新頻率是否穩定	資料多不等於資料準，收集層不處理品質
儲存：資料湖	以原生格式保存原始與非結構化資料，保留詳細程度供不同分析重複使用	資料湖、雲端物件儲存	是否需要留下未經處理的原始層	湖不會自動把資料整理成可查詢的結構
儲存：資料倉儲	保存抽取進來、結構化且預先定義的資料，供營運用途	資料倉儲、分析型資料庫	營運用途的查詢能否穩定執行	倉儲收的是結構化、預先定義的資料，原始細節要看資料湖
儲存與運算：分散層	把檔案切割、備份後分散到多節點，運算在同一批節點上進行	HDFS、Hadoop MapReduce、NoSQL 資料庫	容量與可靠度是否一起被處理	來源自述的速度倍數不能直接當成選型依據
運算：批次	一次處理一批已經落地的資料	Hadoop MapReduce、Spark 批次模式	可以等排程跑完的分析	批次跑完前拿不到即時結果
運算：串流	資料到達時就開始處理	Spark 記憶體內串流、即時串流平台	需要接近即時反應的監控與偵測	串流層不負責長期存放資料
分析與視覺化	從大型資料集取出模式，再轉成可讀的圖表與報表	資料採礦、預測分析、Tableau、Power BI	模型與報表能否交付給非技術背景的人使用	分析層不修資料，品質問題仍回到收集與清理

SAP 指出，現代大數據架構多半做成彈性管道而非固定系統；把各階段分開，個別元件才能各自擴充、新的資料來源也比較容易接進來，同一個組織可以視使用案例，用不同方式擷取、處理與分析資料，即時監控與歷史分析能夠並存。這張表的每一列，就是照這個分層來對照。

下一次複查要看的欄位

下一次回頭看時，先確認儲存層留下的是原始資料還是已轉換的結構化資料，再看運算層跑的是批次還是串流。這兩欄如果跟目前的分析需求對不上，通常代表架構需要調整；新增主要資料來源或更新頻率明顯改變時，就是再核一次的時機。

FAQ

大數據分析的英文怎麼稱呼？

就是 Big Data analytics。中文文件常寫成巨量資料分析，指的是同一套從大量高速、多來源資料集收集、處理並取得深入解析的方法、工具與應用程式（Azure 的說明）。這類分析通常不是單一系統或單一軟體，而是由一群彼此搭配的技術與工具組成（Azure）。

資料一天 1TB 就一定要上大數據架構嗎？

不一定。LargitData 用「一天內可生成 1TB 以上」作量化說法，換算約 128 個 8G 隨身碟；CHCI 也以「狹義來說」寫一天 1TB 以上。SAP 的看法是，資料量之外還要看多樣性、傳遞速度與管理難度；Oracle 則以資料集龐大複雜到無法用傳統資料處理工具，尤其是試算表，輕易管理或分析來說明。

Spark 和 Hadoop 可以互相取代嗎？

不能完全取代。Spark 負責運算，不含長期儲存，使用時仍要接上 HDFS 等系統；Hadoop 則是儲存與處理一起的框架，HDFS 存資料、MapReduce 算資料（LargitData）。SAP 則說，部分環境把 Hadoop 當成基礎或舊有元件使用。

資料湖和資料倉儲要用哪一個？

通常兩者搭配使用。資料湖保存未經處理的原始與非結構化資料，準備好之後供應多個應用程式；資料倉儲從各種來源抽取結構化、預先定義的資料，再處理成可用於營運的形式（Azure）。兩者功能不同，卻常一起構成同一套儲存系統（Azure）。

哪一層的大數據分析工具最常見？

視各層分工而不同。收集與儲存層常見 Hadoop、NoSQL 資料庫、資料湖與資料倉儲；處理層有資料整合軟體與記憶體內處理框架；清除層有資料前置處理與清理工具；分析層則有資料採礦、預測分析與即時分析（Azure）。一般企業在收集端可以用 Google Form、SurveyCake 這類問卷工具，慢慢累積資料量（LargitData）。

大數據分析有哪些產業案例？

各行業都有。金融用於詐欺偵測、預測與風險分析；醫療保健用於臨床研究、診斷支援與營運最佳化；製造業用於預測性維護與品質監控；零售用於需求預測與商品組合規劃；物流用於路線最佳化與供應鏈資訊可見度；能源與公用事業用於使用量預測與基礎架構監控（SAP）。共同模式是歷史資料加上即時訊號，用來支撐營運決策或流程自動化（SAP）。

大數據分析有標準的分析流程嗎？

以四步為共骨幹，但切分方式隨來源不同。取得、儲存、運算、視覺化是多數來源共用的說法，運算階段再含清理、轉換與分析（MKC）。也有來源從整合、管理、分析三個動作切入，並指出傳統的 ETL 機制多半無法勝任 TB 到 PB 規模的工作（Oracle）。