Big Data là gì? Dữ liệu lớn không chỉ đơn giản là dữ liệu thật nhiều

Cập nhật tháng 09/2026: Nha viết bài này lần đầu vào năm 2016, sau một lần đi đường sách và mua cuốn Big Data của Lisa Arthur. Mười năm sau đọc lại, phần định nghĩa cơ bản vẫn còn giá trị nhưng nhiều ví dụ, con số và cách nhìn về Big Data đã thay đổi khá nhiều. Vì vậy Nha viết lại bài này và giữ phiên bản năm 2016 ở cuối để mọi người có thể so sánh.

Năm 2016, Nha đi đường sách, thấy cuốn Big Data của Lisa Arthur.

Nhìn chữ Big Data thấy vừa quen vừa có vẻ... to.

Mua.

Về đọc.

Rồi lên Google tìm tiếp.

Sau đó viết bài này.

Lúc đó Nha hiểu Big Data theo cách khá phổ biến:

Dữ liệu nhiều đến mức những công cụ truyền thống không xử lý nổi.

Cách hiểu này không sai.

Nhưng sau nhiều năm làm việc với dữ liệu, Nha thấy nó chưa đủ.

Nếu hôm nay có người hỏi:

Big Data là gì?

Nha sẽ trả lời ngắn hơn thế này:

Big Data là những tập dữ liệu có quy mô, tốc độ phát sinh hoặc mức độ đa dạng đủ lớn và phức tạp khiến cách lưu trữ, xử lý và phân tích dữ liệu truyền thống không còn phù hợp hoặc hiệu quả.

Và quan trọng hơn:

Big Data không có giá trị chỉ vì nó “Big”. Giá trị chỉ xuất hiện khi chúng ta biến dữ liệu thành thông tin có thể sử dụng để giải quyết một vấn đề thực tế.

Đây là phần mà năm 2016 Nha đã nhắc tới.

Nhưng phải đến sau này Nha mới thấy chữ Value có khi còn quan trọng hơn chữ Big.

Big Data có phải đơn giản là dữ liệu rất lớn?

Không hẳn.

Đây là điều đầu tiên Nha muốn sửa lại trong cách hiểu cũ.

Ngày trước người ta thường đưa ra những con số:

• vài chục terabyte;

• hàng trăm terabyte;

• petabyte;

• exabyte;

• zettabyte.

Nhìn rất ấn tượng.

Nhưng không có một con số kiểu:

99 GB  = Data 100 GB = Big Data 

hoặc:

999 TB = Data 1 PB   = Big Data 

Big Data mang tính tương đối với bài toán và khả năng của hệ thống.

Một file dữ liệu 5 TB có thể rất lớn đối với một ứng dụng đang chạy trên một SQL Server đơn lẻ.

Nhưng 5 TB lại chẳng có gì đặc biệt đối với một nền tảng dữ liệu phân tán được thiết kế để xử lý hàng petabyte.

Vì vậy câu hỏi tốt hơn không phải:

Dữ liệu bao nhiêu TB thì gọi là Big Data?

Mà là:

Khối lượng, tốc độ và độ phức tạp của dữ liệu đã vượt quá khả năng xử lý hiệu quả của kiến trúc hiện tại chưa?

Nếu có, lúc đó chúng ta bắt đầu bước vào bài toán Big Data.

Big Data thường được giải thích bằng các chữ V

Ngày trước Nha viết rằng Big Data có 5V.

Điều này vẫn là một cách giải thích rất hữu ích.

Nhưng Nha muốn bổ sung thêm một chút:

Không có một “bộ 5V duy nhất” bắt buộc mọi tài liệu phải sử dụng.

Có tài liệu mô tả Big Data bằng 3V:

• Volume

• Velocity

• Variety

Có nơi bổ sung:

• Veracity

Và có nơi thêm:

• Value

Hiện IBM sử dụng mô hình 5V gồm Volume, Velocity, Variety, Veracity và Value.

