Skalowanie firmowej infrastruktury danych: framework dla ponad 300 źródeł

Problem

Dane firmy znajdowały się w ponad 300 różnych systemach, między innymi w Veeva, SAP, Salesforce, Oracle i PubMed. Pobierano je ręcznie, a takich procesów nie dało się skalować. Dane leżały w silosach, nie zawsze zgadzały się między systemami i przybywało ich szybciej, niż radziły sobie z tym tradycyjne metody ETL.

Firma potrzebowała jednej centralnej platformy: zautomatyzowanej i skalowalnej, która pobierze, przetworzy i udostępni ponad 70 TB danych, zachowując nad nimi ścisły nadzór i czytelny ślad audytowy.

Podejście

Nie zaczęliśmy od 300 konektorów. Zaczęliśmy od frameworku. Każde źródło jest opisane w metadanych (jak się do niego dostać, co pobrać, jak często i dokąd to trafia), a framework robi resztę w ten sam sposób dla każdego źródła.

Prace przebiegały w dwóch fazach:

1. Pobranie danych. Jedna standardowa ścieżka dla każdego źródła, niezależnie od tego, czy komunikuje się ono przez API, SFTP czy JDBC. Dane zawsze trafiają do data lake w AWS S3.
2. Przetworzenie danych. Transformacje pod kontrolą wersji, napisane w dbt i uruchamiane w Amazon Redshift, tak, żeby każda zmiana w wyliczeniach podlegała weryfikacji i była łatwa do prześledzenia.

Przeczytaj diagram jako tekst

1. Jeden pipeline na źródło: Źródło 1: własny pipeline, potem Źródło 2: własny pipeline, potem I tak dalej, ponad 300 razy. Każdą poprawkę trzeba wprowadzić w każdym pipeline'ie.
2. najpierw framework
3. Jeden framework: Jeden rekord metadanych na źródło, potem Wspólne loadery: API, SFTP, JDBC, potem Jeden lake i jeden sposób pracy dla każdego źródła. Nowe źródło to nowy rekord, a nie nowy projekt.

Metodę w całości opisuje przewodnik Data ingestion at scale: a metadata-driven framework for hundreds of sources (po angielsku).

Wdrożenie

Przeczytaj diagram jako tekst

1. Ponad 300 źródeł: Veeva, SAP, Salesforce, Oracle, PubMed i inne, dostępne przez API, SFTP lub JDBC
2. Metadane: opis każdego źródła, czytany przez framework
3. Framework do pobierania danych: jeden silnik, który podłącza każde źródło przy minimalnej ręcznej konfiguracji
4. Data lake w S3: dane surowe, potem oczyszczone, potem zintegrowane, więc pochodzenie danych jest jasne
5. Modele dbt w Redshift: modułowe transformacje SQL, które da się testować
6. Analityka: Tableau, ThoughtSpot i Google Sheets, korzystające z jednego źródła prawdy
7. Pod każdym etapem: Argo Workflows na Kubernetes: orkiestracja: skalowalne przetwarzanie w kontenerach
8. Pod każdym etapem: AWS CDK: infrastruktura jako kod: powtarzalne środowiska pod kontrolą wersji
9. Pod każdym etapem: GitLab CI/CD z botami AI: automatyczne wdrożenia; boty do przeglądu merge requestów, wydań i obsługi incydentów

Co zbudowaliśmy i co każdy z tych elementów daje klientowi:

• Własny framework do pobierania danych. Silnik sterowany metadanymi, który podłącza ponad 300 źródeł przy minimalnej ręcznej konfiguracji.
• Wielowarstwowy data lake na AWS. Warstwy surowa, oczyszczona i zintegrowana w S3, więc wiadomo, skąd pochodzą dane.
• Orkiestracja i moc obliczeniowa. Argo Workflows i Kubernetes do skalowalnego przetwarzania w kontenerach.
• Warstwa transformacji. dbt Cloud do modułowego, testowalnego SQL w Amazon Redshift.
• Infrastruktura jako kod. AWS CDK, dzięki czemu infrastruktura jest powtarzalna, a każda zmiana wersjonowana.
• CI/CD. GitLab do kodu i automatycznych wdrożeń, z botami AI do przeglądu merge requestów, procesu wydań i proaktywnej obsługi incydentów.

Efekt

podłączonych i obsługiwanych źródeł danych

300+

danych firmowych, z wysoką dostępnością

70+ TB

czas podłączenia źródła

Z tygodni do dni

• Skala. Podłączyliśmy i obsługujemy ponad 300 różnych źródeł danych.
• Wolumen. Platforma obsługująca ponad 70 TB danych firmowych z wysoką dostępnością.
• Szybkość. Czas podłączania nowego źródła spadł z tygodni do dni dzięki autorskiemu frameworkowi.
• Zaufanie. Jedno źródło prawdy dla globalnej analityki, z którego zespoły korzystają w Tableau, ThoughtSpot i Google Sheets.

Wnioski

Skala bierze się z lepszych abstrakcji, a nie z większych serwerów. Własny framework zamiast pojedynczych pipeline’ów pozwolił zlikwidować wąskie gardło przy obsłudze 300 źródeł i stworzyć powtarzalny, zautomatyzowany system.

Jeśli masz więcej źródeł, niż Twój zespół jest w stanie obsłużyć, umów rozmowę, a sprawdzimy, czy wdrożenie takiego rozwiązania by się u Ciebie zwróciło.

Technologie

AWS, CDK, Python, dbt, Redshift, Argo Workflows, Kubernetes, GitLab CI/CD

Rodzaj

Strategia i wdrożenie

• data-engineering
• aws
• redshift
• dbt
• kubernetes
• automation
• enterprise-data
• ingestion-framework