Видео

#KOSOWO 👋

Głupi tytuł.

Pewna słuchaczka zajmująca się logopedią zapytała czy nie sądzę, że pewne odcinki są stworzone przez ai… i czy autor w ten sposób nie bawi się ze słuchaczami oraz czy ktoś to zauważy(ł)? Ciekaw jestem, co Autor odpowie ;)

Mam nadzieję ,że kanał się rozwinie

Czekam na odcinek z notatnikiem!

transformator

Bardzo dobry podcast. Ciekawa perspektywa historyczna :) Dzięki

Ciszej sie nie da?

Zapowiada się ciekawie. Fajnie się słucha. Leci sub, czekam na kolejne odcinki.

niewiem

Miło się słucha,ciekawy temat na czasie,zasubskrybowałem,zobaczymy co dalej będzie,pozdrawiam i powodzenia;)

Witajcie. Mam nadzieję, że nie będzie bana? :) 02:36 Grzegorz, to proste. Inspiracja kolorami z logo dwóch produktów: Fabric albo Databricks. Wybór architektonicznie nie będzie prosty, ale może oba na raz? Tylko nie mieszaj, bo wyjdzie kolor "konkurencji" ! ;) 29:50, 32:28, 34:50 Jakub, w punkt! To dopiero początek tej drogi i z czasem przybędzie "SaaS"owych integracji jednego-z-drugim-czy-trzecim komponentem. Ale wiecie co? Mam nieodparte wrażenie, że MS kolejny raz przespał post-rewolucję Big Data. Wiadomo, było PDW, był Polybase, (ba!) był nawet SQL BDC! Kierunek ciekawy, historia jednak pokazała, że nie po drodze z trendami. A potem miał być Synapse Gen-Z ;) No i wyszło coś dużo więcej. Moim zdaniem integracja "nieco" na siłę z Power BI to strzał w dziesiątkę, a dokładniej w stopę, obok dużego palca, prosto tam, gdzie boli. Słabo ludzie rozumieją te wszystkie lejki, łerhałzy, kql itp. Zmiana brandingu, zmiana nazw komponentów, ekranów, elementów infrastruktury... Ale jak poznają i się wszystko "zagoi", to może i biegać będzie łatwiej w tym "maratonie"? :) Pytanie tylko czy branża nie wymyśli czegoś nowego i już Delta z innymi cukierkami będzie passe za te 3-5 lat, kiedy Fabric dotrze do tej utopijnej spójności.... No bo taki Databricks, czy inny Snowflake mogą obligatoryjnie podnieść runtime i lokomotywa jedzie dalej. Co najwyżej "popraw swój kod". A w Fabric ciężar spada również na producenta, żeby cały ekosystem był jako tako spójny. Wystarczy spojrzeć jak Synapse Pipelines goniło swojego starszego brata ADF (a przecież to były produkty spod tej samej strzechy!) 33:01, 36:34 Bartek, dokładnie! Czy t-sql i jego "kompatybilność", czy "integracja" jako całość i na końcu pytanie Grzegorza ("Kiedy Fabric będzie kompletnie ukończonym produktem?") - wiemy dobrze, że marketing nieco wyprzedza technologię (samospełniająca się przepowiednia :P ) Nie było jednak dobrego czasu na start platformy i z konsekwencjami produktu względnie stabilnego, choć pełnego niekomfortowych kompromisów, trzeba nadrabiać dobrym słowem "z ambony" i wyjść z tym co jest. Na moje oko doby ruch, choć nam architektom nadaje to nieco gorzkiego posmaku w tym nawarzonym przez nich piwie ;) 38:56 Grzegorz, co do tej stabilności SSAS Multi... Wyjątek pewnie nienegujący regułę, ale opisałem kiedyś buga na blogu, zgłosiłem oficjalnie i na stackoverflow. Oczywiście nikt tego nie naprawił. ( azure.pawlikowski.pro/2019/07/18/internal-error-an-unexpected-exception-occurred-when-trying-to-filter-simple-dimension-that-has-ragged-parent-child-hierarchy-in-multidimensional-model/ ) Niestety, MS OFICJALNIE potwierdził, że nie zamierza w Azure iść w MultiDim i jedyny słuszny kierunek w erze taniego i powszechnie dostępnego RAMu to Tabular ( learn.microsoft.com/en-us/analysis-services/comparing-tabular-and-multidimensional-solutions-ssas?view=asallproducts-allversions#:~:text=you%20can%20stop%20reading%20now.%20Multidimensional%20models%20will%20not%20be%20supported%20in%20Azure%20Analysis%20Services%20or%20Power%20BI%20Premium%20semantic%20models. ) 40:47, 47:06 - Witaj w chmurze, gdzie nie masz już kontroli nad cyklem wdrażania poprawek i wersji rodem z WSUSa. W sumie to, co podsumował kolega Tomasz. Cloud to jedna nieustajaca faza 'versionless', gdzie bardzo często producent zapomina nawet wspomnieć w changelogu o wprowadzanych zmianach. Akurat PBI/Fabric uważam, że ma najlepszy opis waves i samych ficzerów/poprawek. Niemniej jednak jest to frustrujące i doskonale podzielam Twoje zdanie Grzegorz! Swoją drogą, nie wiem czy wiecie, ale Databricks formalnie w dokumentacji ficzery preview uznaje za 'ready to go live on prod'. Mają SLA, mają support, świetna decyzja! ( learn.microsoft.com/en-us/azure/databricks/release-notes/release-types#:~:text=Public%20preview-,Everyone,Support%20team,-Features%20are%20documented%20in%20the%20public%20Azure%20Databricks%20documentation.%20Preview ) 50:55 Bartek, to to jeszcze nic. Przykładowo, żeby spełnić wymagania compliance, hipaa, knf itp, trzeba szyfrować nasze klocki CMK. Jedna z podstawowych platform przechowującą istotne dane, często nawet i wrażliwe, pozwala na to dopiero od ok. $6000 miesiecznie (req 100GB/d dedicated cluster, tak, logi w Log Analytics :P). Zbieranie doświadczenia o tym co dana platforma w jakim sku potrafi, z czym zadziała, z czym nie i czy to się opłaci, jest IMO jedną z największych zmor architekta (a tych jest całkiem sporo, ale to może temat na inną, waszą?, dyskusję :) ) 53:19 Bartek, nie zapominajmy o tak trywialnej sprawie jak konieczność zalogowania do Azure aby utworzyć capacity. Zasłyszane co prawda, ale ponoć grupa projektowa potwierdziła - trzeba teraz wynieść się z portalu PBI i zaskładać capacity w Azure. Niby nic wielkiego, ale jednak nie ta strona księżyca, nie ten portal, nie ten rodzaj administracji :| Tak do brzegu zmierzając ;) Jest w tym sporo racji, że Databricks ma swoją dojrzałość, wyrobioną markę, swoje zaplecze community, sporo know-how już w głowach specjalistów i w internecie, czego nie można powiedzieć o Fabricu. Oczywiście teraz rozumiem MS czemu dogadywał się z Databricks i nawet w niego inwestował (choć "bywały" momenty, kiedy nie było im po drodze). To początek długiej drogi, na końcu której wszystko może się wydarzyć. Mamy erę generatywnej magii, nieco (za) wolno rozpędzający się świat technologii kwantowej i zdecydowanie wielu graczy na tym placu boju, więcej niż przed laty. Chociaż MS imponuje nadrabianiem strat w Gartnerze, wszyscy depczą mu po piętach. A my, userzy, nieco "zatracamy się" galopując na oślep w nadrabianiu zaległości o nowych ficzerach, dobrych praktykach, szukając optymalnych rozwiązań, które przestają być zasadne czasem nawet po kilku tygodniach... Ale taki już jest koszt innowacyjności na skalę "big". Do następnego odcinka! ;) p.s. Maciek, wbijaj szpile 'starszyznie', bo mam wrażenie, że sporo chodzi Ci po głowie, ale za mocno tamci kręcą się wokół swoich wymian piłeczek i ciężko Ci się wstrzelić :) Odwagi!

Dobrze, że Grzegorz bierze udział w rozmowach :) Może trochę ścinacie zakręty tematów, czasem zbaczając również z trasy, ale punkt widzenia osoby, która zjadła zęby na on-premie i próbuje nadrobić zaległości na szybko relatywizując swoją wiedzę w odniesieniu do chmurowej fizyki, pokazuje z czym trzeba się mierzyć na co dzień w pracy architekta z niektórymi klientami i jak tłumaczyć pewne rzeczy szerszej publiczności. Zmusza to nas też do zejścia na ziemię podczas tego całego bujania w chmurowych obłokach :) Pozwolę sobie też nieco dalej poelaborować. Technologie do rozproszonego przetwarzania w oparciu o równie rozproszone repozytoria plikowe z sukcesem wspierały big data od dawna, nie dając sobie jednak rady z koncepcjami stosowanymi w hurtowniach, które tak się składa, budujemy od lat w silnikach relacyjnych. W międzyczasie Spark i Hive całkiem sporo odmieniło w tym temacie. Idąc dalej, wprowadzenie takiej transakcyjności, jaką daje delta lake, wniosło wiele dobrego i odmieniło uciążliwy los systemów próbujących okiełznać współbieżność, wersjonowanie, choć nie zapominajmy, że on nie był pierwszy. Zachęcam Was przy okazji do poznania funkcjonalności przykładowo Apache Hudi i Iceberg. Poszerzy to horyzonty wiedzy o silnikach operujących na plikach osadzonych w data lake. Ale wracając do tematu, rozproszone systemy, czy to aplikacyjne, czy storage, niosą za sobą sporo wyzwań, których nie doświadczaliśmy w monolitach. Brak więzów integralności jest tego najprostszym przykładem. Choć jeszcze bardziej fundamentalnym jest brak choćby constrainta UNIQUE. I przy tym PK czy FK (jeśli w ogóle jest), ich znaczenie jest symboliczne, a czasem nawet zgubne (przypadek PDW/ADWH/Synapse Dedicated Pools i PK, który duplikuje dane w joinach: tinyurl.com/synapsepk ). Sporym wyzwaniem jest mimo wszystko brak bezpośredniego dostępu do danych na poziomie klastrów, sektorów, extentów, stron danych czy innych offsetów, co jest typowe dla systemów plików wykorzystywanych w bazach danych relacyjnych. Systemy plików w chmurze, takie jak Azure Data Lake, opierają się na modelu obiektowym, gdzie dane są dostępne poprzez wysokopoziomowe prymitywne REST API, który stawia na łatwość i powszechność, zapominając mocno o wydajności, którą formalnie kompensuje astronomiczną wręcz skalowalnością (chociaż kto nie osiągnął limit requestów ADLS 20k/s w porządnym lakehouse niech pierwszy rzuci kamieniem) To GIGANTYCZNIE utrudnia realizację wielu optymalnych operacji typowych dla niskopoziomowego dostępu do danych. Oznacza to, że trudniej jest realizować optymalizacje specyficzne dla systemów dyskowych, takie jak np. operacje na stronach danych czy bezpośredni dostęp do fragmentów plików. Nadal więc istnieje wyzwanie związane z optymalizacją dostępu I/O na poziomie pojedynczych rekordów. Na dodatek, tradycyjne bazy danych relacyjne oferują zaawansowane mechanizmy indeksowania (np. B-tree, hash), które pozwalają na szybki dostęp do danych na podstawie kluczy lub wartości. Synapse pozwalał w niektórych sytuacjach na indeksowanie i budowę w oparciu o rowstore i clusterd/nonclustered. Snowflake poszedł w Iceberg dla danych, ale dla większej kompatybilności pomyślał też o Unistore (poczytajcie, też ciekawy temat). Wracając do databricks/fabric i delta lake.. Różne mechaniki optymalizacji są tam stosowane, takie jak tradycyjny i nowy (liquid) clustering, ordering (z-|v-), kompaktowanie (defragmentacja? :) ) itp. Ale to optymalizacje na zupełnie innych poziomach, które przegrywają z wydajnością poczciwych baz, co niekiedy mocno zaskakuje ludzi, którzy w rozwiązaniach chmurowych poszukują mega wydajności przy mega skalowalności.. A tymczasem pobranie kilku rekordoów bez sortowania i filtrowania wymaga długich sekund operacji. Trzeba zawsze poświęcić czasu i cierpliwości na wyjaśnienie czym ten świat się charakteryzuje i na jakie kompromisy to wszystko poszło. Spodziewam się, że w najbliższej przyszłości prace nad mechaniką tych platform pójdą w kierunku zdecydowanie większej wydajności i zapewnienia obsługi zapytań na poziomie atomowym (z czasem dostępu rzędu ms), tak jak wspomniane przykłady z Synapse i Snowflake. Coś na koniec. Dla mnie osobiście największy żal, który ściska za pośladki, związany jest z BACKUPami i zapewnieniem prawdziwym odtwarzalnym Disaster Recovery. Nawet jeśli ostatecznie MS wprowadzi Azure Backup dla ADLS (tak jak zamierza to zrobić z blob storage w trybie "snapshota" do wybranego storage), wciąż będzie brakowało możliwosći zrobienia !konsystentnego! backupu, taki jaki robiony jest w silnikach relacyjnych (np w MSSQL backup stron + zrzut z dziennika aby zrobic rollback lub rollforward). Na dodatek platforma uzależniona jest od wielu komponentów, do których podejście w odtwarzaniu może być kompletnie inne, sposób sparowania z dodatkowym regionem oparty na innych zasadach i często niemożliwym do przetestowania. Repliki active-passive są ciężkie w realizacji w kontekście całych infrastruktur i nie do końca opłacalne... Czy ktokolwiek z was zastanawiał się może, co się stanie z regionem sparowanym albo nawet availability zone, jeśli dojdzie do padu? Czy mamy gwarancję capacity? Wszyscy wiemy jak obciążone są WE i NE, nie bez powodu mamy opcję capacity reserveration, czy dla usług PaaS i SaaS też ona jest przewidziana natywnie od zaplecza...? No nie wiem :) No dobra, czy doczekamy się poprawy sytuacji? Mam nadzieję, że wszystkie stajnie spod znaku Big Data znajdą na to sposób, bo im więcej ludzi przesiada się z klasycznych hurtowni, gdzie byli przyzwyczajeni do wszystkich mechanizmów silników relacyjnych w swoich hurtowniach, tym więcej pojawia się głosów niezadowolenia i zmiany decyzji co do niektórych wdrożeń. Pozdrawiam i do następnego odcinka ;)

Panowie jak zawsze w punkt. Natomiast patrzycie z perspektywy tych bardziej zaawansowanych. Czyli mamy Azure i chcemy jego elementy przenieść do Fabric. Mnie by interesowało jak z migracją w drugą stronę - mam Fabric i czy bez problemu przejdę na Azure? To jest chyba bardziej prawdopodobny scenariusz, bo Fabric wydaje się być idealnym krokiem pomiędzy brakiem Bi i pełnym BI dla średnich organizacji. To co mnie boli to teoretycznie te same elementy co w DataFactory, ale z ograniczonymi możliwościami. Takie Copy data nie ma w Fabric jako źródła Salesforce'a i co dalej? Muszę korzystać z DF.

No body is pefect. Ostatnio w pracy wdrożono nam nowatorski system komputerowy ! A co na to komputer ? Szybko przekazywaną mu nową wiedzę zaczął chować do swoich ,,KIESZENI" 😂

Super wykład 🙂

brawo !