Nha cũng thích bộ 5V này vì nó giúp người mới nhìn Big Data đầy đủ hơn.

Volume – Khối lượng dữ liệu

Đây là chữ V dễ hiểu nhất.

Volume là lượng dữ liệu.

Ví dụ một hệ thống thương mại điện tử có thể sinh ra:

• lượt xem trang;

• lượt tìm kiếm;

• lượt xem sản phẩm;

• click;

• giỏ hàng;

• đơn hàng;

• thanh toán;

• lịch sử giá;

• log ứng dụng;

• hành vi người dùng;

• hình ảnh;

• đánh giá;

• hội thoại hỗ trợ.

Một người dùng có thể tạo ra hàng chục hoặc hàng trăm sự kiện trong một phiên.

Nhân với hàng triệu người dùng.

Nhân tiếp với nhiều năm.

Lúc đó dữ liệu bắt đầu khá lớn.

Nhưng như Nha vừa nói:

Volume chỉ là một phần của Big Data.

Nhiều chưa chắc khó.

Velocity – Tốc độ dữ liệu

Đây mới là phần thú vị.

Giả sử mỗi ngày hệ thống nhận 10 triệu bản ghi.

Nếu tất cả được gửi một lần lúc 2 giờ sáng và bạn có cả ngày hôm sau để xử lý, bài toán khá khác.

Nhưng nếu 10 triệu sự kiện đó đến liên tục và hệ thống cần phản ứng trong vài giây thì độ khó tăng lên nhiều.

Ví dụ:

Khách vừa thực hiện giao dịch bất thường.

Hệ thống chống gian lận phải phản ứng:

Ngày mai phân tích cũng được.

thì hơi muộn.

Hay khách vừa xem một sản phẩm.

Hệ thống recommendation đợi ba ngày sau mới gợi ý sản phẩm liên quan thì có thể khách đã mua ở chỗ khác rồi.

Đó là Velocity.

Không chỉ dữ liệu nhiều.

Mà dữ liệu đến nhanh và đôi khi giá trị của nó giảm rất nhanh theo thời gian.

Variety – Sự đa dạng của dữ liệu

Ngày trước làm hệ thống, Nha khá quen với kiểu:

Customer Product Order OrderDetail 

Database quan hệ.

Cột.

Dòng.

Khóa chính.

Khóa ngoại.

Rất đẹp.

Nhưng dữ liệu thực tế ngày nay có thể gồm:

Structured Data

Dữ liệu có cấu trúc:

• khách hàng;

• đơn hàng;

• giao dịch;

• sản phẩm.

Semi-structured Data

Dữ liệu bán cấu trúc:

{     "event": "product_view",     "product_id": 123,     "user_id": 456 } 

JSON, XML, log...

Unstructured Data

Dữ liệu phi cấu trúc:

• hình ảnh;

• video;

• audio;

• email;

• tài liệu;

• hội thoại;

• nội dung mạng xã hội.

Đặc biệt khi AI phát triển, nhóm dữ liệu phi cấu trúc ngày càng quan trọng.

Một doanh nghiệp có thể có hàng triệu văn bản, cuộc trò chuyện, hình ảnh hay tài liệu nhưng trước đây chưa khai thác được hết.

Big Data không chỉ là:

Có rất nhiều dòng trong database.

Mà còn là:

Có rất nhiều loại dữ liệu khác nhau cần được kết nối và hiểu cùng nhau.

Veracity – Dữ liệu có đáng tin không?

Đây là chữ V Nha ngày càng thấy quan trọng.

Giả sử có:

100 triệu records 

Nghe rất Big Data.

Nhưng:

• 20 triệu record trùng;

• khách hàng có 5 ID khác nhau;

• ngày sinh bị nhập sai;

• số điện thoại thiếu;

• dữ liệu bot lẫn với người thật;

• tracking event bị bắn hai lần;

• timezone sai;

• nguồn A và nguồn B định nghĩa doanh thu khác nhau.

