Menu Zamknij

Autor: Arkadiusz Kasprzak

Czy już nadszedł odpowiedni moment, żeby pomyśleć o BigQuery? Z historią w tle! [Podcast]

Czy wiesz, że dzięki BigQuery można zbudować małą hurtownię danych zupełnie za darmo? Czy wyobrażasz sobie wykorzystanie BigQuery w małej rodzinnej firmie, która produkuje dania obiadowe i kanapki?

Ten odcinek się trochę różni się od pozostałych, ponieważ Marcin opowiada w nim o BigQuery, ale z nieco innej perspektywy niż możesz się spodziewać.

BigQuery na pewno kojarzy się z przetwarzaniem ogromnych ilości danych, w petabajtowej skali, czyli klasyczne Big Data. I to wszystko się zgadza, jednak nie jest to cała prawda o BigQuery.

Spojrzymy na to trochę od strony biznesowej, trochę z perspektywy architekta rozwiązań, który może zbudować całkiem potężny system zarządzający procesami w przedsiębiorstwie, którego model działania nie może wykorzystać istniejących rozwiązań. A wszystko to w błyskawicznym tempie i niskim kosztem, wykorzystując w większości gotowe narzędzia.

W odcinku dowiesz się, czym różni się BigQuery od innych narzędzi Big Data, takich jak np. Hadoop oraz o tym, kiedy można czerpać największe korzyści z usług typu serverless, bo nie do końca prawdą jest, że serverless sprawdza się najlepiej w dużej skali.

A wszystko to będzie poparte realnym przykładem z życia wziętym, w którym koszty infrastruktury systemów informatycznych dla małego przedsiębiorstwa mieściły się w kwocie 5 zł miesięcznie. Tak, nie ma tu pomyłki, słownie pięć złotych miesięcznie, a konkretnie około 1$.

Kimball, Inmon czy Linstedt – rozmowa o hurtowniach danych [Podcast]

Dzisiejszy temat trochę w innej (zupełnie dla mnie nowej!) formie. Tym razem nie będzie długiego artykułu. Zamiast tego zapraszam Cię do wysłuchania podcastu Marcina Siudzińskiego: Od Danych Do Danych, którego byłem gościem.

Poniżej w artykule znajdziesz więcej informacji jak i dodatkowe materiały. A samego nagrania możesz posłuchać tutaj:

Inmon, Kimball a może Linstedt (Data Vault)?

Rozmawialiśmy o różnych koncepcjach związanych z hurtowniami danych. Oczywiście pojawił się Kimball oraz Inmona. Nie mogło również zabraknąć również Data Vaulta.

Starałem się temat ująć tak, abyś jak najlepiej zrozumiał(a) różnice pomiędzy tymi podejściami. Oczywiście temat jest znacznie głębszy i był to jedynie wierzchołek góry lodowej.

Pojawił się również kontekst dużych danych oraz nowoczesnych hurtowni danych w chmurze.

Certyfikacja z Google Cloud? To żaden problem! [Wideo]

Ostatnimi czasy temat certyfikacji jest bardzo często poruszany. Zwłaszcza chmurowych. A biorąc pod uwagę ostatnie newsy związane z centrum danych Google w Polsce, to certyfikacja GCP jest naprawdę „gorącym” tematem.

Jeżeli się tym interesujesz, to idealnie się składa! 🙂 Mam coś, co może Ci pomóc.

Zapraszam Cię do poznania się z krótką recenzją spotkania grupy GDG Cloud Poznań, na którym miałem okazję dzielić się doświadczeniem i prezentować swoje przemyślenia w kwestii certyfikacji.

Bardzo wartościowym elementem spotkania był panel dyskusyjny z ekspertami z branży. Samo spotkanie składało się z kilku części:

  1. Wprowadzenie
  2. Moja prezentacja dotycząca certyfikatów [6:15]
  3. Przedstawienie ścieżek certyfikacyjnych Google – [22:50]
  4. Panel dyskusyjny [41:00]

Motywacja w IT – czy to co robisz, ma dla Ciebie znaczenie?

Od czasu do czasu lubię oderwać się od spraw technologicznych i zagłębić się w tematy bardziej „miękkie”. Tym razem padło na temat – motywacja w IT.

Napisano na ten temat już wiele. Natomiast ten temat ostatnimi czasy bardzo mocno „chodzi mi po głowie”. Zastanawiam się, co sprawia, że w jednych firmach ludzie chcą pracować, a w innych niekoniecznie. Z czego wynika, że realizując niektóre projekty, nie czujemy, że jesteśmy w pracy, a przy innych zastanawiamy się gdzie w życiu popełniliśmy błąd 🙂

Na początek historia

