Dịch vụ kỹ thuật dữ liệu và xây dựng luồng dữ liệu

Dịch vụ kỹ thuật dữ liệu mang lại những gì?

Sáu câu hỏi khách hàng thường đặt ra trước khi thuê một đội kỹ thuật dữ liệu, được trả lời từ chính các luồng dữ liệu chúng tôi đang vận hành.

01 / 06

Một dự án kỹ thuật dữ liệu thực sự bàn giao những gì?

Một nền tảng dữ liệu chạy được, không phải một bộ slide. Tùy điểm xuất phát, đó là các kết nối thu nạp từ mọi nguồn bạn cần, kho dữ liệu hoặc lakehouse được mô hình hóa theo lớp, cơ chế điều phối lên lịch và thử lại từng job, cùng dashboard, API hoặc tính năng AI đọc dữ liệu từ đó.

Thu nạp: kết nối API SaaS, cơ sở dữ liệu, file và webhook, nạp tăng dần ở mọi chỗ nguồn cho phép.
Mô hình hóa: các lớp dbt từ dữ liệu thô đến staging và marts sẵn sàng cho nghiệp vụ, kèm kiểm thử và tài liệu sinh ra từ mã.
Điều phối: Airflow, Dagster, Prefect hoặc bộ lập lịch của cloud, có thử lại, cảnh báo và nạp lại dữ liệu lịch sử.
Bàn giao: mã nguồn trong repository của bạn, hạ tầng dạng mã trong tài khoản cloud của bạn, tài liệu vận hành và video hướng dẫn.

Điểm chính: Bạn phải biết được mỗi dashboard phụ thuộc vào những bảng nào, và ai nhận cảnh báo khi một bảng bị trễ.

02 / 06

ETL hay ELT, theo lô hay streaming: bạn cần gì?

Phần lớn công việc phân tích hiện nay nạp dữ liệu thô vào kho dữ liệu cloud trước rồi biến đổi bằng SQL ngay trong kho (ELT): kho giữ toàn bộ lịch sử thô, nên mô hình nào cũng dựng lại được. ETL vẫn phù hợp hơn khi dữ liệu phải được đọc, làm sạch hoặc che trước khi vào kho, như dữ liệu cá nhân hay các định dạng file khó.

Chạy theo lô mỗi giờ hoặc mỗi ngày đáp ứng hầu hết nhu cầu báo cáo. Gần thời gian thực, tính bằng phút, hợp với các nguồn vận hành như luồng dữ liệu thị trường điện trên trang này, nhận một báo cáo mỗi năm phút. Streaming với Kafka hoặc Pub/Sub chỉ đáng chi phí vận hành khi quyết định phải đưa ra trong vài giây.

Điểm chính: Chọn độ trễ theo quyết định mà dữ liệu phục vụ, không theo công nghệ: càng gần thời gian thực, chi phí chạy và vận hành càng cao.

03 / 06

Làm sao để luồng dữ liệu không âm thầm hỏng?

Luồng dữ liệu âm thầm hỏng khi không có gì kiểm tra thứ nó bàn giao. Chúng tôi đưa ba lớp bảo vệ vào mọi job.

Chạy lại an toàn: mỗi lần nạp có thể lặp lại mà không nhân đôi dữ liệu, nhờ khóa hợp nhất, ghi đè theo phân vùng hoặc kiểm tra đã tồn tại, nên thử lại hay nạp lại lịch sử luôn an toàn.
Kiểm thử dữ liệu: độ mới, số dòng, tính duy nhất, giá trị rỗng và giá trị hợp lệ trên mọi mô hình, chạy cùng mỗi lần nạp bằng dbt test hoặc Great Expectations.
Cảnh báo và truy vết: lỗi và dữ liệu trễ được báo cho đúng người phụ trách, còn bản đồ truy vết cho biết bảng bị lỗi đang cấp dữ liệu cho dashboard nào.

Điểm chính: Biết job đã chạy là chưa đủ. Hãy kiểm tra thứ nó bàn giao.

04 / 06

Kho dữ liệu, data lake hay lakehouse?

