Kinh nghiệm làm việc với Big Data

Working with Big Data

Đã bao giờ bạn cảm thấy quá tải khi làm việc với Big Data chưa? Đã bao giờ bạn phải ngồi hàng giờ chỉ để transfer dữ liệu từ server này sang server khác chỉ để test thuật toán của mình? Hay những lúc chán chường khi nhìn script của mình bắt đầu chạy hàng giờ và cuối cùng phát hiện ra mình đã sai đâu đó? Mình nghĩ rằng tất cả những ai khi mới bắt đầu làm việc với Big Data đều có những cảm nhận như vậy. Trong bài viết này, tôi xin góp một chút kinh nghiệm của mình để làm việc với Big Data hiệu quả hơn, kể cả cá nhân hay làm việc nhóm.

Hãy lên plan thật tốt

Big Data decision

Khi bắt đầu một dự án về Big Data, Project manager sẽ đối mặt với rất nhiều quyết định như nên lựa chọn hệ database nào cho phù hợp với bài toán đặt ra, phát triển trên ngôn ngữ lập trình gì để dễ dàng phát triển và bảo trì sau này. Khi chưa có nhiều kinh nghiệm, việc mắc sai lầm là điều tất yếu. Nhưng mấu chốt vấn đề vẫn là có được một plan thật tốt sẽ cứu sống dự án cũng như các thành viên của mình về sau.

Ví dụ, ở các công ty chuyên xử lý dữ liệu log và time series, thì dữ liệu sinh ra hàng giờ lên đến hàng Gigabytes là chuyện bình thường. Bài toán đặt ra gồm hai phần. Thứ nhất, làm thế nào để lưu trữ nhanh dữ liệu xuất phát từ nhiều nguồn về chung một nơi lưu trữ mà không bị mất mát thông tin. Thứ hai, làm sao có thể tổng hợp nhanh dữ liệu từ cấp độ phút sang giờ sang ngày để thực hiện phân tích dữ liệu.

Lúc này, Project manager sẽ đứng trước hai lựa chọn để lưu trữ và truy vấn nhanh thông tin:

1. Sử dụng MongoDB và Java: các thành viên đã có kinh nghiệm về hai công nghệ này nên có thể phát triển ngay.
2. Sử dụng Kafka và Spark: đây là công nghệ mới đáp ứng được nhu cầu của bài toán nhưng đòi hỏi thời gian cập nhật công nghệ và chưa có nhiều kinh nghiệm để phát triển.

Cuối cùng, do ưu tiên việc cho ra sản phẩm nhanh chóng cũng như tự tin với kinh nghiệm của đội nhóm hiên tại, Project manager đã quyết định chạy dự án trên MongoDB. Và đây là một quyết định chỉ đáp ứng được nhu cầu hiện tại nhưng về lâu dài sẽ gây ra nhiều rắc rối và phiền toái có thể dẫn đến thất bại của toàn bộ dự án.

Bên cạnh những ưu điểm của một NoSQL system đó là đảm bảo tính sẵn sàng của hệ thống, MongoDB có nhiều khuyết điểm không phù hợp cho phân tích real-time trên Big Data.

• Cơ chế MapReduce (MR) chậm, khó lập trình phân tán trên nhiều server. Mặc dù có Aggregation thay thế cho MapReduce để cải thiện về tốc độ tổng hợp dữ liệu nhưng vẫn còn đó nhiều lỗi phát sinh liên quan đến quản lý bộ nhớ chưa được khắc phục.
• Các phiên bản nâng cấp không tương thích ngược với các phiên bản trước đó. Dẫn đến nhiều khó khăn trong việc nâng cấp mã nguồn. Nhiều hàm sẽ bị loại bỏ và thay thế, ta khó có thể sử dụng lại được.
• Database không có schema hay ràng buộc toàn vẹn, khiến cho dữ liệu có nhiều thông tin bị trùng lặp và không chính xác. Việc thực thi các phân tích số liệu dựa trên dữ liệu không toàn vẹn (invalid data) như thế này dẫn đến những sai sót không thể chấp nhận được.
• Không thể chuyển qua sử dụng công nghệ khác. Hệ thống đã chạy và phát triển được một thời gian dài nên không thể đập bỏ hết và làm lại từ đầu. Điều này lại khiến cho việc bảo trì hệ thống về lâu dài không được đảm bảo, khó khăn trong việc kế thừa hệ thống.

Do vậy, nếu bạn lên plan tốt hơn thì đã chọn Kafka kết hợp với Spark để làm nền tảng phát triển. Việc nâng cấp và bảo trì cũng dễ dàng hơn. Đừng vì tính dễ sử dụng và thời gian phát triển nhanh mà đưa ra plan không tốt.

