Apache Spark: 5 cạm bẫy bạn PHẢI giải quyết trước khi thay đổi kiến ​​trúc của bạn


Hoàng Hùng Dũng
4 năm trước
Hữu ích 4 Chia sẻ Viết bình luận 0
Đã xem 1749

Có vẻ như mọi người chỉ nói về công nghệ mới nóng nhất và bỏ bê ý nghĩa thực sự của việc áp dụng nó. Nhưng nó chỉ tự nhiên, phải không? Các tính năng mới và hứa hẹn vượt trội hơn mọi thứ khác và những thách thức và quyết định khó khăn bị gạt sang một bên.

Nhà phát triển Java / Scala? Takipi  thay thế việc đăng nhập vào các JVM sản xuất và cho phép bạn xem trạng thái biến gây ra từng lỗi và ngoại lệ của nhật ký.

Không phải lúc này. Kiến trúc phần mềm là khó, và đánh đổi là tên của trò chơi.

Bài đăng mới: 5 cạm bẫy bạn PHẢI giải quyết trước khi chuyển sang Apache #Spark http://t.co/knczTos9Zg pic.twitter.com/UHibF66w8x

- Takipi (@takipid) ngày 17 tháng 8 năm 2015

Trong bài đăng này, chúng tôi muốn lùi lại một bước và xem ý nghĩa thực sự của việc thực hiện quyết định chuyển sang Spark từ đầu. Một lời cảm ơn sâu sắc gửi tới Tzach Zohar , Nhà phát triển và Kiến trúc sư hệ thống tại Kenshoo , người đã chia sẻ kinh nghiệm của anh ấy với chúng tôi cho bài đăng này.

Tại sao phải di chuyển cả?

Nếu bạn đang bắt đầu với một dự án hoàn toàn mới có lợi từ phân tích dữ liệu phân tán, có thể là phân tích theo lô hoặc phân tích hợp lý, Spark đã thiết lập được uy quyền của mình như là triển khai tốt nhất của MapReduce. Chủ yếu là do cách nó sử dụng xử lý trong bộ nhớ. Mặt khác, nếu bạn nhận được thông lượng bạn cần với một máy chủ và dữ liệu bạn đang sử dụng sẽ không vượt quá tốc độ, có lẽ bạn nên tránh sự phức tạp thêm của việc phân phối. Lưu ý cách chúng tôi không nói dữ liệu lớn dù chỉ một lần. Oh . Ngoài ra, Spark có một thư viện máy học tuyệt vời và dễ sử dụng.

Spark so với Hadoop

Có nhiều khả năng mặc dù điểm xuất phát của bạn là một giải pháp hiện có mà bạn đã có và đây là nơi mọi thứ có thể có thêm lông. Chúng tôi sẽ đặt trọng tâm của bài viết về điều đó. Di chuyển từ Hadoop hoặc một giải pháp trồng tại nhà trên cơ sở dữ liệu đang vật lộn với quy mô. Việc tăng hiệu suất cuối cùng có thể cắt giảm chi phí phần cứng của bạn, tăng năng suất hoặc thực sự là cách duy nhất để thoát khỏi những gì bạn đang cố gắng làm.

Lợi ích lớn nhất đến từ góc phân tích hàng loạt, vì vậy nếu đó là trường hợp sử dụng của bạn - Nâng cấp cụm của bạn có thể còn cấp bách hơn. Trong trường hợp của Zackhoo, một giải pháp MySQL một máy chủ là một lần là quá đủ. Nhưng khi công ty phát triển và nhiều năm trôi qua, điều này không còn đủ nữa - Hàng chục triệu bản ghi mỗi ngày, hàng trăm bảng, hơn một tỷ bản ghi trên những bản lớn hơn và hàng terabyte dữ liệu. Đó không phải là Kansas nữa . Sẽ có một điểm khi tất cả các tối ưu hóa bạn ném vào nó và ngay cả các công cụ lưu trữ hiệu suất cao như TokuDB sẽ không làm được. Những gì bạn làm cuối cùng là một MySQL đột biến trên steroid.