Kho dữ liệu (BigQuery, Snowflake, Redshift) là đường nhanh nhất đến phân tích SQL đáng tin cậy. Data lake trên object storage (S3, Cloud Storage, Azure Blob) là nơi rẻ nhất để giữ lịch sử thô và bán cấu trúc. Lakehouse, như Databricks hoặc các định dạng bảng mở trên data lake, kết hợp cả hai khi khoa học dữ liệu và BI dùng chung dữ liệu.

Dù dùng nền tảng nào, chúng tôi tổ chức dữ liệu theo lớp, thô, đã làm sạch và sẵn sàng cho nghiệp vụ, thường gọi là bronze, silver và gold, để một nguồn lỗi không làm sai số liệu tài chính và lịch sử luôn xử lý lại được.

Điểm chính: Chọn nền tảng mà đội của bạn vận hành được và chi trả được. Cách phân lớp quan trọng hơn thương hiệu.

05 / 06

Có hiện đại hóa nền tảng cũ mà không cần viết lại không?

Có, và đó là cách duy nhất chúng tôi làm. Các dự án viết lại toàn bộ thường đình trệ vì nghiệp vụ vẫn thay đổi trong lúc nền tảng mới đang xây, còn hệ cũ vẫn phải chạy thêm nhiều tháng.

Chúng tôi chọn quy trình đang gây khó nhất, như khóa sổ tài chính chậm hay một dashboard không ai tin, xây lại lát cắt đó từ đầu đến cuối, chạy song song với job cũ và chỉ chuyển đổi khi đối soát đạt. Rồi đến lát cắt tiếp theo.

Điểm chính: Hiện đại hóa thành công khi mỗi lát cắt tắt được một phần hệ cũ. Phần hiện đại hóa bên dưới cho thấy một lát cắt chạy ra sao.

06 / 06

Tính phí thế nào và mất bao lâu?

Mỗi luồng dữ liệu được báo giá cố định sau buổi tư vấn miễn phí, trước khi bắt đầu xây dựng. Mức giá phụ thuộc vào số nguồn, logic biến đổi và độ trễ bạn cần; hiện đại hóa nền tảng dữ liệu được báo giá theo từng lát cắt.

Luồng dữ liệu đơn giản trên hạ tầng có sẵn chạy được sau 2 đến 3 tuần, nền tảng nhiều nguồn sau 4 đến 6 tuần, và lát cắt hiện đại hóa đầu tiên sau 6 đến 10 tuần.

Điểm chính: Giá và tiến độ được chốt sau một buổi khảo sát ngắn, trước khi bắt đầu xây dựng.

Chúng tôi triển khai như thế nào? Qua bốn giai đoạn bên dưới, do nhà sáng lập dẫn dắt từ cuộc trao đổi đầu tiên.

Đặt lịch tư vấn

Luồng dữ liệu đang vận hành

Bốn luồng dữ liệu khó nhất chúng tôi xây, từng bước một

Thanh toán được đối soát tới ngân hàng, tồn kho bán lẻ trên mọi cửa hàng và kênh bán, tìm khách hàng tiềm năng tới email cá nhân hóa, và dữ liệu y tế theo HIPAA. Mỗi sơ đồ dựa trên các dự án đã bàn giao, được nêu bên dưới: dữ liệu đến từ đâu, chuyện gì xảy ra ở từng bước và cuối cùng nằm ở đâu. Chọn một luồng, tạm dừng hoặc xem từng bước.

Google Cloud · hướng sự kiện · tài chính

Thanh toán được đối soát tới ngân hàng, trên Google Cloud

Sự kiện Stripe đến không theo thứ tự, được gửi lại và đôi khi đến hai lần. Luồng dữ liệu này nhận mỗi sự kiện đúng một lần, giữ sổ cái kép và khớp từng khoản thu với khoản chi trả, dòng sao kê ngân hàng và bút toán QuickBooks của nó.

Stripe

Shopify

File ngân hàng

QuickBooks

Nhận webhook

Pub/Sub

Job đồng bộ

Cloud Scheduler

Cloud Storage

BigQuery raw

dbt

Sổ cái

Đối soát

Mart doanh thu

Secret Manager