Nên rút data sample để thực nghiệm

Tasting soup

Khi làm việc với Big Data, điểm khác biệt duy nhất đó là thời gian. Thời gian copy, thời gian chạy thuật toán, thời gian kiểm chứng, … đều kéo dài từ một đến nhiều tiếng thậm chí là vài ngày. Cách tốt nhất đó là hãy quyên chữ Big đi và rút trích ngay small sample để thực nghiệm, như vậy sẽ nhanh và dễ kiểm soát hơn.

Nhỏ ở đây có nghĩa là từ vài chục đến vài trăm dòng dữ liệu, có thể chạy trực tiếp và kiểm tra trên các phần mềm như Excel. Nhờ vậy, ta có thể kiểm tra được thuật toán của mình có chạy đúng hay không, và tự tin khi implement trên dữ liệu Big thật sự.

Cho nên, hãy rút trích ra các mẫu dữ liệu có thể quan sát được và thực nghiệm trên đó để đảm bảo tính đúng đắn. Ta có thể tư duy theo kiểu quy nạp từ tiền đề, giả thuyết, cho đến chứng minh tổng quát tính đúng đắn của dữ liệu.

Tập làm quen với debug

IntelliJ debugger

Trong giai đoạn thử việc, công ty đòi hỏi bạn phải hiểu mọi người đang làm gì, cụ thể là code của họ viết. Cách tốt nhất đó là học debug, đây thật sự là một kĩ năng cần thiết.

Khi mới vào công ty, tôi cũng không thích dùng debug tool cho lắm vì trong quá trình làm việc với Python tôi đã quen viết code tới đâu thì run tới đấy và debug tới đó trên dòng lệnh (command line), nhưng điều này chỉ khiến tôi chậm bước. Khi tiếp tục dự án của người khác, bạn sẽ khó có thể theo kịp logic flow nếu không debug. Nhờ có debug bạn sẽ hiểu được ý tưởng của chức năng này làm gì, tại sao lại có điều kiện này, tại sao xuất hiện biến kia. Từ đó, bạn có khả năng phát hiện ra các lỗi logic mà dự án đang gặp phải cũng như những điểm chưa tối ưu để có thể đưa ra các cải tiến cho hệ thống hiện tại.

Hãy chọn cho mình các tool debug thuận lợi cho công việc của bạn như Eclipse, Netbeans, intelli J, iPython, Robomongo, Pycharm,…

Đã làm về big data thì cần phải có nhiều server

Lập trình MapReduce với Python

Điều này nghe có vẻ vô lý, nhưng công ty làm về big data mà chỉ có một server thì nghe thật là nực cười.

Vấn đề ở đây đó là một server ngoài việc chịu tải về I/O còn chịu tải về xử lý và phân tích dữ liệu. Như vậy, hệ quả đó là hệ thống sẽ bị quá tải và trì trệ. Nhiều người nghĩ rằng có thể áp dụng Spark trên một server là đủ rồi. Xin thưa không bao giờ có chuyện đó. Spark là một công nghệ phụ thuộc rất nhiều vào RAM, càng nhiều RAM, càng nhiều server thì càng phát huy được thế mạnh của thuật toán để đáp ứng cho các ứng dụng real-time.

Hãy phân tán ra nhiều server vì MapReduce chạy trên một server chỉ làm tốn kém thêm tài nguyên hệ thống mà thôi.

Hãy viết document thật kỹ

Atlassian Confluence

Nếu bạn là lính mới và công ty có sẵn chương trình training thì bạn thật may mắn. Nhưng hầu hết các công ty start-up không làm điều này, nên dẫn đến nhiều khó khăn cho những người mới vào.

Document ở đây không chỉ là coding có comment đầy đủ mà là có đầy đủ tài liệu về thiết kế hệ thống, định nghĩa các chức năng và cách thức cài đặt. Nhờ có document mà ta sẽ hạn chế được rất nhiều trở ngại khi người cũ ra đi và người mới bước vào.

Hãy viết document cho những thiết kế về hệ thống ngay từ buổi ban đầu. Mô tả rõ các tác vụ của hệ thống, biểu diễn mạch lạc logic flow của chương trình, những phiên bản và những cập nhật hiện tại,…

Dữ liệu và công nghệ phải đồng bộ

Local Staging and Production