Thì 100 triệu records đó có thể tạo ra...

một báo cáo rất đẹp nhưng sai.

Nha từng nghĩ Big Data khó vì dữ liệu quá lớn.

Sau này mới thấy:

Dữ liệu sai mà càng lớn thì đôi khi chỉ giúp mình sai với quy mô lớn hơn.

Đó là Veracity.

Tính chính xác.

Độ tin cậy.

Nguồn gốc.

Tính nhất quán.

Data quality và data governance vì thế không phải việc phụ.

Chúng là phần rất quan trọng của bài toán dữ liệu.

Value – Cuối cùng dữ liệu dùng để làm gì?

Đây là chữ Nha thích nhất.

Một doanh nghiệp có thể lưu:

10 PB dữ liệu 

nhưng không ai sử dụng.

Một doanh nghiệp khác chỉ có:

100 GB dữ liệu 

nhưng dùng nó để:

• giảm gian lận;

• dự báo nhu cầu;

• tối ưu tồn kho;

• cá nhân hóa trải nghiệm;

• tăng conversion;

• giảm chi phí;

• tìm nguyên nhân khách rời bỏ.

Theo Nha, doanh nghiệp thứ hai đang làm dữ liệu tốt hơn.

Bởi mục tiêu cuối cùng không phải:

Chúng tôi sở hữu Big Data.

Mà là:

Dữ liệu này giúp mình quyết định hoặc hành động tốt hơn điều gì?

Nếu không trả lời được câu đó, đôi khi chúng ta đang xây một cái kho rất lớn.

Chứ chưa chắc đang tạo ra giá trị.

Big Data không phải là một công nghệ

Đây cũng là một điều dễ nhầm.

Không có một phần mềm duy nhất tên:

BigData.exe 

Cài xong là công ty có Big Data.

Big Data là một bài toán dữ liệu.

Để giải quyết nó, chúng ta có thể sử dụng nhiều công nghệ khác nhau:

• distributed storage;

• distributed computing;

• data warehouse;

• data lake;

• lakehouse;

• stream processing;

• NoSQL;

• cloud storage;

• Apache Spark;

• Kafka;

• các dịch vụ dữ liệu trên cloud.

Công nghệ thay đổi.

Bài toán vẫn là:

Làm sao thu thập, lưu trữ, xử lý, quản trị và khai thác dữ liệu ở quy mô phù hợp?

Hadoop có còn đồng nghĩa với Big Data không?

Ngày trước nói Big Data thường rất dễ đi cùng Hadoop.

Có lúc học Big Data gần như đồng nghĩa:

Học Hadoop.

Hadoop rất quan trọng trong lịch sử Big Data vì nó phổ biến cách lưu trữ và xử lý dữ liệu phân tán trên nhiều máy.

Nhưng ngày nay hệ sinh thái dữ liệu rộng hơn rất nhiều.

Cloud giúp doanh nghiệp sử dụng tài nguyên theo nhu cầu.

Apache Spark phổ biến cho xử lý dữ liệu.

Data warehouse trên cloud có thể xử lý dữ liệu rất lớn.

Data lake cho phép lưu nhiều loại dữ liệu.

Lakehouse cố gắng kết hợp ưu điểm của data lake và data warehouse.

Streaming platform xử lý dữ liệu liên tục.

Vì vậy:

Big Data không phải Hadoop.

Hadoop là một trong những công nghệ quan trọng từng giúp giải quyết Big Data.

Hai khái niệm không phải một.

Data Warehouse, Data Lake và Lakehouse khác Big Data thế nào?

Nha diễn giải đơn giản như sau.

Data Warehouse

Giống một kho dữ liệu đã được tổ chức khá cẩn thận.

Thường phục vụ:

• báo cáo;

• BI;

• dashboard;

• phân tích dữ liệu có cấu trúc.

Data Lake

Giống một hồ chứa lớn.

Có thể lưu:

• structured data;

• semi-structured data;

• unstructured data.