Cảnh báo

Ngoại lệ

Bút toán

Looker Studio

Agent tài chính

Một dịch vụ Cloud Run kiểm tra chữ ký của từng sự kiện Stripe và loại bản lặp theo khóa idempotency; Pub/Sub giữ sự kiện của từng tài khoản đúng thứ tự và giữ lại sự kiện lỗi trong dead-letter topic thay vì làm mất chúng.
- Stripe
- Nhận webhook
- Pub/Sub
Các job theo lịch lấy đơn hàng Shopify, file sao kê ngân hàng và tài khoản QuickBooks, đồng thời nạp nhiều năm lịch sử qua cơ chế phân trang của từng API mà không vượt giới hạn tần suất.
- Shopify
- File ngân hàng
- QuickBooks
- Job đồng bộ
- Cloud Scheduler
- Secret Manager
Mọi payload được lưu trữ đúng như khi nhận và nạp vào BigQuery không chỉnh sửa, nên mọi con số đều truy được về sự kiện tạo ra nó và mọi mô hình đều dựng lại được.
- Cloud Storage
- BigQuery raw
dbt biến sự kiện thô thành khoản thu, hoàn tiền, phí và chi trả sạch trong một mô hình có xử lý đa tiền tệ; kiểm thử chạy ở mỗi lần nạp, và lần nạp trễ hoặc lỗi sẽ phát cảnh báo trước khi có ai đọc phải số sai.
- dbt
- Cảnh báo
Mỗi dòng tiền được ghi hai lần, nợ và có, theo từng loại tiền, nên sổ luôn cân theo cấu trúc và một khoản hoàn tiền hay tranh chấp không bao giờ bị lẫn vào con số ròng.
- Sổ cái
Mỗi khoản thu được khớp với khoản chi trả chứa nó, và khoản chi trả được khớp với dòng sao kê ngân hàng; khoản nào chưa khớp được đưa vào hàng chờ Slack cho kế toán kèm bằng chứng, thay vì nằm trong bảng tính cuối tháng.
- Đối soát
- Ngoại lệ
Các mart MRR, tỷ lệ rời bỏ, phí và hoàn tiền cung cấp dữ liệu cho dashboard tài chính, và một agent tài chính trả lời câu hỏi từ chính các mart đó, kèm các dòng dữ liệu đã dùng.
- Mart doanh thu
- Looker Studio
- Agent tài chính
Bút toán tổng hợp hằng ngày được ghi ngược vào QuickBooks, nên kế toán chốt sổ tháng từ số liệu đã đối soát thay vì nhập lại thủ công.
- Bút toán

Mỗi sự kiện đúng một lần. Một dịch vụ Cloud Run kiểm tra chữ ký của từng sự kiện Stripe và loại bản lặp theo khóa idempotency; Pub/Sub giữ sự kiện của từng tài khoản đúng thứ tự và giữ lại sự kiện lỗi trong dead-letter topic thay vì làm mất chúng.

Dựa trên dự án đã bàn giao: các luồng dữ liệu Shopify, QuickBooks và Stripe cho một công ty phân tích, cùng phần thanh toán Stripe trong alice/ai, SeaSure và Graspr.

Cách chúng tôi xây nền tảng dữ liệu cho bạn

Bốn giai đoạn, mỗi giai đoạn kết thúc bằng thứ bạn kiểm tra được: phạm vi bằng văn bản, kiến trúc đã duyệt, một luồng dữ liệu chạy trên dữ liệu thật và một nền tảng đội của bạn tự vận hành.

