#167 - Các kỹ thuật tối ưu Spark không thể bỏ qua

Apr 19, 2021

Những bài viết hay

Các kỹ thuật tối ưu Spark không thể bỏ qua — medium.com

Spark có lẽ đã trở nên không xa lạ với nhiều bạn Data Engineer nhờ khả năng xử lý lượng data khổng lồ theo batch hay streaming, khả năng chịu lỗi, scale up, tương thích tốt với Hadoop và nhiều nguồn dữ liệu khác nhau, hỗ trợ nhiều ngôn ngữ với cộng đồng người dùng lớn, ...

Tuy nhiên, làm việc với Spark luôn mang đến nhiều thách thức với các kĩ sư, đặc biệt là việc tối ưu hóa performance và memory của Spark trong môi trường phân tán với lượng dữ liệu rất lớn hoặc streaming. Trong bài viết, ngoài việc phân tích các ưu và nhược điểm của Spark, tác giả tổng hợp các kĩ thuật các kĩ thuật quan trọng, được ứng dụng trong nhiều trường hợp, giúp ứng dụng Spark của bạn chạy nhanh hơn, hiệu quả hơn, đỡ tốn memory và đáng tin cậy hơn:

Filter data càng sớm càng tốt
Sử dụng file format tối ưu cho các mục đích đọc và viết
Chọn lựa sử dụng API thích hợp RDD/Dataframe/Dataset
Sử dụng các biến đặc biệt như Accumulator và Broadcast
Tối ưu Parallelism với Coalesce/Repartition
Kĩ thuật Data Serialization với sự tối ưu của Kyro Serialization so với Java Serialization
Caching và Persistence
Kĩ thuật làm giảm Shuffle Operation
Cài đặt limit cho Broadcast Join
Compressing data với các tác vụ xử lý SQL
Phân bổ memory và tài nguyên hợp lý

Gửi SMS trên quy mô lớn với Twilio — www.twilio.com

Việc gửi tin nhắn SMS để cung cấp hay xác nhận thông tin mang lại trải nghiệm người dùng tốt hơn cho ứng dụng của bạn. Phát triển tính năng gửi SMS cũng khá dễ dàng khi sử dụng Twilio, tất cả những gì bạn cần làm là đăng kí tài khoản Twilio và gửi một http request tới API "send message", nó thậm chí còn dễ dàng hơn nếu bạn dùng các SDK do Twilio cung cấp.

Tuy nhiên bài toán trở nên phức tạp hơn nếu hệ thống cần scale up để gửi hàng trăm thậm chí hàng ngàn tin nhắn tại một thời điểm. Một số vấn đề bạn đối mặt khi scale hệ thông như:

Giới hạn từ nhà cung cấp dịch vụ (Viettel, Vinaphone hay Mobifone). Ví dụ, ở Mỹ, mỗi giây bạn chỉ có thể gửi 1 tin nhắn từ một số điện thoại, con số này là 10/giây ở những nước khác.
Tuỳ chọn của người dùng. Người dùng thường có xu hướng chỉ nhận tin nhắn từ số cục bộ (số trong nước).
Chống spam. Bạn cần phải xử các phản hồi "STOP" hay "UNSUBSCRIBE" từ người dùng để tránh spam SMS.
API rate limits (trong một khoản thời gian bạn có thể gọi một API mấy lần). Trong trường hợp bạn gửi quá nhiều tin nhắn trong một khoản thời gian ngắn, Twilio sẽ trả về kết quả HTTP/429 (Too Many Requests)
Theo dõi tình trạng tin nhắn và gửi lại khi cần thiết. Khi bạn gọi API để gửi tin nhắn, tin nhắn được đưa vào hàng chờ để gửi. Tuy nhiên sau đó tin nhắn có thể thất bại trong quá trình gửi đi vì một lý do nào đó. Theo dõi hàng nghìn tin nhắn và phản ứng lại trong từng trường hợp là một việc không hề đơn giản.
Bộ lọc từ các nhà cung cấp dịch vụ. Các nhà cung cấp dịch vụ thường thiết lập các bộ lọc để chặn các tin nhắn spam, giả mạo hay tin nhắn lừa đảo.

Bài viết sau tác giả đưa ra hai giải pháp để giải quyết các vấn đề trên:

Bốn sai lầm tôi gặp phải khi còn là developer

