2

Tôi mới bắt đầu một dự án nơi chúng tôi quyết định sử dụng Hadoop lần đầu tiên. Chúng tôi là một cửa hàng Python đang phát triển một tính năng phân tích. Chúng tôi có khoảng 150m hồ sơ cần phân tích hàng ngày hoặc khoảng 20 GB dữ liệu. Ngay cả trong các cuộc thảo luận ban đầu của chúng tôi, chúng tôi biết rằng chúng tôi có thể làm điều này với chồng Python và MySQL hiện có của chúng tôi. Nhưng chúng tôi muốn có được đôi chân ướt át với Hadoop và có được một số kinh nghiệm với nó để xem liệu chúng tôi có thể sử dụng nó rộng rãi hơn không.

Dữ liệu lớn giống như tình dục tuổi teen: mọi người đều nói về nó, không ai thực sự biết cách làm điều đó, mọi người đều nghĩ rằng mọi người khác đang làm điều đó, vì vậy mọi người tuyên bố họ đang làm điều đó -  Dan Ariely

Chúng tôi thực sự đã làm mọi thứ hoạt động với một đống HBase / Sqoop / Hive. Nhưng chúng tôi rất không hài lòng với một số khía cạnh của giải pháp mà chúng tôi hiện đang quay lại và triển khai lại trong Python / MySQL. Vì vậy, chúng tôi đã học được những gì?

Hadoop / HBase không phải là mục đích chung

Rõ ràng là ngay cả khi đọc tài liệu khó hiểu, bản thân Hadoop HDFS không phải là một hệ thống truy cập ngẫu nhiên có mục đích chung. Đó là HBase dành cho. Nhưng ngay cả khi đó, bạn đang đạt được khả năng mở rộng của việc viết và đọc hàng loạt, nhưng mất tính linh hoạt ở dạng xóa và cập nhật nhanh, cũng như sắp xếp theo thời gian thực. Cuối cùng, bạn cũng phải chuẩn hóa dữ liệu của mình một lần cho mỗi mẫu đọc bạn sẽ có. Đã làm việc quá lâu với cơ sở dữ liệu quan hệ, bạn có xu hướng chấp nhận tất cả sự linh hoạt mà họ cung cấp cho bạn để thay đổi yêu cầu của bạn một cách nhanh chóng. SQL là ma thuật cực hữu cho các bộ dữ liệu có kích thước khá lớn như 1TB.

Đừng từ bỏ một trong những công cụ có giá trị nhất trong hộp công cụ của bạn cho đến khi bạn thực sự phải làm. Tôi sẽ đi xa hơn để nói nếu bạn gặp vấn đề về dữ liệu lớn, bạn sẽ biết điều đó bởi vì nó đang phá hủy máy chủ của bạn và bạn đã mất hàng tháng để tối ưu hóa. Cho đến lúc đó, tránh Hadoop.

Có vẻ như bạn chỉ đơn giản là có dữ liệu lớn, mà thực tế là mọi công ty đều có. Dữ liệu lớn - và thậm chí là hầu hết dữ liệu lớn ngay bây giờ - có thể được phân tích và hiển thị trong thời gian thực bằng phần mềm BI như arcplan mà không cần đầu tư vào các thiết bị trong bộ nhớ như SAP HANA, kho dữ liệu khổng lồ như Teradata, cơ sở dữ liệu NoQuery như Cassandra và xử lý phân phối như Hadoop. -  Tiemo Winterkamp

Bạn không thể tránh Java

Tôi đã làm việc với Java rất nhiều trong quá khứ và tôi đã đưa ra một quyết định rõ ràng là định hướng lại sự nghiệp của mình theo hướng Python hơn. Tôi có thể liệt kê hàng tá lý do tại sao, nhưng tất cả đều hiểu rõ điều này: Cá nhân tôi thấy làm việc với Python là một niềm vui, trong khi làm việc với Java luôn cảm thấy như là công việc. Với ý nghĩ đó, bạn không nên ảo tưởng rằng bạn có thể coi Hadoop như một hộp đen.

Về lý thuyết, bạn chỉ có thể nói chuyện với HBase và bắt đầu các công việc Hive thông qua các khách hàng tiết kiệm tương ứng của họ. Trong thực tế, cuối cùng bạn phải tự triển khai các dịch vụ, điều này khá phức tạp ngay cả với các bản phân phối tốt như Cloudera. Bạn cũng sẽ kết thúc điều chỉnh các tham số JVM và tìm kiếm thông qua I-shit-you-not trăm CLASSPATH khai báo dòng  . Bạn sẽ kết thúc việc Google cho một JAR mà bạn dường như không thể tìm thấy, và sau đó giải nén nó để đảm bảo rằng đó thực sự là phiên bản chính xác mà bạn cần.