01
Bước 01
Khảo sát và phân tích dữ liệu
Tuần 1
Chúng tôi liệt kê mọi nguồn, đích đến và mốc thời gian, rồi phân tích dữ liệu thật của bạn trước khi cam kết bất cứ điều gì.
Danh mục nguồn: hệ thống, khối lượng, cách cập nhật và quyền truy cập của từng nguồn
Phân tích dữ liệu: giá trị rỗng, trùng lặp, bản ghi trễ và thay đổi schema được phát hiện từ dữ liệu thật, không phải phỏng đoán
Phạm vi bằng văn bản: hạng mục bao gồm, tiến độ, rủi ro và giá cố định
Kết quả: tài liệu phạm vi bạn có thể mang đi hỏi bất kỳ đơn vị nào.
02
Bước 02
Kiến trúc và hợp đồng dữ liệu
Tuần 1 đến 2
Một trang kiến trúc và nhật ký quyết định cho từng lựa chọn công cụ, được duyệt trước khi tạo bất kỳ hạ tầng nào.
Sơ đồ kiến trúc: nguồn, các lớp dữ liệu, điều phối và nơi sử dụng
Nhật ký quyết định: vì sao chọn kho dữ liệu, công cụ điều phối và thu nạp này, chi phí vận hành của từng thứ
Hợp đồng dữ liệu: schema và độ mới mà mỗi bên sử dụng có thể tin cậy
03
Bước 03
Xây dựng theo từng phần
Tuần 2 đến 6
Tuần đầu tiên có một luồng dữ liệu chạy trọn vẹn trong môi trường phát triển; mỗi sprint sau đó thêm nguồn và mô hình.
Demo hằng tuần, toàn bộ mã nằm trong repository của bạn từ commit đầu tiên
Hạ tầng dạng mã (Terraform) ngay từ ngày đầu
Kiểm thử dbt và cảnh báo được viết cùng mô hình, không để sau
Kết quả: một luồng dữ liệu chạy trên dữ liệu của bạn ngay cuối tuần đầu tiên.
04
Bước 04
Kiểm chứng, vận hành và bàn giao
Nạp lại toàn bộ lịch sử và đối soát với nguồn, chạy song song nếu có hệ cũ, rồi chuyển đổi và bàn giao.
Nạp lại lịch sử, đối soát số dòng và tổng với từng nguồn
Chạy song song 5 đến 10 ngày làm việc trước khi chuyển đổi
Tài liệu vận hành, tài liệu truy vết nguồn gốc và video hướng dẫn
30 ngày hỗ trợ sau khi vận hành
Kết quả: báo cáo kiểm chứng bạn ký duyệt trước khi vận hành chính thức.

Script và cron job so với luồng dữ liệu production

Phần lớn đội ngũ bắt đầu bằng script. Chúng chạy tốt cho đến lần hỏng âm thầm đầu tiên, lần đổi schema đầu tiên hoặc khi kỹ sư viết ra chúng nghỉ việc. Đây là khác biệt chúng tôi xây vào hệ thống.

Tiêu chí

Script và cron jobChạy được cho đến khi hỏng

Luồng dữ liệu productionThứ chúng tôi xâyBáo lỗi rõ, chạy lại an toàn

Xử lý lỗi

Script và cron jobHỏng âm thầm; ai đó phát hiện dashboard không cập nhật

Luồng dữ liệu productionTự thử lại, rồi báo cho người phụ trách kèm bước bị lỗi

Chạy lại và nạp lịch sử

Script và cron jobChạy lại thì nhân đôi dữ liệu hoặc bỏ sót ngày

Luồng dữ liệu productionNgày nào cũng chạy lại được an toàn

Chất lượng dữ liệu

Script và cron jobKiểm tra bằng mắt, nếu có

Luồng dữ liệu productionKiểm thử độ mới, khối lượng, khóa và giá trị sau mỗi lần nạp

Thay đổi schema

Script và cron jobLàm hỏng job lúc nửa đêm

Luồng dữ liệu productionĐược hợp đồng dữ liệu chặn lại trước khi đến báo cáo

Khả năng quan sát

Script và cron jobLog nằm trên một máy chủ

Luồng dữ liệu productionLịch sử chạy, truy vết nguồn gốc và độ mới ở một nơi

Lịch sử dữ liệu

Script và cron jobBị ghi đè sau mỗi lần chạy

Luồng dữ liệu productionGiữ lịch sử thô, mô hình nào cũng dựng lại được

Quyền sở hữu

Script và cron jobNằm trong đầu một người

Luồng dữ liệu productionReview mã, tài liệu và hướng dẫn vận hành trong repository của bạn

Kiểm soát chi phí

Script và cron jobKéo lại toàn bộ dữ liệu mỗi lần chạy