Ở phía bên kia bờ biển có Spark, giải quyết tất cả các vấn đề, mới, nhưng thực hiện các nguyên tắc lâu đời, và có được sự chấp nhận nhanh chóng và nhiều tín hiệu tích cực từ cộng đồng.

1. HDFS so với Cassandra so với S3

Sự lựa chọn của bạn về một máy chủ lưu trữ cho Apache Spark sẽ phản ánh những gì bạn đánh giá cao nhất cho hệ thống của bạn. Ba tùy chọn phổ biến ở đây là HDFS của Hadoop, Apache Cassandra và S3 của Amazon. S3 phù hợp với các trường hợp sử dụng rất cụ thể, khi địa phương dữ liệu không quan trọng. Ví dụ như các công việc chạy một lần mỗi ngày hoặc bất kỳ công việc nào thực sự không yêu cầu dữ liệu và khả năng xử lý để chia sẻ máy. Việc làm không khẩn cấp. Đối với vấn đề HDFS so với Cassandra, chi phí phần cứng để chạy HDFS thấp hơn, vì nó được thiết kế để giải quyết các trường hợp sử dụng đơn giản hơn. Thấp như thế nào? Cho đến 10 lần. Sự khác biệt chính đến từ HDFS giải quyết vấn đề chạy hệ thống tệp phân tán, trong khi Cassandra được thiết kế đặc biệt để lưu trữ khóa-giá trị thông lượng cao.

Mặc dù chi phí cao hơn, Cassandra có ưu thế hơn khi phân tích dữ liệu tương tác, phát trực tuyến - Đối lập với việc chạy các công việc hàng loạt. Bạn có thể nói rằng HDFS yêu thích các tệp lớn, trong khi Cassandra không phải tải tất cả dữ liệu, chỉ sử dụng những gì nó cần và tiếp cận

S3 - Công việc hàng loạt không khẩn cấp.
Cassandra - Hoàn hảo để phân tích dữ liệu trực tuyến và quá mức cần thiết cho các công việc hàng loạt.
HDFS - Rất phù hợp cho các công việc hàng loạt mà không ảnh hưởng đến địa phương dữ liệu.

2. Greenfield vs Tái cấu trúc

Được rồi, vì vậy, bạn đã quyết định chuyển sang Spark, bây giờ, bạn có nên bắt đầu mới với dự án greenfield hoặc refactor dựa trên ứng dụng hiện tại của bạn không? Mỗi người đều có những cảnh báo riêng và Zackhoo quyết định từ bỏ con đường xanh để ủng hộ việc tái cấu trúc hệ thống hiện tại của họ. Quyết định này thu hẹp xuống còn 4 yếu tố:

1. Tránh một kịch bản mục tiêu di chuyển - Xây dựng một hệ thống mới từ đầu cần nhiều thời gian, nhiều tháng phát triển. Và trong thời gian đó, hệ thống kế thừa cũng thay đổi, vì vậy thông số kỹ thuật của bạn thực sự là một mục tiêu di động thay đổi theo thời gian.

2. Không khác biệt dung sai - Hệ thống mới sẽ đạt được kết quả tương tự như di sản, phải không? Những gì nghe có vẻ như là một quá trình đơn giản, là một vấn đề ngụy trang. Với nhiều năm phát triển, tất cả các loại quirks và tùy chỉnh cho các quy trình phân tích cụ thể đã được mã hóa cứng vào ứng dụng cũ. Chẳng hạn, một số giả định, kết quả làm tròn và yêu cầu từ các khách hàng riêng lẻ - Đã tạo ra một quy trình phân tích phức tạp khó có thể tạo lại từ đầu.