Dữ liệu có thể được giữ ở dạng gần với nguyên bản để xử lý sau.

Data Lakehouse

Là cách tiếp cận cố gắng kết hợp:

sự linh hoạt của Data Lake

với:

khả năng quản lý và phân tích của Data Warehouse.

Nhưng cần nhớ:

Data Warehouse, Data Lake hay Lakehouse là kiến trúc/công nghệ quản lý dữ liệu.

Còn Big Data mô tả đặc điểm và bài toán của dữ liệu.

Đừng gom mọi khái niệm thành một.

Cloud đã làm Big Data thay đổi rất nhiều

Trong bài năm 2016, Nha từng viết đại ý:

Người dùng bình thường rất khó khai thác Big Data vì các giải pháp có thể tốn hàng trăm nghìn USD.

Nếu viết hôm nay, Nha sẽ không còn nói như vậy.

Cloud thay đổi khá nhiều thứ.

Ngày trước muốn xử lý dữ liệu rất lớn có thể phải:

• mua server;

• mua storage;

• dựng cluster;

• thuê đội vận hành;

• đầu tư trước rất nhiều.

Ngày nay có thể thuê:

• storage;

• database;

• data warehouse;

• compute;

• streaming;

• machine learning;

theo nhu cầu.

Chưa kể rất nhiều công nghệ dữ liệu quan trọng là mã nguồn mở.

Điều đó không có nghĩa Big Data trở thành rẻ.

Xử lý hàng petabyte vẫn có thể rất tốn tiền.

Nhưng:

Rào cản để bắt đầu đã thấp hơn rất nhiều.

Một nhóm nhỏ hoàn toàn có thể xây những pipeline dữ liệu mà năm 2016 cần một hệ thống phức tạp hơn rất nhiều.

Big Data và AI có phải một thứ không?

Không.

Đây là hai khái niệm khác nhau.

Big Data tập trung vào:

lưu trữ, xử lý và khai thác dữ liệu có quy mô hoặc độ phức tạp lớn.

AI tập trung vào:

xây dựng hệ thống có khả năng thực hiện những nhiệm vụ liên quan đến nhận diện, dự đoán, sinh nội dung, ra gợi ý hoặc tự động hóa dựa trên mô hình.

Nhưng hai thứ ngày càng liên quan.

Machine Learning cần dữ liệu để học.

Deep Learning thường cần lượng dữ liệu lớn.

Generative AI cũng mở ra nhu cầu khai thác rất nhiều:

• văn bản;

• hình ảnh;

• audio;

• video;

• tài liệu doanh nghiệp.

Nhưng có một hiểu lầm Nha muốn tránh:

Có nhiều dữ liệu không tự nhiên tạo ra AI tốt.

Nếu dữ liệu:

• sai;

• trùng;

• thiên lệch;

• thiếu ngữ cảnh;

• không được quản trị;

• không có quyền sử dụng rõ ràng;

thì mô hình AI vẫn có thể tạo ra kết quả tệ.

Big Data giúp chúng ta có nhiều nguyên liệu.

Data quality quyết định nguyên liệu đó có dùng được không.

AI/ML quyết định chúng ta xử lý nguyên liệu theo cách nào.

Đừng trộn ba việc thành một.

Google Flu Trends – một ví dụ mà Nha muốn sửa lại

Đây là phần thú vị nhất khi Nha đọc lại bài năm 2016.

Ngày đó Nha dùng Google Flu Trends như một ví dụ rất đẹp về sức mạnh Big Data.

Ý tưởng nghe quá hay.

Google nhìn vào lượng tìm kiếm liên quan đến triệu chứng cúm.

Từ đó dự đoán mức độ lây lan của dịch.

Nhanh hơn dữ liệu y tế truyền thống.

Quá đẹp cho một bài Big Data.

Nhưng câu chuyện sau đó không đẹp hoàn toàn như vậy.

Google Flu Trends từng gặp những sai số rất lớn.