Nếu bạn là một Freelancer thì công việc của bạn chỉ liên quan đến local và remote server. Mọi công đoạn phát triển, testing, debug đều được hoàn thành tại local sau đó mọi thay đổi sẽ được push lên remote server để ra phiên bản production. Tuy nhiên, với các dự án lớn như Big Data bạn sẽ có thêm một bước trung gian đó là staging (bước testing trước khi publish thành phiên bản production). Lúc này, bạn sẽ đối mặt với việc đồng bộ hoá dữ liệu.

Bước staging có ưu điểm về bảo mật cũng như tránh mất mát dữ liệu khi xảy ra sự cố, đồng thời đảm bảo tính sẵn sàng (available) của phiên bản production đang được khách hàng sử dụng. Tuy nhiên, điều này sẽ trở nên bất lợi khi làm việc với Big Data.

Như đã được đề cập ở trên, khó khăn của Big Data đó là thời gian và kiểm chứng sự đúng đắn của dữ liệu. Mặc dù thuật toán của bạn chạy đúng trên local và staging nhưng chưa chắc đã đúng trên phiên bản production. Sự mất đồng bộ về dữ liệu cũng như phiên bản phần mềm giữa các hệ thống luôn là mối nguy hại tiềm tàng trong tương lai và dễ dẫn đến nhiều sai sót, khó bảo trì.

Vì vậy các Data engineer, Data scientist và System admin hãy phối hợp với nhau để lên plan đồng bộ hoá dữ liệu mỗi ngày. Đồng thời, cài đặt môi trường phát triển sao cho mọi phiên bản đều đồng bộ. Như vậy, các khâu từ developing, released và production sẽ được trơn tru hơn.

Học tập công nghệ mới thật nhanh

Do more think less

Lĩnh vực mà bạn đang theo đuổi có tốc độ thay đổi rất nhanh. Những công nghệ bạn học được tại Đại học đã trở nên lỗi thời. Vậy làm thế nào để có thể theo kịp mọi công nghệ hiện nay. Câu trả lời đó là kiến thức nền tảng và thói quen (đam mê) vọc công nghệ mới.

Kiến thức nền tảng gồm toán học (đại số tuyến tính, toán rời rạc, giải tích, lý thuyết đồ thị, xác suất và thống kê), lập trình (C/C++, hướng đối tượng, Java, C#) và các môn cơ sở ngành (hệ điều hành, kiến trúc máy tính và hợp ngữ, mạng máy tính, cơ sở dữ liệu, cấu trúc dữ liệu và giải thuật). Những kiến thức này tạo cho bạn một điểm tựa vựng chãi khi đối diện với những đợt sóng lớn của công nghệ. Vì tất cả những gì được phát minh, sáng chế ngày nay đều dựa trên nền tảng khoa học cơ bản này. Toán học sẽ giúp cho bạn làm việc hiệu quả và logic, biết cách sắp xếp công việc và giải quyết vấn đề mạch lạc. Lập trình giúp bạn truyền tải mọi ý tưởng vào máy tính. Bản chất của máy tính là “trâu bò”. Máy tính có thể thực hiện nhiều tác vụ đơn giản theo chỉ thị của lập trình viên. Nếu bạn có thể thực hiện bằng tay các tác vụ bạn cần, bạn có thể chỉ cho máy tính làm theo ý bạn. Các môn cơ sở ngành giúp bạn có cái nhìn tổng quát về hệ thống phần mềm, giúp bạn biết được các công cụ liên quan khi giải quyết những vấn đề đối với từng ngành.

Vọc công nghệ mới, dường như là một thói quen và niềm đam mê của bất cứ ai đã xác định cho mình con đường công nghệ thông tin. Hồi xưa, khi chưa có các báo mạng chuyên ngành, tôi thường đọc các tạp chí về công nghệ như “Làm bạn với máy vi tính”, “Echip”, “Thế giới vi tính”, “Thế giới Game”, … Mỗi lần có thủ thuật hay phần mềm gì hay, tôi đều cài đặt và làm thử. Nhờ vậy mà trong vòng 2 tuần tôi đã bắt kịp nhiều công nghệ cùng lúc: git, pyspark, ipython, pandas, glassfish, node.js, bower, jira, stash, scala, mongodb, spark, sbt, maven, … Thật là may mắn nếu bạn đã từng vọc qua các công nghệ này một lần, như vậy bạn đã có lợi thế hơn rất nhiều người rồi.

Do đó, hãy lấy nền tảng kiến thức làm chỗ dựa, đừng như đom đóm chạy theo công nghệ này, tool kia, lúc chợp rồi lại tắt không vững vàng. Hãy luôn trau dồi công nghệ mới, không phải vì công việc bắt buộc mà vì sự thích thú tìm tòi học hỏi. Sẽ có lúc bạn cần tới nó, vì kiến thức không bao giờ là thừa cả.