#220 - Xử lý những chú chim quậy phá bằng kỹ thuật như thế nào?
Trong số này, chúng ta cùng tìm hiểu về:
Bài học từ việc scale Airflow ở Shopify.
Câu chuyện xử lý sự phiền toái của những chú chim bồ câu của một kĩ sư.
So sánh các Data Warehouses.
Bài toán Find the Duplicate Number và lời giải Merge k Sorted Lists.
Kỹ thuật Chaos Engineering.
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 nhé.
Những bài viết hay
The overengineered Solution to my Pigeon Problem
Đã bao giờ bạn gặp những tình huống phiền toái trong cuộc sống và giải quyết nó bằng kỹ năng lập trình của mình chưa? Bài viết sau đã kể lại một câu chuyện như thế.
Chuyện là anh chàng Max Nagy ngày nào cũng phải đối mặt với những chú chim bồ câu và vài thứ không hay ho ở ban công. Anh đã thử một số phương án tìm được trên internet như sau: quạ nhựa, âm thanh động vật, hình dán phản quang v.v... Tuy nhiên các phương án đó không mấy hiệu quả, cũng như anh không muốn sử dụng các phương án gây hại tới những chú chim bồ câu này.
Cuối cùng anh đã đi tới một giải pháp thú vị với ý tưởng như sau: Sử dụng một khẩu súng bắn nước được gắn trên ban công. Khẩu súng này sẽ kết nối thông qua wifi với một chương trình xử lý ảnh. Chương trình xử lý ảnh đọc dữ liệu từ camera và xác định thời điểm khi có bồ câu đậu trên ban công, khi đó một lệnh sẽ gửi tới khẩu súng và thực hiện việc bắn nước để đuổi bồ câu.
Mời các bạn cùng đọc bài viết sau để tìm hiểu chi tiết nhé.
(by lpv)
Lessons Learned From Running Apache Airflow at Scale
Airflow, một nền tảng nguồn mở, được dùng để sắp xếp, phát triển, lập lịch và giám sát các workflows. Shopify đã sử dụng Airflow trên production trong hai năm cho nhiều workflows khác nhau, bao gồm trích xuất dữ liệu, machine learning model training, bảo trì các bảng trong Apache Iceberg và data modeling với DBT.
Với việc scale nhanh các workflows chạy trên Airflow, Shopify đã gặp phải một số thách thức, bao gồm việc truy cập file chậm, thiếu khả năng kiểm soát đối với các DAGs, lưu lượng traffic không đồng đều và tranh chấp tài nguyên giữa các workflows.
Qua bài viết, tác giả muốn chia sẻ một số bài học Shopify đã học được và các giải pháp họ đã xây dựng để vận hành Airflow trên quy mô lớn:
Khi số lượng các file DAG tăng lên đáng kể, tốc độ truy cập và parse các files này ở Airflow Scheduler sẽ bị ảnh hưởng đáng kể. Việc lưu trữ trên Cloud Storage (GCS, S3) là một giải pháp phổ biến, tuy nhiên cần một thiết kết hợp lý cho quá trình sync files từ Cloud đến môi trường nơi Airflow chạy. Sự kết hợp giữa Cloud Storage (GCS, S3) và NFS cho phép quản lý tệp hiệu quả và dễ sử dụng.
Cần xác định retention policy (thời gian tồn tại) cho metadata của Airflow. Khi có nhiều DAGs và chạy được một thời gian dài trên Airflow, lượng metadata lưu trong SQL database sẽ tăng lên đáng kể. Việc này ảnh lượng tiêu cực đến performance của Airflow, đặc biệt đối với Airflow Web-server và quá trình upgrade Airflow.
Khi chạy Airflow trong môi trường multi-tenant, điều quan trọng là có thể xác định ownership của một DAG, điều này giúp chúng ta dễ dàng tìm ra owner khi một DAG có vấn đề xảy ra. Lưu trữ DAG ở chung một Git repo có thể dễ dàng tìm ra owner thông qua Git blame. Tuy nhiên việc này sẽ cản trở sự chủ động trong quá trình release của từng team. Một giải pháp Shopify đưa ra là Airflow Namespaces. Users phải đăng kí namespace cho DAGs của họ thông qua một file YAML.
Các policies cho Airflow DAGs rất hữu ích để thực thi các tiêu chuẩn và giới hạn của các jobs. Shopify tạo ra các policies để validate các DAGs, giúp nâng cao tiêu chuẩn và chất lượng cho các DAGs, từ đó khi chúng chạy ổn định, tối ưu hơn.
Việc đảm bảo schedule workloads một cách đồng đều là rất khó đặc biệt khi chúng ta có khuynh hướng schedule job các khung giờ tròn và có nhiều DAG được tạo tự động. Điều này tạo ra một lượng lớn traffic trong một khoảng thời gian ngắn, có thể làm quá tải Airflow Scheduler. Để giải quyết vấn đề này, Shopify sử dụng khoảng thời gian lịch biểu ngẫu nhiên để xác định cho tất cả các DAG được tạo tự động.
Có rất nhiều điểm có thể xảy ra tranh chấp tài nguyên trong Airflow, việc sử dụng các tính năng có sẵn như Pools, Priority Weight, Celery Queues, Isolated Workers, ... rất hữu ích cho việc quản lý tài nguyên.
(by MS)
Chaos Engineering in Accounting Engineering team
Chaos Engineering là kỹ thuật khai phá các vấn đề chưa biết của hệ thống với những lỗi thường gặp trong tính toán phân tán. Kỹ thuật này có thể coi là một sự bổ sung hoàn hảo cho các phương pháp kiểm thử phần mềm như Unit testing, Integration testing. Ở ZaloPay, Chaos Engineering bước đầu đã được áp dụng khi xây dựng phần lõi kế toán. Các vấn đề phát hiện được đã giúp đảm bảo chất lượng hệ thống, nhất là trong điều kiện không ngừng thay đổi của môi trường Kubernetes/Cloud. Ngoài ra đội ngũ kỹ thuật tại đây cũng đã phát hiện và sửa lỗi liên quan tới Split-Brain trong Redis (version < 6.2.7).
Mời các bạn cùng đọc bài viết sau để tìm hiểu về kỹ thuật Chaos Engineering và cách áp dụng tại ZaloPay nhé.
by AnhLe
Góc Data
A Comparison of Data Warehouses and Query Engines
Chọn lựa đúng Data Warehouses(DW) và Query Engines(QE) là một việc rất quan trọng. Trong những thập kỷ qua, đã có nhiều giải pháp được phát triển, phục vụ các nhu cầu sử dụng dữ liệu khác nhau:
Hybrid Cloud Data Warehouses: được phát triển chủ yếu từ máy on-premises như Oracle, Teradata, Vertica hay Greenplum, phù hợp cho đội BI sử dụng để làm báo cáo và dashboards.
Thế hệ đầu tiên của Cloud DW: Redshift được xây dựng dựa trên ParAccel, đơn giản hóa việc xây dựng và triển khai Data Warehouse thông qua dịch vụ điện toán đám mây.
Thế hệ thứ 2 của cloud DW: Snowflake và BigQuery giúp cải thiện đáng kể khả năng scalability bằng cách tách biệt phần lưu trữ và tính toán, đông thời giúp việc quản lý trở nên dễ dàng hơn.
Thế hệ thứ 2 của QE: Presto hay Athena đã cung cấp các công cụ truy vấn được liên kết trên nhiều nguồn dữ liệu.
Thế hệ thứ 3 của Cloud DW: Firebolt giúp cải thiện hiệu suất và giảm chi phí bằng việc sử dụng những công nghệ mới nhất trong DW, có nhiều sự lựa chọn và kiểm soát cho phần tính toán, cũng như các mô hình định giá khác nhau.
Sau đây là một số điểm nổi bật của những DW và engines này:
Redshift: được cho là hoàn thiện và có nhiều tính năng nhất nhưng cũng có những hạn chế như một DW truyền thống.
Athena: được cho là dễ sử dụng nhất, ít tốn kém nhất và phù hợp nhất cho việc "phân tích một lần". Nhưng nó cũng là hạn chế nhất và đòi hỏi bạn phải quản lý rất tốt việc lưu trữ, ingestion dữ liệu (bên ngoài) và đặc biệt khó đối với việc continuous ingestion.
BigQuery: kết hợp những gì tốt nhất của Athena như một DW serverless. Mặc dù giá thường khá đắt đối với một workload thông thường. Tuy nhiên, BigQuery cũng đi kèm với những hạn chế của một dịch vụ dùng chung, bao gồm các giới hạn để bảo vệ khách hàng của BigQuery khỏi các truy vấn giả mạo. Hiệu suất truy vấn của nó cũng tương tự như Redshift hay Snowflake và quá chậm để phân tích tương tác trên quy mô lớn.
Snowflake: như một cloud DW hiện đại với các tính năng lưu trữ và tính toán tách rời, dễ dàng quản lý với reporting và dashboards, đồng thời cung cấp khả năng scalability cho người dùng. Snowflake có thể chạy trên nhiều nền tảng đám mây (GCP, AWS, Azure). Nhưng giống như những DW khác, Snowflake không mang lại hiệu suất xử lý cao (dưới 1s) cho các queries với workload vừa phải, đồng thời không hỗ trợ tốt continuous ingestion. Snowflake có thể rất tốn kém khi xử lý các các tập dữ liệu lớn với các truy vấn phức tạp hoặc dữ liệu bán cấu trúc.
Firebolt: là DW duy nhất có lưu trữ và tính toán được tách rời, đồng thời hỗ trợ phân tích dữ liệu phức tạp hiệu suất cao trên quy mô dữ liệu lớn. Việc quản lý cũng trở nên đơn giản hơn. Chi phí tổng thể thấp và một phần đặt biệt hơn nữa là có hỗ trợ index.
Chi tiết hơn cho từng DW và QE mời bạn tham khảo thêm ở bài báo. Lưu ý, bài viết có thể chứa những so sánh chủ quan và thiên vị đối với sản phẩm tác giả muốn giới thiệu (Firebolt).
(by ndquoc)
Góc Lập Trình
Đề ra tuần này: Find the Duplicate Number
Lời giải đề bài tuần trước: Merge k Sorted Lists
Đề bài yêu cầu gộp k linked-list đã được sắp xếp theo thứ tự tăng dần lại thành một linked-list duy nhất cũng được sắp xếp theo thứ tự tăng dần.
Đây là bài toán mở rộng từ bài toán gộp 2 linked list. Để gộp 2 linked
Ta có thể thực hiện gộp từng list liên tiếp nhau đến khi gộp toàn bộ k list cho ban đầu. Độ phức tạp thời gian cho cách làm này là O(kN), với k là số lượng list cho trước, N là số lượng phần tử lớn nhất trong 1 list.
Tuy nhiên ta có thể tối ưu hơn bước gộp này bằng phương pháp chia để trị. Thay vì gộp từng list liên tiếp nhau, ta có thể gộp theo từng cặp 2 list lại thành 1, và lặp lại quá trình cho tới khi chỉ còn 1 list duy nhất. Bằng cách này, với mỗi vòng lặp, số lượng list sẽ giảm đi một nửa, do đó độ phức tạp thuật toán được giảm xuống O(Nlogk).
Cài đặt thuật toán như sau: https://pastebin.com/n6Wj1SyA
by ndaadn
Code & Tools
OpenLineage: OpenLineage là một nền tảng mở để thu thập và phân tích data lineage. Nó theo dõi metadata của các datasets, jobs, qua đó cung cấp cho người dùng thông tin cần thiết để xác định nguyên nhân gốc rễ của các vấn đề phức tạp và hiểu hơn về tác động của một sự thay đổi nào đó. OpenLineage định nghĩa một tiêu chuẩn mở cho data lineage, cách thức triển khai việc lưu trữ metadata (Marquez), thư viện cho các ngôn ngữ chung và khả năng tích hợp với các data pipeline tools.
Dijkstra - Ấn Phẩm Chuyên Đề Cho Kỹ Sư Phần Mềm Người Việt - Tập 2
Trong các hệ thống máy tính, bộ nhớ là một loại tài nguyên cực kỳ quan trọng được dùng để lưu trữ mã lệnh và dữ liệu cần thiết để chương trình có thể thực thi. Bộ nhớ cùng với CPU là loại tài nguyên có giới hạn cần được tối ưu hóa để có thể chạy nhiều ứng dụng cùng một lúc nhưng vẫn đảm bảo được hiệu năng như lúc chỉ chạy duy nhất một chương trình.
Những hệ thống máy tính hiện đại ngày nay được thiết kế sử dụng một giải pháp khả thi và ít tốn kém để có thể đáp ứng được yêu cầu trên với một lượng tài nguyên và chi phí giới hạn gọi là Memory Hierarchy.
Các bạn có thể đặt mua ấn phẩm Dijkstra tập 2 tại đây để cùng tìm hiểu về kỹ thuật Memory Hierarchy cũng như các bài viết hay khác nhé.
Quotes
Object-oriented programming offers a sustainable way to write spaghetti code. It lets you accrete programs as a series of patches.
― Paul Graham, Hackers & Painters: Big Ideas from the Computer Age
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)