AWS :Analiza Danych
Historia analityki i dużych zbiorów danych
1. Organizacja, która chce zbudować pulpit nawigacyjny do analityki operacyjnej w czasie rzeczywistym dla swojej aplikacji gier mobilnych, rozważa różne opcje budowy pulpitu nawigacyjnego. Która z poniższych opcji zapewni odpowiednie parametry wydajności dla takiej aplikacji?
A. Użyj Amazon S3 do zasilania pulpitu nawigacyjnego.
B. Użyj Amazon Redshift do zasilania pulpitu nawigacyjnego.
C. Użyj Amazon Elasticsearch Service do zasilania pulpitu nawigacyjnego.
D. Użyj Amazon DynamoDB do zasilania pulpitu nawigacyjnego.
2. Administrator ma plik o rozmiarze 6 GB w Amazon S3. Administrator uruchamia polecenie COPY co noc w klastrze Amazon Redshift z 2 węzłami (32 segmenty). Administrator chce przygotować dane, aby zoptymalizować wydajność polecenia COPY. Jaki jest najlepszy sposób przygotowania danych przez administratora?
A. Skompresuj plik za pomocą kompresji gzip.
B. Podziel plik na 64 pliki o równym rozmiarze.
C. Podziel plik na 500 mniejszych plików.
D. Podziel plik na 32 pliki o równym rozmiarze.
3. Klient chce zbudować rozwiązanie do analizy logów w AWS z opóźnieniem poniżej sekundy dla funkcji wyszukiwania. Dodatkowym wymogiem jest zbudowanie pulpitu nawigacyjnego dla personelu operacyjnego. Która z poniższych technologii zapewniłaby bardziej optymalne rozwiązanie?
A. Przechowuj logi w Amazon S3 i użyj Amazon Athena do zapytania logów. Użyj Amazon QuickSight do zbudowania pulpitu nawigacyjnego.
B. Przechowuj logi w Amazon Redshift i użyj Query Editor do uzyskania dostępu do logów. Użyj Amazon QuickSight do zbudowania pulpitu nawigacyjnego.
C. Przechowuj logi w Amazon Elasticsearch Service i użyj Kibana do zbudowania pulpitu nawigacyjnego.
D. Przechowuj logi w HDFS w klastrze EMR. Użyj Hive do zapytania logów. Użyj Amazon QuickSight do zbudowania pulpitu nawigacyjnego.
4. Wiodący dostawca usług telekomunikacyjnych przenosi się do AWS i ma około 50 TB danych w swoim lokalnym środowisku Hadoop, przechowywanych w HDFS i używa Spark SQL do analizy danych. Klient poprosił o ekonomiczne i wydajne rozwiązanie do szybkiej migracji do AWS, ponad 100 mbps (megabitów na sekundę) połączenia, aby móc zbudować katalog, który może być używany przez inne usługi i analizować dane, jednocześnie zarządzając jak najmniejszą liczbą serwerów. Które rozwiązanie byłoby najlepsze dla tego klienta?
A. Migracja danych za pomocą poleceń S3 przy użyciu interfejsu CLI do Amazon S3, użycie AWS Glue do przeszukiwania danych i tworzenia katalogu oraz analiza za pomocą Amazon Athena.
B. Migracja danych do S3 za pomocą AWS Snowball, użycie AWS Glue do przeszukiwania danych i tworzenia katalogu oraz analiza za pomocą Amazon Athena.
C. Migracja danych za pomocą Amazon Snowball do Amazon S3, użycie Hive na EMR z systemem Spark do utworzenia katalogu i analiza danych za pomocą Park SQL.
D. Migracja danych za pomocą interfejsu CLI do AMAZON S3, użycie Hive na EMR z systemem Spark do utworzenia katalogu i analiza danych za pomocą Spark SQL.
5. Wiodąca organizacja finansowa chce przeprowadzić migrację swojego korporacyjnego magazynu danych do AWS. Ma 30 TB danych w swoim magazynie danych, ale wykorzystuje tylko 500 GB do raportowania i pulpitu nawigacyjnego, podczas gdy pozostałe dane są okazjonalnie wymagane do celów zgodności. Które z poniższych rozwiązań jest bardziej opłacalne?
A. Migracja danych do AWS. Utworzenie klastra EMR z dołączoną pamięcią masową HDFS hostującą 30 TB danych. Użyj Amazon QuickSight do pulpitu nawigacyjnego i Hive do wymagań raportowania zgodności.
B. Migracja danych do Amazon S3. Utworzenie klastra Redshift hostującego 30 TB danych. Użyj QuickSight do pulpitu nawigacyjnego i Athena do wykonywania zapytań z S3. C. Migracja danych do Amazon S3. Utworzenie klastra Redshift hostującego 500 GB danych. Używanie Amazon QuickSight do obsługi pulpitu nawigacyjnego i Redshift Spectrum do wyszukiwania pozostałych danych w razie potrzeby.
D. Migracja danych do AWS w klastrze Amazon Elasticsearch Service. Używanie Kibana do obsługi pulpitu nawigacyjnego i Logstash do wyszukiwania danych z klastra ES.
6. Nadchodzący startup zajmujący się grami zbiera dzienniki gier ze swojej niedawno uruchomionej i niezwykle popularnej gry. Dzienniki są dostarczane w formacie JSON z 500 różnymi atrybutami dla każdego rekordu. CMO zażądał pulpitu nawigacyjnego opartego na sześciu atrybutach, które wskazują przychody generowane na podstawie rekomendacji zakupów w grze wygenerowanych przez zespół ML działów marketingu. Dane znajdują się w S3 w surowym formacie JSON, a raport jest generowany przy użyciu QuickSight na podstawie dostępnych danych. Obecnie tworzenie raportu trwa godzinę, podczas gdy publikowanie raportu jest bardzo szybkie. Ponadto dział IT skarżył się na koszt skanowania danych w S3. Poproszono Cię jako architekta rozwiązań o dostarczenie rozwiązania, które poprawi wydajność i zoptymalizuje koszty. Która z poniższych opcji jest najbardziej odpowiednia do spełnienia wymagań?
A. Użyj AWS Glue, aby przekonwertować dane JSON do formatu CSV. Przeszukaj przekonwertowane dane w formacie CSV za pomocą Glue Crawler i utwórz raport za pomocą Amazon Athena. Utwórz front-end w Amazon QuickSight.
B. Załaduj dane JSON do Amazon Redshift w kolumnie VARCHAR. Utwórz raport za pomocą SQL i front-end w QuickSight.
C. Załaduj dane JSON do Amazon Redshift. Wyodrębnij atrybuty raportowalne z kolumny JSON w tabelach. Utwórz raport za pomocą SQL i front-end w QuickSight.
D. Użyj AWS Glue, aby przekonwertować dane JSON do formatu Parquet. Przeszukaj przekonwertowany format Parquet za pomocą Glue Crawler i utwórz raport za pomocą Athena. Utwórz front-end w Amazon QuickSight.
7. Wiodąca organizacja produkcyjna obsługuje duży klaster Redshift i skarżyła się na długi czas odpowiedzi na zapytania. Jakie opcje konfiguracji sprawdzilibyście, aby zidentyfikować przyczynę problemu?
A. Liczba i typ kolumn w tabeli
B. Ograniczenia klucza podstawowego i pomocniczego
C. Wyrównanie klucza sortowania tabeli z predykatami w instrukcji SELECT
D. Liczba wierszy w tabeli
E. Schemat partycji dla bazy danych
8. Twój klient poprosił Cię o pomoc w budowie jeziora danych w S3. Systemem źródłowym są pliki MySQL, Oracle i standardowe pliki CSV. Dane nie mają żadnego klucza przyrostowego. Klient oczekuje, że przechwycisz początkowy zrzut danych i zmiany podczas fazy budowy jeziora danych. Jakie narzędzia/technologie poleciłbyś, aby obniżyć całkowity koszt migracji?
A. Załaduj początkowy zrzut i zmiany za pomocą AWS Glue.
B. Załaduj początkowy zrzut i zmiany za pomocą DMS (Database Migration Service).
C. Załaduj początkowy zrzut za pomocą AWS Glue i przechwyć zmiany za pomocą AWS Glue i DMS (Database Migration Service).
D. Załaduj początkowy zrzut za pomocą DMS (Database Migration Service) i zmiany w danych za pomocą AWS Glue.
9. Pulpit nawigacyjny QuickSight umożliwia przeglądanie danych źródłowych, ale nie wprowadzanie w nich żadnych zmian.
A. Prawda
B. Fałsz
10. Amazon QuickSight może interpretować Twoje wykresy i tabele i sugerować spostrzeżenia w prostym języku angielskim.
A. Prawda
B. Fałsz
Odpowiedzi
1. C. Odpowiedź A jest nieprawidłowa, ponieważ Amazon S3 świetnie nadaje się do przechowywania ogromnych ilości danych, ale nie nadaje się do pobierania i wizualizacji danych w czasie rzeczywistym.
Odpowiedź B jest nieprawidłowa, ponieważ Amazon Redshift to dobre narzędzie do wstawiania i skanowania danych na dużą skalę. Jednak zapytania w czasie rzeczywistym nie są dobrym przypadkiem użycia dla Amazon Redshift ze względu na potencjalne ograniczenia współbieżności.
Odpowiedź C jest prawidłowa, ponieważ Elasticsearch to odpowiednia technologia do analityki operacyjnej.
Odpowiedź D jest nieprawidłowa, ponieważ Amazon DynamoDB to technologia, która może zapewnić aplikacjom opóźnienie poniżej sekundy i jest zalecana, gdy masz dobrze znane ścieżki dostępu. Typowe aplikacje pulpitu nawigacyjnego uruchamiają skanowanie danych, co nie jest dostępem opartym na kluczach, a zatem DynamoDB nie jest dobrym wyborem.
2. B. Odpowiedź A jest nieprawidłowa, ponieważ chociaż możesz załadować spakowane dane, gzip nie jest plikiem, który można podzielić, a zatem nie skorzystasz z paralelizmu systemu.
Odpowiedź B jest prawidłowa, ponieważ najlepszą praktyką jest dzielenie danych na wiele plików. Przeczytaj dokumentację AWS. https://docs.aws.amazon.com/redshift/latest/dg/t_splitting-data-files.html Ponadto, ponieważ masz wiele wycinków, lepiej jest, aby liczba plików była wielokrotnością liczby wycinków Redshift.
C jest niepoprawne, ponieważ podział na dużą liczbę mniejszych plików skutkowałby powolnym działaniem listy S3 i nieefektywnym wykorzystaniem odczytów S3. Każdy odczyt bloku odczytałby stosunkowo małą ilość danych, co skutkowałoby niepotrzebnymi odczytami.
D jest prawdopodobną opcją. Jednak B jest lepsze, ponieważ liczba plików jest wielokrotnością liczby wycinków Redshift. Gdybyśmy nie mieli opcji B, D byłoby poprawne.
3. C. A jest niepoprawne, ponieważ chociaż rozwiązanie pomoże zbudować pulpit nawigacyjny, wymóg opóźnienia poniżej sekundy nie zostałby spełniony. Amazon S3 i Athena są dobre do raportowania ad hoc. Jednak gdy dane są często przeszukiwane, opóźnienie jest większe, a ponadto koszt związany z częstym skanowaniem danych sprawia, że jest to nieprawidłowa architektura.
Odpowiedź B jest nieprawidłowa, ponieważ Redshift świetnie nadaje się do budowania hurtowni danych i magazynów danych, ale opóźnienie poniżej sekundy nie jest możliwe, biorąc pod uwagę, że będziesz musiał połączyć się za pomocą JDBC z QuickSight.
Odpowiedź C jest prawidłowa, ponieważ Amazon Elasticsearch to właściwe podejście. Elasticsearch to świetne narzędzie do operacji w czasie niemal rzeczywistym (aws.amazon.com/elasticsearch-service/ what-is-elasticsearch). Użycie Kibany pomogłoby Ci utworzyć pulpit nawigacyjny o niższym całkowitym koszcie posiadania.
Odpowiedź D jest nieprawidłowa, ponieważ Hive nie może być używany do przeszukiwania dzienników z opóźnieniem poniżej sekundy. Hive to lepsze narzędzie do operacji wsadowych.
4. B. Odpowiedź A jest nieprawidłowa. Migracja 50 TB danych za pomocą interfejsu CLI dla Amazon S3 na połączeniu internetowym będzie czasochłonna. Ponieważ wymaganiem jest szybkie przeprowadzenie tej migracji, to rozwiązanie nie zadziała.
B jest poprawna, ponieważ migracja danych za pomocą Snowball będzie lepszą opcją. Gdy dane znajdą się w S3, indeksowanie za pomocą Glue w celu utworzenia katalogu i analiza za pomocą Athena byłyby lepsze, ponieważ klient chciał zarządzać jak najmniejszą liczbą serwerów, a zarówno Athena, jak i Glue są bezserwerowe.
C jest niepoprawne, ponieważ migracja danych za pomocą Snowball zadziała, ale użycie Hive na EMR z uruchomionym Spark w celu utworzenia katalogu jest droższe i wymaga więcej zasobów oraz dodatkowych skryptów, czego można uniknąć, wybierając opcję B.
D jest niepoprawne, ponieważ migracja danych za pomocą interfejsu CLI dla Amazon S3 (który jest drogi) i bardziej złożony (katalogowanie za pomocą Glue).
5. C. A jest niepoprawne, ponieważ rozwiązanie będzie drogie. Ponieważ potrzebne jest tylko 30 TB danych, ładowanie danych do HDFS i płacenie powiązanego kosztu przechowywania w klastrze Hadoop jest niepotrzebne i jest mniej prawdopodobne, że przyniesie jakiekolwiek korzyści dla klienta z perspektywy kosztów.
B jest niepoprawne z powodów wymienionych w wyjaśnieniu opcji A. Podczas gdy Redshift jest dobrym rozwiązaniem dla magazynów danych w chmurze, utrzymywanie wszystkich gorących i zimnych danych w Redshift nie jest dobrym podejściem i jest antywzorcem, biorąc pod uwagę wcześniejszą dyskusję na temat jezior danych. Rozwiązanie będzie działać, ale będzie droższe w utrzymaniu. Podczas gdy Redshift oferuje korzyści finansowe i jest 10 razy tańszy niż tradycyjne rozwiązania magazynów danych, klient może uzyskać większe oszczędności kosztów dzięki innym architekturom.
C jest poprawne i jest dobrym rozwiązaniem do skonfigurowania magazynu wielotemperaturowego. To rozwiązanie nie tylko obniży koszty w krótkim okresie, ale będzie również dobrą architekturą w długim okresie, gdy dane będą rosły. Wzrost danych oznaczałby, że klienci mogliby zacząć korzystać z większej ilości S3 i używać Redshift Spectrum, gdy wymagane jest połączenie gorących i zimnych danych.
D jest niepoprawne. Elasticsearch nie jest dobrym narzędziem do tworzenia magazynu danych, w którym należy utworzyć wiele ścieżek dostępu do danych. Dane 30 TB na ES byłyby bardzo drogie, a z każdym indeksem zapotrzebowanie na pamięć masową wzrosłoby wielokrotnie. Amazon Redshift jest lepszym wyborem architektury do budowy magazynu danych.
6. D. A jest niepoprawne, ponieważ CSV jest formatem wierszowym. Użycie Atheny do zapytania CSV oznaczałoby odczytanie wielu niepotrzebnych atrybutów danych, co skutkowałoby niższą wydajnością i wyższymi kosztami skanowania danych.
B jest niepoprawne, ponieważ załadowanie danych do kolumny VARCHAR, a następnie zapytanie przy użyciu funkcji ekstrakcji JSON byłoby droższe, a wydajność łączenia byłaby bardzo słaba.
C jest niepoprawne, ponieważ ekstrakcja atrybutów będzie działać lepiej, ale dane przechowywane w Redshift są droższe niż w S3. Ponadto w dłuższej perspektywie to rozwiązanie nie będzie opłacalne.
D jest poprawne, ponieważ wykorzystuje opcję bezserwerową do konwersji danych do formatu kolumnowego, takiego jak Parquet, i umożliwia bardziej niezawodne rozwiązanie, które byłoby odporne na przyszłość nawet przy rosnących rozmiarach danych.
7. C. A jest niepoprawne, ponieważ liczba i typy kolumn nie powinny być pierwszą rzeczą, na którą należy zwrócić uwagę. Chociaż istnieją pewne przypadki, w których typ kolumny może mieć wpływ na łączenie zapytań, należy to rozważyć po zapoznaniu się z podstawami, które obejmują sprawdzenie predykatów i kluczy sortowania, które ograniczają ilość danych skanowanych w zapytaniu.
B jest niepoprawne. Ograniczenia klucza podstawowego Redshift mają charakter wyłącznie informacyjny.
C jest poprawne, ponieważ klucze sortowania działają jak indeks i są odpowiedzialne za ograniczenie danych skanowanych z dysku.
D jest niepoprawne. Redshift jest bazą danych MPP i jeśli jest prawidłowo zaprojektowana, liczba wierszy w tabeli nie powinna mieć bezpośredniego wpływu na wydajność zapytania.
E jest niepoprawne. Dane znajdują się w bazie danych, a partycjonowanie nie jest opcją w Redshift.
8. C. A jest niepoprawne. AWS może przechwycić początkowy zrzut, ale zmiany z baz danych, które nie mają kluczy przyrostowych, nie mogą zostać przechwycone przez AWS Glue. Zobacz następującą stronę internetową:
aws.amazon.com/blogs/database/how-to-extract-transform-and-load-datafor-analytic-processing-using-aws-glue-part-2/
B jest niepoprawne, ponieważ AWS DMS nie może być używane do przechwytywania plików CSV.
C jest poprawne, ponieważ początkowy zrzut można wykonać za pomocą Glue, a przyrostowe przechwytywanie można wykonać za pomocą DMS dla baz danych i AWS Glue dla plików CSV.
D jest niepoprawne, ponieważ DMS nie może przechwytywać zmian ani początkowego zrzutu z plików CSV.
9. A. Amazon QuickSight nie pozwala na wprowadzanie zmian w danych w raportach.
10. A. Amazon QuickSight pozwala na tworzenie autonarracji. Zobacz następującą stronę internetową:
https://docs.aws.amazon.com/quicksight/latest/user/narratives-creating.html
