Żyjemy w niesamowitych czasach, kiedy można szybko i łatwo podłączyć kilka gotowych narzędzi open source, ustawić je z „wyłączoną świadomością” zgodnie z radą stackoverflow, bez zagłębiania się w „wiele liter” i uruchomić ich do działalności komercyjnej. A kiedy trzeba zaktualizować/rozbudować lub ktoś przypadkowo restartuje kilka maszyn - zdajesz sobie sprawę, że zaczął się jakiś obsesyjny zły sen, wszystko stało się dramatycznie skomplikowane nie do poznania, nie ma odwrotu, przyszłość jest niejasna i bezpieczniejsza, zamiast programować hoduj pszczoły i rób sery.
Nie bez powodu bardziej doświadczeni koledzy, z głowami usianymi błędami i przez to już szarymi, zastanawiają się nad niesamowicie szybkim rozmieszczeniem paczek „kontenerów” w „kostkach” na dziesiątkach serwerów w „modnych językach” z wbudowaną obsługą asynchroniczne, nieblokujące wejścia/wyjścia, uśmiechaj się skromnie. I w milczeniu nadal ponownie czytają „man ps”, zagłębiają się w kod źródłowy „nginx”, aż oczy im krwawią, i piszą, piszą, piszą testy jednostkowe. Koledzy wiedzą, że najciekawsze będzie, gdy „to wszystko” pewnego dnia zostanie postawione w noc sylwestrową. Pomoże im jedynie głębokie zrozumienie natury Uniksa, zapamiętanej tabeli stanów TCP/IP i podstawowych algorytmów sortowania i wyszukiwania. Aby przywrócić system do życia po uderzeniu dzwonka.
Oj, trochę się rozkojarzyłam, ale mam nadzieję, że udało mi się oddać stan oczekiwania.
Dziś chcę podzielić się naszym doświadczeniem we wdrożeniu wygodnego i niedrogiego stosu dla DataLake, który rozwiązuje większość zadań analitycznych w firmie dla zupełnie innych działów strukturalnych.
Jakiś czas temu doszliśmy do wniosku, że firmom coraz bardziej potrzebne są owoce zarówno analityki produktowej, jak i technicznej (nie mówiąc już o wisience na torcie w postaci uczenia maszynowego) oraz zrozumienia trendów i zagrożeń – musimy zbierać i analizować coraz więcej wskaźników.
Podstawowa analityka techniczna w Bitrix24
Kilka lat temu, równolegle z uruchomieniem usługi Bitrix24, aktywnie inwestowaliśmy czas i zasoby w stworzenie prostej i niezawodnej platformy analitycznej, która pomogłaby szybko dostrzec problemy w infrastrukturze i zaplanować kolejny krok. Oczywiście wskazane było skorzystanie z gotowych narzędzi, które były możliwie proste i zrozumiałe. W rezultacie wybrano nagios do monitorowania, a munin do analityki i wizualizacji. Teraz mamy tysiące czeków w nagios, setki wykresów w munin, a nasi koledzy z powodzeniem korzystają z nich na co dzień. Metryki są jasne, wykresy przejrzyste, system działa niezawodnie od kilku lat i regularnie dodawane są do niego nowe testy i wykresy: uruchamiając nową usługę, dodajemy kilka testów i wykresów. Powodzenia.
Trzymaj rękę na pulsie – zaawansowana analityka techniczna
Chęć otrzymywania informacji o problemach „jak najszybciej” skłoniła nas do aktywnych eksperymentów z prostymi i zrozumiałymi narzędziami - pinba i xhprof.
Pinba przesłała nam w pakietach UDP statystyki dotyczące szybkości działania części stron internetowych w PHP, a my mogliśmy zobaczyć online w pamięci MySQL (Pinba posiada własny silnik MySQL do szybkiej analizy zdarzeń) krótką listę problemów i odpowiedzieć na ich. A xhprof automatycznie pozwolił nam zebrać wykresy wykonania najwolniejszych stron PHP od klientów i przeanalizować, co może do tego doprowadzić - spokojnie, nalewając herbatę lub coś mocniejszego.
Jakiś czas temu zestaw narzędzi został uzupełniony o kolejny dość prosty i zrozumiały silnik oparty na algorytmie indeksowania odwrotnego, doskonale zaimplementowany w legendarnej bibliotece Lucene – Elastic/Kibana. Prosty pomysł wielowątkowego zapisywania dokumentów do odwrotnego indeksu Lucene na podstawie zdarzeń w logach i szybkiego ich przeszukiwania za pomocą podziału fasetowego okazał się naprawdę przydatny.
Pomimo dość technicznego wyglądu wizualizacji w Kibanie z niskopoziomowymi koncepcjami typu „wiadro” „płynące w górę” i wymyślonym na nowo językiem nie do końca zapomnianej algebry relacyjnej, narzędzie zaczęło nam dobrze pomagać w następujących zadaniach:
- Ile błędów PHP miał klient Bitrix24 na portalu p1 w ciągu ostatniej godziny i jakie? Zrozum, wybacz i szybko popraw.
- Ile rozmów wideo odbyło się na portalach w Niemczech w ciągu ostatnich 24 godzin, w jakiej jakości i czy były jakieś problemy z kanałem/siecią?
- Jak dobrze działa funkcjonalność systemu (nasze rozszerzenie C dla PHP), skompilowana ze źródeł w najnowszej aktualizacji usługi i wdrożona dla klientów? Czy występują segfaulty?
- Czy dane klienta mieszczą się w pamięci PHP? Czy są jakieś błędy dotyczące przekroczenia pamięci przydzielonej procesom: „brak pamięci”? Znajdź i zneutralizuj.
Oto konkretny przykład. Pomimo dokładnych i wielopoziomowych testów klient, z bardzo niestandardową obudową i uszkodzonymi danymi wejściowymi, otrzymał irytujący i nieoczekiwany błąd, zawyła syrena i rozpoczął się proces jego szybkiej naprawy:
Dodatkowo kibana pozwala organizować powiadomienia o określonych zdarzeniach i w krótkim czasie z narzędzia w firmie zaczęło korzystać kilkudziesięciu pracowników z różnych działów - od wsparcia technicznego i rozwoju po QA.
Aktywność dowolnego działu w firmie stała się wygodna do śledzenia i mierzenia – zamiast ręcznie analizować logi na serwerach, wystarczy raz skonfigurować parsowanie logów i wysłać je do klastra elastycznego, aby cieszyć się np. kontemplacją w kibanie dashboard liczba sprzedanych dwugłowych kociąt wydrukowanych na drukarce 3D za ostatni miesiąc księżycowy.
Podstawowa analityka biznesowa
Każdy wie, że analityka biznesowa w firmach często zaczyna się od niezwykle aktywnego wykorzystania, owszem, Excela. Ale najważniejsze jest to, że to nie koniec. Oparte na chmurze Google Analytics również dolewa oliwy do ognia – szybko zaczynasz przyzwyczajać się do dobrych rzeczy.
W naszej harmonijnie rozwijającej się firmie gdzieniegdzie zaczęli pojawiać się „prorocy” intensywniejszej pracy z większymi danymi. Regularnie zaczęła pojawiać się potrzeba tworzenia bardziej szczegółowych i wieloaspektowych raportów i dzięki staraniom ludzi z różnych działów, jakiś czas temu powstało proste i praktyczne rozwiązanie - połączenie ClickHouse i PowerBI.
Przez dłuższy czas to elastyczne rozwiązanie bardzo pomagało, jednak stopniowo zaczęło przychodzić do głowy zrozumienie, że ClickHouse nie jest gumowy i nie można z niego tak żartować.
Tutaj ważne jest, aby dobrze zrozumieć, że ClickHouse, podobnie jak Druid, jak Vertica, jak Amazon RedShift (który jest oparty na postgresie), są silnikami analitycznymi zoptymalizowanymi pod kątem w miarę wygodnej analityki (sumy, agregacje, minimum-maksimum według kolumny i kilka możliwych złączeń ), ponieważ zorganizowane w celu wydajnego przechowywania kolumn tabel relacyjnych, w przeciwieństwie do MySQL i innych znanych nam (wierszowych) baz danych.
W istocie ClickHouse to po prostu bardziej pojemna „baza danych”, z niezbyt wygodnym wstawianiem punkt po punkcie (tak to ma wyglądać, wszystko jest w porządku), ale przyjemną analityką i zestawem ciekawych, potężnych funkcji do pracy z danymi. Tak, można nawet stworzyć klaster - ale rozumie się, że wbijanie gwoździ pod mikroskopem nie jest do końca poprawne i zaczęliśmy szukać innych rozwiązań.
Zapotrzebowanie na Pythona i analityków
W naszej firmie jest wielu programistów, którzy od 10-20 lat piszą kod niemal codziennie w językach PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. Jest też wielu doświadczonych administratorów systemów, którzy doświadczyli niejednej absolutnie niesamowitej katastrofy, która nie mieści się w prawach statystyki (na przykład, gdy większość dysków w raid-10 zostaje zniszczona przez silne uderzenie pioruna). W takich okolicznościach przez długi czas nie było jasne, kim jest „analityk Pythona”. Python jest jak PHP, tylko nazwa jest trochę dłuższa, a w kodzie źródłowym interpretera jest nieco mniej śladów substancji zmieniających umysł. Jednak w miarę tworzenia coraz większej liczby raportów analitycznych doświadczeni programiści zaczęli coraz bardziej rozumieć znaczenie wąskiej specjalizacji w narzędziach takich jak numpy, pandas, matplotlib, seaborn.
Decydującą rolę najprawdopodobniej odegrało nagłe omdlenie pracowników od połączenia słów „regresja logistyczna” i demonstracja skutecznego raportowania na dużych danych za pomocą tak, tak, pyspark.
Apache Spark, jego paradygmat funkcjonalny, do którego idealnie wpasowuje się algebra relacyjna, oraz jego możliwości wywarły takie wrażenie na programistach przyzwyczajonych do MySQL, że potrzeba wzmocnienia szeregów o doświadczonych analityków stała się jasna jak słońce.
Dalsze próby startu Apache Spark/Hadoop i co nie do końca poszło zgodnie ze scenariuszem
Szybko jednak okazało się, że coś systemowo jest nie tak ze Sparkiem, albo po prostu trzeba lepiej myć ręce. Jeśli stos Hadoop/MapReduce/Lucene został stworzony przez dość doświadczonych programistów, co jest oczywiste, jeśli przyjrzysz się bliżej kodowi źródłowemu w Javie lub pomysłom Douga Cuttinga w Lucene, to Spark nagle zostanie napisany w egzotycznym języku Scala, który jest bardzo kontrowersyjny z punktu widzenia praktyczności i obecnie nie jest rozwijany. Regularny spadek obliczeń w klastrze Spark z powodu nielogicznej i niezbyt przejrzystej pracy z alokacją pamięci na potrzeby operacji zmniejszania (wiele kluczy pojawia się jednocześnie) stworzył wokół niego aureolę czegoś, co ma miejsce na rozwój. Dodatkowo sytuację pogarszała duża liczba dziwnych otwartych portów, pliki tymczasowe rozrastające się w najbardziej niezrozumiałych miejscach i piekło zależności jar-ów - co spowodowało, że administratorzy systemu mieli jedno uczucie dobrze znane z dzieciństwa: zaciekłą nienawiść (a może musieli myć ręce mydłem).
W rezultacie „przetrwaliśmy” kilka wewnętrznych projektów analitycznych, które aktywnie korzystają z Apache Spark (w tym Spark Streaming, Spark SQL) i ekosystemu Hadoop (i tak dalej, i tak dalej). Pomimo tego, że z biegiem czasu nauczyliśmy się całkiem nieźle przygotowywać i monitorować „to” i „to” praktycznie przestało się nagle zawieszać z powodu zmian w naturze danych i braku równowagi jednolitego hashowania RDD, chęć wzięcia czegoś już gotowego , aktualizowany i administrowany gdzieś w chmurze, stawał się coraz silniejszy. To właśnie w tym czasie próbowaliśmy skorzystać z gotowego zestawu chmurowego Amazon Web Services - a następnie próbował rozwiązać problemy za jego pomocą. EMR to Apache Spark przygotowany przez Amazon z dodatkowym oprogramowaniem z ekosystemu, podobnie jak kompilacje Cloudera/Hortonworks.
Gumowe przechowywanie plików do celów analitycznych jest pilną potrzebą
Doświadczenie „gotowania” Hadoopa/Sparka z oparzeniami różnych części ciała nie poszło na marne. Coraz bardziej narastała potrzeba stworzenia jednego, niedrogiego i niezawodnego magazynu plików, który byłby odporny na awarie sprzętowe i w którym możliwe byłoby przechowywanie plików w różnych formatach z różnych systemów oraz tworzenie wydajnych i oszczędzających czas próbek do raportów z tych danych jasne.
Chciałem też, aby aktualizacja oprogramowania tej platformy nie zamieniła się w noworoczny koszmar z odczytywaniem 20-stronicowych śladów Java i analizowaniem kilometrowych szczegółowych logów klastra za pomocą Spark History Server i podświetlanej lupy. Chciałem mieć proste i przejrzyste narzędzie, które nie wymagałoby regularnego zagłębiania się w szczegóły, gdyby standardowe żądanie MapReduce programisty przestało być wykonywane, gdy pracownikowi redukcji danych zabrakło pamięci z powodu niezbyt dobrze wybranego algorytmu partycjonowania danych źródłowych.
Czy Amazon S3 jest kandydatem na DataLake?
Doświadczenie z Hadoop/MapReduce nauczyło nas, że potrzebujemy skalowalnego, niezawodnego systemu plików i dodatkowo skalowalnych procesów roboczych, „zbliżających się” do danych, aby nie przesyłać ich przez sieć. Pracownicy powinni mieć możliwość odczytywania danych w różnych formatach, ale najlepiej nie czytać niepotrzebnych informacji i mieć możliwość wcześniejszego przechowywania danych w dogodnych dla pracowników formatach.
Jeszcze raz podstawowa idea. Nie ma potrzeby „wlewania” dużych zbiorów danych do jednego, klastrowego silnika analitycznego, który prędzej czy później się udławi i trzeba będzie go brzydko podzielić na kawałki. Chcę przechowywać pliki, po prostu pliki, w zrozumiałym formacie i wykonywać na nich efektywne zapytania analityczne przy użyciu różnych, ale zrozumiałych narzędzi. A plików w różnych formatach będzie coraz więcej. I lepiej jest shardować nie silnik, ale dane źródłowe. Potrzebujemy rozszerzalnego i uniwersalnego DataLake, zdecydowaliśmy...
A co jeśli przechowujesz pliki w znanym i dobrze znanym skalowalnym magazynie w chmurze Amazon S3, bez konieczności przygotowywania własnych kotletów z Hadoopa?
Oczywiste jest, że danych osobowych jest „mało”, ale co z innymi danymi, jeśli je wyniesiemy i „skutecznie wykorzystamy”?
Ekosystem analityki klastrów Amazon Web Services – w bardzo prostych słowach
Sądząc po naszych doświadczeniach z AWS, Apache Hadoop/MapReduce jest tam aktywnie wykorzystywany już od dłuższego czasu pod różnymi sosami, np. w usłudze DataPipeline (zazdroszczę kolegom, nauczyli się to poprawnie przygotowywać). Tutaj konfigurujemy kopie zapasowe z różnych usług z tabel DynamoDB:
Od kilku lat działają regularnie na wbudowanych klastrach Hadoop/MapReduce jak w zegarku. „Ustaw i zapomnij”:
Możesz także skutecznie zaangażować się w satanizm danych, konfigurując laptopy Jupiter w chmurze dla analityków i korzystając z usługi AWS SageMaker do szkolenia i wdrażania modeli AI w walce. Oto jak to wygląda u nas:
I tak, możesz wybrać laptopa dla siebie lub analityka w chmurze i podłączyć go do klastra Hadoop/Spark, wykonać obliczenia, a następnie wszystko ustalić:
Naprawdę wygodne dla indywidualnych projektów analitycznych, a dla niektórych z powodzeniem korzystaliśmy z usługi EMR do obliczeń i analiz na dużą skalę. A co z rozwiązaniem systemowym dla DataLake, czy będzie działać? W tej chwili byliśmy na granicy nadziei i rozpaczy i kontynuowaliśmy poszukiwania.
Klej AWS - starannie zapakowany Apache Spark na sterydach
Okazało się, że AWS ma własną wersję stosu „Hive/Pig/Spark”. Rola Hive, tj. Katalog plików i ich typów w DataLake realizuje usługa „Data Catalog”, która nie ukrywa swojej zgodności z formatem Apache Hive. Musisz dodać do tej usługi informacje o tym, gdzie znajdują się Twoje pliki i w jakim są formacie. Dane mogą znajdować się nie tylko w s3, ale także w bazie danych, ale nie jest to temat tego wpisu. Oto jak zorganizowany jest nasz katalog danych DataLake:
Pliki są zarejestrowane, świetnie. Jeśli pliki zostały zaktualizowane, uruchamiamy roboty ręcznie lub zgodnie z harmonogramem, które zaktualizują informacje o nich z jeziora i zapiszą je. Następnie dane z jeziora można przetworzyć, a wyniki gdzieś przesłać. W najprostszym przypadku wgrywamy również na s3. Przetwarzanie danych można przeprowadzić w dowolnym miejscu, ale sugeruje się skonfigurowanie przetwarzania w klastrze Apache Spark przy użyciu zaawansowanych możliwości interfejsu API AWS Glue. W rzeczywistości możesz pobrać stary, dobry i znany kod Pythona za pomocą biblioteki pyspark i skonfigurować jego wykonanie na N węzłach klastra o określonej pojemności z monitorowaniem, bez zagłębiania się w wnętrzności Hadoopa i przeciągania kontenerów docker-moker oraz eliminowania konfliktów zależności .
Znów prosty pomysł. Nie ma potrzeby konfigurowania Apache Spark, wystarczy napisać kod Pythona dla pyspark, przetestować go lokalnie na pulpicie, a następnie uruchomić na dużym klastrze w chmurze, określając, gdzie znajdują się dane źródłowe i gdzie umieścić wynik. Czasami jest to konieczne i przydatne. Oto jak to konfigurujemy:
Zatem jeśli chcesz coś obliczyć w klastrze Spark przy użyciu danych w s3, piszemy kod w python/pyspark, testujemy go i życzymy powodzenia chmurze.
A co z orkiestracją? A co jeśli zadanie upadło i zniknęło? Tak, zaproponowano stworzenie pięknego potoku w stylu Apache Pig i nawet tego próbowaliśmy, ale na razie zdecydowaliśmy się skorzystać z naszej głęboko dostosowanej orkiestracji w PHP i JavaScript (rozumiem, że istnieje dysonans poznawczy, ale działa to np. lat i bez błędów).
Format plików przechowywanych w jeziorze jest kluczem do wydajności
Bardzo, bardzo ważne jest zrozumienie dwóch kolejnych kluczowych punktów. Aby zapytania dotyczące danych plików w jeziorze były wykonywane tak szybko, jak to możliwe, a wydajność nie uległa pogorszeniu po dodaniu nowych informacji, należy:
- Przechowuj kolumny plików osobno (abyś nie musiał czytać wszystkich wierszy, aby zrozumieć, co jest w kolumnach). W tym celu przyjęliśmy format parkietu z kompresją
- Bardzo ważne jest podzielenie plików do folderów takich jak: język, rok, miesiąc, dzień, tydzień. Silniki obsługujące tego typu sharding będą przeglądać tylko niezbędne foldery, bez przeglądania wszystkich danych z rzędu.
Zasadniczo w ten sposób rozkładasz dane źródłowe w najbardziej efektywnej formie dla zawieszonych na górze silników analitycznych, które nawet w folderach podzielonych na fragmenty mogą selektywnie wprowadzać i odczytywać tylko niezbędne kolumny z plików. Nie musisz nigdzie „uzupełniać” danych (pamięć po prostu pęknie) - po prostu mądrze umieść je w systemie plików we właściwym formacie. Oczywiście powinno być tutaj jasne, że przechowywanie w DataLake ogromnego pliku csv, który musi najpierw zostać odczytany linia po linii przez klaster, aby wyodrębnić kolumny, nie jest zbyt wskazane. Pomyśl jeszcze raz o powyższych dwóch punktach, jeśli nie jest jeszcze jasne, dlaczego to wszystko się dzieje.
AWS Athena – jack-in-the-box
A potem, tworząc jezioro, jakimś cudem natknęliśmy się na Amazon Athenę. Nagle okazało się, że starannie układając nasze ogromne pliki dziennika w fragmenty folderów w odpowiednim (parkietowym) formacie kolumn, można bardzo szybko dokonać z nich niezwykle pouczających selekcji i zbudować raporty BEZ, bez klastra Apache Spark/Glue.
Silnik Athena zasilany danymi w s3 bazuje na legendarnym - przedstawiciel rodziny podejść do przetwarzania danych MPP (massive równoległe przetwarzanie), pobierający dane tam, gdzie się znajdują, od s3 i Hadoop po Cassandrę i zwykłe pliki tekstowe. Wystarczy poprosić Atenę o wykonanie zapytania SQL, a wtedy wszystko „zadziała szybko i automatycznie”. Należy pamiętać, że Athena jest „inteligentna”, trafia tylko do niezbędnych folderów podzielonych na fragmenty i czyta tylko te kolumny, które są potrzebne w żądaniu.
Interesujące są również ceny za zapytania do Ateny. Płacimy za . Te. nie dla liczby maszyn w klastrze na minutę, ale... dla danych faktycznie przeskanowanych na 100-500 maszynach, tylko dane niezbędne do zrealizowania żądania.
A żądając tylko niezbędnych kolumn z prawidłowo podzielonych folderów, okazało się, że usługa Athena kosztuje nas kilkadziesiąt dolarów miesięcznie. No cóż, świetnie, prawie za darmo w porównaniu do analityki w klastrach!
Przy okazji, oto jak dzielimy dane w s3:
W rezultacie w krótkim czasie zupełnie różne działy w firmie, od bezpieczeństwa informacji po analitykę, zaczęły aktywnie wysyłać zapytania do Atheny i szybko, w ciągu kilku sekund, otrzymywać przydatne odpowiedzi z „dużych” danych w dość długich okresach: miesięcy, pół roku itd. P.
Ale poszliśmy dalej i zaczęliśmy szukać odpowiedzi w chmurze : analityk pisze zapytanie SQL w znanej konsoli, która na 100-500 maszynach „za grosze” wysyła dane do s3 i zwraca odpowiedź zwykle w ciągu kilku sekund. Wygodny. I szybko. Nadal nie mogę w to uwierzyć.
W efekcie decydując się na przechowywanie danych w s3, w wydajnym formacie kolumnowym i przy rozsądnym dzieleniu danych na foldery... otrzymaliśmy DataLake oraz szybki i tani silnik analityczny - gratis. I stał się bardzo popularny w firmie, ponieważ... rozumie SQL i działa o rząd wielkości szybciej niż poprzez uruchamianie/zatrzymywanie/konfigurowanie klastrów. „A jeśli wynik jest taki sam, po co płacić więcej?”
Prośba do Ateny wygląda mniej więcej tak. W razie potrzeby możesz oczywiście uformować wystarczająco dużo , ale ograniczymy się do prostego grupowania. Zobaczmy, jakie kody odpowiedzi klient miał kilka tygodni temu w logach serwera WWW i upewnijmy się, że nie ma błędów:
odkrycia
Po przebyciu, żeby nie powiedzieć długiej, ale bolesnej ścieżki, stale adekwatnie oceniając ryzyko oraz poziom złożoności i kosztu wsparcia, znaleźliśmy rozwiązanie dla DataLake i analityki, które niezmiennie nas cieszy zarówno szybkością, jak i kosztem posiadania.
Okazało się, że zbudowanie efektywnego, szybkiego i taniego w obsłudze DataLake na potrzeby zupełnie różnych działów firmy jest całkowicie w zasięgu nawet doświadczonych programistów, którzy nigdy nie pracowali jako architekci i nie umieją rysować kwadratów na kwadratach za pomocą strzałki i poznaj 50 terminów z ekosystemu Hadoop.
Na początku podróży moja głowa pękała od wielu dzikich ogrodów zoologicznych otwartego i zamkniętego oprogramowania oraz zrozumienia ciężaru odpowiedzialności wobec potomków. Po prostu zacznij budować DataLake od prostych narzędzi: nagios/munin -> Elastic/kibana -> Hadoop/Spark/s3..., zbierając opinie i dogłębnie rozumiejąc fizykę zachodzących procesów. Wszystko skomplikowane i mętne - oddaj to wrogom i konkurentom.
Jeśli nie chcesz korzystać z chmury i lubisz wspierać, aktualizować i łatać projekty open source, możesz zbudować schemat podobny do naszego lokalnie, na niedrogich komputerach biurowych z Hadoopem i Presto na wierzchu. Najważniejsze, żeby się nie zatrzymywać i iść do przodu, liczyć, szukać prostych i jasnych rozwiązań, a na pewno wszystko się ułoży! Życzę wszystkim powodzenia i do zobaczenia ponownie!
Źródło: www.habr.com