Một số nghiên cứu chỉ ra hệ thống đã có thời điểm đánh giá mức độ cúm cao hơn đáng kể so với dữ liệu giám sát thực tế.

Google Flu Trends sau đó ngừng hoạt động vào năm 2015.

Và đây lại trở thành một bài học Big Data còn hay hơn ví dụ Nha từng viết.

Bài học là:

Big Data không thay thế tư duy khoa học.

Có hàng tỷ dữ liệu không có nghĩa mô hình sẽ đúng.

Correlation không tự nhiên trở thành causation.

Hành vi con người thay đổi.

Thuật toán thay đổi.

Nguồn dữ liệu thay đổi.

Media có thể ảnh hưởng đến lượng tìm kiếm.

Bias vẫn tồn tại.

Model drift vẫn tồn tại.

Nha thấy đây là một bài học rất đáng nhớ:

More data không tự động đồng nghĩa với better data.

Có khi dữ liệu ít hơn nhưng được lấy mẫu và kiểm soát tốt lại đáng tin hơn.

Big Data được ứng dụng vào đâu?

Ứng dụng thì rất nhiều.

Nhưng Nha thích chia theo bài toán thay vì liệt kê ngành.

Cá nhân hóa

Một hệ thống có thể học từ:

xem gì → tìm gì → click gì → mua gì → bỏ gì 

để đưa ra recommendation phù hợp hơn.

Phát hiện gian lận

Phân tích lượng giao dịch lớn để tìm:

• hành vi bất thường;

• giao dịch đáng ngờ;

• pattern khác thường.

Dự báo

Dữ liệu lịch sử kết hợp các yếu tố khác có thể giúp dự đoán:

• nhu cầu;

• doanh số;

• tồn kho;

• lưu lượng;

• churn.

Vận hành

Log từ hàng nghìn máy chủ, thiết bị và ứng dụng có thể được phân tích để:

• phát hiện lỗi;

• cảnh báo;

• tìm bottleneck;

• dự báo sự cố.

IoT

Cảm biến liên tục sinh dữ liệu về:

• nhiệt độ;

• vị trí;

• tốc độ;

• máy móc;

• phương tiện;

• môi trường.

Đây là bài toán điển hình của Volume + Velocity.

Marketing và trải nghiệm khách hàng

Dữ liệu từ:

• website;

• ứng dụng;

• CRM;

• quảng cáo;

• giao dịch;

• chăm sóc khách hàng;

có thể được kết nối để hiểu hành trình người dùng tốt hơn.

Nhưng Nha nhấn mạnh:

Thu thập được không đồng nghĩa được phép sử dụng tùy ý.

Privacy, consent, security và governance phải đi cùng dữ liệu.

Một doanh nghiệp nhỏ có cần Big Data không?

Không nhất thiết.

Đây là một câu hỏi Nha thấy rất thực tế.

Nếu doanh nghiệp có 100.000 dòng dữ liệu và Excel giải quyết tốt thì:

Cứ dùng Excel.

Không cần dựng Hadoop cluster để trông công nghệ hơn.

Nếu SQL Server xử lý ổn:

Cứ dùng SQL Server.

Nếu PostgreSQL xử lý tốt:

Cứ dùng PostgreSQL.

Công nghệ tốt nhất không phải công nghệ nghe hoành tráng nhất.

Mà là:

Công nghệ đủ để giải quyết bài toán với chi phí hợp lý.

Nha rất thích nguyên tắc:

Đừng xây Big Data trước khi thực sự có bài toán Big Data.

Vậy khi nào bắt đầu nghĩ tới kiến trúc Big Data?

Nha sẽ nhìn một số tín hiệu.

Dữ liệu tăng quá nhanh

Hệ thống hiện tại bắt đầu quá tải.

Có nhiều loại dữ liệu

Không chỉ bảng quan hệ mà còn log, JSON, ảnh, tài liệu, sự kiện...

Cần xử lý gần real-time

