Sự cáo chung của Big Data (2023)
(motherduck.com)- Dựa trên kinh nghiệm thời kỳ đầu làm kỹ sư BigQuery, nút thắt của nhiều tổ chức gần với cách sử dụng dữ liệu và cấu trúc chi phí hơn là kích thước dữ liệu
- Từ khách hàng BigQuery và phản hồi trong ngành, phần lớn kho dữ liệu có quy mô dưới 1TB, và ngay cả mức trung vị của các khách hàng dùng nhiều cũng nhỏ hơn rất nhiều so với 100GB
- Việc tách biệt storage và compute trên cloud đã làm dung lượng lưu trữ tăng mạnh, nhưng nhu cầu compute cho phân tích tập trung vào dữ liệu gần đây và dữ liệu tổng hợp nên không tăng theo cùng tỷ lệ
- Trong BigQuery, 90% truy vấn của khách hàng chi hơn 1.000 USD mỗi năm xử lý dưới 100MB, và ngay cả khách hàng có dataset khổng lồ cũng không thường xuyên chạy truy vấn lớn
- Dữ liệu cũ có thể trở thành gánh nợ vì quy định, kiện tụng, ý nghĩa phai nhạt và logic xử lý đặc biệt, nên cần xem lại liệu tổng hợp, xóa hoặc tóm lược có tốt hơn việc giữ nguyên dữ liệu gốc hay không
Sự khác biệt giữa nỗi sợ Big Data và nút thắt thực tế
- Hơn 10 năm qua, thông điệp rằng rất khó rút ra insight có thể hành động từ dữ liệu vì quy mô dữ liệu đã liên tục được lặp lại
- Đi kèm là đơn thuốc rằng chỉ cần mua công nghệ mới để xử lý mở rộng quy mô lớn là sẽ giải quyết được, nhưng ngay cả sau khi mua công cụ mới và di chuyển khỏi hệ thống legacy, nhiều tổ chức vẫn gặp khó trong việc hiểu dữ liệu của mình
- Tình hình năm 2023 đã khác thời điểm những lời cảnh báo về Big Data bắt đầu xuất hiện
- Cuộc đại hồng thủy dữ liệu được dự đoán đã không xảy ra
- Quy mô dữ liệu có tăng phần nào, nhưng phần cứng tăng nhanh hơn
- Vendor vẫn nhấn mạnh khả năng scale, nhưng người làm thực tế bắt đầu nghi ngờ điều đó liên quan thế nào đến vấn đề họ đang gặp
Quy mô dữ liệu khách hàng nhìn từ trải nghiệm BigQuery
- Tác giả, một kỹ sư sáng lập của Google BigQuery, từng chạy truy vấn 1PB trong các buổi trình bày công khai để trình diễn khả năng xử lý dữ liệu quy mô lớn
- Sau đó ông debug vấn đề của khách hàng BigQuery, đồng chấp bút 2 cuốn sách, và từ năm 2018 đảm nhiệm vai trò quản lý sản phẩm với công việc trao đổi với khách hàng và phân tích các chỉ số sản phẩm
- Quan sát gây ngạc nhiên nhất là phần lớn người dùng “BigQuery” thực ra không hề có Big Data
- Ngay cả khách hàng có dữ liệu lớn cũng thường có workload chỉ dùng một phần nhỏ của toàn bộ dataset
- Khi BigQuery ra mắt, tốc độ xử lý nhanh trông như khoa học viễn tưởng, nhưng về sau các cách xử lý truyền thống hơn cũng đã bắt kịp
- Các biểu đồ trong bài là phác thảo dựa trên ký ức chứ không phải số liệu chính xác, và điều quan trọng không phải giá trị tuyệt đối mà là hình dạng của phân bố
- Cơ sở nhận định đến từ log truy vấn, phân tích hậu kiểm giao dịch, kết quả benchmark, ticket hỗ trợ khách hàng, trao đổi với khách hàng, service log, bài blog công khai và trực giác
Phần lớn tổ chức không có nhiều dữ liệu đến vậy
- Những slide bán hàng kiểu “Big Data đang đến” truyền đi thông điệp rằng chẳng bao lâu nữa ai cũng sẽ bị dữ liệu nhấn chìm, nhưng sau 10 năm tương lai đó vẫn không thành hiện thực
- Nhìn vào quy mô khách hàng BigQuery, tổng dữ liệu lưu trữ của đa số khách hàng là dưới 1TB
- Có khách hàng có hàng trăm PB dữ liệu, nhưng quy mô tuân theo phân bố lũy thừa giảm rất nhanh
- Có hàng nghìn khách hàng trả dưới 10 USD/tháng cho storage, tương đương khoảng 0,5TB
- Ngay cả trong nhóm dùng dịch vụ nhiều, mức lưu trữ trung vị vẫn nhỏ hơn rất nhiều so với 100GB
- Trong các cuộc trao đổi với các nhà phân tích ngành như Gartner và Forrester, phản hồi cũng cho thấy phần lớn data warehouse của doanh nghiệp nhỏ hơn 1TB
- Theo cảm nhận chung của ngành, quy mô hợp lý của một data warehouse là khoảng 100GB
- Nhóm BigQuery lấy quy mô này làm trọng tâm chính cho nỗ lực benchmark
- Một nhà đầu tư khảo sát các công ty trong danh mục của mình và thấy rằng ngay cả ở các công ty công nghệ, nơi quy mô dữ liệu có khả năng tương đối lớn, công ty B2B lớn nhất chỉ khoảng 1TB, công ty B2C lớn nhất khoảng 10TB, còn đa số nhỏ hơn nhiều
- Ngay cả trong ví dụ về doanh nghiệp cỡ trung, dữ liệu cũng không dễ phình thành khổng lồ
- Giả sử 1.000 khách hàng mỗi ngày tạo 1 đơn hàng và 100 line item thì lượng dữ liệu mỗi ngày vẫn dưới 1MB, và sau 3 năm cũng chỉ khoảng 1GB
- Một database marketing có 1 triệu lead và vài chục campaign thì bảng lead vẫn dưới 1GB, còn theo dõi campaign nhiều khả năng chỉ ở mức vài GB
- Ngay cả khi SingleStore là một kỳ lân Series E tăng trưởng nhanh giai đoạn 2020~2022, toàn bộ warehouse tài chính, dữ liệu khách hàng, theo dõi campaign marketing và service log cộng lại cũng chỉ vài GB
Ảo giác do việc tách storage và compute tạo ra
- Các nền tảng dữ liệu cloud hiện đại đều áp dụng tách biệt storage và compute, giúp khách hàng không bị khóa vào một form factor duy nhất
- Thay đổi này có thể còn quan trọng hơn cả scale-out trong kiến trúc dữ liệu suốt 20 năm qua
- Thay cho kiến trúc shared-nothing khó quản lý, cấu trúc shared disk cho phép mở rộng storage và compute một cách độc lập
- Object storage có thể mở rộng và đủ nhanh như S3 và GCS giúp nới lỏng các ràng buộc trong thiết kế database
- Trên thực tế, quy mô dữ liệu tăng nhanh hơn rất nhiều so với quy mô compute
- Dữ liệu được tạo ra theo thời gian, nên ngay cả ở doanh nghiệp tĩnh, lượng lưu trữ cũng tăng tuyến tính theo thời gian
- Phân tích thường chủ yếu nhắm vào dữ liệu gần đây nên nhu cầu compute không cần tăng như dung lượng lưu trữ
- Dữ liệu cũ không thay đổi, vì vậy cứ tiếp tục scan nó là gần như lãng phí, còn những câu trả lời quan trọng có thể được tạo ra qua tổng hợp
- Với các khách hàng chuyển từ on-premises sang cloud có tách storage và compute, lượng lưu trữ tăng mạnh nhưng nhu cầu compute thường không thay đổi nhiều
- Một khách hàng bán lẻ lớn của BigQuery có data warehouse on-premises khoảng 100TB, nhưng sau khi lên cloud đã tăng thành 30PB
- Dung lượng lưu trữ tăng 300 lần, nhưng chi phí compute không tăng theo cùng tỷ lệ, và họ không hề chi hàng tỷ USD cho phân tích
- Cấu trúc này cho thấy nếu dùng object store có khả năng mở rộng thì có thể chỉ cần ít compute hơn rất nhiều so với dự đoán, thậm chí có thể không cần distributed processing
Workload truy vấn thực tế nhỏ hơn rất nhiều so với toàn bộ dữ liệu
- Khối lượng dữ liệu mà workload phân tích thực sự xử lý có thể nhỏ hơn trực giác nghĩ rất nhiều
- Dashboard thường được dựng từ dữ liệu tổng hợp
- Người dùng chủ yếu xem dữ liệu của 1 giờ gần nhất, 1 ngày hoặc 1 tuần
- Bảng nhỏ được truy vấn thường xuyên hơn, còn bảng khổng lồ được truy vấn chọn lọc hơn
- Khi phân tích truy vấn của các khách hàng chi hơn 1.000 USD/năm trên BigQuery, 90% truy vấn xử lý dưới 100MB
- Dữ liệu được chia và phân tích theo nhiều cách để tránh việc khối lượng truy vấn của một khách hàng cụ thể làm méo kết quả
- Các truy vấn chỉ thao tác metadata, không đọc dữ liệu, đã bị loại trừ
- Truy vấn ở mức GB chỉ xuất hiện ở các percentile cao, còn truy vấn mức TB là cực kỳ hiếm
- Ngay cả khách hàng có quy mô dữ liệu cực lớn cũng hầu như không truy vấn dữ liệu cực lớn
- Khi họ chạy truy vấn lớn, mục đích thường là tạo báo cáo và hiệu năng không phải ưu tiên hàng đầu
- Một công ty mạng xã hội lớn chạy các truy vấn rất lớn vào cuối tuần để chuẩn bị báo cáo cho lãnh đạo vào thứ Hai, nhưng đó chỉ là phần cực nhỏ trong hàng trăm nghìn truy vấn của cả tuần
- Các database phân tích hiện đại dùng nhiều kỹ thuật để giảm lượng dữ liệu thực sự phải đọc
- Column projection chỉ đọc các field cần thiết
- Partition pruning chỉ đọc phạm vi ngày hẹp
- Loại bỏ segment nhờ clustering hoặc micro-partitioning tự động để tận dụng tính cục bộ của dữ liệu
- Tính toán trên dữ liệu nén, projection và predicate pushdown cũng giúp giảm I/O tại thời điểm truy vấn
- Việc giảm I/O làm giảm lượng tính toán cần thiết, hạ chi phí và độ trễ
- Tài liệu liên quan: giảm chi phí cloud data warehouse
- Tài liệu liên quan: chẩn đoán nút thắt hiệu năng data warehouse
Chi phí xử lý dữ liệu buộc người ta phải truy vấn nhỏ hơn
- Việc có thể xử lý nhanh nhờ scale-out không đồng nghĩa với xử lý rẻ
- Nếu cần 1.000 node để ra kết quả thì chi phí có thể rất lớn
- Truy vấn 1PB từng được chạy trong demo BigQuery có giá bán lẻ là 5.000 USD
- Kiểu kém hiệu quả này là một phần của big data tax đối với các nhóm không vận hành ở quy mô PB
- Động lực tài chính để giảm lượng dữ liệu xử lý vẫn tồn tại ngay cả khi không dùng mô hình tính phí theo số byte scan
- Dù là chi phí scan của BigQuery hay chi phí nhàn rỗi của instance Snowflake, các cloud data warehouse lớn đều có thể âm thầm làm hóa đơn phình ra
- Làm truy vấn nhỏ hơn giúp dùng instance nhỏ hơn, truy vấn nhanh hơn và chạy đồng thời được nhiều hơn
Phần lớn dữ liệu gần như không bao giờ được truy vấn
- Tỷ lệ lớn dữ liệu được xử lý là dữ liệu mới trong vòng dưới 24 giờ
- Khi dữ liệu đã khoảng 1 tuần tuổi, xác suất nó được truy vấn thấp hơn khoảng 20 lần so với dữ liệu của ngày gần nhất
- Sau 1 tháng, dữ liệu phần lớn chỉ nằm đó và chỉ được truy vấn khi chạy các báo cáo hiếm gặp
- Phân bố độ tuổi của dữ liệu được lưu trữ bằng phẳng hơn nhiều so với mô hình truy cập
- Nhiều dữ liệu bị bỏ đi khá nhanh, nhưng cũng có nhiều dữ liệu tiếp tục được append ở cuối bảng
- Ngay cả khi dữ liệu của 1 năm gần nhất chỉ chiếm 30% tổng dữ liệu, nó vẫn có thể chiếm 99% lượt truy cập dữ liệu
- Ngay cả khi dữ liệu của 1 tháng gần nhất chỉ chiếm 5% tổng dữ liệu, nó vẫn có thể chiếm 80% lượt truy cập dữ liệu
- Khi dữ liệu dần lắng xuống theo thời gian, working set thực tế trở nên có kích thước dễ quản lý hơn dự đoán
- Dù có một bảng 1PB chứa dữ liệu 10 năm, phần được truy cập thường xuyên trên thực tế có thể chỉ là dữ liệu trong ngày
- Dữ liệu trong ngày có thể dưới 50GB sau khi nén
Giới hạn của một máy đơn vẫn liên tục được đẩy xa hơn
- Nếu định nghĩa Big Data là “thứ không thể nằm vừa trong một máy đơn”, thì số workload thuộc loại đó đang giảm dần qua từng năm
- Khi bài báo Google MapReduce năm 2004 được viết, chuyện workload dữ liệu thông thường không thể nằm trong một máy đa dụng đơn lẻ là rất phổ biến
- Khi AWS ra mắt EC2 năm 2006, instance được cung cấp chỉ có một lõi CPU và 2GB RAM, nên nhiều workload không vừa với cỗ máy đó
- Hiện nay, instance tiêu chuẩn của AWS dùng 64 core và 256GB RAM ở mức máy chủ vật lý
- RAM đã tăng lên theo bội số hai chữ số so với các instance EC2 đầu tiên năm 2006
- Nếu trả thêm cho các instance tối ưu bộ nhớ, có thể nâng RAM thêm nhiều bội số hai chữ số nữa
- Điều này dẫn đến câu hỏi có bao nhiêu workload thực sự cần hơn 24TB RAM hoặc 445 CPU core
- Trên cloud, chi phí của VM lớn tăng gần tuyến tính theo sức mạnh compute
- Một VM dùng trọn máy chủ chỉ đắt gấp 8 lần VM dùng 1/8 máy chủ
- Có thể cho rằng hiệu năng tương đương benchmark 3.000 node song song trong bài báo Dremel gốc nay có thể đạt được trên một node đơn
Dữ liệu có thể là gánh nợ chứ không phải tài sản
- Một định nghĩa khác của Big Data là “trạng thái mà chi phí giữ lại dữ liệu còn thấp hơn chi phí quyết định nên vứt bỏ thứ gì”
- Data lake của nhiều tổ chức giống một đầm lầy khổng lồ phình to không phải vì cần mà vì chưa xóa
- Không biết bên trong có gì
- Không biết dọn dẹp có an toàn hay không
- Chi phí giữ dữ liệu lớn hơn chi phí vật lý để lưu byte
- Các quy định như GDPR và CCPA yêu cầu phải theo dõi việc sử dụng một số loại dữ liệu nhất định
- Một số dữ liệu phải bị xóa trong thời hạn nhất định
- Nếu số điện thoại còn nằm quá lâu trong các file parquet của data lake, tổ chức có thể vi phạm yêu cầu pháp lý
- Dữ liệu cũ cũng có thể bị dùng bất lợi cho tổ chức trong kiện tụng
- Giống như nhiều tổ chức giới hạn thời gian lưu email để giảm trách nhiệm pháp lý tiềm ẩn, dữ liệu trong data warehouse cũng có thể trở thành bằng chứng bất lợi
- Nếu log từ 5 năm trước cho thấy lỗi bảo mật trong code hoặc vi phạm SLA, thì càng giữ lâu thời gian phơi bày pháp lý càng kéo dài
- Dữ liệu cũng có thể mất dần ý nghĩa giống như hiện tượng bit rot của code
- Mọi người có thể quên ý nghĩa chính xác của các field đặc biệt
- Các bug dữ liệu trong quá khứ có thể biến mất khỏi trí nhớ
- Ví dụ, trong một thời gian ngắn mọi
customer idcó thể đã bị đặt thành null, hoặc một giao dịch gian lận khổng lồ có thể đã khiến kết quả quý 3 năm 2017 trông đẹp hơn thực tế - Logic nghiệp vụ để lôi dữ liệu từ các giai đoạn cũ ra có thể ngày càng phức tạp, như “trước 2019 thì là revenue, từ 2019~2021 là revenue_usd, từ 2022 trở đi là revenue_usd_audited”
Kiểm tra xem bạn có thuộc nhóm 1% Big Data không
- Big Data là có thật, nhưng có thể phần lớn mọi người không cần lo lắng về nó
- Để tự đánh giá mình có phải Big Data One-Percenter hay không, có thể đặt các câu hỏi sau
- Bạn có thực sự tạo ra lượng dữ liệu khổng lồ không
- Nếu có, bạn có thực sự cần dùng lượng dữ liệu khổng lồ đó cùng một lúc không
- Nếu có, nó có thực sự lớn đến mức không thể nằm trong một máy đơn không
- Nếu có, liệu bạn có chỉ là người đang chất đống dữ liệu mà thôi không
- Nếu vậy, có phải tổng hợp nó sẽ tốt hơn không
- Nếu chỉ cần một trong các câu hỏi này có câu trả lời là “không”, bạn có thể là ứng viên phù hợp cho thế hệ công cụ dữ liệu mới, tương xứng hơn với quy mô dữ liệu thực tế mình đang có
- Một ví dụ liên quan được nhắc đến là các lựa chọn thay thế BigQuery hiện đại
- Thay vì sợ hãi quy mô dữ liệu mà có thể một ngày nào đó mình sẽ có, các tổ chức nên chọn công cụ và chính sách lưu trữ dựa trên quy mô dữ liệu thật sự đang có và mô hình truy vấn thực tế của mình
1 bình luận
Các ý kiến trên Hacker News
Một câu hỏi bẫy mà tôi từng hay dùng ở công ty cũ khi tuyển nhà khoa học dữ liệu là: “Nếu yêu cầu nói rằng có tối đa 6TiB dữ liệu, bạn sẽ xây stack/kiến trúc nào?”
Khi nghe những câu trả lời hoành tráng như BigQuery, Hadoop, rồi hỏi thêm chi phí phần cứng/phần mềm/giấy phép, thường sẽ ra báo giá hàng chục nghìn đô la mỗi năm
Cuối cùng, người được nhận là người hiểu rằng 6TiB là lượng dữ liệu mà 6 người trong một phòng có thể chia nhau chứa trên smartphone; một ổ HDD doanh nghiệp giá 199 đô la là đủ, hoặc ba ổ để có dự phòng; và dữ liệu dạng CSV có thể được nạp vào bộ nhớ nhiều lần rồi xử lý bằng cả script
awkBản thân tôi cũng dễ rơi vào lỗi “khi đã học dùng búa thì mọi thứ trông như cái đinh”, nhưng trong tuyển dụng, việc không có cảm giác về quy mô của “big data thật sự” là lý do để loại
Thay vì kết luận chỉ từ những câu trả lời đó rằng họ sẽ thiết kế quá mức mọi thứ, có lẽ đúng hơn là xem đó là việc họ mắc bẫy trong một tình huống nhân tạo, nơi người phỏng vấn ở thế thượng phong
Gần đây tôi có một buổi phỏng vấn kỹ thuật với một người phỏng vấn có thâm niên và kinh nghiệm tương tự, và tôi đã trả lời tệ; người phỏng vấn tỏ thái độ phán xét với câu trả lời dở của tôi. Nếu đổi vai, tôi cũng có thể làm anh ta lúng túng y như vậy với một chủ đề mà tôi biết rõ hơn
Nếu là người phỏng vấn, cần đặc biệt cẩn thận để không lạm dụng vị thế vượt trội. Điều đó cũng phản tác dụng với công ty, và cũng không tốt cho người đang ngồi trước mặt mình
“Dịch vụ tư vấn: bạn mang đến cho tôi một bài toán big data, tôi nói ‘tập dữ liệu của bạn vừa trong RAM’, và bạn trả tôi 10.000 đô la vì đã tiết kiệm được 500.000 đô la”
Vài năm trước, một giám đốc cho tôi xem một hệ thống do IT xây bằng Hadoop, API gateway, nhiều lập trình viên, với chi phí hàng trăm nghìn đô la mỗi năm; khi tôi nói rằng với quy mô hiện tại và quy mô tương lai có thể dự đoán, chỉ cần một ổ USB cắm vào laptop của ông ấy cùng vài script Python là đủ để chạy, ông ấy đã rất bực bội, và từ đó tôi không bao giờ được tham gia lại dự án đó nữa
Tôi xem đó là một phần của vòng lặp khoe mẽ lan tràn trong công ty. Đó là một cấu trúc không thể thừa nhận rằng “chúng ta đang làm một việc đơn giản”
awk, và kể cả nếu họ muốn, quét 6TB bằng một CPU đơn lẻ cho mỗi truy vấn mà không có phân vùng hay lưu trữ hướng cột thì lúc nào cũng chậmVới những mục đích như vậy, BigQuery thường khá ổn. Giao diện console đủ dùng cho phân tích ad hoc, và cũng có thể kết nối với nhiều công cụ như Metabase, Tableau
Nếu phân vùng đúng, chi phí cũng không quá cao; nếu có vấn đề thì thêm bảng rollup là được
.parquetbị đánh giá thấp hoàn toàn, và vẫn còn nhiều người chưa biết định dạng nàyKhác với CSV, nó giữ được kiểu dữ liệu, nhỏ hơn CSV 10 lần nên 6TB thành 600GB, và đọc nhanh hơn 50 lần. Đây cũng là một chuẩn mở của Apache Foundation
Không thể nhìn lướt nội dung dễ như CSV, nhưng đánh đổi đó là xứng đáng. Tôi mong nơi nào cung cấp CSV để tải xuống thì cũng cung cấp kèm
.parquetNhìn chung tôi đồng ý với nhiều phần của bài viết, nhưng có vài điểm cần lưu ý. Thứ nhất, MongoDB không phù hợp làm mốc so sánh. Tôi chưa từng thấy việc gì MongoDB làm mà PostgreSQL không làm tốt hơn, và giải pháp big data thường không phải NoSQL/MongoDB mà là cơ sở dữ liệu hướng cột, MapReduce, Cassandra, v.v.
Thứ hai, phải lên kế hoạch cho thành công. 95% doanh nghiệp không trở thành kỳ lân, nhưng nếu nhắm tới 5% còn lại thì không thể đạt được mà không chuẩn bị. Lý do thiết kế có tính đến khả năng mở rộng khi chỉ có 5 khách hàng là để có thể nắm bắt khoảnh khắc tăng trưởng theo cấp số nhân khi nó đến
Tuy vậy, bài học cốt lõi là đúng. Phần lớn dữ liệu không lớn, và dữ liệu về tất cả mọi người trên thế giới cũng có thể nằm vừa trong một chiếc Chromebook 100 đô la. Phần lớn dữ liệu hiếm khi được truy cập và truy vấn cũng nhỏ; bước đầu tiên của các tác vụ big data thường là giảm terabyte xuống quy mô GB, MB, đôi khi là KB thực sự cần thiết. Do quy định, chi phí dữ liệu cũng đang tăng lên
Mọi người không chỉ lập kế hoạch, mà thường còn triển khai luôn. Nếu chỉ lập kế hoạch cho 3 tháng tới, bạn có thể linh hoạt và năng suất hơn nhiều. Nếu không thực thi được thì không thể trở thành kỳ lân
Có vẻ như đó là sự kết hợp giữa hội chứng hệ thống thứ hai và thiên lệch sống sót. Những người đã dọn dẹp mớ hỗn độn của một MVP tốt sẽ phàn nàn “lẽ ra chúng ta phải làm cái này từ trước”, nhưng những công ty thật sự đã lên kế hoạch và thiết kế trước thì không sống sót, nên cũng không còn đó để bị đem ra phàn nàn
Tôi gần như đồng ý với phần còn lại, nhưng chỗ này có vẻ sai nên không thể bỏ qua
Runway của startup có hạn, và nếu các kỹ sư đang tiêu tiền vào những việc chỉ được đền đáp sau vài năm, thì họ đang làm tăng xác suất thất bại trước khi thời điểm đó đến
Việc sản phẩm có được lực kéo mạnh như vậy thường đến từ hiệu ứng tổng hợp của sự tồn tại và nhu cầu của cơ sở người dùng. Ngay cả khi vấp váp trong việc thêm người dùng mới trong lúc tăng trưởng, khả năng người dùng hiện có quay lại sản phẩm cũ hoặc chuyển sang nơi khác là thấp
Twitter ngày xưa gần như ngày nào cũng thấy fail whale, nhưng phần lớn người dùng không rời đi, và cũng không có cuộc di cư quy mô lớn sang một lựa chọn thay thế mở rộng tốt hơn. Bản thân những sản phẩm trải qua tăng trưởng theo cấp số nhân như vậy đã hiếm, và việc chật vật mở rộng trong quá trình đó khiến tính sẵn sàng kém đi là chuyện phổ biến. Tôi tò mò không biết thực tế đã có sản phẩm tăng trưởng theo cấp số nhân nào thất bại vì không mở rộng được hay chưa
Khi “big data” còn là trào lưu, tôi từng là nhà nghiên cứu tại Large Hadron Collider. Với chúng tôi, phân tích toàn bộ dữ liệu là một use case có ý nghĩa, và trong thống kê tần suất luận, càng nhiều dữ liệu càng tốt
Nhưng dù dùng mạng lưới siêu máy tính toàn cầu, chúng tôi nhận ra rằng lưu trữ cục bộ nhanh còn tốt hơn việc chờ các tác vụ khổng lồ hoàn tất. Cuối cùng, mọi nghiên cứu sinh đều thu gọn chính xác dữ liệu liên quan xuống còn 1–5TB mà không mất nhiều độ linh hoạt trong phân tích
Có vẻ ở đây tồn tại một thứ như định luật về sự tiện lợi, tương đương với định luật mở rộng của Amdahl
Điều này có vẻ gần với giới hạn của con người hơn là toán học. Rõ ràng có một trần đối với mức độ linh hoạt mà chúng ta có thể tận dụng. Nó có thể thay đổi nếu xuất hiện cách giúp chạy các loại phân tích mới dễ hơn, nhưng có lẽ sẽ tăng theo kiểu logarit so với số việc ta muốn làm
Con người rất giỏi tìm ra những cách tiện lợi để mỗi năm làm tốt hơn một chút, nhưng bất kỳ ý tưởng nào cũng cần một khoảng thời gian tối thiểu để thực hiện
Nếu tôi nhớ không nhầm, hàng đợi của thiết bị đó dài bằng hoặc dài hơn thời gian chạy công việc trên phần cứng rẻ tiền, và các hệ thống xử lý song song quy mô lớn như Beowulf đã ra đời từ những nỗ lực như vậy
Giảm kích thước cơ sở dữ liệu lưu trữ và khối lượng tính toán là một cách tuyệt vời để giảm tối đa hóa đơn hằng tháng của khách hàng
Theo kinh nghiệm của tôi, dữ liệu tiếp tục tăng theo cấp số nhân, nhưng lượng thông tin thì không tăng như vậy
Trong tài chính, nếu muốn, bạn có thể dễ dàng lấy 100 triệu điểm dữ liệu mỗi ngày cho một chuỗi thời gian, và cũng có thể xử lý hàng nghìn chuỗi thời gian. Nhưng tốc độ lấy mẫu và số lượng chuỗi thời gian đó thường trùng lặp 99,99%. Vì các trị riêng gần như rơi về 0 sau khoảng 10 chiều, đôi khi còn sớm hơn nhiều
Hầu như không có lý do gì để lưu hàng petabyte dữ liệu tick mà bạn sẽ không bao giờ truy vấn. Trong nhiều trường hợp, hợp lý hơn nhiều là thực hiện giảm chiều mạnh tay và có mất mát ngay tại thời điểm thu thập, chỉ lưu vài thành phần chính đầu tiên và các ngoại lệ, đồng thời giám sát độ ổn định của trị riêng để xem liệu những yếu tố mới từng bị xem là không đáng kể có trở nên quan trọng hay không
Kết quả là tập dữ liệu nhỏ hơn và dễ xử lý hơn rất nhiều, và vì thực sự có thể dùng được nên thường còn đem lại insight nhiều hơn
Nghe rất thú vị, nhưng với tôi đây là chủ đề hoàn toàn mới
Điều buồn cười của “big data” là nó từng tạo ra một động cơ méo mó khiến người ta né tránh cả những tối ưu hóa cơ bản và hiển nhiên nhất ở cấp phần mềm. Vì yêu cầu phần cứng càng lớn thì càng chứng minh được mình ghê gớm
Ví dụ, nếu nói “Sếp, thay vì tính trên toàn bộ tập dữ liệu, chỉ cần đọc một mẫu là có thể tính các giá trị trung bình trong báo cáo này chỉ bằng laptop”, thì sếp sẽ hiểu kiểu: “Mẫu là ý gì? Cậu đang ám chỉ gì bằng mấy thứ nhảm nhí kiểu nhà toán học/kỹ sư đó? Chắc không phải là tôi đã phí hàng triệu đô la đấy chứ?”
Thổi phồng bán hàng và nhiễu loạn quanh big data, cùng cuộc thi khoe khoang xem dữ liệu của ai đủ lớn, đã từng rất nghiêm trọng trong một thời gian
Trong một thời gian dài, rất khó có được hơn 64GB bộ nhớ trên một máy, và khi có giới hạn cứng, độ phức tạp triển khai sẽ tăng vọt rất nhanh
Một quy trình chỉ cần dữ liệu lớn hơn một chút và thất bại 1 lần trong 50 lần đã rất phá hoại. Các đội vận hành hàng chục cron job định kỳ như vậy, và nếu mỗi cái thường xuyên hỏng thì cuối cùng chỉ còn việc trực on-call để cắt nhỏ từng mảnh
Hadoop và MapReduce không cực kỳ hiệu quả, nhưng nếu dùng đúng thì khá ổn, và việc chạy ổn định quan trọng hơn nhiều. Ý là nó tốt hơn đoạn mã C++ tối ưu từng bit mà không ai tin tưởng hay bảo trì được, rồi cứ thứ Năm hằng tuần lại chết vì một lỗi segmentation kỳ quặc
Ngày nay thì có lẽ chỉ cần dùng Snowflake, nhưng vào thời đó đó là công cụ hợp lý
Bài viết này không hoàn toàn chính xác. Ban đầu big data được định nghĩa theo ba chiều: dung lượng, tốc độ, đa dạng
Dung lượng nhìn chung đã được giải quyết, tốc độ cũng đã được giải quyết nhưng đắt đỏ. Đa dạng thì vẫn chưa được giải quyết
Big data ngày nay không hẳn là “thiếu dung lượng lưu trữ hay năng lực tính toán”, mà gần với “thiếu năng lực nhận thức để tích hợp và hiểu nó” hơn
Cũng rất khuyến nghị các bài giảng liên quan. Phần lớn có trên YouTube
[1] https://www.youtube.com/watch?v=KRcecxdGxvQ
[2] https://amturing.acm.org/award_winners/stonebraker_1172121.c...
Mỗi máy bay có một hệ thống radar, bên trong có 8 bộ lưu trữ SSD RAID-0 gồm 16 ổ, mỗi bộ 20TiB. Thường không ghi đầy RAID, nên tạo ra khoảng 176TiB mỗi ngày; nếu bay 7 lần trong 2 tuần thì khoảng 1,2PiB mỗi đợt, tức khoảng 7,2PiB mỗi năm
Lý do phải nghỉ một ngày giữa các chuyến bay là vì cần tải dữ liệu qua cáp quang xuống một máy chủ lưu trữ được nhét tạm vào góc nhà chứa máy bay cạnh sân đỗ. Sau đó sao chép sang máy chủ thứ hai để an toàn, và khi nhiệm vụ kết thúc thì gửi toàn bộ về trụ sở để lưu trữ và xử lý
Dữ liệu này có giá trị, nhưng không đến mức “hàng chục tỷ đô la”. Nó được dùng cho khai thác tài nguyên, lập bản đồ, nghiên cứu môi trường và trắc địa, v.v.; chúng tôi đã lưu giữ từng byte từ năm 2008. Vì khi có thuật toán mới, có thể xử lý lại dữ liệu cũ theo tiêu chuẩn mới
Các tệp được stream theo đơn vị 800GiB~2TiB tới máy chủ xử lý GPU, và không nén được. Lý do là phần lớn thứ thu được, bức xạ nền vi sóng vũ trụ, khá ngẫu nhiên. Có lúc tôi từng lầm tưởng rằng ghi ra băng từ sẽ có thể giảm một nửa hạ tầng, nhưng có vẻ dung lượng băng từ được tính như khi lưu các tệp văn bản cỡ gigabyte toàn số 0
GPU cũng chậm, CPU cũng chậm, bus PCIe cũng chậm, RAM cũng chậm, tốc độ gõ phím của tôi cũng chậm. Mọi thứ lúc nào cũng cần nhanh hơn
Mọi thứ đều quá chậm, quá khó và quá nhỏ. Ổ cứng quá nhỏ; việc tinh chỉnh kernel Linux và thiết lập mạng nhanh, ổn định tới cụm xử lý thì quá khó. Ngay cả các bản cập nhật kernel/gói chỉ thay đổi hành vi nội bộ đơn giản cũng làm hỏng hệ thống theo những cách chỉ chúng tôi gặp
Cấu hình mặc định đang sống trong ảo tưởng rằng RAM khan hiếm, nên được đặt để tiết kiệm bộ nhớ cho tác vụ mạng. Nhưng máy chủ tệp có 0,5TB RAM, nên tôi muốn nó dùng hết để làm mạng và hệ thống tệp nhanh hơn. Rốt cuộc phải đọc tài liệu network stack 6 tiếng để kéo I/O lên mức thường thức của năm 2024
Có lẽ tôi hiểu
sysctl.confrõ hơn gần như bất kỳ ai trên Trái ĐấtCác kho lưu trữ đối tượng bền vững phân tán tự xưng dành cho big data hoặc sụp đổ hoàn toàn dưới workload của chúng tôi, hoặc tốn hàng trăm triệu đô la. Khi nói kích thước object xấp xỉ 1TB, nhân viên kinh doanh hệ thống tệp phân tán ngừng trả lời. Có vendor đọc yêu cầu rồi còn nối tôi với người phụ trách khách hàng cơ quan tình báo. Tôi không phải NSA và cũng không có ngân sách của NSA
Thỉnh thoảng có MBA hoặc PMP đọc bài viết về cloud trên Bloomberg nhìn chi phí trung tâm dữ liệu on-premises rồi hỏi về việc chuyển sang AWS hay Azure; khi tôi cho xem các con số về cả tiền lẫn thời gian, họ làm vẻ mặt như sắp nôn và đổi chủ đề
Hơn nữa, các vendor đều đang chạy theo trào lưu AI/cloud và ngừng các dòng sản phẩm phù hợp với chúng tôi. Giờ chúng tôi phải cạnh tranh GPU với các quỹ phòng hộ và startup AI muốn đào bới dữ liệu khách hàng để hiển thị quảng cáo
Chúng tôi thiếu dung lượng lưu trữ và năng lực tính toán, mà dung lượng lưu trữ và năng lực tính toán hiện có cũng quá chậm. DPU/IPU rất thú vị, nhưng một khi object lớn hơn truy vấn cơ sở dữ liệu SQL hay các mảnh video streaming nén thì lập tức đụng giới hạn
Trước đây tôi từng làm ở một công ty tạo ra 20GB dữ liệu phân tích mỗi ngày; có lẽ đó sẽ là dữ liệu lớn nhất tôi từng xử lý
Với tư cách dự án junior, tôi viết tác vụ xử lý dữ liệu để tổng hợp batch và thời gian thực, rồi lưu kết quả vào Parquet blob trên Azure
Sếp đủ thông minh để thường xuyên tổ chức các cuộc họp với bên liên quan nhằm thảo luận giữ gì và bỏ gì, và nhờ thuật toán tốt, dữ liệu có thể được nén xuống khoảng 200MB mỗi ngày
2 tháng gần nhất được đưa lên SQL Server, 2 năm gần nhất được tổng hợp thêm rồi đưa vào một máy chủ khác, và cả công ty truy vấn bằng Excel trong thời gian hợp lý. Dữ liệu big data gốc thì đang mục ruỗng trong kho băng từ để phòng khi một ngày nào đó cần đến
Sếp là một quản lý tệ, nhưng hiểu dữ liệu; nhìn lại thì ông ấy đã làm đúng nhiều thứ và tôi cũng học được rất nhiều
Trong nhiều năm, tôi đã thấy sự over-engineering của các công cụ và pipeline dữ liệu “lớn”. Trong nhiều use case, data warehouse và data lake chỉ ở phạm vi GB hoặc vài TB một chữ số, nên có thể đơn giản hóa hơn nhiều bằng cách chạy DuckDB trên một instance EC2 ổn
Theo kinh nghiệm của tôi, làm vậy thì có kết quả trước cả khi hệ thống khác bắt đầu chạy truy vấn. Tôi đang nói đến Athena đấy
Dạo này tôi nghĩ nhiều truy vấn cũng có thể chạy ngay trong trình duyệt, nên với sự trợ giúp của DuckDB WASM(https://github.com/duckdb/duckdb-wasm) và perspective.js(https://github.com/finos/perspective), tôi đã tạo https://sql-workbench.com/
Có vẻ chu kỳ trào lưu đó rốt cuộc đã chạm tới “cao nguyên chết”. Đây không phải kết cục hiếm trong ngành vốn bị trào lưu chi phối cực độ này
AI cũng dùng toàn bộ dữ liệu và gắn thêm một mạng nơ-ron ma thuật để tìm ra ý nghĩa của nó
Cá nhân tôi cho rằng động lực chính của big data là cái tôi của các nhà sáng lập công ty. Kiểu như: đương nhiên công ty của chúng ta sẽ tăng trưởng bùng nổ và đạt thành công ở quy mô toàn cầu, nên phải thiết kế cho tương xứng với quy mô đó
Thật bi kịch khi mắc sai lầm như vậy, dù chỉ một DB SQLite là đủ cho đến trước khi sản phẩm đạt Series C. Toàn bộ năng lượng lúc này nên tập trung vào sản phẩm, chứ chưa phải vào quy mô
Hadoop bắt đầu từ cảm hứng lấy từ những gì có ở Google, rồi trở nên phổ biến trong các doanh nghiệp trên toàn thế giới muốn xử lý dữ liệu theo cách rẻ hơn và tốt hơn Oracle
Spark xuất hiện như một giải pháp cho sự phức tạp của Hive/Pig và các công cụ tương tự; khi các công ty có thể xây dựng pipeline dữ liệu đáng tin cậy, họ mới có thể đặt AI lên trên đó
Các mô hình dữ liệu được tạo ra từ hành vi có chủ ý của con người như nhấp liên kết, gửi tin nhắn, mua hàng nhìn chung đều nhỏ. Vì số lượng con người và số sự kiện có chủ ý mà con người có thể tạo ra mỗi giây là có giới hạn
Ngược lại, các mô hình dữ liệu do máy tạo ra có thể có tốc độ và dung lượng lớn hơn nhiều bậc độ lớn, và cũng không có ranh giới rõ ràng về kích thước mô hình dữ liệu. Loại dữ liệu này thường là thú vị nhất và bị khai thác chưa đúng mức nhất, vì nó cho phép thu được nhiều sự thật về thế giới mà các mô hình dữ liệu có chủ ý của con người không thể đem lại