#192 - Chi tiết về sự cố của Facebook vào ngày 04/10
Trong số này chúng ta cùng tìm hiểu về: Delta Lake; cách Netflix deploy ứng dụng cho clients; sự cố outage của Facebook vào ngày 04/10; cách Slack thiết kế hệ thống data lineage; cách Google thiết kế Colossus; cách Facebook sử dụng cache engine CacheLib; và cuối cùng là nghe tác giả Runar Bjarnason nói về sự mâu thuẫn mà chúng ta phải đối mặt khi nghĩ về abstractions.
Những bài viết hay
Delta Lake: Powering Change Data Capture(CDC) Through Lakehouse Architecture
Data warehouse đóng vai trò quan trọng trong việc hỗ trợ ra quyết định và kinh doanh thông minh trong doanh nghiệp. Tuy nhiên để giải quyết vấn đề về dữ liệu không có cấu trúc, bán cấu trúc và lượng dữ liệu tăng mỗi ngày về mặt khối lượng, tốc độ và sự đa dạng thì chúng ta cần xây dựng hệ thống data lake.
Mặc dù data lake thoả mãn những yêu cầu trên nhưng thiếu 1 số tính năng quan trọng của data warehouse như transactions, kiểm tra chất lượng dữ liệu, tính nhất quán. Vì thế trong hầu hết những công ty, tổ chức đều duy trì cả 2 hệ thống data lake và data warehouse và họ phải đối mặt với chi phí để thực hiện nhiều luồng dữ liệu và chi phí để bảo trì.
Với sự ra đời của data lakehouse (là sự kết hợp của data lake và data warehouse) giải quyết được những mặc hạn chế của data lake và data warehouse gặp phải với chi phí lưu trữ thấp và phục vụ từ BI cho tới AI.
Một số tính năng của lakehouse như: hỗ trợ transaction; thực thi và quản trị lược đồ; các định dạng lưu trữ được tiêu chuẩn hóa; hỗ trợ BI; lưu trữ và tính toán tách biệt nhau; hỗ trợ đa dạng loại dữ liệu và workload; hỗ trợ streaming. Những tool được xây dựng trên kiến trúc lakehouse như: Databricks Delta, Azure Synapse, Google Bigquery, AWS Redshift hay những mã nguồn mở như Delta lake, Apache Iceberg & Apache Hudi.
Bên cạnh đó tác giả có giới thiệu về Delta lake là một dự án mã nguồn mở được xây dựng dựa trên kiến trúc Lakehouse với các hệ thống lưu trữ hiện có như S3, ADLS, GCS và HDFS. Những tính năng của Delta lake:
Hỗ trợ về ACID transaction
Tận dụng sức mạnh xử lý phân tán của Spark để xử lý tất cả siêu dữ liệu cho các bảng quy mô hàng petabyte với hàng tỷ file một cách dễ dàng
Time travel - Dễ dàng truy cập và hoàn lại những phiên bản trước của dữ liệu
Định dạng mở lưu trữ dưới Parquet file
Hợp nhất Batch & Streaming, Source & Sink
Dễ dàng thay đổi lược đồ hiện tại của bảng để phù hợp với dữ liệu.
Hiệu suất nhanh với Apache Spark
Safe Updates of Client Applications at Netflix
Netflix được biết đến là một ứng dụng streaming video trên rất nhiều nền tảng (platform) khác nhau, số lượng các loại devices lên đến hàng ngàn và có đến hàng trăm microservices hoạt động để phục vụ cho các nền tảng này. Netflix chia các bản cập nhật ứng dụng client thành 02 nhóm: nhóm các ứng dụng được hosted bởi app store (android, ios và cả game console) và nhóm các gói ứng dụng được tải về từ các service hoặc CDN (ví dụ như Netflix's video player hoặc TV UI javascript package).
Với mỗi nhóm client, Netflix sẽ có một kế hoạch deploy khác nhau. Vậy nên, cập nhật cho ứng dụng trên mobile sẽ khác so với trên Smart TV hoặc các nền tảng khác. Một kĩ thuật được áp dụng rộng rãi đó là staged or phased rollout, thay vì update cho toàn bộ user ngay lập tức, bản cập nhật sẽ được cập nhật từ từ trên một nhóm user hay thiết bị.
Ngoài ra, Netflix còn sử dụng A/B testing để đánh giá và quyết định liệu có launch tính năng mới hay không. Người dùng có thể trải nghiệm tính năng mới được thiết kế để A/B tested và tính năng này sẽ được kiểm soát bằng cờ (feature flag). Có 03 phases chính trong quá trình A/B testing: Allocation, Metric Collection, Analysis. Netflix sử dụng sự điều phối (orchestration) để kết nối và quản lí các ứng dụng client thông qua A/B test lifecycle, bằng cách đó sẽ giảm tải "gánh nặng tinh thần" (cognitive load) khi thường xuyên phải thực hiện việc deployment (cài đặt, thực thi, phân tích và ra quyết định) trên rất nhiều các tập khách hàng.
More details about the October 4 outage
Ngày 4 tháng 10, người dùng không thể truy cập hàng loạt các dịch vụ của Facebook trong nhiều giờ liền, bao gồm Timeline, Messenger, WhatsApp, Instagram. Đây có lẽ là một trong những sự cố nghiêm trọng nhất Facebook gặp phải trong những năm gần đây. Vậy chuyện gì đã xảy ra? Có phải các kĩ sư của Facebook phải lái xe đến Data Center để "restart server" không?
Trong bài viết trên trang Facebook engineering, Santosh Janardhan, VP infrastructure của Facebook, đã chia sẻ những gì đã xảy ra:
Hệ thống global backbone network của Facebook là nguyên nhân gây ra sự cố ngừng hoạt động lần này. Đây là hệ thống mạng được Facebook xây dựng nhằm kết nối tất cả các cơ sở hạ tầng trên toàn cầu với nhau.
Data traffic giữa các cơ sở hạ tầng được quản lý bởi các routers. Thông thường để bảo trì hệ thống, một phần của backbone network cần được đưa về chế độ offline. Tuy nhiên, vào ngày xảy ra sự cố, một câu lệnh trong quá trình này đã vô tình tắt tất cả các kết nối trong backbone network, điều này khiến các data centers của Facebook mất kết nối trên toàn cầu. Bạn có thể sẽ hỏi tại sao một câu lệnh nguy hiểm như vậy không được Facebook chặn lại? Lý do rất đơn giản, dù các câu lệnh luôn được audit trước khi thực thi, nhưng audit tool của Facebook lại có một bug, khiến cho nó không thể ngăn chặn câu lệnh trên.
Do đó các DNS servers của Facebook không thể truy cập được mặc dù chúng vẫn đang hoạt động bình thường. Điều này khiến người dùng internet không thể tìm thấy các máy chủ của Facebook.
Bởi vì hệ thống network và DNS sập, các tools nội bộ của Facebook không thể hoạt động thông qua kết nối Internet bình thường. Và vì thế, các kĩ sư cần phải đến Data center để debug và restart các servers. Quá trình này mất khá nhiều thời gian bởi vì các data center của Facebook được thiết kế với an ninh rất cao. Để tiếp cận, debug trực tiếp và restart các servers, các kĩ sư cần phải đi qua nhiều bước kiểm soát an ninh.
Khi backbone network được phục hồi, dù các data centers được kết nối trở lại, mọi chuyện có thể vẫn chưa kết thúc. Lý do là việc bật lại các dịch vụ cùng một lúc có thể gây ra một loạt sự cố mới do lưu lượng truy cập tăng vọt một cách đột ngột. Mỗi data center đã báo cáo mức tiêu thụ điện năng giảm xuống hàng chục megawatt khi sự cố xảy ra và việc đảo ngược mức tiêu thụ điện năng đột ngột như vậy có thể khiến mọi thứ từ hệ thống điện đến bộ nhớ đệm gặp rủi ro.
May thay, tình huống này đã được Facebook chuẩn bị từ trước bởi các lần diễn tập "storm" khi mà một hoặc vài data centers sẽ bị tắt hoàn toàn. Cuối cùng, các servers của Facebook đã dần dần trở lại hoạt động một cách bình thường sau khi mạng lưới network được hồi phục lại dần dần.
Hiện nay, với số lượng dữ liệu ngày càng gia tăng ở các doanh nghiệp, việc quản lý, theo dõi và giám sát dữ liệu là một trong những công việc đầy thách thức tại những công ty lớn. Để cung cấp cho người dùng như Data Analytics, Machine Learning Engineer hay Data Science… một cách tiếp cận dễ dữ liệu dàng nhất thì hầu như các công ty hiện nay đều có một đội Data Platform để giải quyết vấn đề này.
Với khối lượng dữ liệu lớn đa dạng và phức tạp, các Data Engineer trong đội Data Platform sẽ gặp phải những bài toán lớn, nhỏ rất thú vị qua từng giai đoạn phát triển của doanh nghiệp. Một trong những bài toán này là Data Lineage. Vậy Data Lineage là gì mà các công ty lớn như Uber, Linkedin, Spotify, Netflix... đều dùng rất nhiều nguồn lực để đầu tư vào bài toán này. Để hiểu rõ về bài toán này, chúng ta sẽ cùng tìm hiểu bài viết sau của Slack, các ý chính có đề cập trong bài, bao gồm:
Data Lineage là gì? Lý do nên xây dựng hệ thống Data Lineage?
Kiến trúc tổng quan hệ thống Data Lineage
Các tính năng quan trọng trong hệ thống Data Lineage
Data Lineage có thể hiểu đơn giản là một bức tranh tổng quát thể hiện cách thức và vị trí tổ chức các nguồn dữ liệu được sử dụng trong hệ thống dữ liệu của doanh nghiệp. Trong những năm đầu, việc tổ chức dữ liệu với một số lượng nhỏ data pipeline thì không cần phải lo lắng nhiều về data lineage. Tuy nhiên, khi các bộ dữ liệu ngày càng phức tạp và số lượng data pipeline ngày càng tăng theo nhu cầu, thì việc hiểu được mối quan hệ giữa các nguồn dữ liệu khác nhau ngày càng trở nên khó khăn hơn.
Hiểu được data lineage có thể giúp các công việc maintenance dữ liệu ở đội Data Platform trở nên dễ dàng hơn. Một trong những công việc mà Data Engineer cần làm đó là backfill, việc này giúp hồi phục dữ liệu sau khi có bugs xảy ra trong data pipeline. Lúc này, với vai trò là một Data Engineer, để giải quyết vấn đề bạn sẽ cần phải hiểu rõ mối quan hệ giữa downstream, upstream của dữ liệu cần backfill. Sau đó, tìm cách backfill sao cho hợp lý và giảm tối đa việc tạo thêm bugs ngoài ý muốn.
Để phục vụ mục đích này thì Slack đã xây dựng một hệ thống về data lineage nhằm thu thập “lineage” của dữ liệu từ những dữ liệu thô trong MySQL, sau đó xử lý bằng Spark và lưu vào Hive. Việc này được tích hợp vào từ 2 luồng chính là: các data pipeline/DAGs ở Airflow và dữ liệu từ những dashboard ở BI Tool tại Slack. Ngoài ra, việc phân tích và trích xuất thông tin từ các câu SQL cũng đem lại những giá trị nhất định về quan hệ của các nguồn dữ liệu được sử dụng tại những câu SQL này.
“Lineage” của dữ liệu sau khi trích xuất sẽ được lưu trữ dưới dạng flattened table bao gồm những thông tin như source, target và layer ở trong Hive. Kết quả của việc này hướng tới ý đồ xây dựng một lineage graph, giúp người dùng dữ liệu có một cái nhìn tổng quát nhất về mối quan hệ của các nguồn dữ liệu, có thể hình dung graph này sẽ giống như là một bản mở rộng liên kết DAGs trong Airflow.
Ngoài ra, việc tích hợp data lineage cùng với các hệ thống quản trị dữ liệu liệu khác trong Slack cũng giúp cho người dùng dữ liệu nắm được các thay đổi liên quan đến “lineage”. Trong bài viết cũng đã đề cập thêm về các tính năng, nhằm tận dụng tối đa giá trị của hệ thống data lineage mà đội có thể triển khai trong thời gian tới. Chi tiết mời các bạn truy cập vào link bài viết để đọc kỹ hơn.
Góc Distributed System
Colossus: thế hệ tiếp theo của Google File System (GFS)
Năm 2003, Google đã công bố bài báo về GFS trong đó mô tả một vài ý tưởng thiết kế quan trọng cho hệ thống file dữ liệu phân tán tại Google. Tiếp nối GFS, Yahoo! đã phát triển hệ thống file dữ liệu phân tán HDFS cùng với toàn bộ hệ sinh thái mã nguồn mở Apache Hadoop, một trong những dự án quan trọng nhất đóng góp cho sự phát triển nhanh chóng của Big Data ngày nay. Song song với sự tiến hoá của HDFS trong cộng đồng mã nguồn mở, hệ thống GFS cũng liên tục được cải tiến để phù hợp với các yêu cầu và bài toán đa dạng tại Google.
Vậy từ GFS đến Colossus (GFS II), những phát triển và tiến hoá nào đã xảy ra?
Trong một bài thuyết trình về "Kiến trúc và các thách thức của kho lưu trữ dữ liệu", Andrew Fikes, principle engineer tại Google, có chia sẻ một vài ý tưởng quan trọng về Colossus:
Được phát triển với tầng metadata phân tán tự động
Tính năng sao chép, mã hoá dữ liệu tuỳ theo hệ thống client (hệ thống client của Colossus là phần phức tạp nhất của cả hệ thống)
Tính năng ghi chép dữ liệu sử dụng Reed-Solomon, giúp cải thiện MTTF (mean time to failure) và chi phí.
Năm 2020, Dean Hildebrand, Technical Director, và Denis Serenyi - Tech Lead, Google Cloud Storage - chia sẻ về Google Storage Infrastructure có nhắc đến khá chi tiết về cách thức hoạt động của Colossus. Trong đó phải kể đến những ý tưởng thiết kế của Colossus client, metadata service Curators, background storage manager Custodians, ý tưởng tổ chức dữ liệu (cold/hot data), và sự kết hợp giữa flash disks và spinning disks.
Đọc thêm chi tiết về những thiết kế quan trọng xoay quanh Colossus ở bài viết này
Góc Database
The CacheLib Caching Engine: Design and Experiences at Scale
Thông thường, để cải thiện hiệu suất truy vấn dữ liệu, các hệ thống database hay là các ứng dụng kết nối với database sẽ xây dựng một lớp cache trên bộ nhớ. Với hệ thống lớn và phức tạp như Facebook, để đáp ứng tải cao và tối ưu việc sử dụng tài nguyên một cách hiệu quả, đội ngũ kỹ sư của họ đã nghiên cứu và áp dụng rất nhiều phân hệ cũng như kỹ thuật khác nhau phục vụ quá trình caching dữ liệu, có thể kể đến như:
CDN để cache các HTTP requests tới nội dung chứa media như ảnh, video.
Key-value store để cache các database query, user data.
Flash drive để cache những khối dữ liệu có tần suất truy cập lớn mà vượt quá IOPS của ổ đĩa.
Page buffer để tăng throughput và giảm latency khi database phục vụ yêu cầu truy vấn từ ứng dụng.
Facebook nhận thấy rằng:
Họ có hàng trăm dịch vụ khác nhau mà trong đó chúng xử lý bài toán caching hiệu quả một cách hoàn toàn độc lập.
Mỗi dịch vụ thường gồm rất nhiều nodes mà mỗi node đòi hỏi dung lượng cache tới hàng trăm GB để đạt được tỷ lệ cache hit ở mức chấp nhận được. Trong khi đó, do tính lịch sử, hầu hết các hệ thống chỉ hướng tới tối ưu hiệu quả khi cache trên DRAM mà bỏ qua các loại Flash memory.
Tuy mỗi dịch vụ có đặc điểm, tính chất riêng ảnh hưởng tới việc lựa chọn thiết kế nhưng đa phần chúng có cùng lớp bài toán chung mà mọi hệ thống cache đều phải giải quyết.
Khi có ý tưởng hoặc nghiên cứu mới cho lớp bài toán chung, sẽ khó để triển khai áp dụng cho toàn bộ các dịch vụ.
Năm 2017, Facebook đã lần đầu áp dụng cache engine có tên CacheLib vào dịch vụ của họ, đến nay đã có hơn 70 dịch vụ lớn nhỏ khác nhau sử dụng CacheLib để triển khai các tính năng liên quan đến caching. Một số tính năng nổi bật của CacheLib:
CacheLib là một thư viện C++ (thread-safe, scalable) cung cấp các tính năng quan trọng mà mọi hệ thống cache đều cần tới (unified caching implementation).
Hỗ trợ hybrid-caching bằng cách kết hợp DRAM và Flash memory một cách hiệu quả.
Có thể khởi động lại dịch vụ mà vẫn giữ nguyên trạng thái của dữ liệu trên bộ đệm.
Tối ưu cache cho các cấu trúc dữ liệu phổ biến như array, hashmap mà không tốn chi phí cho quá trình serialization object.
Với CacheLib, các developers tại Facebook có thể áp dụng cache cho dịch vụ của họ dễ dàng hơn, giúp giảm hàng chục nghìn dòng code dư thừa, tăng độ ổn định của các chức năng liên quan đến cache.
Đầu tháng 9 vừa qua, CacheLib đã được Facebook cung cấp dưới dạng open source. Bạn đọc có thể tìm hiểu thêm về quá trình Facebook thiết kế CacheLib thông qua bài talk ngắn hoặc paper mà họ công bố.
Góc Lập Trình
Đề tuần này:
Cho trước một danh sách liên kết, hãy đảo ngược các node trong danh sách này theo từng group có độ dài k cho trước.
Ví dụ:
Input: head = [1,2,3,4,5], k = 2
Output: [2,1,4,3,5]
Các bạn có thể thử sức tại đây.
Lời giải tuần trước:
Để giải được bài này, ta cần ôn lại khái niệm chuỗi đối xứng. Chuỗi đối xứng là chuỗi mà nếu ta đọc xuôi hay ngược đều cho ta cùng một kết quả. Ví dụ: abcba, baab, bbbbb đều là những chuỗi đối xứng.
Một cách tiếp cận là tìm tất cả những chuỗi là subsequence của chuỗi đầu vào, rồi kiểm tra xem chuỗi có phải đối xứng hay không. Độ phức tạp của giải thuật là O(2^n * n) với n là độ dài của chuỗi đầu vào. Tìm tất cả các chuỗi là subsequence có độ phức tạp là O(2^n), thao tác kiểm tra xem chuỗi đối xứng có độ phức tạp là O(n).
Quan sát các chuỗi đối xứng, ta thấy nếu chuỗi p có độ dài n, ta luôn có p[1] == p[n], p[2] == p[n - 1] ... p[k] == p[n - k + 1] với mọi 1 <= k <= n. Như vậy nếu tại 2 điểm bất kỳ i, j trong chuỗi đầu vào, nếu ta có s[i] == s[j], ta chỉ cần đi tìm subsequence có dài lớn nhất trong chuỗi [i + 1, j - 1]. Ta có công thức như sau:
LSP(i, j) = LSP(i + 1, j - 1) + 2nếus[i] == s[j]LSP(i, j) = max( LSP(i + 1, j), LSP(i, j - 1) )nếus[i] != s[j]
Đây chính là cấu trúc con tối ưu (optimal substructure) của bài toán, triển khai công thức trên ta sẽ gặp những bài toán con gối nhau (overlapping subproblems), nên ta có thể áp dụng Dynamic Programming để giải như sau: https://pastebin.com/kjDuy5yK
Độ phức tạp của giải thuật time complexity, space complexity đều là O(n ^2), với n là độ dài của chuỗi đầu vào. Ngoài ra, ta cũng có thể giải bài này bằng đệ quy với time complexity là O(2^n), xin dành phần giải cho bạn đọc.
Tech Talks
Constraints Liberate, Liberties Constrain — Runar Bjarnason
Chúng ta nên abstract hệ thống/phần mềm đến mức nào? Quyết định đó ảnh hưởng như thế nào đến tính biểu đạt và sự chính xác của hệ thống? Phải chăng một ngôn ngữ, library càng mạnh thì càng tốt? Trong video này, Ruar Bjarnason - một trong những tác giả của ngôn ngữ Unison và đồng tác giả của sách đỏ Functional Programming in Scala đã đi sâu vào sự mâu thuẫn mà chúng ta phải đối mặt khi nghĩ về abstractions. Anh ấy muốn truyền đạt một thông điệp: sự ràng buộc và chính xác thì sẽ tốt hơn sức mạnh và sự tự do. Ràng buộc trên mỗi một component design sẽ dẫn tới sự tự do và khả năng sắp xếp component đó trong hệ thống.
Code & Tools
Unison - An open-source functional programming language based on a simple idea with big implications: code is content-addressed and immutable
Drake - Model-Based Design and Verification for Robotics
Góc Sponsors
Fossil Vietnam, formerly Misfit, is the Center of Excellence for Wearables Research & Development of Fossil Group. We’re an innovative team that designs and engineers world-class wearables products that touch the lives of millions of people. We take pride in being innovators who are pushing the boundaries of fashion and technology.
Why you’ll love working at Fossil Vietnam
Opportunities to work with global Tech giants.
Attractive salary and performance bonus twice a year.
Premium healthcare for employees and family, even on probation.
15 days of Annual leave and 2 days of Volunteer leave, even on probation.
All tools you need: Mac/Windows, iOS/Android, Testing devices/State-of-the-art wearables, you name it.
Welcome watch after probation.
You’ll get food to get fit, we’ll take care of it all.
Join us, and you’ll contribute to the development of next-generation wearable technology that makes a difference in people’s everyday lives. View all featured positions.
Keep in touch
Quotes
“Truth can only be found in one place: the code.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship