@Jean-LafleurJohna Lafleura

Współzałożyciel Airbyte.io, nowego standardu integracji danych open source

W ciągu ostatniego roku nasz zespół przeprowadził wywiady z ponad 200 firmami na temat ich przypadków użycia w zakresie integracji danych. Odkryliśmy, że integracja danych w 2021 r. to nadal bałagan.  

Obecna sytuacja, której nie można skalować

Co najmniej 80 z 200 wywiadów przeprowadzono z użytkownikami istniejącej technologii ETL, takiej jak Fivetran, StitchData i Matillion. Odkryliśmy, że każdy z nich również budował i utrzymywał własne konektory, mimo że korzystał z rozwiązania ETL (lub ELT – dla uproszczenia użyję tylko terminu ETL). Dlaczego?

Znaleźliśmy dwa powody: 

1. Niepełne pokrycie złączy
2. Znaczne tarcia wokół replikacji bazy danych

Niemożność zaspokojenia wszystkich potrzeb złączy

Rozwiązanie ETL wielu użytkowników nie obsługiwało pożądanego łącznika lub obsługiwało go, ale nie w sposób, w jaki tego potrzebował.  

Przykład kontekstowy: Fivetran istnieje od ośmiu lat i obsługuje 150 złączy. Jednak tylko w dwóch sektorach — martech i adtech — istnieje ponad 10,000 XNUMX potencjalnych złączy. 

Najtrudniejszą częścią ETL nie jest budowanie złączy, ale ich utrzymanie. Jest to kosztowne, a każde rozwiązanie o zamkniętym kodzie źródłowym jest ograniczone względami ROI (zwrotu z inwestycji). W efekcie dostawcy ETL skupiają się na najpopularniejszych integracjach, jednak firmy z miesiąca na miesiąc wykorzystują coraz więcej narzędzi, a długi ogon konektorów jest ignorowany. 

Tak więc nawet przy użyciu narzędzi ETL zespoły danych nadal inwestują ogromne pieniądze i czas w tworzenie i konserwację wewnętrznych łączników. 

Brak możliwości rozwiązania przypadku użycia replikacji bazy danych

Większość firm przechowuje dane w bazach danych. Nasze wywiady ujawniły dwa istotne problemy ze złączami baz danych dostarczanymi przez istniejący ETL. 

1. Ceny oparte na wolumenie: Bazy danych są ogromne i obsługują coraz większe ilości danych. Baza danych zawierająca miliony wierszy, której celem jest obsługa setek milionów wierszy, to powszechny widok. Problemem w obecnych rozwiązaniach ETL jest ich wycena oparta na wolumenie. Pracownikowi łatwo jest zreplikować wielomilionową bazę danych jednym kliknięciem. A to proste kliknięcie może kosztować kilka tysięcy dolarów! 
2. Prywatność danych: W obliczu dzisiejszych obaw o prywatność i bezpieczeństwo, firmy przywiązują coraz większą wagę do kontroli swoich danych. . Architektura istniejących rozwiązań ETL często kończy się pobieraniem danych z prywatnej chmury firmy. Oferty z zamkniętym kodem źródłowym uniemożliwiają firmom ścisłą kontrolę bazowego kodu/systemów ETL. Mniejsza widoczność oznacza mniejsze zaufanie
    

Oba te punkty wyjaśniają, dlaczego firmy ostatecznie budują dodatkowe wewnętrzne potoki replikacji baz danych.

Brak możliwości skalowania z danymi

Wspomniane powyżej dwa punkty dotyczące cen opartych na ilości i prywatności danych mają również zastosowanie w przypadku skalowania firmy. Dla firm taniej staje się posiadanie wewnętrznego zespołu inżynierów danych do budowania tych samych potoków, które są utrzymywane w rozwiązaniach ETL. 

Dlaczego Open Source to jedyna droga naprzód

Oprogramowanie typu open source rozwiązuje wiele kwestii poruszonych powyżej. Oto, co daje nam open source.

• Prawo do dostosowania: Posiadanie dostępu i możliwość edytowania kodu zgodnie z własnymi potrzebami to przywilej, który daje open-source. Na przykład, co jeśli w łączniku Salesforce brakuje niektórych potrzebnych danych? W przypadku open source taka zmiana jest tak prosta, jak przesłanie zmiany kodu. Nigdy więcej długich wątków na zgłoszeniach do pomocy technicznej!
• Adresowanie długiego ogona złączy: Nie musisz już przekonywać zastrzeżonego dostawcy ETL, że warto zbudować złącze, którego potrzebujesz. Jeśli potrzebujesz łącznika szybciej niż platforma go opracuje, możesz go zbudować samodzielnie i utrzymywać przy pomocy dużej społeczności użytkowników.
• Szersze integracje z narzędziami danych i przepływami pracy: Ponieważ produkt typu open source musi obsługiwać szeroką gamę stosów i przepływów pracy na potrzeby orkiestracji, wdrażania, hostingu itp., istnieje większe prawdopodobieństwo, że znajdziesz gotową obsługę stosu danych i przepływu pracy (opartego na interfejsie użytkownika, interfejsie API oparte na CLI itp.) ze społecznością open source. Niektóre z nich, jak na przykład operator Airflow typu open source firmy Airbyte, są tworzone przez społeczność dyskusyjną. Aby być uczciwym, teoretycznie możesz to zrobić z podejściem o zamkniętym kodzie źródłowym, ale prawdopodobnie będziesz musiał zbudować wiele narzędzi od zera.
• Autonomia debugowania: Jeśli wystąpią jakiekolwiek problemy z łącznikiem, nie będziesz musiał czekać, aż zespół obsługi klienta skontaktuje się z Tobą lub Twoja poprawka znajdzie się na szczycie priorytetów firmy zewnętrznej. Możesz sam rozwiązać problem.
• Niestandardowe zabezpieczenia i zgodność z prywatnością. Jeśli projekt open source jest wystarczająco otwarty (MIT, Apache 2.0 itp.), każdy zespół może bezpośrednio zaspokoić swoje potrzeby integracyjne, wdrażając kod open source w swojej infrastrukturze.

Konieczność zestawu rozwojowego złącza

Jednak samo oprogramowanie open source nie wystarcza do rozwiązania problemu integracji danych. Dzieje się tak, ponieważ bariera wejścia do tworzenia solidnego i w pełni funkcjonalnego łącznika jest zbyt wysoka. 

Rozważmy na przykład skrypt, który pobiera dane z interfejsu API REST. 

Koncepcyjnie jest to proste zapytanie `SELECT * FROM entity` dotyczące niektórych danych znajdujących się w bazie danych, potencjalnie z klauzulą ​​`WHERE` do filtrowania według pewnych kryteriów. Ale każdy, kto napisał skrypt lub łącznik, aby stale i niezawodnie wykonywać to zadanie, wie, że jest to nieco bardziej skomplikowane. 

Po pierwsze, istnieje uwierzytelnianie, które może być tak proste, jak nazwa użytkownika/hasło, lub tak skomplikowane, jak wdrożenie całego przepływu OAuth (oraz bezpieczne przechowywanie tych danych uwierzytelniających i zarządzanie nimi). 

Musimy również utrzymywać stan między uruchomieniami skryptu, aby nie odczytywać w kółko tych samych danych. 

Następnie będziemy musieli zająć się ograniczaniem szybkości i ponawiać sporadyczne błędy, upewniając się, że nie pomylimy ich z prawdziwymi błędami, których nie można powtórzyć. 

Następnie będziemy chcieli przekształcić dane do formatu odpowiedniego dla dalszych konsumentów, jednocześnie wykonując wystarczająco dużo rejestrowania, aby rozwiązać problemy, gdy coś nieuchronnie się zepsuje. 

Aha, i wszystko to musi być dobrze przetestowane, łatwe do wdrożenia… i oczywiście zrobione wczoraj.

Podsumowując, obecnie zbudowanie nowego łącznika źródłowego interfejsu API REST zajmuje kilka pełnych dni. Ta bariera wejścia oznacza nie tylko mniej złączy tworzonych przez społeczność, ale często może oznaczać złącza niższej jakości. 

Uważamy jednak, że 80% tych trudności jest przypadkowych i można je w większości zautomatyzować. Skrócenie czasu implementacji znacznie pomogłoby społeczności wnieść wkład i rozwiązać problem długiego ogona łączników. Jeśli ta automatyzacja zostanie wykonana w inteligentny sposób, możemy również poprawić standaryzację, a tym samym konserwację wszystkich wniesionych łączników. 

Jak wygląda zestaw rozwojowy złącza

Przyjrzyjmy się jeszcze raz pracy związanej z budowaniem łącznika, ale z innej perspektywy.

Przypadkowa złożoność

• Konfigurowanie struktury pakietu
• Pakowanie złącza w kontenerze Docker i konfigurowanie potoku uwalniania

Wiele powtarzającej się logiki:

• Wymyślanie na nowo tych samych wzorców projektowych i struktury kodu dla każdego typu łącznika (interfejsy API REST, bazy danych, magazyny, jeziora itp.) 
• Pisanie tych samych pomocników do przekształcania danych do standardowego formatu, implementowania synchronizacji przyrostowej, rejestrowania, sprawdzania poprawności danych wejściowych itp.
• Testowanie, czy łącznik prawidłowo przestrzega protokołu.

Testowanie szczęśliwe przepływy i krawędziowe przypadki

Widać, że wiele można zautomatyzować, i z przyjemnością dowiesz się, że Airbyte udostępnił Open Source Connector Development Kit (CDK), aby to wszystko zrobić. 

Wierzymy w końcu, droga do budowa tysięcy wysokiej jakości złączy to myślenie warstwami cebuli. Aby zrobić paralelę z zwierzę/bydło koncepcja, która jest dobrze znana w DevOps/Infrastructure, łącznik to kod bydła i chcesz poświęcić mu jak najmniej czasu. To znacznie przyspieszy produktywność.

Abstrakcje jako warstwy cebuli

Maksymalizacja pracy przy wysokim lewarowaniu prowadzi do zbudowania architektury o strukturze cebuli:

Centrum definiuje najniższy poziom API. Implementacja łącznika na tym poziomie wymaga dużo czasu inżynieryjnego. Ale to jest twój właz ewakuacyjny do bardzo złożonych złączy, w których potrzebujesz dużej kontroli.

Następnie budujesz nowe warstwy abstrakcji, które pomagają bardzo szybko radzić sobie z rodzinami złączy. Na przykład źródła mają określony interfejs, a miejsca docelowe mają inny rodzaj interfejsu. 

Następnie dla źródeł masz różne rodzaje, takie jak łączniki oparte na HTTP-API i bazy danych. Łączniki HTTP mogą być podzielone na REST, GraphQL i SOAP, podczas gdy bazy danych mogą zostać podzielone na relacyjne, NoSQL i wykresy. Miejsca docelowe mogą być podzielone na magazyny, jeziora danych i interfejsy API (w przypadku odwrotnego ELT). 

CDK jest szkieletem dla tych abstrakcji!

Co jest już dostępne

CDK Airbyte jest wciąż na początku, więc spodziewaj się wielu ulepszeń, które pojawią się z czasem. Obecnie platforma jest dostarczana z następującymi funkcjami: 

1. Framework Pythona do pisania konektorów źródłowych 
2. Ogólna implementacja szybko rozwijających się łączników dla interfejsów API HTTP
3. Zestaw testów do testowania zgodności z protokołem Airbyte i szczęśliwymi ścieżkami kodu 
4. Generator kodu do ładowania początkowego programowania i pakowania Twojego łącznika

Ostatecznie CDK umożliwia budowanie solidnych, w pełni funkcjonalnych złączy w ciągu 2 godzin w porównaniu z 2 dniami wcześniej. 

Zespół Airbyte używa tego frameworka wewnętrznie do opracowywania złączy i jest to kulminacja naszego doświadczenia w tworzeniu ponad 70 złączy (naszym celem jest 200 do końca roku z pomocą społeczności użytkowników!). Wszystko, czego uczymy się z własnego doświadczenia, wraz ze społecznością użytkowników, idzie na ulepszanie CDK.

Wniosek – przyszłość przed nami 

Czy nie byłoby wspaniale skrócić czas potrzebny na zbudowanie nowego łącznika do 10 minut i objąć nim coraz więcej rodzin możliwych integracji. Jak to na księżycowy strzał! 

Jeśli uda nam się to zrobić razem z naszą społecznością użytkowników, to w końcu długi ogon integracji zostanie rozwiązany w mgnieniu oka! Nie wspominając o tym, że potoki integracji danych będą utowarowione przez open-source 

Jeśli chcesz się zaangażować, mamy nadzieję, że dołączysz do naszego Społeczność Slacka – najbardziej aktywny wokół integracji danych – ponieważ łączymy się z przyszłością open source z korzyścią dla wszystkich!

Opublikowano również: https://airbyte.io/blog/why-etl-needs-open-source-to-address-the-long-tail-of-integrations

PlatonAi. Nowa koncepcja sieci Web3. Wzmocniona analiza danych.

Kliknij tutaj, aby uzyskać dostęp.

Źródło: https://hackernoon.com/open-source-is-the-only-way-to-address-the-long-tail-of-integrations-7028376x?source=rss