3. Mã là thông số kỹ thuật duy nhất - Tài liệu rất có thể là Không ai tồn tại. Và nếu nó tồn tại, rất có thể nó không phản ánh trạng thái hiện tại của hệ thống. Đây là một ví dụ mà bạn có thể liên quan đến, những góc tối trong mã:

Chuyện mà không nên xảy ra, nhưng nó có xảy ra không?

4. Tái sử dụng thử nghiệm - Các thử nghiệm hiện tại của bạn được kết hợp với triển khai cũ hơn và giả định một thiết lập khác. Một nhiệm vụ khác ở đây là viết lại chúng để phù hợp với việc thực hiện mới.

Điểm mấu chốt: Trong trường hợp này, tái cấu trúc, thay vì khởi động hoàn toàn mới - Tạo ra ý nghĩa nhất.

3. Tái cấu trúc những thách thức

Việc chọn đường dẫn tái cấu trúc cũng có những thách thức, mã kế thừa chưa được kiểm tra, khớp nối chặt chẽ với các thành phần hệ thống khác và sự thay đổi mô hình cho một kiến ​​trúc mới. Chuyển đổi từ một kiến ​​trúc Hadoop tương tự sẽ dễ dàng hơn là đi vào đường dẫn hệ thống phân tán sau khi ở trên một ứng dụng nút đơn. Có những kỹ năng mới để học, các quy trình để điều chỉnh và có rất nhiều ma sát. Greenfield hay không, đó là một nhiệm vụ khó khăn, nhưng nếu bạn xác định rằng nó xứng đáng - có một ánh sáng ở cuối đường hầm này.

Trong trường hợp của Zackhoo, nhiệm vụ của họ là giải phóng một bộ phận tổng hợp cổ chai khỏi một hệ thống 8 năm tuổi. Bộ tổng hợp thực hiện xử lý hàng loạt thỉnh thoảng trên dữ liệu và nhóm nó theo các khóa khác nhau.

Điểm mấu chốt: Biết trước các điểm yếu của bạn trước khi di chuyển và đảm bảo bạn có các phương pháp giải pháp cho các đường dẫn quan trọng trong triển khai mới của mình.

4. Giải pháp tiếp cận

4.1. Quy tắc kinh doanh cốt lõi đầu tiên

Một trong những lợi ích chính của tái cấu trúc là sử dụng lại mã khóa học. Bước đầu tiên để xây dựng hệ thống mới là trước tiên phải tuân thủ các quy tắc kinh doanh cốt lõi và tạo ra một bình độc lập từ chúng. Các phương thức được tái cấu trúc thành các phương thức tĩnh Java để tránh các vấn đề tuần tự hóa trong Spark.

4.2. Số liệu Dropwizard và gỡ rối mã di sản

Tiến lên, hãy nhớ rằng không nên xảy ra ví dụ về người Viking? Zackhoo đã dựng nó lên với bộ đếm Metwizard :

Và bạn biết gì Nó xảy ra khá nhiều:

Xảy ra sự kiện của ..

Điểm mấu chốt: Sử dụng các số liệu để đo lường các ẩn số trong mã kế thừa đã được chứng minh là một công cụ mạnh mẽ, cho phép biến các tính năng của Hidden Hidden thành các tính năng rõ ràng, được chứng minh bằng tài liệu và được kiểm tra tốt.

4.3. Kiểm tra chế độ cục bộ

Để vượt qua các thử thách thử nghiệm, Zackhoo đã sử dụng và lấy cảm hứng từ chế độ cục bộ của Spark - Tạo một ví dụ như Spark được nhúng bên trong thành phần tổng hợp mới. Hơn nữa, sau đó họ đã lấy thành phần mới này và nhúng nó vào hệ thống cũ, sử dụng lại các thử nghiệm cũ hơn và đảm bảo hệ thống mới đáp ứng tất cả các yêu cầu:

4.4. Graphite the diff diffececorder