Luồng dữ liệu productionNạp tăng dần, phân vùng và tài nguyên đúng cỡ

Bảo mật

Script và cron jobMật khẩu dán thẳng vào script

Luồng dữ liệu productionTrình quản lý bí mật, phân quyền tối thiểu, mã hóa

Sẵn sàng cho AI

Script và cron jobDữ liệu rải rác khắp các công cụ

Luồng dữ liệu productionBảng sạch, có tài liệu, để agent và mô hình truy vấn

Hiện đại hóa nền tảng dữ liệu

Hiện đại hóa nền tảng theo từng quy trình

Dịch vụ hiện đại hóa nền tảng dữ liệu cho ETL cũ, bộ lập lịch dễ hỏng và kho dữ liệu không theo kịp nhu cầu. Chúng tôi không bao giờ đề xuất viết lại toàn bộ trong một lần: mỗi lát cắt được xây lại, chạy song song và đối soát trước khi tắt bất cứ thứ gì.

Di chuyển theo giai đoạn · chạy song song

Một quy trình chuyển sang nền tảng mới, đường cũ vẫn chạy cho đến khi số liệu khớp

Mọi lát cắt của dự án hiện đại hóa đều theo cùng một cách: lập bản đồ, xây song song, đối soát, chuyển đổi, rồi tắt hệ cũ.

Hệ thống nguồnERP, CRM, file

Job cũCron, script SQL, SSIS

Bảng cũBáo cáo hiện đọc từ đây

Luồng dữ liệu mớiAirflow và dbt, có kiểm thử

Mô hình mớiStaging và marts

Đối soátSố dòng, tổng, khóa

Báo cáoTài chính, vận hành, HĐQT

Chúng tôi lần theo một quy trình từ đầu đến cuối, ví dụ khóa sổ tài chính cuối tháng: mọi nguồn, script, bảng và báo cáo liên quan, và ai đang phụ thuộc vào từng thứ.
- Hệ thống nguồn
- Job cũ
- Bảng cũ
- Báo cáo
Luồng dữ liệu mới được xây cạnh luồng cũ và đọc cùng nguồn, có kiểm thử, hợp đồng dữ liệu và truy vết nguồn gốc ngay từ mô hình đầu tiên.
- Luồng dữ liệu mới
- Mô hình mới
Cả hai luồng chạy hằng ngày. Số dòng, tổng và khóa được so sánh tự động, mọi chênh lệch đều được giải thích trước khi chuyển bất cứ thứ gì.
- Đối soát
Khi đối soát đạt yêu cầu trong khoảng thời gian đã thống nhất, báo cáo chuyển sang mô hình mới trong giờ làm việc, luồng cũ vẫn còn để quay lại nếu cần.
- Báo cáo
Chỉ khi đó job cũ mới được tắt. Một quy trình đã được hiện đại hóa, và lát cắt tiếp theo bắt đầu từ một hệ cũ nhỏ hơn.

Lập bản đồ lát cắt. Chúng tôi lần theo một quy trình từ đầu đến cuối, ví dụ khóa sổ tài chính cuối tháng: mọi nguồn, script, bảng và báo cáo liên quan, và ai đang phụ thuộc vào từng thứ.

Các lộ trình di chuyển chúng tôi thực hiện

Cron job và script PythonAirflow, Dagster hoặc Prefect
SSIS, Talend hoặc Informaticadbt với công cụ điều phối hiện đại
Airflow 1Airflow 2, có thử lại và kế hoạch nạp lịch sử
SQL Server hoặc MySQL tại chỗBigQuery, Snowflake hoặc Redshift
Báo cáo bằng bảng tính và SFTPKho dữ liệu với báo cáo theo lịch
TableauPower BI, bằng công cụ di chuyển chúng tôi xây có kiểm tra đầu ra

Những thứ một đợt di chuyển không bao giờ được làm hỏng

