#239 - Cách Wix xử lý multi-threading trong Node.js
Trong số này, chúng ta cùng tìm hiểu về:
Cách Wix xử lý multi-threading trong Node.js
OLAP đã lỗi thời?
4 nguyên tắc trong Data Engineering
Lời giải bài Masking Personal Information
Ngoài ra các bạn vẫn có thể tiếp tục đặt mua ấn phẩm Dijkstra tập 2 tại đây.
News
(by lpv)
How we built Pingora, the proxy that connects Cloudflare to the Internet — blog.cloudflare.com
Cloudflare chuyển từ Nginx qua Pingora, một HTTP proxy được phát triển bằng Rust.
Meta Myths – Stratechery by Ben Thompson — stratechery.com
Meta đang có những dấu hiệu đi xuống thời gian gần đây, tuy nhiên có một số "myth" đã khiến thị trường phản ứng quá mức.
Road to Artificial General Intelligence — maraoz.com
Trong những ngày đầu của trí tuệ nhân tạo, lĩnh vực này được xác định bởi một mục tiêu duy nhất: xây dựng một cỗ máy có thể suy nghĩ và hành xử giống như con người. Chúng ta gọi đó là AGI (artificial general intelligence). Trong hơn 70 năm kể từ khi thành lập lĩnh vực này, chúng ta đã đạt được những tiến bộ vượt bậc. Mời bạn cùng xem lại những thành tựu đã đạt được và những gì cần làm tiếp theo trên con đường này.
Chip Design Shifts As Fundamental Laws Run Out Of Steam — semiengineering.com
Tỉ lệ Dennard không còn nữa, định luật Amdahl đạt đến giới hạn và định luật Moore đang trở nên khó khăn và tốn kém để tuân theo. Những điều đó đã dẫn tới ngành công nghiệp chip đang dần thay đổi.
Những bài viết hay
How Wix Applied Multi-threading to Node.js and Cut Thousands of SSR Pods and Money
(by quangle)
Server-Side-Rendering-Execution (aka SSRE) là một platform được xây dựng bằng NodeJS, nhằm phục vụ cho việc thực thi code ReactJS của các kỹ sư front-end tại Wix. Với lượng truy cập lên đến 1 triệu RPM khiến họ phải tăng resources bằng cách thêm số lượng lớn kubernetes pods, song cũng đặt ra thử thách về việc quản lý số lượng pods quá nhiều trên production.
Với mục tiêu giảm tải lượng công việc hiện đang được thực thi đơn luồng trên NodeJS, đội ngũ kỹ sư tại Wix đã chọn hướng giải quyết bằng cách tận dụng worker_threads - một module cho phép sử dụng nhiều threads để hỗ trợ việc thực thi JS song song kết hợp thêm 2 OS packages khác như generic-pool và comlink.
Kết quả ghi nhận được khi sử dụng worker_threads giúp họ tiết kiệm số lượng pod khoảng 70% và cải thiện được RPM trên mỗi pod 153%.
Để tìm hiểu chi tiết hơn về cách giải quyết, cũng như vai trò của 2 OS packages, mời bạn đọc cùng tham khảo bài viết.
(steven.do)
Đã có nhiều câu hỏi đặt ra rằng liệu OLAP đã trở thành công nghệ lỗi thời, khi search kết quả trên google bằng cụm từ "OLAP is dead" đã có đến hơn 2 triệu kết quả liên quan trả về.
Trước kỷ nguyên cloud, khi các data warehouse được áp dụng rộng rãi, và các DB OLAP đã trở thành phần không thể thiếu trong data mart layer. Nhưng khi bắt đầu có sự chuyển dịch sang cloud, và các data lake bắt đầu nổi lên, OLAP dường như đã trở thành khái niệm lỗi thời và bắt đầu hạ nhiệt, thậm chí bắt đầu có những ý kiến cho rằng OLAP và các xử lý ETL và data modeling đã không còn cần thiết.
Với sự ra đời của hàng loạt các khái niệm mới trong kỷ nguyên cloud như:
Multi-cloud architecture
Cloud-native architecture
Modern Data Stack
Cung cấp các dịch vụ quản lý tổ chức và lưu trữ dữ liệu thuận tiện linh động mà không còn phải bận tâm về việc duy trì cơ sở hạ tầng vật lý với chi phí tối ưu hơn nhưng vẫn đạt được hiệu quả phân tích và mang lại giá trị tối đa cho các tổ chức.
Với sự cường điệu hóa về các công nghệ mới cũng như xu hướng và tốc độ phát triển của các công nghệ này, tác giả đã phân tích các yếu tố liên quan về mặt công nghệ, nhu cầu phân tích thực tế, các vấn đề về mặt kỹ thuật và hướng tiếp cận dịch chuyển OLAP lên cloud để củng cố cho nhận định rằng OLAP sẽ vẫn còn hữu ích và cần thiết. Để có thêm thông tin chi tiết mời các bạn tham khảo thêm thông qua bài viết.
4 Design Principles for Robust Data Pipelines
(by MS)
Trong software engineering, một trong những best practices được nhắc đến nhiều nhất là bạn nên viết test của mình trước khi viết code. Bằng cách đó, bạn đảm bảo rằng khi bạn viết code, tất cả các trường hợp edge-cases đều được xử lý. Tuy nhiên, trong thực tế, chúng ta thường viết test để cover các trường hợp cơ bản, hiếm khi có thể nghĩ hết về các edge-cases. Các trường hợp này thường được tìm ra sau khi đã viết code xong, release trên production và sau đó chúng ta tiếp tục viết test để cover.
Cách tiếp cận như vậy sẽ nhanh chóng đạt đến giới hạn của nó khi xử lý các data pipelines, vì chúng thường có những vấn đề đặc thù nhất định:
Data cần để test thường không available ngay ở một số bước nhất định
Data đến trễ
Data format có thể thay đổi vào một ngày nào đó
Data volume có thể thay đổi vào những khoảng thời gian bất kì
Trong Data engineering, unit tests không nói lên nhiều điều. Test chỉ hữu ích nếu chúng xử lý dữ liệu giống như môi trường production. Nếu pipeline của bạn dùng để trích xuất (extract), tải (load) và chuyển đổi (transform) một lượng dữ liệu lớn, việc pass unit tests với một lượng dữ liệu nhỏ trong một trương kiểm thử có lẽ sẽ không giúp bạn tự tin rằng pipeline sẽ chạy ổn định và đáng tin cậy trong môi trường production. Kể cả bạn có test với một load được kì vọng, điều gì sẽ xảy ra nếu khách hàng gửi một lượng data lớn gấp nhiều lần? Chưa kể, dù mỗi phần riêng lẻ pass các unit tests, bạn sẽ vẫn phải chuẩn bị cho integration test để đảm bảo end-to-end pipeline chạy chính xác.
Trong Data Engineering, những điều không nên xảy ra thường sẽ xảy ra, và khi chúng xảy ra, nhiệm vụ của bạn là khắc phục chúng theo cách nhanh nhất. Trong bài viết, tác giả giới thiệu 4 nguyên tắc trong Data Engineering chúng ta có thể tham khảo:
Incremental Thinking
Data Porosity
Lego Block Assembly
Effective Monitoring
Hãy cùng tham khảo bài viết để hiểu hơn về những nguyên tắc này nhé.
Góc Lập Trình
Đề ra tuần này: Validate Binary Tree Nodes
(by ndaadn)
Giả sử cho một cây nhị phân gồm n nút được đánh số từ 0 đến n-1. Mỗi nút i có 2 nút con leftChild[i] và rightChild[i]. Trả về true khi và chỉ khi tất cả các nút trong chuỗi tạo thành một cây nhị phân hợp lệ.
Ví dụ:
Input: n = 4, leftChild = [1,-1,3,-1], rightChild = [2,-1,-1,-1]
Output: true
Lời giải đề bài tuần trước: Masking Personal Information
(by ndaadn)
Đề bài trông có vẻ phức tạp nhưng thực ra nếu để ý kỹ ta sẽ nhận ra bài toán khá đơn giản.
Đầu tiên cần xác định xem tham số S đề cho là một địa chỉ email hay một số điện thoại. Để xác định điều này ta chỉ cần tìm xem trong chuỗi có ký tự @ hay không, nếu có thì đó là địa chỉ email, nếu không thì đó là một số điện thoại.
Trường hợp chuỗi s là một địa chỉ email, ta thực hiện thao tác mã hóa như sau:
Cắt chuỗi thành 2 chuỗi con s1 và s2 tại vị trí xuất hiện kí tự @.
Mã hóa chuỗi con s1 bằng cách lấy kí tự đầu, cộng với chuỗi “*****”, sau đó cộng với kí tự cuối.
Nối chuỗi con s1 đã mã hóa với kí tự @ và chuỗi con s2, ta được đáp án.
Trường hợp chuỗi s là một số điện thoại, ta quan sát thấy có 4 trường hợp, đó là các trường hợp số điện thoại gồm 10, 11, 12 và 13 số. Các trường hợp này đều có dạng sau khi đã mã hóa cố định (như đề bài) nên ta cũng dễ dàng thực hiện bước mã hóa như sau:
Loại bỏ tất cả các kí tự phân tách ra khỏi chuỗi ban đầu.
Nếu chuỗi sau khi loại bỏ gồm 10 số, lấy 4 số cuối nối vào sau chuỗi “***-***-” ta được đáp án.
Tương tự với các trường hợp 11, 12 và 13 số.
Cài đặt tham khảo bằng ngôn ngữ Java: https://pastebin.com/rfcKtL7x
Code & Tools
buildg - một công cụ hỗ trợ debug Dockerfiles ngay trên các IDE phổ biến VSCode, Emac, Neovim vừa được tác giả Kohei Tokunaga phát hành. Một trong những ưu điểm nổi bật của Buildg chính là cho phép developer chạy step-by-step quá trình container builds, đặt breakpoints và kiểm tra trạng thái từng step. Buildg còn hỗ trợ debug ngay trên các IDE phổ biến thông qua việc sử dụng DAP (Debug Adapter Protocol, được tích hợp trong nhiều trình soạn thảo như VSCode, Eclipse, ..). Phiên bản 0.4.1 đã được phát hành trên Github của tác giả, để tìm hiểu chi tiết hơn về cách sử dụng, mời bạn đọc cùng tham khảo bài viết
Feedback
Bạn đánh giá nội dung số newsletter này thế nào?
(1 = Rất tệ / 5 = Rất tốt)
(Việc đánh giá của các bạn là rất quan trọng, sẽ giúp chúng tôi liên tục cải thiện nội dung newsletter tốt hơn)
Grokking mang lại cho các bạn những kiến thức mới mẻ và hữu ích thông qua:
Tech Talk: Là một hoạt động thường xuyên của Grokking từ những ngày đầu thành lập. Tại đây các diễn giả chia sẻ kiến thức xoay quanh Computer Science và Software Engineer. Các buổi Tech Talk đều được record và upload lên kênh youtube của Grokking.
Grokking Knowledge Graph: Tập hợp những nguồn kiến thức phong phú với hơn 1000 bài viết chọn lọc, các đầu sách, khóa học, v.v… Các bài viết đều được gán nhãn để giúp bạn đọc dễ dàng tìm kiếm.
Webinar: Là chương trình kết nối các kỹ sư Việt Nam và các kỹ sư đang làm việc tại các công ty công nghệ hàng đầu thế giới.
Dijkstra: Một ấn phẩm được xuất bản bởi các thành viên của Grokking. Với những bài viết đào sâu vào kỹ thuật và kiến thức khoa học máy tính.
Kipalog: Nền tảng chia sẻ kiến thức dành cho các lập trình viên.
Newsletter: Những bài viết hay về công nghệ sẽ được gửi tới bạn hàng tuần qua email.
Chúc các bạn sẽ tìm được nhiều điều mới mẻ khi đến với Grokking và xin hẹn gặp lại các bạn vào tuần sau.
Quotes
“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live"
John Woods