Batch cuối ngày không còn đủ.

Một máy không giải quyết tốt

Cần phân tán storage hoặc compute.

Chi phí bắt đầu mất kiểm soát

Kiến trúc hiện tại vẫn chạy nhưng scale lên quá đắt.

Nhiều nhóm cần dùng cùng dữ liệu

BI, Data Science, AI, vận hành và sản phẩm đều cần truy cập.

Đó là lúc cần nghĩ nghiêm túc về kiến trúc dữ liệu.

Không phải lúc đọc báo thấy:

Big Data đang là xu hướng.

Nếu xây hệ thống dữ liệu từ đầu, Nha sẽ nghĩ theo thứ tự nào?

Không bắt đầu từ tool.

Không phải:

Dùng Spark hay Databricks?

Kafka hay cái khác?

Data Lake hay Lakehouse?

Nha sẽ bắt đầu:

1. Bài toán là gì?

Muốn cải thiện quyết định nào?

2. Cần dữ liệu gì?

Không phải dữ liệu nào thu được cũng cần lưu.

3. Dữ liệu đến từ đâu?

Website?

App?

CRM?

Transaction?

IoT?

Third-party?

4. Chất lượng thế nào?

Ai chịu trách nhiệm?

Định nghĩa metric ra sao?

5. Cần nhanh đến mức nào?

Real-time?

5 phút?

1 giờ?

Ngày hôm sau?

6. Ai sử dụng?

Dashboard?

Data Analyst?

Data Scientist?

AI?

Ứng dụng production?

7. Giá trị tạo ra có lớn hơn chi phí không?

Đây là chữ Value quay trở lại.

Tool đứng sau những câu hỏi đó.

Điều Nha từng hiểu chưa đủ về Big Data

1. Big Data là dữ liệu cực kỳ lớn

Đúng nhưng chưa đủ.

Volume chỉ là một chiều.

2. Phải đạt TB hoặc PB mới gọi là Big Data

Không có một ngưỡng cố định như vậy.

Nó còn phụ thuộc bài toán và hệ thống.

3. Có nhiều dữ liệu thì phân tích sẽ chính xác hơn

Không.

Google Flu Trends là một ví dụ rất đáng học.

Big data không thay thế good data.

4. Big Data rất đắt và chỉ công ty lớn mới làm được

Không còn đúng như trước.

Cloud và mã nguồn mở đã giảm đáng kể rào cản tiếp cận.

5. Big Data đồng nghĩa Hadoop

Không.

Hadoop là một phần quan trọng trong lịch sử Big Data, không phải định nghĩa của Big Data.

6. Thu thập càng nhiều dữ liệu càng tốt

Nha không còn nghĩ vậy.

Thu thập dữ liệu phải đi cùng:

• mục đích;

• chất lượng;

• bảo mật;

• privacy;

• governance;

• chi phí.

7. Big Data tự nhiên tạo ra giá trị

Không.

Dữ liệu nằm trong kho vẫn chỉ là dữ liệu.

Giá trị chỉ xuất hiện khi nó giúp chúng ta:

hiểu tốt hơn,

quyết định tốt hơn,

hoặc hành động tốt hơn.

Big Data năm 2026 còn quan trọng không?

Có.

Chỉ là chúng ta ít phải hô:

BIG DATA!

như thời điểm khoảng một thập niên trước.

Nhiều thứ từng được gọi là Big Data giờ đã trở thành hạ tầng khá bình thường của hệ thống hiện đại:

• cloud data warehouse;

• data lake;

• streaming;

• distributed computing;

• analytics;

• machine learning;

• lakehouse;

• AI.

Big Data không biến mất.

Nó dần trở thành một phần của data engineering và data platform.

Và AI lại khiến câu chuyện dữ liệu quan trọng hơn.

AI có thể rất thông minh.

Nhưng cuối cùng nó vẫn phải dựa vào dữ liệu.