Kilka lat temu, przeczytałem artykuł o lekarzu, który przeprowadził operację na dziecku będącym w łonie matki. Dziecku się nie wykształcały odpowiednio płuca. Operacja polegała na wprowadzeniu do płuc maluszka balonika i napompowania go. Wszystko przez brzuch matki. Po kilku dniach nastąpiła operacja odwrotna. Balonik został usunięty tą samą drogą. W efekcie płuca dziecka zaczęły prawidłowo się rozwijać.

Możliwe, że dla ludzi będących „w temacie” to norma, ale na mnie to zrobiło to piorunujące wrażenie i zapadło mi w pamięć. Z jednej strony było wow, ale z drugiej dało mi to do myślenia. Dlaczego?

Wczuj się w rolę tego lekarza. Wracasz do domu. Mąż/żona/dziecko/mama pyta Cię: jak tam w pracy? A Ty opowiadasz historię opisaną powyżej. Dla kontrastu – jaką historię ja miałem do opowiedzenia? W tamtym momencie, że przerzucam dane z jednej kupki na drugą, aby duża instytucja finansowa nie zapłaciła kary od regulatora. No nie powala! 🙂

Zastanówmy się, co z tym możemy zrobić. A na koniec powiem Ci, dlaczego do niedawna dalej te dane przerzucałem 🙂

ETL vs. ELT – różne podejścia do procesowania danych (OZDB #6)

W poprzednich artykułach z serii Od Zera Do Bohatera omówiłem różnego rodzaju pliki, z którymi możesz się spotkać oraz sposoby przechowywania danych nie tylko ustrukturyzowanych. W ostatnim z kolei opowiedzieliśmy sobie o nowoczesnych podejściach do projektowania systemu opartego o dane.

Do pełnego (wysokopoziomowego) obrazu brakuje nam jeszcze elementu odpowiadającego za przerzucanie danych z jednego miejsca do drugiego. I tu pojawiają się dwa podejścia – ETL vs. ELT.

Te idee nie są szczególnie nowe i już kiedyś o nich pisałem:

ETL vs. ELT, czyli różne podejścia do zasilenia hurtowni i repozytoriów danych

Powyższy tekst ma już kilka lat, ale zerknij do niego jeżeli jesteś ciekaw, jak te dwa podejścia można zastosować w samych relacyjnych bazach danych.

Ten artykuł traktuję jako wersję 2.0. Temat odświeżam tak, aby uwzględnić kontekst chmurowy. Ale zacznijmy pokrótce od podstaw.

Mieliśmy hurtownie, mieliśmy Data Lake. Czy teraz czas na Lakehouse? (OZDB #5)

Modern data warehouse a może lakehouse?

Czy Data Lake + Data Warehouse = Lakehouse? Czy będziemy używać podejścia Modern Data Warehouse?

Chciałbym przeprowadzić Cię przez dostępne koncepcje i zastanowić się jak będzie wyglądała przyszłość.

W ostatnim wpisie z serii Od Zera Do Bohatera przyjrzeliśmy się możliwością przechowywania danych nie tylko relacyjnych. Skupiliśmy się na poszczególnych produktach lub usługach. Natomiast, gdy budujemy system przetwarzający dane, to te wszystkie elementy składają się w pewną całość. Dzięki czemu potrafimy nad danymi zapanować.

Wiele z tych koncepcji ma już swoje lata. Napisano na ten temat mnóstwo artykułów i książek. Nie ma sensu odkrywać koła na nowo. Pozwól, że po prostu przeprowadzę Cię przez świat możliwości wraz z linkami do szczegółów.

Ale zacznijmy od początku. Na początku była… baza danych, ale ten etap przeskoczmy i skupmy się na analitycznych rozwiązaniach. Następna była:

Zastanawiasz się, czy warto robić certyfikaty IT? Poznaj różne opinie

Na ostatni wpis w tym roku wybrałem coś lżejszego. Nie będziemy zagłębiać tajników technologicznych, ale odpowiemy sobie na pytanie, które dostałem od Was – czy warto robić certyfikaty.

Czas ku temu jest idealny, bo na początku grudnia z powodzeniem podszedłem do egzaminu na certyfikat: Google Cloud Professional Data Engineer. Można więc powiedzieć, że temat jest mi bliski.

Chciałbym Ci przedstawić, jak to wygląda z mojej perspektywy, czyli:

  • osoby, która sama certyfikaty zdobywa,
  • jest rekruterem technicznym, więc ocenia innych pod kątem wiedzy i doświadczenia,
  • osoby odpowiedzialnej za rozwój organizacji w szeroko pojętych technologiach związanych z przetwarzaniem danych.

Aby zaprezentować jeszcze szerszą perspektywę, to poprosiłem o opinię dwie osoby z firmy GFT, z którą jestem związany. Na tytułowe pytanie pomoże nam odpowiedzieć: Aleksandra Kujawa (Talent Acquisition Manager, czyli szefowa działu odpowiedzialnego za pozyskanie najlepszych ludzi z rynku) oraz Maciej Paszta (Executive Delivery Manager, osoba odpowiedzialna za kluczowych klientów w firmie).

Jak przechowywać dane (nie tylko) relacyjne? Na przykładzie Google Cloud Platform (OZDB #4)

Dane ustrukturyzowane czy nie? Relacyjne czy nie? Duże lub małe? Silna spójność w danych (ang. strong consistency) czy ostateczna (ang. eventual consistency)?

Sporo tego, prawda? W tym artykule rozwieję trochę wątpliwości. Myślę, że jak to omówimy, to w połączeniu z rozumieniem typów plików (przybliżonych w poprzednim wpisie), będzie Ci łatwiej poruszać się w świecie przetwarzania danych.

Temat różnych typów danych poruszyłem już we wpisie omawiających 7 pytań, które musisz zadać, projektując system przetwarzający dane. Jeżeli go nie znasz, to mocno zachęcam, aby spojrzeć na niego w pierwszej kolejności. Dzisiejszy artykuł jest jego rozwinięciem.

Z racji, że aktualnie najbardziej na czasie są technologie chmurowe, a mi z kolei najbliżej do Google Cloud Platform, to na tym rozwiązaniu się głównie skupimy, od strony narzędziowo-praktycznej. Większość z wymienionych tu usług odwiedzimy jeszcze osobno, aby dokładniej się im przyjrzeć, ale teraz chciałbym Ci te rozwiązania przedstawić z „lotu ptaka”. Umożliwi Ci to poznanie możliwości, które mamy w naszej palecie.

5 typów plików, z którymi spotkasz się pracując z danymi (OZDB #3)

W ostatnim wpisie serii Od Zera Do Bohatera omówiliśmy sobie jak podejść do tworzenia systemów przetwarzania danych. Wspomniałem tam, że przybliżę Ci różne źródła danych.

W tym wpisie skupmy się na plikach, bo bardzo często korzysta się z nich przy dostarczaniu danych, a wielokrotnie napotykałem przeróżne problemy z plikami, w których dostarczane są dane. Zarówno takie, które powodowały błędy podczas procesowania danych, jak po prostu schemat dostarczony wraz z plikami, kompletnie nie pomagał, aby dane zrozumieć.

Wyobraź sobie, że mamy taki diagram (model logiczny), który ma na celu zobrazować dane, które przetwarzamy:

Model logiczny

Wynika z niego, że mamy tabelę KLIENT, która przechowuje klientów z ich podstawowymi danymi i tabelę ADRES, która przechowuje adresy. Nie chciałbym wchodzić w analizę danych relacyjnych, ale na potrzeby tych przykładów zwróćmy uwagę, że jeden klient może mieć wiele adresów, a jeden adres w systemie może być przypisane jedynie do danego klienta. Nawet gdy mamy dwóch klientów pod tym samym adresem (np. małżeństwo), to adres występuje dwa razy i jest przypisany do dwóch różnych klientów.

10 najczęstszych błędów związanych z feedbackiem. Z historią w tle

Chciałbym się podzielić z Tobą pewną historią. Mogłoby się wydawać, że delegowanie zadań jest czymś łatwym, bo cóż może być trudnego w ich rozdzieleniu? Cytując klasyka: nic bardziej mylnego 🙂

Historia z życia – jak nie delegować zadań

Pracowałem w projekcie, w którym byłem analitykiem i głównym kontaktem dla klienta. Mój problem polegał na tym, że zbierając wymagania, to przy omawianiu ich z zespołem często dawałem gotowe rozwiązanie. Wynikało to z tego, że projekt był prowadzony w obszarze, w którym miałem duże doświadczenie technologiczne. Jak możesz się domyślić, zabijało to kreatywność ludzi w zespole i ich rozwój. A już na pewno nie motywowało do aktywniejszego udziału. Co gorsze, jeżeli zadanie otrzymywała osoba mniej asertywna, która widziała lepsze (od mojego) rozwiązanie, to mogła nie być chętne się nim podzielić.

Wiesz co było w tym najdziwniejsze? To, że zdawałem sobie sprawę, że taki styl zarządzania (zwany niekiedy mikrozarządzaniem) jest zły. Więc jak wpadłem w tę pułapkę? Myślę, że odpowiedź jest bardzo prosta – robiłem to nieświadomie. Czasem, ktoś patrzący z boku, potrafi takie rzeczy zauważyć. I właśnie dzięki temu, że dostałem taką informację od kolegi z zespołu, to mogłem to poprawić i bardziej uważać na to jak deleguję zadania.

Sama sztuka delegowania zadań jest odrębnym tematem, ale zależy mi, żebyś zwrócił(a) uwagę na moc informacji zwrotnej, czyli feedbacku.