Bạn sẽ xem mọi thứ sụp đổ và cháy do sự khác biệt phiên bản .01 giữa hai phụ thuộc mà bạn chỉ biết về ý thức. Và bạn sẽ thấy mình đang nhìn chằm chằm vào một ngăn xếp 1.000 dòng cho bạn biết hoàn toàn không có gì về vấn đề thực sự là gì. Đừng nói rằng tôi đã không cảnh báo bạn.

Bạn cũng không thể tránh MapReduce

Đừng nghĩ rằng bạn có thể thoát khỏi việc sử dụng Hive hoặc Pig cho bản đồ của mình để giảm bớt công việc. Thứ nhất, ngay cả khi bạn có thể, trường hợp tốt nhất là bạn kết thúc với một trong hai tập lệnh hql. Đó là những đoạn mã trông khá xấu xí, đặc biệt là các đoạn script lợn. Chúng cung cấp một lớp trừu tượng tốt, nhưng không đủ để bạn có thể đặt một lớp trừu tượng Python thực tế lên trên chúng mà không làm mất tất cả chức năng của chúng. Chúng cũng không thể kiểm tra được bên ngoài JVM, vì vậy hãy chuẩn bị để thực hiện một ngăn thử nghiệm tích hợp liên tục mới.

Pig có một số khả năng tương tác Python. Bạn có thể viết UDF tùy chỉnh bằng Python và chúng sẽ chạy qua Jython trong bản đồ của bạn giảm công việc. Nhưng điều đó chỉ cung cấp cho bạn các phần mở rộng rất cơ bản. Có toàn bộ các lớp UDF chỉ có thể được viết bằng Java.

Hive, trong khi khá tuyệt, cũng thiếu rất nhiều thao tác cơ bản. Ví dụ, hiện tại không có cách nào để tính tổng chạy mà không có  UDF tùy chỉnh . Thực hiện một là không tầm thường; chúng ta đang nói về hàng ngàn dòng mã Java, trong thời gian đó bạn phải hiểu đầy đủ cách thức làm giảm bản đồ. Đột nhiên bản đồ của bạn giảm sự trừu tượng không quá trừu tượng.

Hadoop vẫn đang trưởng thành

Bản thân Hadoop khá khó để triển khai. Đây vẫn là một công việc đang tiến triển. Ngay cả những thay đổi phiên bản nhỏ vẫn có thể phá vỡ mọi thứ trong thời trang ngoạn mục. Chắc chắn sử dụng Cloudera, nhưng đừng mong đợi việc triển khai chìa khóa trao tay. Bạn nên đầu tư vào ít nhất một tá máy móc hoặc máy ảo để bắt đầu. Trên thực tế, nếu cuối cùng bạn không muốn chạy hàng chục hoặc hàng trăm máy trong một cụm, có lẽ bạn không thực sự cần Hadoop.

Hãy chuẩn bị để dành ít nhất một thời gian cho các vấn đề độ tin cậy. Giống như bất cứ điều gì, cơ sở hạ tầng mới có thể không ổn định và sẽ đi xuống thường xuyên cho đến khi bạn xử lý tất cả các nút thắt. Vì lý do đó, tôi không khuyến nghị người dùng phải đối mặt trực tiếp với HBase.

Tin vào ruột của bạn

Bạn không có vấn đề về Dữ liệu lớn. -  Brent Ozar

Kiểm tra gấp đôi và gấp ba rằng bạn thực sự cần một giải pháp dữ liệu lớn. Cho đến lúc đó, bạn tốt hơn với một ngăn xếp truyền thống. Nếu bạn nghĩ rằng bạn có thể cung cấp một giải pháp bằng Python + MySQL, hãy làm điều đó. Tận dụng ma thuật trên đỉnh của một cơ sở dữ liệu quan hệ. Đừng đánh giá thấp sự mất tính toàn vẹn dữ liệu, tính linh hoạt, công cụ, khả năng kiểm tra và khả năng duy trì của ngăn xếp hiện tại của bạn.

Nếu bạn kết thúc với một dự án cơ sở hạ tầng dữ liệu lớn, ít nhất hãy xem một số giải pháp gốc mới hơn của Python. Ngoài ra, hãy suy nghĩ về việc thực hiện một nghiên cứu / tạo mẫu thuần túy trước khi bạn cố gắng cung cấp một tính năng mới VÀ cơ sở hạ tầng mới cùng nhau.

Một cuộc điều tra nghiên cứu gần đây của Microsoft có tiêu đề 'Không ai từng bị sa thải vì sử dụng Hadoop trên một cụm' đã tìm thấy các cài đặt Hadoop sai lầm cả ở công ty của họ và tại Yahoo!, Xử lý ít hơn 14G dữ liệu. Bài viết kết luận bằng cách khuyên các nhà phân tích không nên vượt qua các vòng Hadoop cho đến khi kích thước dữ liệu của bạn vượt qua giới hạn ổ cứng tiêu chuẩn (hiện tại khoảng 1 Terabyte) hoặc ít nhất là giới hạn bộ nhớ hợp lý (512 GB). -  Dave Fowler

|