Báo cáo mà tài chính, vận hành hoặc hội đồng quản trị dùng mỗi tuần
Luồng dữ liệu cấp cho sản phẩm khách hàng dùng hoặc cam kết SLA bên ngoài
Luồng dữ liệu chịu ràng buộc tuân thủ và dấu vết kiểm toán của chúng
Các số liệu đã báo cáo, nền tảng mới phải tái tạo đúng
Quy tắc phân quyền và che dữ liệu đã thống nhất với đội bảo mật
Trần chi phí của nền tảng mới, được kiểm tra trước khi chuyển đổi

Chỉ chuyển đổi khi số liệu khớp trong khoảng thời gian đã thống nhất, không bao giờ theo một ngày ấn định trên lịch.

Đặt lịch tư vấn

Tran Tien Van, nhà sáng lập Van Data Team

Dấu hiệu cảnh báo

Dấu hiệu nền tảng dữ liệu đang tốn kém hơn mức cần thiết

Nếu bạn thấy quen với từ hai dấu hiệu trở lên, vấn đề thường nằm ở lớp luồng dữ liệu, không phải ở những người dùng dữ liệu.

01Hai dashboard cho ra hai con số khác nhau cho cùng một chỉ số, và không ai biết số nào đúng.
02Bạn chỉ biết luồng dữ liệu bị hỏng khi có người hỏi vì sao báo cáo hôm qua trống.
03Thêm một nguồn dữ liệu mới mất nhiều tuần và cần một kỹ sư thật dũng cảm.
04Các script cron cũ chạy những báo cáo quan trọng và không ai dám động vào.
05Hóa đơn kho dữ liệu tăng nhanh hơn cả dữ liệu lẫn đội ngũ.
06Dự án AI hoặc phân tích bị kẹt vì chờ dữ liệu sạch.

Nếu bạn đang gặp bất kỳ dấu hiệu nào ở trên, hãy cùng trao đổi.

Đặt lịch tư vấn

Dự án kỹ thuật dữ liệu

Những luồng dữ liệu chúng tôi đã xây và các con số phía sau

Mọi dự án ở đây đều đã được bàn giao. Khách hàng được giữ kín tên trừ khi đã được nêu tên ở nơi khác trên trang này, và mọi con số đều lấy từ chính dữ liệu của dự án.

Chu kỳ thu nạp của luồng dữ liệu thị trường điện: 5 phút
Nguồn dữ liệu nhà cung cấp hợp nhất trong một nền tảng BigQuery: 81
Cho đợt nạp 5 năm dữ liệu từng mất khoảng 10 ngày: Vài giờ

Thị trường năng lượng300 kỳ điều độ × 5 vùng

Thị trường điện bán buôn NEM: theo dõi điều độ

Kỳ điều độ: 300; 8 đến 11/11/2022
Giá giao ngay trung bình: $81; mỗi MWh, dao động −⁠$65 đến $196
Kỳ giá âm: 24; 8% của giai đoạn
Nhu cầu đỉnh: 8.354 MW; NSW1, gấp 6,9 lần vùng nhỏ nhất

00-0404-0808-1212-1616-2020-24NSW11211176078128111QLD1110892282154118VIC14481143914577SA1876816−5123107TAS16680323111487

Câu trả lờiSA1, từ 12:00 đến 16:00

Dựng cho portfolio từ dữ liệu đã bàn giao

Nhóm phân tích thị trường năng lượngDự án khách hàng

Thị trường năng lượng

Pipeline thị trường điện thời gian thực trên AWS

Pipeline AWS Lambda chạy theo lịch lấy từng báo cáo điều độ trên NEMWeb mỗi 5 phút, lưu file vào S3, ghi 19 chỉ số điều độ của từng vùng vào DynamoDB và cấp dữ liệu cho ứng dụng Plotly Dash để chuyên viên phân tích so sánh giữa các vùng.

tần suất nạp dữ liệu: 5 phút
chỉ số điều độ trên 5 vùng thị trường: 19

AWS Lambda · CloudWatch · Amazon S3 · DynamoDB · Plotly Dash

Đọc case study

Phân tích mạng xã hội

Giám sát người theo dõi Twitter/X ở quy mô lớn

Khách hàng phân tích mạng xã hộiDự án khách hàng

30.000+

hồ sơ được theo dõi mỗi ngày

Thương mại điện tử

