Tìm kiếm
31 kết quả cho “Shadow pipeline”. Tìm không phân biệt dấu.
- Pipeline dữ liệu và analytics Chủ đề Thành viên
Lúc đầu, báo cáo chạy thẳng trên DB production. Đến một lúc truy vấn phân tích làm chậm giao dịch, dữ liệu cần gộp từ nhiều nguồn, và có thêm người dùng mới (analyst, ML, khách hàng xem dashboard). Khi đó cần một mặt…
- How We Replaced Our Data Pipeline With Zero Downtime Bài tóm tắt · Twilio · 2014
…time (với công ty viễn thông, downtime là rớt cuộc gọi): 1. Shadow (công cụ tự viết, mã nguồn mở): proxy gửi cùng request tới bản ổn định và bản mới, báo khác biệt, chỉ trả kết quả…
- From Homegrown to Flink: Migrating a Stateful Ad Event Join at Scale Bài tóm tắt · Zalando · 2026
…ý là sai. Họ tăng pod từ 16 lên 20 GB. - Migration: - dựng shadow pipeline đầy đủ (stream và bảng riêng), chạy 4 tuần; - so tỷ lệ làm giàu event (khớp 99,9%, ngưỡng 99–101%), số l…
- Deploying Large-scale Fraud Detection Machine Learning Models at PayPal Bài tóm tắt · PayPal · 2021
…s://medium.com/paypal-tech/machine-learning-model-ci-cd-and-shadow-platform-8c4f44998c78) Bài đầu của một series về nền tảng shadow cho model; các phần sau (meta-learning, feature…
- Migrating Data Ingestion Systems at Meta Scale Bài tóm tắt · Meta · 2026
…thêm tiêu chí riêng do team phụ thuộc đặt ra. - Ba pha: 1. Shadow: job mới đọc cùng nguồn, ghi vào bảng shadow; liên tục so số dòng và checksum, sửa lỗi ở pre-production; đo quota…
- Maintaining Machine Learning Model Accuracy Through Monitoring Bài tóm tắt · DoorDash · 2021
…t. - Log có predictor name ánh xạ tới model mặc định và các shadow model : shadow cũng chấm và được ghi log, đúng kỳ vọng thì được nâng thành mặc định. - Bản thứ hai, sau phản hồi:…
- Deploy và release an toàn Chủ đề Thành viên
Phần lớn sự cố bắt đầu bằng một thay đổi: code mới, cấu hình mới, hạ tầng mới. Khi hệ thống và tổ chức lớn lên, câu hỏi là làm sao đưa thay đổi lên production thường xuyên mà vẫn giới hạn được thiệt hại khi có lỗi.
- Migration không downtime Chủ đề Thành viên
Hệ thống đang chạy thật (gọi xe, chat, thiết kế) không được dừng, nhưng phải đổi ngôn ngữ, database hoặc hạ tầng bên dưới.
- Nền tảng ML (feature, training, serving, giám sát model) Chủ đề Thành viên
Model ML đầu tiên của một công ty thường được nhúng thẳng vào một service có sẵn, với feature tính trong vài script và train bằng một job riêng. Khi số model và số người làm model tăng, bốn chỗ cùng hỏng:
- Observability và monitoring Chủ đề Thành viên
Lúc đầu, monitoring là vài dashboard và một công cụ cài sẵn; log đọc thẳng từ máy. Khi hệ lớn lên, chính hệ quan sát thành một hệ phân tán có bài toán riêng:
- Stream processing Chủ đề Thành viên
Khi batch hằng ngày hay hằng giờ không còn đủ tươi (chi tiêu quảng cáo phải dừng đúng lúc chạm ngân sách, dashboard MRR không được trễ 24 giờ, alert phải bắn khi contest sắp đầy), hệ phải tính liên tục trên luồng sự…
- Failover, replica và dự phòng dữ liệu Chủ đề Thành viên
Mọi hệ có trạng thái đều giữ nhiều bản (replica) để một máy chết không làm mất dịch vụ. Khó không nằm ở việc có bản sao mà ở lúc chuyển sang bản sao:
- Tự động hoá vận hành và auto-remediation Chủ đề Thành viên
Khi số máy, shard, pod tăng lên hàng nghìn, lỗi "hiếm" (một node chết, một đĩa hỏng, một replica trễ) thành chuyện hằng ngày, và thao tác tay không còn theo kịp: Stripe có hàng trăm lần shard suy giảm mỗi năm, mỗi lần…
- Nền tảng nội bộ cho service (đường ray chung) Chủ đề Thành viên
Tách hệ thống thành nhiều phần (service, hoặc component trong một monolith) giải được bài toán tổ chức. Nhưng nếu mỗi team tự làm RPC, retry, log, metric, contract theo cách riêng, thì ta chỉ đổi một kiểu hỗn loạn lấy…
- Thử nghiệm A/B và nền tảng experimentation Chủ đề Thành viên
Khi nhiều team cùng thay đổi một sản phẩm, "ship rồi xem metric" không còn trả lời được thay đổi nào gây ra gì. Thí nghiệm có đối chứng trả lời được, nhưng ở quy mô lớn nó thành một hệ thống: gán người dùng vào biến thể…
- Load shedding, rate limit và backpressure Chủ đề Thành viên
Mọi hệ đều có lúc nhận nhiều việc hơn sức làm: spike của người dùng, client nội bộ có bug, dependency chậm đi, retry dồn lại. Theo Discord, khi chạm giới hạn năng lực thì đó là bài toán kinh tế: hoặc tăng cung (thêm…
- Xử lý sự cố và on-call Chủ đề Thành viên
Khi hệ còn nhỏ, vài người biết hết mọi thứ; có lỗi thì người thấy đầu tiên sửa luôn. Khi có hàng trăm service và hàng trăm engineer, câu hỏi đổi khác:
- Hot partition và thundering herd Chủ đề Thành viên
Chia dữ liệu và tải ra nhiều máy chỉ hiệu quả khi tải chia đều. Thực tế tải lệch: một khách hàng khổng lồ, một kênh có @everyone, một bài của người nổi tiếng. Có hai dạng hay gặp:
- Sự cố và postmortem Chủ đề Thành viên
Nhiều bước ngoặt kiến trúc trong wiki bắt đầu từ một sự cố: Netflix lên cloud sau 3 ngày không gửi được DVD, Twitter viết lại hệ thống sau World Cup 2010, Instagram đi nhiều data center sau trận bão 2012. Trang này gom…
- Multi-tenancy và cô lập tenant Chủ đề Thành viên
Một hệ phục vụ nhiều khách (tenant: workspace, shop, organization, account, service nội bộ) trên cùng hạ tầng thì rẻ và dễ vận hành, vì tài nguyên được dùng chung. Cái giá là bốn câu hỏi đi theo hệ suốt đời:
- Grab Công ty Thành viên
Dùng AWS từ ngày đầu (MyTeksi 2012: Rails trên EC2 + RDS MySQL) và theo Grab chỉ cần dưới 10 kỹ sư vận hành nhờ managed service . Năm 2016 họ chuyển API hành khách từ Rails sang Go theo từng endpoint bằng shadow…
- Meta Công ty Thành viên
Facebook khởi đầu trên LAMP với mỗi trường đại học một DB; mở rộng bằng Memcache, rồi TAO, rồi data center riêng, edge cạnh ISP và region nhiều toà nhà. Giai đoạn 2010–2020 là các ca góc của hệ phân tán: bất nhất cache…
- Zalando Công ty Thành viên
Năm 2016 Zalando dựng microservices CRUD phát event mà không có read API: mỗi team tự replay stream và dựng bản sao, sinh nhiều nguồn sự thật; event Offer trễ tới 30 phút dịp Cyber Week. Từ 2022 họ gom về Product Read…
- Alibaba Công ty Thành viên
Database của Alibaba đi qua ba giai đoạn, đều do đỉnh tải Double 11 dẫn dắt: thương mại (IBM/Oracle/EMC, 2005–2009) → "De-IOE" sang mã nguồn mở với middleware TDDL và AliSQL (2010–2015) → tự phát triển X-DB (từ 2016).…
- Multilingual message content moderation at scale (part 1) Bài tóm tắt · Bumble · 2021
…đã có. Liên quan - - Cùng công ty: · - Cùng bài toán: (cổng shadow trước khi model tham gia quyết định) · ·…
- Multi-region high availability for Kafka workloads with a single Stretch Cluster Bài tóm tắt · Redpanda · 2026
Pipeline dữ liệu quan trọng chạy nhiều gigabit/giây, trải nhiều region. Sao chép bất đồng bộ (mirroring) luôn để lại cửa sổ mất dữ liệu và cần bước failover.
- Twilio Công ty Thành viên
Năm 2014 Twilio tách dữ liệu cuộc gọi đang chạy khỏi dữ liệu đã xong, đặt service trước DB, rồi shard MySQL theo AccountSid (range + lookup), tất cả không downtime nhờ shadow proxy và account flag . Năm 2017, hệ queue…
- Apache Hudi at Uber: Engineering for Trillion-Record-Scale Data Lake Operations Bài tóm tắt · Uber · 2026
…tore tập trung để rollout thay đổi trên hàng nghìn dataset; shadow pipeline, backfill và sửa tự động biến phục hồi từ nhiều ngày thành runbook. - Hướng tiếp: IngestionNext chuyển i…
- Architecting Restaurant Wait Time Predictions Bài tóm tắt · Yelp · 2019
…uan - · - Cùng công ty: - Cùng bài toán lệch train/serve: · shadow model:…
- Project STAR*: Streamlining Our On-Call Process Bài tóm tắt · LinkedIn · 2018
…ần; manager điểm danh xác nhận ở mốc 4 và 2 tuần; - có lịch shadow cho người mới trực lần đầu. - Công cụ: SRE riêng của Voyager nhận hỗ trợ công cụ deploy và viết playbook; team Pr…
- Shopify Công ty Thành viên
Năm 2015 không còn mua được DB to hơn nên Shopify shard, rồi phát hiện thao tác lặp mọi shard làm mất cô lập lỗi. Kiến trúc pod (mỗi request chỉ chạm một tập datastore cô lập, Pod Mover dời pod sang DR) ra đời .…