Pipeline dữ liệu và analytics

Bài toá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 phẳng dữ liệu thứ hai, nằm ngoài đường request:

• Đưa dữ liệu ra khỏi hệ online: dump định kỳ, CDC, hay để service phát event? Không được làm hại DB nguồn, không được mất dòng.
• Batch hay stream: độ tươi đổi lấy độ phức tạp (trùng, trễ, state, checkpoint).
• Điều phối: hàng trăm tới hàng chục nghìn job phụ thuộc nhau, chia tài nguyên chung.
• Đúng và kịp: job "thành công" chưa chắc dữ liệu đủ và đúng giờ; lỗi ở một bảng lan sang mọi bảng hạ nguồn.
• Chi phí: compute batch và lưu trữ lake lớn dần theo dữ liệu chứ không theo người dùng.

Trang này nói về pipeline dữ liệu cho analytics, data warehouse/lake và chấm điểm offline. Messaging giữa các service (queue, outbox, consumer) ở Event-driven, message queue và Kafka; pipeline log/metric cho vận hành ở Observability và monitoring; index search là một dạng dữ liệu dẫn xuất riêng ở Hạ tầng tìm kiếm.

Diễn tiến theo thời gian

• 2005→2013 · LinkedIn: Databus tách "theo dõi thay đổi" (relay) khỏi "dựng lại từ đầu" (bootstrap snapshot), để dựng index mới mà không đụng DB chính. LinkedIn 2013
• 2008→2013 · LinkedIn: theo Kreps, Hadoop chỉ có giá trị khi dữ liệu vào được: lấy từ Oracle warehouse không được (đã xử lý không đảo ngược), phải đi thẳng DB nguồn và log; mỗi nguồn là một dự án hay hỏng. Lời giải là log trung tâm có schema để load Hadoop tự động (bảng Hive tự sinh). LinkedIn 2013
• 2012→2017 · Airbnb: Báo cáo tài chính từ ETL MySQL chạy đêm (trigger ghi lịch sử, bảng trung gian, báo cáo riêng lẻ; cuối đời hơn 24 giờ một lần chạy) sang Spark/Scala theo event handler sinh subledger kế toán kép: 4–5 giờ, scale ngang, unit test từng handler và smoke test luật dữ liệu. Airbnb 2017
• 2012→2014 · LinkedIn: Pinot: ingest Kafka gần realtime cộng Hadoop cho bootstrap và đối soát, thay đường Hadoop → Oracle không realtime và cron xoá dữ liệu cũ. LinkedIn 2014
• 2014 · Pinterest: analytics cho doanh nghiệp là pipeline Hadoop MapReduce hằng ngày (khoảng 100 job, Hive + Cascading, điều phối bằng Pinball) từ event Kafka trên S3 và object từ DB, ghi vào HBase đã gộp sẵn theo ngày/tuần/tháng. Pipeline mất tới 19 giờ; tăng tốc bằng checkpoint trung gian, giảm cỡ dữ liệu, tránh sort, cắt bản ghi ở khoá lệch. Row key đặt khoá phân tán đầu, ngày cuối. Pinterest 2014
• 2014 · Netflix: DW khoảng 10 PB trên S3, ETL bằng Pig/Hive, báo cáo trên Teradata; thêm Presto cho khám phá tương tác (khoảng 250 worker, 2.500 query/ngày làm việc), nhanh hơn Hive 10–100 lần với query một–hai pha MapReduce. Presto không chạy pipeline production; query cần đưa vào production phải viết lại bằng HiveQL/Pig. Netflix 2014
• 2014 · LinkedIn (Jay Kreps, O'Reilly): phản biện lambda: giữ hai hệ (Hadoop + Storm) cho cùng kết quả là gánh nặng không sửa được; LinkedIn đã thử API "trong suốt" chạy cả hai và thấy đó là trừu tượng rò rỉ nhất. Đề xuất kappa: một hệ stream, giữ log trong Kafka, cần tính lại thì chạy bản job thứ hai từ đầu log ra bảng mới rồi chuyển đọc. Theo Kreps, chi phí hai cách gần ngang nhau; lợi thế thật là một framework. LinkedIn 2014
• 2015 · Yahoo: khoảng 2.300 node Storm; team Storm tự viết benchmark gần tải thật (Kafka → lọc → join Redis → đếm theo cửa sổ 10 giây, SLA 1 giây). Storm và Flink latency dưới giây, gần tuyến tính; Spark Streaming (micro-batch) latency bậc thang, đổi lấy thông lượng, và chọn độ dài batch tốn nhiều lượt đo. Theo Yahoo, không có bên thắng rõ. Yahoo 2015
• 2015→2026 · Uber: Hudi ra đời vì data lake file-chỉ-append không chịu được dữ liệu thay đổi liên tục: thêm ACID, index + upsert, đọc tăng dần. Quy mô 2026: 19.500 dataset, 6 nghìn tỉ dòng và 10 PB ingest mỗi ngày, 350.000 commit/ngày; Metadata Table thay việc list file trên NameNode, Record Index thay index HBase bên ngoài (1–2 ms mỗi khoá); theo Uber, quản lý cấu hình tập trung và kiểm tra tự động là điều kiện vận hành; chuyển ingest sang Flink để độ trễ từ giờ xuống phút. Uber 2026
• 2015 · LinkedIn (Kafka Audit): độ đầy đủ đo bằng số đếm producer tự báo so với số mỗi tầng nhận, Hadoop ghi audit như tầng cuối, nên kiểm được đầu-cuối từ producer tới consumer. LinkedIn 2015
• 2015→2020 · LinkedIn (HDFS): cụm lớn nhất 20 PB → 500 PB, 145 triệu → 1,6 tỷ object; 90% file là file nhỏ → tách log hệ thống sang satellite cluster (FailoverFS ghi mới bên mới, đọc gộp hai bên); Wormhole thay các pipeline tự chế đưa dữ liệu HDFS ra service online qua cụm drop box từng DC (bài 2021). LinkedIn 2021
• 2015 · Airbnb: Pipeline offline mỗi repository: dump delta ra S3, Spark merge với snapshot cũ và feature tính offline, kiểm sanity, nạp snapshot mới; snapshot trên S3 dùng luôn cho analytics. Airbnb 2016
• 2016 · Zillow: đổi cách nghĩ từ bảng SQL Server sang event stream: producer tự viết lấy phần thay đổi mỗi giây từ checkpoint, Kinesis Firehose đổ vào data lake S3; producer có thể sinh trùng nên khử trùng ở hạ nguồn. Zillow 2016
• 2016 · Medium: đưa dữ liệu từ DynamoDB sang warehouse bằng Spark: scan song song theo partition (nhanh hơn khoảng 75%) kèm giới hạn tốc độ để không ăn hết read capacity của bảng production; backup ra S3 dạng JSON rồi nạp vào Redshift, Databricks. Medium 2016
• 2016 · Medium: bộ lập lịch nội bộ Conduit chạy job khi điều kiện phụ thuộc thoả (đủ log một ngày), tách người sản xuất khỏi người dùng dữ liệu; schema Protobuf chung cho app, web và warehouse, sinh tài liệu từ .proto. Medium 2016
• 2016→2019 · LinkedIn (Brooklin CDC): stream thay đổi Oracle, Espresso, MySQL (có bootstrap snapshot, giữ ranh giới transaction) để ứng dụng không phải query DB online; cách ly tài nguyên giữa ứng dụng và DB. LinkedIn 2019
• 2016→2020 · LinkedIn (catalog): WhereHows (2016, crawler kéo metadata) → DataHub (2019): nguồn tự đẩy qua schema, entity chia thành aspect do nhiều team sở hữu, metadata changelog dựng các index. Bài 2020 chia catalog thành ba thế hệ (theo LinkedIn: Amundsen thế hệ 1, DataHub và Atlas thế hệ 3). LinkedIn 2019 LinkedIn 2020
• 2016→2017 · Zillow: từ job ETL tự lên lịch sang Airflow trên ECS (RabbitMQ, metadata trên RDS), job nặng đẩy sang EMR; DAG có CI/CD và ba cụm local/staging/prod; khoảng 30 pipeline giữa 2017. Zillow 2017
• 2017→2024 · Slack: Airflow chạy job trên EMR bằng SSH vào master node từ khoảng 2017; tới 2024 có hơn 700 job như vậy (zombie khi pod restart, tranh tài nguyên master, chặn Spark on Kubernetes). Chuyển hết sang nộp job qua REST (gateway Quarry → YARN; lệnh shell tuỳ ý chạy bằng YARN Distributed Shell) trên 8 region trong 3 quý, không downtime. Slack 2026
• 2017 · Zillow: hàng trăm job ETL batch (Spark, Hive, Sqoop) chạy trên cụm EMR autoscale theo HDFS, YARN memory và container pending; mẻ dữ liệu lớn tới 10 TB cần có ngay cho analyst. Zillow 2017
• 2017 · Box: Snitch: filesystem kế thừa S3A ghi thêm metastore DynamoDB để phát hiện và chờ list() nhất quán cuối của S3; dedupe/ETL không còn bỏ sót object; ép mọi thành phần dùng qua core-site.xml (bài 2018, chạy hơn một năm). Box 2018
• 2018 · Walmart: dashboard còn hàng theo dạng lambda: Kafka → Spark Streaming upsert vào Cassandra (tới khoảng 100 MB/giây) → Spark batch mỗi 6 giờ gộp ra Parquet cho Tableau. Walmart 2018
• 2018→2024 · trivago: pipeline ảnh dời từ data center sang AWS (2018) rồi một phần sang GCP mà để DB chung, file ảnh và bảng ánh xạ ID ở chỗ cũ, thành ba môi trường. Lần cuối (2022→2024) thiết kế lại với Apache Beam/Dataflow, ID sinh trong DB; đổi ảnh chính từ khoảng một ngày xuống vài giây. Theo trivago, Kinesis → Lambda là mẫu "đang thịnh" không hợp, làm chậm và đắt. trivago 2024
• 2018 · Zillow: clickstream gần một tỷ event/ngày qua bốn phiên bản: C# → CSV → Redshift; thêm đa luồng; Hadoop MapReduce; rồi Spark trên EMR ghi Parquet vào data lake S3, Airflow lên lịch. ETL từ vài giờ xuống khoảng 30 phút. Zillow 2018
• 2018 · Two Sigma: Flint, thư viện chuỗi thời gian trên Spark (từ thư viện nội bộ): asof join có dung sai và có hướng, phép tính theo cycle (cùng timestamp), cửa sổ trên một chuỗi lớn không cần partition key. Two Sigma 2018
• 2018 · Jane Street: gộp bước xáo trộn tốn kém vào bước tiền xử lý đã phải chạy (ghi ra nhiều đống thay vì một file), đổi truy cập ngẫu nhiên thành tuần tự. Jane Street 2018
• 2019 · LinkedIn: sau một migration, ingest Kafka bootstrap lại bốn ngày dữ liệu mà job vẫn báo thành công; 1,5 ngày sau người dùng mới phát hiện, gần hai tuần mới đuổi kịp. Đổi sang chỉ số theo dataset (ingestion lag, mất dữ liệu theo mapper, data availability) và auto-remediation. LinkedIn 2019
• 2019→2022 · Twitter: mỗi team tự đưa dữ liệu HDFS vào BigQuery mất khoảng 2 tuần mỗi dataset; chuyển sang framework ingest tập trung theo cấu hình (Dataflow, Airflow) cho hơn 1.000 dataset, còn khoảng 1 giờ mỗi dataset (5/2022). Twitter 2022
• 2019 · Stripe: canonical log line gửi bất đồng bộ theo schema protobuf vào Kafka → S3 → Presto/Redshift: dữ liệu vận hành thành dữ liệu analytics (ví dụ tỉ lệ phiên bản client) và nuôi dashboard cho khách. Stripe 2019
• 2019→2022 · Spotify: 20.000 pipeline batch/ngày, hơn 1.000 repo, 300 team trên Luigi/Flo (thư viện đóng trong image Docker): không đẩy được bản sửa vì user không nâng phiên bản, workflow là hộp đen với nền tảng. Chuyển sang dịch vụ điều phối Flyte với SDK mỏng để nền tảng nâng cấp tập trung và tự động hoá (backfill, báo trễ). Spotify 2022
• 2019 · Lyft: Amundsen, tìm dữ liệu như tìm trên web: xếp hạng bảng theo số lần được query, "ai hay dùng" sinh tự động từ audit log, metadata cơ bản ai cũng xem còn thống kê cột và xem trước chỉ cho người có quyền. Theo Lyft, thời gian tìm ra một artifact còn khoảng 5% so với trước. Lyft 2019
• 2019 · Netflix: DBLog: CDC cho MySQL/PostgreSQL kèm dump theo chunk xen kẽ với event log, không khoá bảng, dump được bất cứ lúc nào để bootstrap hoặc sửa kho dẫn xuất; watermark ghi vào chính change log để chunk không ghi đè thay đổi mới hơn. Nền connector của Delta từ 2018. Netflix 2019
• 2019 · LinkedIn: feature coverage của FollowFeed: ETL ingest và response mẫu sang HDFS, Spark đối chiếu hằng ngày. LinkedIn 2019
• 2020 · Gojek: giám sát nền tảng điều phối Airflow: lỗi hay gặp là "job không chạy" nên đo heartbeat, schedule delay, thời gian parse DAG cùng trạng thái task. Gojek 2020
• 2020 · Tinder: pipeline kết quả thí nghiệm: hơn 80 job Spark hằng ngày trên EMR (gán thí nghiệm, metric từ S3/Redshift, thống kê), điều phối bằng Airflow, kết quả ra RDS; metric mới chỉ cần một rollup Redshift theo hợp đồng; khối gán thí nghiệm tăng 2 → 25 job (pre/post-auth, loại bot); bất biến thống kê nhúng vào hệ thống (chỉ hiện ý nghĩa thống kê sau 2 tuần, hiệu chỉnh so sánh bội). Tinder 2020
• 2020 · Spotify (bài 6/2022): pipeline forecast: QA dữ liệu đầu vào, tham số và nhãn lưu BigQuery, tune song song bằng Dataflow, job nhỏ là container Python trên Kubernetes, kết quả tự sinh tóm tắt và biểu đồ cho cả công ty Spotify 2022
• 2020 · Walmart: pipeline knowledge graph chạy định kỳ trên Hadoop, kết quả nạp hàng loạt vào kho đồ thị để phục vụ; mở rộng từng danh mục (bắt đầu Home & Garden). Walmart 2020
• 2020 · Zillow: thay Sqoop kéo từ DB và các team tự ghi S3 bằng Data Streaming Platform: REST API, kiểm schema, tự lưu bảng Hive, Data Catalog có lineage và tag PII, Luminaire kiểm chất lượng; đưa dữ liệu vào lake từ vài tuần xuống vài ngày. Zillow 2020
• 2020 · Zillow: event analytics đổi tên hay ngừng bắn làm hỏng consumer; ở môi trường test mọi event cũng gửi vào Kafka qua Data Streaming Platform để Selenium kiểm theo người dùng và test thụ động 5 phút một lần kiểm schema. Zillow 2020
• 2020→2022 · DoorDash: Thay các pipeline riêng lẻ vào Snowflake: Flink ghi Parquet lên S3 (exactly-once theo checkpoint, backfill được) rồi Snowpipe nạp; mỗi event một job và một Snowpipe để cô lập lỗi; onboard event tự động bằng GitHub App + Cadence, từ vài ngày còn vài phút. DoorDash 2022
• 2020→2022 · Twitter: Sparrow: pipeline nạp log từ batch (độ trễ vài giờ) sang streaming-first trên Google Cloud (aggregator → Kafka/PubSub → Beam trên Dataflow → BigQuery, GCS), vẫn phục vụ cả dữ liệu lịch sử; độ trễ còn phút hoặc giây. Twitter 2022
• 2021 · trivago: pipeline gallery ảnh chuyển AWS → GCP và thiết kế lại: chuỗi job Dataflow điều phối bằng log sink → Pub/Sub → Cloud Function (Composer phải chạy cả ngày cho việc vài giờ); chỉ stream phần đổi bằng so snapshot hôm trước (cẩn thận không sinh bản ghi xoá cho chỗ ở không được tính lại); snapshot = snapshot cũ + CDC nên dựng lại được khi lỡ ngày; kiểm bất biến (thứ tự 1..N) trước khi stream. trivago 2021
• 2021 · Zillow: chất lượng dữ liệu pipeline được giám sát bằng Luminaire thay vì luật ngưỡng do từng team viết; mã nguồn mở thư viện mô hình. Zillow 2021
• 2022 · Shopify: Airflow dùng chung hơn 10.000 DAG, 150.000 lượt chạy/ngày: parse DAG trên GCS nghẽn (chuyển sang NFS), metadata phình (xoá quá 28 ngày), cần manifest chủ sở hữu, DAG policy, lịch ngẫu nhiên tất định để khỏi dồn đầu giờ, pool và queue riêng. Shopify 2022
• 2022 · Netflix: nền tảng Data Mesh mở rộng từ CDC cho Studio thành nền tảng di chuyển và xử lý dữ liệu chung: connector đọc binlog (DBLog, CockroachDB, Cassandra), processor là job Flink, Kafka giữa các bước, schema Avro bắt buộc để kiểm tương thích, lineage theo trường và tự nâng cấp pipeline phía sau; mục tiêu thay dần Keystone và Delta. Netflix 2022
• 2022→2024 · ClickHouse: DWH nội bộ bắt đầu từ việc VP Product phân tích bằng Excel: batch theo giờ, không CDC (nguồn có update thì nạp lại toàn bộ), S3 làm tầng trung gian chuẩn, ghi idempotent bằng ReplacingMergeTree, một DAG chính lớn. Một năm sau: 19 nguồn, 470 TB nén; hai tầng RAW/MART không đủ (cần tầng thực thể nghiệp vụ), DAG lớn thành một miền lỗi duy nhất nên tách thành 9 tiến trình sau khi thêm dbt; thêm dữ liệu gần thời gian thực (một bảng 4 tỉ dòng/ngày) bên cạnh báo cáo batch. ClickHouse 2023 ClickHouse 2024
• 2023 · Instacart: job batch chấm điểm còn hàng cho mọi item mỗi 2–4 giờ từ Snowflake quá đắt và trễ; chuyển sang lịch phân tầng theo độ nóng (khoảng 1% item chấm hằng giờ và real-time, còn lại hằng ngày), chi phí tính toán giảm khoảng 80%. Điểm được nạp vào DB phục vụ bằng full sync vài lần mỗi ngày cộng lazy refresh khi item hiện trong search, giảm 2/3 tải ingest. Instacart 2023 Instacart 2023
• 2023 · Uber (qua lời kể của Onehouse 2024): Lambda architecture phục vụ bốn loại nhu cầu (streaming dưới một phút, real-time tới khoảng 2.000 QPS, interactive, batch): Kafka → Flink → Pinot cho nhánh nhanh, Spark/Hudi/HDFS cho nhánh lake; Hudi đưa độ tươi từ 24 giờ xuống một giờ; ba tầng truy vấn (Presto SQL, Flink/Spark SQL, API). Onehouse 2024
• 2023 · Zillow: Streamz (hơn 2 tỷ event/ngày): producer tự tạo topic Kafka + bảng lake + job Flink bằng Terraform; Data Portal gom schema registry, catalog, data contract (Luminaire) dùng làm kiểm tra sẵn sàng của dependency. Zillow 2023
• 2024 · Allegro: copy Postgres → BigQuery khi GCP không nối thẳng được tới DB: loại outbox + Debezium vì khó đảm bảo không mất/trùng; chọn batch theo khoảng thời gian, load vào bảng tạm rồi chèn idempotent, so số dòng sau mỗi lần. Allegro 2024
• 2024→2025 · Grab: data mesh (Signals Marketplace) từ 2024: chủ sở hữu theo domain, hợp đồng dữ liệu, chứng nhận bảng; chỉ số north star là tỉ lệ query vào bảng đã chứng nhận (75% năm 2025), số bảng P80 giảm hơn 58%, số bảng khai tử tăng 400%. Grab 2025
• 2024 · Slack: hơn 60 cụm EMR, hàng nghìn DAG, pipeline billing trễ SLA. Migrate Hive 2/Spark 2 sang Spark 3 trong một năm, chạy song song hai thế hệ cụm trên một Hive Metastore đã nâng lên bản tương thích ngược, cờ boolean trong operator Airflow để chuyển từng job, so khớp dữ liệu chính xác bằng EXCEPT/COUNT trên Trino. Phần lớn task nhanh hơn 30–60%; AQE thay code tự xử lý lệch dữ liệu. Slack 2024
• 2024 · Notion: catalog DataHub có mà ít dùng, vì dữ liệu nguồn là JSON không schema, bảng thiếu mô tả, mô tả không lan xuống. Chữa ở nguồn: mỗi analytics event là một kiểu TypeScript (kèm chủ sở hữu, tier), đổi thành JSON Schema hằng ngày vào catalog; mô tả bảng dẫn xuất sinh bằng LLM theo lineage từ trên xuống, người đẩy code duyệt trước khi đồng bộ. Notion 2024
• 2024 · Zillow: StreetEasy dùng dbt biến hàng trăm bảng event thô thành vài chục certified dataset có định nghĩa metric thống nhất, test và tài liệu; một câu hỏi A/B từ vài ngày xuống vài phút. Zillow 2024
• 2025 · ClickHouse: (nhà cung cấp) CDC từ Postgres/TimescaleDB sang ClickHouse bằng logical replication: snapshot song song theo ctid, tra bảng cha cho chunk của hypertable, theo dõi kích thước replication slot; dùng cho migrate từng bước (dời đọc trước, ghi sau) hoặc cho hai kho cùng tồn tại. ClickHouse 2025
• 2025 · Spotify: khai tử hai dataset người dùng có khoảng 1.800 pipeline phụ thuộc trực tiếp trên ba framework, hạn 6 tháng. Lineage trong Backstage cho biết consumer, Fleetshift điều phối, coding agent mở 240 PR theo bảng ánh xạ trường tường minh; bỏ Scio vì mỗi team viết một kiểu, và repo không có test nên team chủ phải kiểm tay. Spotify 2026
• 2025 · Stripe: analytics Billing từ batch tính lại toàn lịch sử (trễ 24 giờ) sang Flink giữ state subscription tăng dần + Pinot engine đa tầng cho aggregation theo cửa sổ lúc query (bỏ tiền tổng hợp): gần như mọi cập nhật trong 15 phút, query dưới 300 ms. Đổi định nghĩa metric: batch tính lại lịch sử, đệm sự kiện mới trong Flink, vá state rồi phát lại. Stripe 2025
• 2025 · Doximity: hơn 900 DAG của gần 20 team: bỏ build DAG vào image Airflow (20 phút, kèm restart theo lịch) sang xuất bản lên S3 + manifest, service đồng bộ mỗi phút vào volume (sidecar; init container cho Kubernetes executor); deploy còn khoảng một phút. Doximity 2025
• 2025 · Two Sigma: (theo Two Sigma) hàng nghìn nguồn dữ liệu, snapshot DB thành nút cổ chai; chuyển sang BigQuery + dbt, pipeline khai báo bằng Terraform, version dataset và hạ tầng để replay, giám sát chất lượng tự động, hướng tới data contract. Two Sigma 2025
• 2026 · Grab: data lake hàng petabyte rời Hive sang Iceberg dần theo bảng giá trị cao, kèm catalog chuyển hướng để truy vấn hạ nguồn không vỡ khi bảng đổi định dạng. Grab 2026
• 2026 · Meta: thay hệ ingest MySQL → warehouse (vài PB/ngày, CDC) do từng team khách sở hữu bằng một dịch vụ do warehouse quản; shadow → reverse shadow → dọn, so số dòng và checksum, đánh dấu partition lỗi để chặn lan truyền. Meta 2026
• 2026 · Notion: gom job Spark về EMR on EKS, bin packing, rồi Spot Balancer giữ tỉ lệ spot/on-demand theo từng job để một lần thu hồi không giết nhiều executor; compute Spark giảm 60–90%. Notion 2026
• 2026 · Zalando: join stream quảng cáo tự viết không có checkpoint (mất tới 15 phút event mỗi lần deploy, phải cấp dư pod) chuyển sang Flink có checkpoint; shadow 4 tuần, A/B một tuần; pod trung bình từ 20 xuống khoảng 5. Zalando 2026
• 2026 · Grab: data mesh với hợp đồng dữ liệu; vi phạm hợp đồng mới thành sự cố (DPI), phân loại lỗi thô (upstream, platform, job, data) để tự giao chủ, tự sửa lỗi đã biết; 86,9% DPI tự giải quyết. Grab 2026
• 2026 · Grab: công cụ cho chứng nhận: catalog Hubble (DataHub, lineage tới mức cột) với chứng nhận được tính từ event metadata (có CertifiedPlus đòi cả upstream đạt); test chất lượng Genchi chạy khi pipeline xong (nghe event của Lighthouse) thay vì cron đoán giờ; registry hợp đồng chỉ giữ tham chiếu + health URL. Grab 2026
• 2026 · Render: team dữ liệu 2 người bỏ việc chạy dbt hai, ba lần mỗi ngày "cho chắc" vì một dataset đến muộn: chia model theo phụ thuộc, chờ sentinel từ job nguồn bằng cơ chế retry của bộ điều phối, ghi event mỗi task để dự đoán giờ dữ liệu sẵn sàng; theo Render tiết kiệm khoảng 100 nghìn USD/năm (dbt + cache dashboard). Render 2026
• 2026 · Alibaba: bỏ job Flink/Spark chỉ dùng để chép Kafka vào bảng Iceberg: chuyển việc giải mã, tự tiến hoá schema tương thích, upsert từ CDC, commit snapshot và kiểm soát file nhỏ (micro-batch 32 MB, file 64 MB, compaction nền) vào sát broker; tiến độ lưu trong metadata của leader Kafka. Theo Alibaba, job tính toán thật (cửa sổ, join nhiều stream) vẫn cần Flink. Bài nhà cung cấp, beta. Alibaba 2026
• 2026 · DuckDB Labs: streaming vào data lake vướng file nhỏ (mỗi lô một Parquet + metadata), compaction chỉ chữa sau; DuckLake để ghi nhỏ nằm trong database catalog rồi flush khi checkpoint (theo benchmark của họ, nhanh hơn Iceberg + Polaris hai bậc). DuckDB Labs 2026
• 2026 · Snowflake: MERGE/UPDATE thưa của pipeline CDC/ELT trên file bất biến bị write amplification (chép cả dòng không đổi). Ghi delta + bitmap, dùng lại thống kê cột, prefetch và cache metadata: một MERGE từ 6 phút 28 giây còn 28 giây, byte ghi giảm 545 lần (theo Snowflake, có phần do phần cứng mới). Snowflake 2026
• 2026 · Doximity: thêm CDC (Debezium → Kafka → Snowflake) bên cạnh snapshot batch thay vì thay nó: snapshot + vị trí GTID làm mốc khởi tạo và dựng lại bảng, view base + delta để query trước khi merge, delete tổng hợp cho ON DELETE CASCADE mà binlog không ghi, đối chiếu và tự chữa bằng snapshot. 95% sự kiện query được trong 8 phút. Bảng CDC tươi hơn nhưng nhóm bảng không còn nhất quán cùng thời điểm. Doximity 2026
• 2026 · Salesforce: khoảng 8 triệu lần chạy Spark mỗi ngày; telemetry thu qua gateway nộp job (listener Spark), lớp phân tích định nghĩa rõ cách đếm retry, spill, lần chạy hoàn chỉnh; giảm executor ban đầu và trần executor theo bằng chứng (executor 0 task, CPU rảnh), kiểm cả tác động lên nền tảng: chi phí compute tuần −31%. Salesforce 2026
• 2026 · DuckDB Labs: (nhà cung cấp) giải phẫu bảng Iceberg: catalog chỉ giữ con trỏ tới metadata.json, mọi file khác bất biến, commit là dời con trỏ có điều kiện; mỗi commit thêm manifest và lịch sử snapshot nên ghi nhỏ nhiều làm chậm đọc, phải expire và gộp. DuckLake 1.0 (4/2026) đặt metadata trong database thay vì file; 68 trên 108 PR để lên 1.0 là sửa tính đúng (mất delete khi retry commit đồng thời, dọn file mồ côi có thể xoá chính catalog). DuckDB Labs 2026 DuckDB Labs 2026
• 2026 · Memgraph: telemetry sản phẩm: Lambda ghi nguyên request JSON lên S3 làm nguồn sự thật, Glue gom hằng đêm thành Parquet theo ngày (gom chứ không biến đổi), ClickHouse kéo từ S3 vào cột JSON + type hint; developer thêm trường mới mà không cần migration. Memgraph 2026
• 2026 · Uber: một database Hive chung cho mọi team của Delivery: chung số phận khi metadata hỏng, noisy neighbor trên Metastore và HDFS, mọi việc qua một team trung tâm, ACL mở; tách theo domain bằng đổi con trỏ trong Metastore, dọn dataset cũ tiết kiệm hơn 1 PB. Uber 2026
• 2026 · Uber: Data Abstraction Layer cho báo cáo quảng cáo: consumer gọi bảng logic, DAL chọn bảng vật lý theo schema, cửa sổ sẵn có (độ tươi, thời gian giữ) và cardinality, sinh query cho từng loại DB (OLAP, Docstore, Hive), ghép kết quả (nối theo thời gian, join, rollup); báo cáo mới từ nhiều tuần còn dưới hai ngày. Uber 2026
• 2026 · Uber: COUNT(DISTINCT) chính xác cho metric non-rollup (MAU, giữ chân theo quý, 3,6 tỉ UUID): Bitmap-32 cần từ điển toàn cục nên backfill tuần tự (hơn 20 ngày), Bitmap-64 vỡ ở giới hạn 2 GB của byte[] trong JVM (khoảng 179 triệu ID); chia bitmap thành 65.536 khúc theo 16 bit đầu của hash, serialize theo luồng, bước cuối chỉ trả 8 byte; magic number để đọc lẫn dữ liệu cũ, không phải tính lại lịch sử. Backfill −65%, pipeline ngày −23%. Uber 2026
• 2026 · Uber: stream join dự đoán với impression trên Flink: parallelism 768 cho join (lớn nhất ở Uber), checkpoint RocksDB mặc định phình hơn 12 TB/giờ nên tự quản state (chỉ giữ metadata, xoá ngay sau join, dedupe); feature dạng mảng của transformer được trải phẳng trước khi gửi Kafka. Uber 2026

Các lựa chọn và đánh đổi

Quy tắc rút ra

1. Tách tải phân tích khỏi DB giao dịch sớm, kể cả bằng một batch copy đơn giản. Allegro 2024 Pinterest 2014
2. Chọn batch hay stream theo yêu cầu độ tươi và độ đầy đủ thật sự; nếu cho phép trễ hàng giờ mà không được mất dòng, batch idempotent có đối chiếu thường đơn giản hơn. Allegro 2024 Walmart 2018
3. Mọi bước load phải chạy lại được (idempotent, theo khoảng hoặc partition) và có đối chiếu (số dòng, checksum); đó là cách duy nhất chứng minh không mất dữ liệu. Allegro 2024 Meta 2026 LinkedIn 2019
4. "Job thành công" không phải SLO. Đo theo dataset (độ tươi, đầy đủ) hoặc theo hợp đồng với consumer. LinkedIn 2019 Grab 2026
5. Lỗi dữ liệu lan theo lineage: đánh dấu partition hỏng, gắn sự cố hạ nguồn vào nguyên nhân upstream thay vì đổ cho chủ bảng hạ nguồn. Meta 2026 Grab 2026
6. Tính lại theo mức thay đổi, không đồng loạt; và luôn có một lượt quét toàn bộ để phủ phần không bao giờ được đọc. Instacart 2023 Instacart 2023
7. Khi số pipeline lớn, chuyển từ "mỗi team tự viết" sang nền tảng ingest theo cấu hình có chủ sở hữu rõ. Twitter 2022 Meta 2026 Shopify 2022
8. Scheduler dùng chung cần chủ sở hữu, policy, giới hạn đồng thời và rải lịch để khỏi tự tạo tải đầu giờ. Shopify 2022
9. Gộp sẵn ở batch và thiết kế khoá lưu trữ theo mẫu đọc, để phía phục vụ không phải gộp lúc đọc. Pinterest 2014
10. Đổi nền tảng pipeline bằng shadow có tiêu chí định lượng; nhưng nếu lớp cũ đã chồng qua nhiều môi trường, cân nhắc thiết kế lại thay vì dời tiếp. Meta 2026 Zalando 2026 trivago 2024
11. Compute batch là chỗ dễ tiết kiệm lớn (spot, bin packing, định dạng bảng), miễn là tôn trọng tính chịu lỗi của từng job. Notion 2026 Grab 2026
12. Nối các bước bằng tín hiệu thật (sentinel, event "pipeline xong"), không bằng khoảng thời gian hay cron đoán giờ; test chất lượng cũng chạy theo lần chạy thật. Render 2026 Grab 2026
13. Lấy dữ liệu ra khỏi kho online cần cả song song lẫn giới hạn tốc độ; job chạy trên cụm nên được nộp qua API có trạng thái phía server, không qua kết nối giữ từ bộ điều phối. Medium 2016 Slack 2026
14. Tin cậy dữ liệu là bài toán tổ chức trước: chủ sở hữu rõ, hợp đồng, chứng nhận và một chỉ số mà cả bên sản xuất lẫn bên dùng cùng kéo; pipeline trùng lặp là triệu chứng của thiếu tin cậy. Grab 2025 Grab 2026
15. Giữ batch làm mốc khi thêm stream: snapshot nhất quán + vị trí log là cơ chế khởi tạo, dựng lại và đối chiếu cho CDC; tách hiển thị (view base + delta) khỏi merge vật lý; và nói rõ bảng tươi hơn không có nghĩa nhóm bảng nhất quán (Doximity 2026). Doximity 2026
16. Năng lực nền tảng dạng dịch vụ + SDK mỏng, không dạng thư viện dày: thư viện không được nâng cấp đều và biến workflow thành hộp đen (Spotify 2022). Spotify 2022
17. Đổi logic tính toán trên hệ stream có state: tính lại lịch sử bằng batch, đệm sự kiện mới, vá state, phát lại rồi chuyển một lần, để người dùng luôn thấy dữ liệu nhất quán (Stripe 2025). Stripe 2025
18. Giả định về độ tươi thường đứng lâu hơn giả định về cấu trúc: DWH của ClickHouse vẫn đúng với "theo giờ, không CDC" sau một năm, nhưng hai tầng RAW/MART và một DAG chính đều phải bỏ (cần tầng thực thể nghiệp vụ; DAG lớn là một miền lỗi duy nhất). Ghi idempotent theo khoá ngay từ đầu để retry và nạp lại luôn an toàn. ClickHouse 2023 ClickHouse 2024
19. Catalog chỉ tốt bằng metadata đưa vào nó: schema đặt ở nguồn (kiểu trong code, bắt buộc khi log), chủ sở hữu và tier ghi lúc tạo, mô tả lan theo lineage; tín hiệu "ai dùng" lấy từ audit log. Notion 2024 Lyft 2019
20. Công khai sự tồn tại của dữ liệu, giới hạn nội dung: tên, mô tả, chủ sở hữu ai cũng xem để biết mà xin quyền; thống kê và xem trước chỉ cho người có quyền. Lyft 2019
21. Tách code pipeline (DAG) khỏi runtime nền tảng (image): artifact có phiên bản + manifest + đồng bộ định kỳ thay vì rebuild image và restart cho mỗi thay đổi. Doximity 2025
22. Pipeline phục vụ ra quyết định cần cả bất biến thống kê nhúng vào hệ thống (thời gian tối thiểu trước khi hiện ý nghĩa thống kê, hiệu chỉnh so sánh bội) chứ không chỉ hợp đồng dữ liệu; bất biến nào đắt thì để quy trình lo. Tinder 2020

Câu hỏi mở

• Lambda (Walmart 2018) hay kappa: Kreps 2014 (LinkedIn) cho rằng chi phí tài nguyên gần ngang nhau và lợi thế của kappa là chỉ một framework, kèm kinh nghiệm LinkedIn thử API chạy cả hai thất bại (LinkedIn 2014); đó là bài quan điểm, chưa có số đo trên cùng workload.
• Allegro 2024 cho rằng CDC/streaming khó đảm bảo không mất/trùng, còn Meta 2026 chạy CDC ở quy mô PB/ngày với đối chiếu checksum; khác biệt có lẽ nằm ở có hay không một lớp đối chiếu, nhưng hai nguồn không bàn trực tiếp. Không tự chọn bên. ClickHouse 2025 (bài nhà cung cấp) thêm một góc: CDC dùng cho migrate từng bước (dời đọc trước) và rủi ro vận hành chính là replication slot phình, nhưng không nói cách đối chiếu đủ dòng. ClickHouse 2025 Doximity 2026 là nguồn đầu tiên dùng batch và CDC song song có đối chiếu: snapshot là mốc khởi tạo, dựng lại và kiểm tra/tự chữa stream, kèm số đo độ tươi 95% dưới 8 phút; vẫn là tự đo (Doximity 2026).
• Data mesh mới có Grab (đủ ba phần: Grab 2025, Grab 2026, Grab 2026); chưa có kết quả ở công ty khác, và số liệu (75% query vào bảng chứng nhận, P80 giảm 58%) do Grab tự đo.
• Chi phí lưu trữ data lake theo thời gian (retention, tầng lạnh) chỉ được nhắc lướt (Pinterest giữ một tháng; Grab chi phí một lần khi migrate).
• Liên hệ: Event-driven, message queue và Kafka (CDC, outbox, Kafka), Migration không downtime (shadow, reverse shadow cho pipeline), Chi phí hạ tầng và build vs buy (compute batch, spot), Observability và monitoring (pipeline log/metric), Tự động hoá vận hành và auto-remediation (auto-remediation cho pipeline).
• Liên hệ: Batching và khấu hao round-trip (micro-batch, gom file khi ghi lake).
• Liên hệ: Thử nghiệm A/B và nền tảng experimentation (pipeline metric của thí nghiệm, holdback).
• Liên hệ: Nền tảng ML (feature, training, serving, giám sát model) (feature store: cùng định nghĩa cho training và serving, nạp batch/stream, chỉ ghi phần đã đổi).
• Liên hệ: Stream processing (tầng tính toán trên stream: state, checkpoint, cửa sổ, join, xử lý lại, HA của job stream).