Biên giới cuối cùng, ngoài thử nghiệm chế độ cục bộ, là kiểm tra dữ liệu thực trong sản xuất và xem kết quả Spark có khớp với các kết quả của hệ thống cũ hay không. Với mục đích này, một diffRecorder đã được gắn kết với trực quan hóa Graphite. Bộ ghi Diff đại diện cho mọi đầu vào thực tế mà hai phiên bản khác nhau như là một Số liệu Graphite, chỉ ra các đầu vào chính xác mà việc triển khai mới không nhất quán.

Và dữ liệu kết quả đã giúp hiểu những gì cần phải điều chỉnh thêm để phù hợp với hệ thống cũ hơn (hoặc khám phá ra các lỗi ẩn trong hệ thống). btw, để tìm hiểu thêm về Graphite, bạn có thể xem bài đăng này về cách chọn kiến ​​trúc Graphite tốt nhất cho hệ thống của bạn .

Bảng điều khiển Graphite của Kenshoo

5. Giám sát tia lửa

Spark có sự tích hợp tuyệt vời với Graphite nơi bạn có thể vẽ bất kỳ loại biểu đồ nào bạn có trong đầu. Ngoài ra, công cụ thứ hai ở đây là Spark web UI để xem công việc và số liệu hiệu suất của bạn. Bất kỳ triển khai nghiêm túc nào của Spark đều đòi hỏi phải suy nghĩ nhiều về hiệu suất và giám sát. Điều này có thể trở thành một vấn đề thực sự khó khăn và bạn cần phải làm quen với nội bộ để điều chỉnh hệ thống. Viết mã cho Spark rất dễ, nhưng hiệu suất lại thêm một lớp phức tạp. Theo nghĩa đó, thật dễ dàng để đi sai ở đây và tạo ra mã xấu.

Kiểm tra bài đăng này nơi chúng tôi khám phá kiến trúc giám sát Spark của Taboola và tại sao họ lại di chuyển về phía trước để thêm Takipi  vào ngăn xếp giám sát của họ.

Tài nguyên được đề xuất để bắt đầu với Spark

Các tài liệu cơ bản là ngắn gọn, đơn giản và hoàn thành công việc. Các chủ đề nâng cao hơn bao gồm điều chỉnh hiệu suất Spark có thể được tìm thấy chủ yếu trong các cuộc thảo luận được ghi lại từ các hội nghị thượng đỉnh Spark trước đây .

Phần kết luận

Lưu trữ, tái cấu trúc kỹ thuật, giám sát, tái sử dụng thử nghiệm và kết quả nhất quán - Chúng tôi hy vọng bạn đã tìm thấy các giải pháp được cung cấp hữu ích và biết cách áp dụng chúng khi cần. Chuyển đổi sang công nghệ mới là khó khăn. Ngoài đường cong học tập, chúng còn khiến bạn dễ bị lỗi hơn (Và cũng khiến bạn có nhiều khả năng nhận cuộc gọi vào giữa đêm để khắc phục một số vấn đề sản xuất quan trọng). Đối với những tình huống này, chúng tôi đã đưa ra  phân tích lỗi của Takipi cho Spark .

Chúng tôi muốn nói lời cảm ơn một lần nữa đến Tzach Zohar từ Kenshoo vì đã chia sẻ kinh nghiệm của anh ấy với chúng tôi cho bài đăng này!

 

Công cụ mới: Theo dõi và phân tích tất cả các lỗi Spark. Hiển thị đầy đủ vào cụm của bạn - Hãy thử Takipi cho Spark

 

15 Công cụ Các nhà phát triển Java nên sử dụng sau khi phát hành chính - Xem danh sách công cụ



Nhà phát triển Java / Scala? Takipi  thay thế việc đăng nhập vào các JVM sản xuất và cho phép bạn xem trạng thái biến gây ra từng lỗi và ngoại lệ của nhật ký.

Hữu ích 4 Chia sẻ Viết bình luận 0
Đã xem 1749