Danh mục phần cứng IT B2B kèm mô tả đã dịch

Khách hàng thương mại điện tửDự án khách hàng

72.685

SKU trên 319 thương hiệu

Nghiên cứu ESG

Dữ liệu bảng nghiên cứu ESG từ LinkedIn

Nhóm nghiên cứu định lượngDự án khách hàng

1,4 triệu

bài đăng của nhân viên được chấm điểm E, S, G

Nghiên cứu học thuật

Bộ dữ liệu bài nghiên cứu và tác giả SSRN

Khách hàng nghiên cứu học thuậtDự án khách hàng

239.037

bài báo đã bàn giao, 43 trường mỗi bài

Thêm các luồng dữ liệu đang vận hành

Các dự án tập trung vào thu nạp, kho dữ liệu và di chuyển hệ thống. Khách hàng được giữ kín tên; công nghệ là những gì đã thực sự triển khai.

ETL dữ liệu bảo hiểm y tế trên AWS
Airflow và Glue đưa hồ sơ thành viên, yêu cầu bồi thường và nhà cung cấp ở bốn định dạng vào Athena, mỗi lần nạp đều có nhật ký kiểm toán theo cột.
Airflow · AWS Glue · Athena · S3
Trung tâm dữ liệu Shopify nhiều khách hàng
Bốn dịch vụ Cloud Run và danh bạ khách hàng trên Firestore; đợt nạp 5 năm dữ liệu giảm từ khoảng 10 ngày xuống vài giờ.
Cloud Run · BigQuery · Firestore · Pub/Sub
KPI bán hàng từ Slack
Claude Haiku chuyển tin nhắn Slack thành các dòng KPI đã kiểm tra trong BigQuery, trên các job chỉ tính phí khi đang chạy.
Cloud Run Jobs · BigQuery · Claude Haiku
ETL quảng cáo đa kênh trên Airflow
Năm nền tảng quảng cáo trong một hệ Airflow chạy Docker, nạp vào Snowflake bằng MERGE nên không bao giờ nhân đôi dữ liệu khi thử lại.
Airflow · Snowflake · Azure SQL · Docker
Data lake dữ liệu chứng khoán Mỹ
Hơn 15 endpoint của Polygon.io vào S3 phân vùng kiểu Hive, mô hình hóa bằng dbt trên Athena và kiểm thử theo từng chỉ báo.
S3 · dbt · Athena · Python
Kho KPI chương trình khách hàng thân thiết
Từ SFTP vào Cloud Storage rồi BigQuery, so sánh theo tháng, năm và cùng kỳ năm trước, xuất ra Excel, Google Sheets và Streamlit.
BigQuery · Cloud Run · Streamlit
Trung tâm dữ liệu marketing đa nền tảng
Hơn 30 kết nối Cloud Function cho công cụ quảng cáo, CRM, thương mại điện tử và tài chính, tính phí theo lượt chạy nên nguồn không dùng không tốn tiền.
Cloud Functions · Cloud Storage · BigQuery
Công cụ chuyển Tableau sang Power BI
Đọc workbook và dữ liệu trích xuất của Tableau, chuyển thành định nghĩa Power BI và kiểm tra đầu ra theo schema.
Python · Tableau REST API · Power BI

Đặt lịch tư vấn Xem tất cả case study

Khách hàng nói gì về các dự án kỹ thuật dữ liệu của chúng tôi

Các đội ngũ tìm đến chúng tôi cho AI agent, thu thập dữ liệu web, nền tảng dữ liệu, báo cáo và hạ tầng đám mây. Đánh giá đã xác minh của họ nói lên cách chúng tôi làm việc: kỹ sư giàu kinh nghiệm, founder trực tiếp dẫn dắt, từ bản thử nghiệm đến vận hành.

Đã xác minh trên Upwork

5.0

71 đánh giá của khách hàng · 69 đánh giá năm sao

5 sao69
4 sao2
3 sao0
2 sao0
1 sao0

Xem đánh giá trên Upwork

CK

Chris K.

30/12/2025

“Lập trình viên backend rất giỏi, rất đáng để giới thiệu!”

Giai đoạn 2 của nền tảng FT