Nếu dữ liệu doanh nghiệp mỗi nơi một kiểu, không biết nguồn nào đúng, khách hàng bị trùng, metric không thống nhất...

thì trước khi nói đến AI, có khi việc nên làm là:

Dọn dữ liệu trước đã.

Không hào nhoáng bằng demo AI.

Nhưng thường hữu ích hơn.

Bạn nên mang gì về sau bài này?

Nếu chỉ nhớ năm điều, Nha chọn:

1. Big Data không đơn giản là dữ liệu rất nhiều

Hãy nghĩ đến Volume, Velocity, Variety, Veracity và Value.

2. Không có ngưỡng TB hay PB cố định

“Big” phụ thuộc vào bài toán và khả năng của hệ thống.

3. Nhiều dữ liệu không đồng nghĩa dữ liệu tốt

Data quality quan trọng hơn việc khoe số lượng record.

4. Big Data không phải một công nghệ

Hadoop, Spark, Data Lake, Warehouse, Lakehouse hay cloud chỉ là những công cụ và kiến trúc để giải quyết bài toán.

5. Value mới là đích đến

Nếu dữ liệu không giúp giải quyết vấn đề nào thì có bao nhiêu petabyte cũng chưa nói lên nhiều điều.

Nếu phải rút lại thành một câu, Nha chọn:

Đừng bắt đầu Big Data bằng câu hỏi “chúng ta có bao nhiêu dữ liệu?”, hãy bắt đầu bằng “dữ liệu này giúp chúng ta làm gì tốt hơn?”.

Mười năm trước Nha mua một cuốn sách vì nhìn thấy chữ Big Data.

Lúc đó bị thu hút bởi chữ Big.

Bây giờ đọc lại bài này, Nha thấy chữ đáng quan tâm hơn lại là:

Value.

Có lẽ đó cũng là điều hay của việc giữ blog lâu năm.

Không chỉ thấy công nghệ đã thay đổi.

Tài liệu tham khảo

Trong quá trình cập nhật lại bài viết được viết từ năm 2016, Nha tham khảo và đối chiếu thêm các tài liệu về Big Data, kiến trúc dữ liệu và một số ví dụ được nhắc đến trong phiên bản cũ:

• IBM – What is Big Data? – Tổng quan về Big Data và mô hình 5V gồm Volume, Velocity, Variety, Veracity và Value.
• Google Cloud – What is Big Data? – Giải thích Big Data dựa trên quy mô, tốc độ, sự đa dạng của dữ liệu và giới hạn của các hệ thống quản lý dữ liệu truyền thống.
• IBM – What is Big Data Analytics? – Tổng quan về cách phân tích dữ liệu lớn, các đặc trưng của Big Data và những kỹ thuật được sử dụng để biến dữ liệu thành insight.
• Databricks – What is a Data Lakehouse? – Tài liệu giải thích kiến trúc Lakehouse và cách kết hợp khả năng mở rộng của Data Lake với khả năng quản lý, truy vấn của Data Warehouse.
• Nature – Detecting influenza epidemics using search engine query data – Nghiên cứu ban đầu về việc sử dụng dữ liệu truy vấn Google để theo dõi hoạt động của bệnh cúm, nền tảng cho Google Flu Trends.
• Scientific Reports – Using Networks to Combine “Big Data” and Traditional Surveillance to Improve Influenza Predictions – Nghiên cứu phân tích những sai số của Google Flu Trends và cho thấy việc kết hợp Big Data với dữ liệu giám sát truyền thống có thể cải thiện kết quả.

Bài viết gốc được Nha xuất bản ngày 11/10/2016 và được cập nhật lại vào tháng 09/2026. Nội dung mới là cách Nha nhìn lại kiến thức cũ sau khi đối chiếu với tài liệu hiện tại và những thay đổi của công nghệ dữ liệu trong khoảng 10 năm qua. Phiên bản năm 2016 vẫn được giữ ở cuối bài để tham khảo và so sánh.

Phiên bản bài viết năm 2016

Tổng hợp