Bất kể trong công việc hay cuộc sống thường ngày, đôi lúc bạn chỉ phát hiện ra các sai lầm của mình khi thay đổi cách nhìn nhận vấn đề. Việc thay đổi này có thể đến từ thay đổi môi trường sống, hay thay đổi công việc. Ở bài viết này tác giả Jakub Górowski chia sẻ bốn sai lầm anh nhận ra sau khi trở thành CTO của một công ty startup. Chú ý những chia sẻ này là các quan điểm của tác giả, có thể đúng với bạn hoặc không.

Luôn nghĩ rằng người dùng là một "tên ngốc", họ sử dụng ứng dụng không đúng cách, hay có những câu hỏi thật ngớ ngẩn, họ thậm chí yêu cầu các tính năng vô nghĩa nữa.
Code là một nghệ thuật và nó cần phải hoàn hảo. Clean code, unit test, documentation là những thứ quan trọng và cần phải có trong tất cả các projects. Chúng ta có thể chậm trong thời điểm hiện tại nhưng sau này nó sẽ giúp ta tiết kiệm rất nhiều thời gian và chi phí. Điều này có vẻ đúng, vậy sai lầm là gì?
Chọn công nghệ XYZ cho project A bởi vì bản thân quen thuộc với XYZ. Vậy có gì sai khi chọn công nghệ quen thuộc với bạn và team cho các projects mới?
Product Owner/Manager đã sai lầm, nếu là tôi, tôi sẽ làm tốt hơn.

Cùng đọc chi tiết hơn ở bài viết của tác giả Jakub Górowski, biết đâu bạn tìm thấy chính mình đâu đó trong bài biết này, cũng như rút ra được một số bài học cho bản thân.

Góc Database

Trong các năm trở lại đây, nhiều hệ thống dữ liệu phân tán đang bắt đầu chuyển dịch theo hướng chấp nhận dữ liệu có tính chất eventual consistency để đổi lại hệ thống sẽ có độ khả dụng cao (high availability). Một trong những lý do được đưa ra là vì đối với các hệ thống eventual consistency, khoảng thời gian mà dữ liệu ở trạng thái không nhất quán (inconsistency window) là khá ngắn, và câu hỏi được đưa ra ở đây sẽ là nó “ngắn” đến mức nào.

Để trả lời cho câu hỏi này thì trước tiên chúng ta cùng khảo sát cách phân loại về đặc tính nhất quán.

Theo như đề cập trong quyển sách "DistributedSystems - Principles and Paradigms" bởi hai tác giả Tanenbaum và Steen thì khái niệm nhất quán có thể phân thành hai nhóm theo hai góc độ khảo sát: nhất quán về theo góc độ lưu trữ (data-centric) và nhất quán theo góc độ người dùng (client-centric)

Khi khảo sát tính nhất quán về mặt lưu trữ (data-centric consistency model) thì một hệ thống dữ liệu phân tán được coi là nhất quán khi tất cả phiên bản của một đơn vị dữ liệu được lưu trên các server khác nhau đều giống nhau.
Theo một hướng khác thì mô hình tính nhất quán theo góc độ người dùng (client-centric consistency model) sẽ không quan tâm dữ liệu được hệ thống storage được lưu trữ như thế nào mà chỉ quan tâm xem dữ liệu nhận về từ các instance khác nhau của một hệ thống có thống nhất (hay nhất quán) hay không.

Dựa theo cách phân loại này thì chúng ta có thể thấy, một hệ thống có thể xem là không nhất quán ở khía cạnh lưu trữ vẫn có khả năng trả về các kết quả nhất quán theo góc độ người dùng.

Trong bài báo này, hai tác giả David Bermbach và Stefan Tai quan tâm đến việc đo đạc ở khía cạnh người dùng nhiều hơn. Các tác giả trình bày kỹ thuật dùng để đo đạc khung thời gian mà dữ liệu không nhất quán (inconsistency window) và áp dụng để đo đạc chỉ số nhất quán của hệ thống Amazon S3. Mời các bạn cùng tham khảo.

Lưu ý: bài báo được đưa ra vào nào 2011 nên kết quả có thể không còn phù hợp ở thời điểm

Code & Tools

This Week Sponsors

LINE đang tích cực tìm kiếm nhiều nhân tố ở các vị trí chủ chốt để đáp ứng nhu cầu phát triển mạnh mẽ của hệ sinh thái LINE. Đặc biệt, trong vai trò Engineering Manager và Project Leader, các bạn sẽ có cơ hội tác động tích cực đến sự phát triển của con người, tổ chức, sản phẩm và hàng trăm triệu người dùng.

Góc Tuyển Dụng

Xem thông tin các vị trí khác ở LINE Technology Vietnam

Quotes

Falling in love with code means falling in love with problem solving and being a part of a forever ongoing conversation.

- Kathryn Barrett