Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00397 008320 10495655 na godz. na dobę w sumie
Big Data. Najlepsze praktyki budowy skalowalnych systemów obsługi danych w czasie rzeczywistym - ebook/pdf
Big Data. Najlepsze praktyki budowy skalowalnych systemów obsługi danych w czasie rzeczywistym - ebook/pdf
Autor: , Liczba stron: 352
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-283-1895-3 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> bazy danych >> inne
Porównaj ceny (książka, ebook (-20%), audiobook).
Obsługa aplikacji, które operują na ogromnych zbiorach danych, czyli na przykład portali społecznościowych, przekracza możliwości zwykłych relacyjnych baz. Praca ze złożonymi zbiorami danych wymaga architektury obejmującej wielomaszynowe klastry, dzięki którym możliwe jest przechowywanie i przesyłanie informacji praktycznie dowolnej wielkości. Architektura taka powinna dodatkowo być prosta w użyciu, niezawodna i skalowalna.

Dzięki tej książce nauczysz się budować tego rodzaju architekturę. Zapoznasz się z technologią wykorzystywania klastrów maszyn. Dowiesz się, jak działają narzędzia przeznaczone specjalnie do przechwytywania i analizy danych na wielką skalę. W książce zaprezentowano łatwe do zrozumienia podejście do obsługi systemów wielkich zbiorów danych, które mogą być budowane i uruchamiane przez niewielki zespół. Nie zabrakło też wyczerpującego opisu praktycznej implementacji systemu Big Data z wykorzystaniem rzeczywistego przykładu.

W tej książce znajdziesz:

Big Data — to skalowalność i prostota obsługi wielkich ilości danych!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Tytuł oryginału: Big Data: Principles and best practices of scalable realtime data systems Tłumaczenie: Lech Lachowski Projekt okładki: Studio Gravite / Olsztyn Obarek, Pokoński, Pazdrijowski, Zaprucki ISBN: 978-83-283-1892-2 Original edition copyright © 2015 by Manning Publications Co. All rights reserved Polish edition copyright © 2016 by HELION SA. All rights reserved. All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the Publisher. Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Wydawnictwo HELION ul. Kościuszki 1c, 44-100 GLIWICE tel. 32 231 22 19, 32 230 98 63 e-mail: helion@helion.pl WWW: http://helion.pl (księgarnia internetowa, katalog książek) Materiały graficzne na okładce zostały wykorzystane za zgodą Shutterstock Images LLC. Pliki z przykładami omawianymi w książce można znaleźć pod adresem: ftp://ftp.helion.pl/przyklady/bigdat.zip Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/bigdat Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. Printed in Poland. • Kup książkę • Poleć książkę • Oceń książkę • Księgarnia internetowa • Lubię to! » Nasza społeczność Spis tre(cid:258)ci Przedmowa 11 Podzi(cid:218)kowania 13 O ksi(cid:200)(cid:285)ce 17 Rozdzia(cid:239) 1. Nowy paradygmat dla Big Data 19 1.1. 1.2. Zawarto(cid:258)(cid:202) ksi(cid:200)(cid:285)ki 20 Skalowanie tradycyjnej bazy danych 21 Skalowanie za pomoc(cid:200) kolejki 22 1.2.1. 1.2.2. Skalowanie przez sharding bazy danych 22 1.2.3. Rozpoczynaj(cid:200) si(cid:218) problemy z odporno(cid:258)ci(cid:200) na b(cid:239)(cid:218)dy 23 1.2.4. 1.2.5. Co posz(cid:239)o nie tak? 24 1.2.6. W jaki sposób techniki Big Data mog(cid:200) pomóc? 24 Problemy z uszkodzeniem danych 24 Pierwsze zasady 25 1.3. NoSQL nie jest panaceum 25 1.4. 1.5. Wymagane w(cid:239)a(cid:258)ciwo(cid:258)ci systemu Big Data 26 1.5.1. Niezawodno(cid:258)(cid:202) i odporno(cid:258)(cid:202) na b(cid:239)(cid:218)dy 26 1.5.2. Odczytywanie i aktualizowanie z nisk(cid:200) latencj(cid:200) 27 1.5.3. 1.5.4. Uogólnienie 27 1.5.5. Rozszerzalno(cid:258)(cid:202) 27 1.5.6. 1.5.7. Minimalna konserwacja 28 1.5.8. Debugowalno(cid:258)(cid:202) 28 Problemy z architekturami w pe(cid:239)ni przyrostowymi 29 1.6.1. 1.6.2. Ekstremalna z(cid:239)o(cid:285)ono(cid:258)(cid:202) osi(cid:200)gania spójno(cid:258)ci ostatecznej 30 1.6.3. Brak odporno(cid:258)ci na ludzkie b(cid:239)(cid:218)dy 32 1.6.4. Rozwi(cid:200)zanie w pe(cid:239)ni przyrostowe w porównaniu z architektur(cid:200) lambda 32 Z(cid:239)o(cid:285)ono(cid:258)(cid:202) operacyjna 29 Zapytania ad hoc 28 Skalowalno(cid:258)(cid:202) 27 1.6. 1.7. Architektura lambda 34 1.7.1. Warstwa przetwarzania wsadowego 36 1.7.2. Warstwa obs(cid:239)uguj(cid:200)ca 37 1.7.3. Warstwy przetwarzania wsadowego i obs(cid:239)uguj(cid:200)ca zapewniaj(cid:200) niemal wszystkie w(cid:239)a(cid:258)ciwo(cid:258)ci 37 1.7.4. Warstwa przetwarzania czasu rzeczywistego 39 1.8. Najnowsze trendy w technologii 41 Procesory nie staj(cid:200) si(cid:218) coraz szybsze 42 1.8.1. 1.8.2. Elastyczne chmury 42 1.8.3. Dynamiczny ekosystem open source dla Big Data 42 Poleć książkęKup książkę 4 Spis tre(cid:258)ci Przyk(cid:239)adowa aplikacja: SuperWebAnalytics.com 44 1.9. 1.10. Podsumowanie 44 CZ(cid:125)(cid:165)(cid:109) I. WARSTWA PRZETWARZANIA WSADOWEGO 47 Rozdzia(cid:239) 2. Model danych dla Big Data 49 2.1. W(cid:239)a(cid:258)ciwo(cid:258)ci danych 51 2.1.1. Dane s(cid:200) surowe 53 2.1.2. Dane s(cid:200) niemutowalne 56 2.1.3. Dane s(cid:200) wiecznie prawdziwe 59 2.2. Reprezentacja danych za pomoc(cid:200) modelu opartego na faktach 60 2.3. Przyk(cid:239)adowe fakty i ich w(cid:239)a(cid:258)ciwo(cid:258)ci 60 2.2.1. 2.2.2. Korzy(cid:258)ci ze stosowania modelu opartego na faktach 62 Schematy graficzne 66 2.3.1. Elementy schematu graficznego 66 2.3.2. Potrzeba zapewnienia egzekwowalno(cid:258)ci schematu 67 2.4. Kompletny model danych dla aplikacji SuperWebAnalytics.com 68 2.5. Podsumowanie 70 Rozdzia(cid:239) 3. Model danych dla Big Data: ilustracja 71 3.1. Dlaczego framework serializacji? 72 3.2. Apache Thrift 72 3.2.1. W(cid:218)z(cid:239)y 73 3.2.2. Kraw(cid:218)dzie 73 3.2.3. W(cid:239)a(cid:258)ciwo(cid:258)ci 74 3.2.4. 3.2.5. Ewolucja schematu 75 Po(cid:239)(cid:200)czenie wszystkich elementów w obiekty danych 75 3.3. Ograniczenia frameworku serializacji 76 3.4. Podsumowanie 78 Rozdzia(cid:239) 4. Przechowywanie danych w warstwie przetwarzania wsadowego 79 4.3. 4.4. 4.1. Wymagania dotycz(cid:200)ce przechowywania g(cid:239)ównego zbioru danych 80 4.2. Wybór rozwi(cid:200)zania pami(cid:218)ci masowej dla warstwy przetwarzania wsadowego 81 4.2.1. U(cid:285)ycie magazynu danych klucz-warto(cid:258)(cid:202) dla g(cid:239)ównego zbioru danych 82 4.2.2. Rozproszone systemy plików 82 Sposób dzia(cid:239)ania rozproszonych systemów plików 83 Przechowywanie g(cid:239)ównego zbioru danych z wykorzystaniem rozproszonego systemu plików 85 Partycjonowanie pionowe 86 4.5. 4.6. Niskopoziomowy charakter rozproszonych systemów plików 87 4.7. Przechowywanie g(cid:239)ównego zbioru danych aplikacji SuperWebAnalytics.com w rozproszonym systemie plików 89 Podsumowanie 90 4.8. Poleć książkęKup książkę Spis tre(cid:258)ci 5 Rozdzia(cid:239) 5. Przechowywanie danych w warstwie przetwarzania wsadowego: ilustracja 91 5.1. Korzystanie z Hadoop Distributed File System 92 Problem ma(cid:239)ych plików 93 Podstawowe operacje biblioteki Pail 95 Serializacja i umieszczanie obiektów w wiaderkach 96 5.1.1. 5.1.2. D(cid:200)(cid:285)enie do wy(cid:285)szego poziomu abstrakcji 93 Przechowywanie danych w warstwie przetwarzania wsadowego z wykorzystaniem biblioteki Pail 94 5.2.1. 5.2.2. 5.2.3. Operacje przetwarzania wsadowego z wykorzystaniem biblioteki Pail 98 5.2.4. 5.2.5. 5.2.6. Przechowywanie g(cid:239)ównego zbioru danych dla aplikacji SuperWebAnalytics.com 102 5.3.1. Ustrukturyzowane wiaderko dla obiektów Thrift 103 5.3.2. 5.3.3. Podsumowanie 107 Partycjonowanie pionowe z wykorzystaniem biblioteki Pail 99 Formaty plików i kompresja biblioteki Pail 100 Podsumowanie zalet biblioteki Pail 101 Podstawowe wiaderko dla aplikacji SuperWebAnalytics.com 104 Podzia(cid:239) wiaderka w celu pionowego partycjonowania zbioru danych 104 5.2. 5.3. 5.4. Rozdzia(cid:239) 6. Warstwa przetwarzania wsadowego 109 6.1. Przyk(cid:239)ady do rozwa(cid:285)enia 110 6.1.1. 6.1.2. 6.1.3. Liczba ods(cid:239)on w czasie 110 Inferencja p(cid:239)ci 111 Punkty wp(cid:239)ywu 111 6.2. Obliczenia w warstwie przetwarzania wsadowego 112 6.3. Porównanie algorytmów ponownego obliczania z algorytmami przyrostowymi 114 6.3.1. Wydajno(cid:258)(cid:202) 116 6.3.2. Odporno(cid:258)(cid:202) na ludzkie b(cid:239)(cid:218)dy 117 6.3.3. Ogólno(cid:258)(cid:202) algorytmów 117 6.3.4. Wybór stylu algorytmu 118 Skalowalno(cid:258)(cid:202) w warstwie przetwarzania wsadowego 119 6.4. 6.5. MapReduce: paradygmat dla oblicze(cid:241) Big Data 119 Skalowalno(cid:258)(cid:202) 121 6.5.1. 6.5.2. Odporno(cid:258)(cid:202) na b(cid:239)(cid:218)dy 123 6.5.3. Ogólno(cid:258)(cid:202) MapReduce 123 6.6. Niskopoziomowy charakter MapReduce 125 6.6.1. Wieloetapowe obliczenia s(cid:200) nienaturalne 125 6.6.2. Operacje (cid:239)(cid:200)czenia s(cid:200) bardzo skomplikowane do r(cid:218)cznej implementacji 126 6.6.3. Wykonywanie logiczne jest (cid:258)ci(cid:258)le powi(cid:200)zane z fizycznym 128 6.7. Diagramy potokowe: wy(cid:285)szy poziom sposobu my(cid:258)lenia na temat oblicze(cid:241) wsadowych 129 6.7.1. Koncepcje diagramów potokowych 129 6.7.2. Wykonywanie diagramów potokowych poprzez MapReduce 134 6.7.3. Agregator (cid:239)(cid:200)cz(cid:200)cy 134 6.7.4. Podsumowanie 136 Przyk(cid:239)ady diagramów potokowych 136 6.8. Poleć książkęKup książkę 6 Spis tre(cid:258)ci Rozdzia(cid:239) 7. Warstwa przetwarzania wsadowego: ilustracja 139 Przyk(cid:239)ad ilustracyjny 140 7.1. 7.2. Typowe pu(cid:239)apki narz(cid:218)dzi do przetwarzania danych 142 7.2.1. 7.2.2. J(cid:218)zyki niestandardowe 142 S(cid:239)abo komponowalne abstrakcje 143 7.3. Wprowadzenie do JCascalog 144 Struktura zapytania JCascalog 145 7.3.1. Model danych JCascalog 144 7.3.2. 7.3.3. Kwerendowanie wielu zbiorów danych 147 7.3.4. Grupowanie i agregatory 150 7.3.5. Analiza przyk(cid:239)adowego zapytania 150 7.3.6. Niestandardowe operacje predykatów 153 7.4. Kompozycja 158 (cid:146)(cid:200)czenie podzapyta(cid:241) 158 Podzapytania tworzone dynamicznie 159 7.4.1. 7.4.2. 7.4.3. Makra predykatów 162 7.4.4. Makra predykatów tworzone dynamicznie 164 Podsumowanie 166 7.5. Rozdzia(cid:239) 8. Przyk(cid:239)adowa warstwa przetwarzania wsadowego: 8.1. architektura i algorytmy 167 Projekt warstwy przetwarzania wsadowego aplikacji SuperWebAnalytics.com 168 8.1.1. Obs(cid:239)ugiwane zapytania 168 8.1.2. Obrazy wsadowe 169 Przegl(cid:200)d przep(cid:239)ywu pracy 172 Przyjmowanie nowych danych 174 8.2. 8.3. 8.4. Normalizacja adresów URL 174 8.5. Normalizacja identyfikatorów u(cid:285)ytkowników 175 8.6. Usuwanie zduplikowanych ods(cid:239)on 180 8.7. Obliczanie obrazów wsadowych 180 Liczba ods(cid:239)on w czasie 180 Liczba unikatowych u(cid:285)ytkowników w czasie 181 8.7.1. 8.7.2. 8.7.3. Analiza wspó(cid:239)czynnika odrzuce(cid:241) 182 Podsumowanie 183 8.8. Rozdzia(cid:239) 9. Przyk(cid:239)adowa warstwa przetwarzania wsadowego: implementacja 185 Punkt startowy 186 Przygotowanie przep(cid:239)ywu pracy 187 Przyjmowanie nowych danych 187 9.1. 9.2. 9.3. 9.4. Normalizacja adresów URL 191 9.5. Normalizacja identyfikatorów u(cid:285)ytkowników 192 9.6. Usuwanie zduplikowanych ods(cid:239)on 197 9.7. Obliczanie obrazów wsadowych 197 Liczba ods(cid:239)on w czasie 197 9.7.1. Poleć książkęKup książkę Spis tre(cid:258)ci 7 Liczba unikatowych u(cid:285)ytkowników w czasie 200 9.7.2. 9.7.3. Analiza wspó(cid:239)czynnika odrzuce(cid:241) 201 Podsumowanie 204 9.8. CZ(cid:125)(cid:165)(cid:109) II. WARSTWA OBS(cid:146)UGUJ(cid:107)CA 205 Rozdzia(cid:239) 10. Warstwa obs(cid:239)uguj(cid:200)ca 207 10.1. Metryki wydajno(cid:258)ci dla warstwy obs(cid:239)uguj(cid:200)cej 209 10.2. Rozwi(cid:200)zanie warstwy obs(cid:239)uguj(cid:200)cej dotycz(cid:200)ce problemu wyboru mi(cid:218)dzy normalizacj(cid:200) a denormalizacj(cid:200) 211 10.3. Wymagania wzgl(cid:218)dem bazy danych warstwy obs(cid:239)uguj(cid:200)cej 213 10.4. Projektowanie warstwy obs(cid:239)uguj(cid:200)cej dla aplikacji SuperWebAnalytics.com 215 10.4.1. Liczba ods(cid:239)on w czasie 215 10.4.2. Liczba u(cid:285)ytkowników w czasie 216 10.4.3. Analiza wspó(cid:239)czynnika odrzuce(cid:241) 217 10.5. Porównanie z rozwi(cid:200)zaniem w pe(cid:239)ni przyrostowym 217 10.5.1. W pe(cid:239)ni przyrostowe rozwi(cid:200)zanie problemu liczby unikatowych u(cid:285)ytkowników w czasie 218 10.5.2. Porównanie z rozwi(cid:200)zaniem opartym na architekturze lambda 224 10.6. Podsumowanie 224 Rozdzia(cid:239) 11. Warstwa obs(cid:239)uguj(cid:200)ca: ilustracja 227 11.1. Podstawy ElephantDB 228 11.1.1. Tworzenie obrazu w ElephantDB 228 11.1.2. Serwowanie obrazu w ElephantDB 229 11.1.3. Korzystanie z ElephantDB 229 11.2. Budowanie warstwy obs(cid:239)uguj(cid:200)cej dla aplikacji SuperWebAnalytics.com 231 11.2.1. Liczba ods(cid:239)on w czasie 231 11.2.2. Liczba unikatowych u(cid:285)ytkowników w czasie 234 11.2.3. Analiza wspó(cid:239)czynnika odrzuce(cid:241) 235 11.3. Podsumowanie 236 CZ(cid:125)(cid:165)(cid:109) III. WARSTWA PRZETWARZANIA CZASU RZECZYWISTEGO 237 Rozdzia(cid:239) 12. Obrazy czasu rzeczywistego 239 12.1. Obliczanie obrazów czasu rzeczywistego 241 12.2. Przechowywanie obrazów czasu rzeczywistego 242 12.2.1. Dok(cid:239)adno(cid:258)(cid:202) ostateczna 243 12.2.2. Ilo(cid:258)(cid:202) stanu przechowywanego w warstwie przetwarzania czasu rzeczywistego 244 12.3. Wyzwania oblicze(cid:241) przyrostowych 245 12.3.1. S(cid:239)uszno(cid:258)(cid:202) twierdzenia CAP 245 12.3.2. Kompleksowa interakcja mi(cid:218)dzy twierdzeniem CAP a algorytmami przyrostowymi 247 12.4. Porównanie aktualizacji asynchronicznych z synchronicznymi 249 12.5. Wygaszanie obrazów czasu rzeczywistego 250 12.6. Podsumowanie 253 Poleć książkęKup książkę 8 Spis tre(cid:258)ci Rozdzia(cid:239) 13. Obrazy czasu rzeczywistego: ilustracja 255 13.1. Model danych Cassandry 256 13.2. Korzystanie z bazy danych Cassandra 257 13.2.1. Zaawansowane funkcje Cassandry 259 13.3. Podsumowanie 259 Rozdzia(cid:239) 14. Kolejkowanie i przetwarzanie strumieniowe 261 14.1. Kolejkowanie 262 14.1.1. Serwery kolejek pojedynczego konsumenta 263 14.1.2. Kolejki wielu konsumentów 264 14.2. Przetwarzanie strumieniowe 265 14.2.1. Kolejki i procesy robocze 266 14.2.2. Pu(cid:239)apki paradygmatu „kolejki i procesy robocze” 267 14.3. Pojedyncze przetwarzanie strumieniowe wy(cid:285)szego poziomu 268 14.3.1. Model Storm 268 14.3.2. Zapewnianie przetwarzania komunikatów 272 14.4. Warstwa przetwarzania czasu rzeczywistego dla aplikacji SuperWebAnalytics.com 274 14.4.1. Struktura topologii 277 14.5. Podsumowanie 278 Rozdzia(cid:239) 15. Kolejkowanie i przetwarzanie strumieniowe: ilustracja 281 15.1. Definiowanie topologii za pomoc(cid:200) Apache Storm 281 15.2. Klastry Apache Storm i wdra(cid:285)anie topologii 284 15.3. Gwarantowanie przetwarzania komunikatów 286 15.4. Implementacja warstwy przetwarzania czasu rzeczywistego aplikacji SuperWebAnalytics.com dla liczby unikatowych u(cid:285)ytkowników w czasie 288 15.5. Podsumowanie 292 Rozdzia(cid:239) 16. Mikrowsadowe przetwarzanie strumieniowe 293 16.1. Osi(cid:200)ganie semantyki „dok(cid:239)adnie raz” 294 16.1.1. (cid:165)ci(cid:258)le uporz(cid:200)dkowane przetwarzanie 294 16.1.2. Mikrowsadowe przetwarzanie strumieniowe 295 16.1.3. Topologie przetwarzania mikrowsadowego 296 16.2. Podstawowe koncepcje mikrowsadowego przetwarzania strumieniowego 299 16.3. Rozszerzanie diagramów potokowych dla przetwarzania mikrowsadowego 300 16.4. Doko(cid:241)czenie warstwy przetwarzania czasu rzeczywistego dla aplikacji SuperWebAnalytics.com 302 16.4.1. Liczba ods(cid:239)on w czasie 302 16.4.2. Analiza wspó(cid:239)czynnika odrzuce(cid:241) 302 16.5. Inne spojrzenie na przyk(cid:239)ad analizy wspó(cid:239)czynnika odrzuce(cid:241) 307 16.6. Podsumowanie 308 Poleć książkęKup książkę Spis tre(cid:258)ci 9 Rozdzia(cid:239) 17. Mikrowsadowe przetwarzanie strumieniowe: ilustracja 309 17.1. Korzystanie z interfejsu Trident 310 17.2. Doko(cid:241)czenie warstwy przetwarzania czasu rzeczywistego dla aplikacji SuperWebAnalytics.com 313 17.2.1. Liczba ods(cid:239)on w czasie 314 17.2.2. Analiza wspó(cid:239)czynnika odrzuce(cid:241) 316 17.3. W pe(cid:239)ni odporne na b(cid:239)(cid:218)dy przetwarzanie mikrowsadowe z utrzymywaniem stanu w pami(cid:218)ci 322 17.4. Podsumowanie 323 Rozdzia(cid:239) 18. Tajniki architektury lambda 325 18.1. Definiowanie systemów danych 325 18.2. Warstwa przetwarzania wsadowego i warstwa obs(cid:239)uguj(cid:200)ca 327 18.2.1. Przyrostowe przetwarzanie wsadowe 328 18.2.2. Pomiar i optymalizacja wykorzystania zasobów przez warstw(cid:218) przetwarzania wsadowego 335 18.3. Warstwa przetwarzania czasu rzeczywistego 339 18.4. Warstwa zapyta(cid:241) 340 18.5. Podsumowanie 341 Skorowidz 343 Poleć książkęKup książkę 10 Spis tre(cid:258)ci Poleć książkęKup książkę Nowy paradygmat dla Big Data W tym rozdziale omówione zostan(cid:261) nast(cid:266)puj(cid:261)ce zagadnienia: (cid:81) typowe problemy pojawiaj(cid:261)ce si(cid:266) podczas skalowania tradycyjnej bazy danych; (cid:81) dlaczego NoSQL nie jest panaceum; (cid:81) my(cid:286)lenie o systemach Big Data od pierwszych zasad; (cid:81) krajobraz narz(cid:266)dzi Big Data; (cid:81) wprowadzenie przyk(cid:225)adowej aplikacji SuperWebAnalytics.com. W ci(cid:200)gu ostatniej dekady znacznie wzros(cid:239)a ilo(cid:258)(cid:202) tworzonych danych. Co sekund(cid:218) gene- rowanych jest ponad 30 000 gigabajtów danych, a tempo tworzenia danych ca(cid:239)y czas ro(cid:258)nie. Dane, z którymi mamy do czynienia, s(cid:200) zró(cid:285)nicowane. U(cid:285)ytkownicy tworz(cid:200) tre(cid:258)ci, takie jak posty na blogach, tweety, interakcje na portalach spo(cid:239)eczno(cid:258)ciowych oraz zdj(cid:218)cia. Serwery ci(cid:200)gle rejestruj(cid:200) komunikaty dotycz(cid:200)ce przeprowadzanych operacji. Naukowcy tworz(cid:200) szczegó(cid:239)owe pomiary otaczaj(cid:200)cego nas (cid:258)wiata. Rozleg(cid:239)o(cid:258)(cid:202) internetu jako osta- tecznego (cid:283)ród(cid:239)a danych jest niemal niepoj(cid:218)ta. Ten zadziwiaj(cid:200)cy wzrost ilo(cid:258)ci danych znacz(cid:200)co wp(cid:239)yn(cid:200)(cid:239) na dzia(cid:239)anie przedsi(cid:218)biorstw. Tradycyjne systemy baz danych, takie jak relacyjne bazy danych, zosta(cid:239)y wykorzystane do granic. W rosn(cid:200)cej liczbie przypadków te systemy za(cid:239)amuj(cid:200) si(cid:218) pod naciskiem Poleć książkęKup książkę 20 ROZDZIA(cid:224) 1. Nowy paradygmat dla Big Data „wielkich zbiorów danych” (ang. Big Data). Nie powiod(cid:239)o si(cid:218) skalowanie do Big Data tradycyjnych systemów i zwi(cid:200)zanych z nimi technik zarz(cid:200)dzania danymi. W celu sprostania wyzwaniom Big Data opracowany zosta(cid:239) nowy rodzaj technologii. Wiele z tych nowych technologii zosta(cid:239)o zgrupowanych pod poj(cid:218)ciem NoSQL. W nie- których aspektach s(cid:200) one bardziej skomplikowane ni(cid:285) tradycyjne bazy danych, a w innych s(cid:200) od nich prostsze. Systemy te mo(cid:285)na skalowa(cid:202) do znacznie wi(cid:218)kszych zbiorów danych, ale u(cid:285)ycie wspomnianych technologii rzeczywi(cid:258)cie wymaga zasadniczo nowego zestawu technik. Nie s(cid:200) one uniwersalnymi rozwi(cid:200)zaniami. Wiele z tych systemów Big Data zosta(cid:239)o zapocz(cid:200)tkowanych przez firm(cid:218) Google — w tym rozproszone systemy plików, platforma MapReduce do przetwarzania równole- g(cid:239)ego oraz rozproszone us(cid:239)ugi blokowania. Innym godnym uwagi pionierem w tej dzie- dzinie by(cid:239)a firma Amazon, która stworzy(cid:239)a nowatorski, rozproszony magazyn danych typu klucz-warto(cid:258)(cid:202) o nazwie Dynamo. W kolejnych latach spo(cid:239)eczno(cid:258)(cid:202) open source odpowiedzia(cid:239)a niezliczonymi projektami, takimi jak Hadoop, HBase, MongoDB, Cas- sandra czy RabbitMQ. Ta ksi(cid:200)(cid:285)ka koncentruje si(cid:218) w podobnym stopniu na z(cid:239)o(cid:285)ono(cid:258)ci, co na skalowalno(cid:258)ci. Aby sprosta(cid:202) wyzwaniom zwi(cid:200)zanym z Big Data, przeanalizujemy na nowo systemy danych od podstaw. Dowiesz si(cid:218), (cid:285)e niektóre z najbardziej podstawowych sposobów zarz(cid:200)dzania danymi w tradycyjnych systemach (takie jak systemy zarz(cid:200)dzania relacyj- nymi bazami danych, ang. Relational Database Management System — RDBMS) s(cid:200) zbyt skomplikowane dla systemów Big Data. Prostszym, alternatywnym podej(cid:258)ciem jest nowy paradygmat dla Big Data, którym si(cid:218) zajmiemy. Nazwali(cid:258)my to podej(cid:258)cie archi- tektur(cid:200) lambda (ang. Lambda Architecture). W tym, zarazem pierwszym, rozdziale zbadamy „problem wielkich zbiorów danych” i zobaczymy, dlaczego potrzebny jest nowy paradygmat dla Big Data. Poznamy nie- bezpiecze(cid:241)stwa zwi(cid:200)zane z niektórymi tradycyjnymi technikami skalowania i odkry- jemy kilka powa(cid:285)nych wad tradycyjnego sposobu budowania systemów danych. Roz- poczynaj(cid:200)c od podstawowych zasad systemów danych, okre(cid:258)limy inny sposób budowania tych systemów, który pozwoli unikn(cid:200)(cid:202) z(cid:239)o(cid:285)ono(cid:258)ci tradycyjnych technik. Zobaczymy, w jaki sposób najnowsze trendy w technologii zach(cid:218)caj(cid:200) do korzystania z nowych rodza- jów systemów, a na koniec przyjrzymy si(cid:218) przyk(cid:239)adowemu systemowi Big Data, który b(cid:218)dziemy budowa(cid:202) w tej ksi(cid:200)(cid:285)ce w celu zilustrowania kluczowych poj(cid:218)(cid:202). 1.1. Zawarto(cid:286)(cid:252) ksi(cid:261)(cid:298)ki T(cid:218) ksi(cid:200)(cid:285)k(cid:218) nale(cid:285)y traktowa(cid:202) przede wszystkim jako podr(cid:218)cznik teoretyczny, koncentru- j(cid:200)cy si(cid:218) na sposobach podej(cid:258)cia do tworzenia rozwi(cid:200)za(cid:241) wszystkich problemów zwi(cid:200)- zanych z Big Data. Zasady, które poznasz, s(cid:200) prawdziwe niezale(cid:285)nie od stosowanych obecnie narz(cid:218)dzi i mo(cid:285)esz je wykorzysta(cid:202) przy rygorystycznym podejmowaniu decyzji w kwestii narz(cid:218)dzi odpowiednich dla danej aplikacji. Ta ksi(cid:200)(cid:285)ka nie jest przegl(cid:200)dem baz danych, systemów obliczeniowych ani innych powi(cid:200)zanych z nimi technologii. Chocia(cid:285) w trakcie lektury dowiesz si(cid:218), jak korzysta(cid:202) z wielu narz(cid:218)dzi, takich jak Hadoop, Cassandra, Storm i Thrift, omawiana ksi(cid:200)(cid:285)ka sama w sobie nie ma na celu prezentacji dzia(cid:239)ania tych narz(cid:218)dzi. S(cid:200) one raczej (cid:258)rodkiem Poleć książkęKup książkę 1.2. Skalowanie tradycyjnej bazy danych 21 s(cid:239)u(cid:285)(cid:200)cym do poznania podstawowych zasady tworzenia architektury dla solidnych i ska- lowalnych systemów danych. Zaprezentowanie szczegó(cid:239)owego zestawienia porów- nawczego tych narz(cid:218)dzi nie zda(cid:239)oby egzaminu, poniewa(cid:285) oderwa(cid:239)oby Ci(cid:218) po prostu od nauki podstawowych zasad. Innymi s(cid:239)owy, dowiesz si(cid:218), jak (cid:239)owi(cid:202) ryby, a nie tylko, jak u(cid:285)ywa(cid:202) konkretnej w(cid:218)dki. W tym duchu przygotowana zosta(cid:239)a struktura tej ksi(cid:200)(cid:285)ki, bazuj(cid:200)ca na podziale na rozdzia(cid:239)y teoretyczne i ilustruj(cid:200)ce konkretne zagadnienia. Mo(cid:285)esz przeczyta(cid:202) tylko rozdzia(cid:239)y teoretyczne i dzi(cid:218)ki temu w pe(cid:239)ni zrozumie(cid:202), jak budowa(cid:202) systemy wielkich zbiorów danych, ale uwa(cid:285)amy, (cid:285)e proces mapowania tej teorii na konkretne narz(cid:218)dzia przedstawiony w rozdzia(cid:239)ach ilustruj(cid:200)cych daje bogatsze, bardziej wszechstronne zro- zumienie materia(cid:239)u. Nie pozwól si(cid:218) jednak zwie(cid:258)(cid:202) tym nazwom — w rozdzia(cid:239)ach teoretycznych wykorzy- stywanych jest wiele przyk(cid:239)adów. G(cid:239)ówny przyk(cid:239)ad w tej ksi(cid:200)(cid:285)ce (aplikacja Super- WebAnalytics.com) jest wykorzystywany zarówno w rozdzia(cid:239)ach teoretycznych, jak i ilustruj(cid:200)cych. W rozdzia(cid:239)ach teoretycznych znajdziesz algorytmy, projekty indeksów i architektur(cid:218) dla aplikacji SuperWebAnalytics.com. W rozdzia(cid:239)ach ilustruj(cid:200)cych pro- jekty te zostan(cid:200) zmapowane na funkcjonuj(cid:200)cy kod za pomoc(cid:200) konkretnych narz(cid:218)dzi. 1.2. Skalowanie tradycyjnej bazy danych Zacznijmy nasz(cid:200) eksploracj(cid:218) Big Data od miejsca, w którym zaczyna wielu programi- stów: od osi(cid:200)gni(cid:218)cia granic tradycyjnych technologii baz danych. Za(cid:239)ó(cid:285)my, (cid:285)e Twój szef prosi Ci(cid:218), (cid:285)eby(cid:258) zbudowa(cid:239) prost(cid:200) aplikacj(cid:218) s(cid:239)u(cid:285)(cid:200)c(cid:200) do analityki internetowej. Aplikacja powinna (cid:258)ledzi(cid:202) liczb(cid:218) ods(cid:239)on strony dla dowolnego adresu URL wybranego przez klienta. Strona klienta ma pingowa(cid:202) serwer WWW aplikacji ze swojego adresu URL za ka(cid:285)dym razem, gdy otrzymywana jest informacja o ods(cid:239)onie. Dodatkowo aplikacja powinna by(cid:202) w stanie w dowolnym momencie dostarczy(cid:202) zestawienie 100 adre- sów URL z najwi(cid:218)ksz(cid:200) liczb(cid:200) ods(cid:239)on. Zaczynasz od tradycyjnego schematu relacyj- nego dla ods(cid:239)on strony, który wygl(cid:200)da mniej wi(cid:218)- cej tak, jak przedstawiono na rysunku 1.1. Twój back-end sk(cid:239)ada si(cid:218) z systemu RDBMS z tabel(cid:200) tego schematu oraz serwera WWW. Za ka(cid:285)dym razem, gdy kto(cid:258) (cid:239)aduje stron(cid:218) (cid:258)ledzon(cid:200) przez Twoj(cid:200) aplikacj(cid:218), strona ta pinguje Twój serwer WWW, informuj(cid:200)c o ods(cid:239)onie, a serwer zwi(cid:218)ksza warto(cid:258)(cid:202) odpowiedniego wiersza w bazie danych. Zobaczmy, jakie problemy b(cid:218)d(cid:200) si(cid:218) pojawia(cid:202) wraz z rozwijaniem tej aplikacji. Jak sam si(cid:218) prze- konasz, napotkamy problemy zarówno ze skalowal- no(cid:258)ci(cid:200), jak i z(cid:239)o(cid:285)ono(cid:258)ci(cid:200). Rysunek 1.1. Schemat relacyjny prostej aplikacji analitycznej Poleć książkęKup książkę 22 ROZDZIAŁ 1. Nowy paradygmat dla Big Data 1.2.1. Skalowanie za pomocą kolejki Przygotowany przez Ciebie produkt do analityki internetowej okazał się ogromnym sukcesem, a ruch kierowany do aplikacji rośnie jak niekontrolowany pożar. Twoja firma wydaje wielkie przyjęcie, ale w środku uroczystości zaczynasz otrzymywać mnóstwo e-maili z systemu monitorującego. We wszystkich e-mailach znajduje się ta sama infor- macja: „Błąd limitu czasu podczas wstawiania do bazy danych”. Przeglądasz wpisy dziennika i odkrywasz oczywisty problem. Baza danych nie może sprostać obciążeniu, przekraczany jest więc limit czasu dla żądań zapisania zwiększenia liczby odsłon stron. Trzeba coś zrobić, aby rozwiązać ten problem, i należy to zrobić szybko. Zdajesz sobie sprawę, że marnotrawstwem jest wykonywanie za każdym razem tylko jednego zwięk- szenia liczby odsłon w bazie danych. Bardziej efektywne może być zgromadzenie wielu inkrementacji w jednym żądaniu. Aby to umożliwić, modyfikujesz architekturę back-endu. Bezpośrednią komunikację serwera WWW z bazą danych zastępujesz kolejką między serwerem WWW a bazą danych. Gdy teraz otrzymasz informację o nowej odsłonie, zdarzenie zostanie dodane do kolejki. Następnie tworzysz proces robo- czy, który odczytuje za jednym razem 100 zdarzeń z kolejki i łączy je w jedną aktu- alizację bazy danych. Przedstawiono to na rysunku 1.2. Rysunek 1.2. Grupowanie aktualizacji za pomocą kolejki i procesu roboczego Ten schemat dobrze się sprawdza i rozwiązuje problemy związane z przekracza- niem limitu czasu. Otrzymujesz nawet pewien bonus. Polega on na tym, że jeśli baza danych znowu zostanie przeciążona, kolejka po prostu będzie robić się coraz większa i nie będziesz miał do czynienia z przekroczeniem limitu czasu dla serwera WWW, co mogłoby potencjalnie powodować utratę danych. 1.2.2. Skalowanie przez sharding bazy danych Niestety dodanie kolejki i przeprowadzanie zbiorczych aktualizacji okazuje się tylko plastrem opatrunkowym dla problemu skalowania. Twoja aplikacja nadal zyskuje na popularności, a baza danych ponownie jest przeciążana. Twój proces roboczy nie może nadążyć z przeprowadzaniem operacji zapisu, zatem próbujesz dodać więcej proce- sów roboczych, aby zapewnić równoległe aktualizacje. Niestety to nie pomaga. Baza danych jest najwyraźniej wąskim gardłem. Szukasz w wyszukiwarce Google sposobów skalowania relacyjnej bazy danych mocno obciążonej operacjami zapisu. Dowiadujesz się, że najlepszym sposobem jest użycie wielu serwerów baz danych i rozłożenie tabeli na wszystkie te serwery. Każdy serwer będzie posiadał podzbiór danych dla tabeli. Nazywa się to partycjonowaniem poziomym lub shardingiem. Ta technika pozwala rozłożyć obciążenie związane z operacjami zapisu na wiele maszyn. Poleć książkęKup książkę 1.2. Skalowanie tradycyjnej bazy danych 23 U(cid:285)ywana przez Ciebie technika shardingu polega na wybieraniu sharda dla ka(cid:285)- dego klucza za pomoc(cid:200) skrótu klucza zmodowanego przez liczb(cid:218) shardów. Mapowanie kluczy na shardy z wykorzystaniem funkcji skrótu powoduje, (cid:285)e klucze s(cid:200) równomiernie dystrybuowane pomi(cid:218)dzy shardami. Piszesz skrypt do mapowania na wszystkie wiersze w Twojej pojedynczej instancji bazy danych i dzielisz dane na cztery shardy. Wpro- wadzenie tego rozwi(cid:200)zania wymaga nieco czasu, tak wi(cid:218)c do momentu zako(cid:241)czenia operacji wy(cid:239)(cid:200)czasz proces roboczy zwi(cid:218)kszaj(cid:200)cy liczniki ods(cid:239)on. W przeciwnym razie straci(cid:239)by(cid:258) inkrementacje w okresie przej(cid:258)ciowym. Na koniec ca(cid:239)y kod aplikacji musi „wiedzie(cid:202)”, jak znale(cid:283)(cid:202) shard dla ka(cid:285)dego klucza. Opakowujesz wi(cid:218)c kod do obs(cid:239)ugi bazy danych za pomoc(cid:200) biblioteki, która odczytuje liczb(cid:218) shardów z pliku konfiguracyjnego, a potem przeorganizowujesz ca(cid:239)y kod apli- kacji. Musisz zmodyfikowa(cid:202) zapytanie o 100 najpopularniejszych adresów URL, aby pobiera(cid:202) 100 adresów z ka(cid:285)dego sharda i na tej podstawie generowa(cid:202) globaln(cid:200) list(cid:218) 100 najpopularniejszych adresów URL. Wraz z coraz wi(cid:218)kszym wzrostem popularno(cid:258)ci aplikacji musisz ca(cid:239)y czas dzieli(cid:202) baz(cid:218) danych na coraz wi(cid:218)ksz(cid:200) liczb(cid:218) shardów, aby nad(cid:200)(cid:285)y(cid:202) za rosn(cid:200)cym obci(cid:200)(cid:285)eniem zwi(cid:200)zanym z operacjami zapisu. Za ka(cid:285)dym razem staje si(cid:218) to coraz bardziej bolesne, poniewa(cid:285) jest bardzo wiele pracy do skoordynowania. Nie mo(cid:285)esz te(cid:285) po prostu uru- chomi(cid:202) jednego skryptu, który przeprowadzi resharding, poniewa(cid:285) by(cid:239)oby to zbyt wolne. Wszystkie czynno(cid:258)ci zwi(cid:200)zane z reshardingiem musisz wykonywa(cid:202) równolegle i zarz(cid:200)- dza(cid:202) wieloma aktywnymi skryptami roboczymi naraz. Je(cid:258)li zapomnisz zaktualizowa(cid:202) kod aplikacji now(cid:200) liczb(cid:200) shardów, spowoduje to, (cid:285)e wiele inkrementacji zostanie zapisa- nych w niew(cid:239)a(cid:258)ciwych shardach. Musisz wi(cid:218)c napisa(cid:202) jednorazowy skrypt, który sprawdzi dane i przeniesie te, które zosta(cid:239)y umieszczone w niew(cid:239)a(cid:258)ciwym miejscu. 1.2.3. Rozpoczynaj(cid:261) si(cid:266) problemy z odporno(cid:286)ci(cid:261) na b(cid:225)(cid:266)dy W ko(cid:241)cu masz tyle shardów, (cid:285)e nierzadkim przypadkiem jest awaria dysku w jednej z maszyn bazodanowych. Gdy maszyna jest wy(cid:239)(cid:200)czona, ta cz(cid:218)(cid:258)(cid:202) danych jest niedost(cid:218)pna. Aby temu zaradzi(cid:202), robisz kilka rzeczy: (cid:81) Aktualizujesz swój system „kolejka-proces roboczy” w taki sposób, aby inkre- mentacje dla niedost(cid:218)pnych shardów by(cid:239)y umieszczane w osobnej kolejce, któr(cid:200) próbujesz opró(cid:285)nia(cid:202) raz na pi(cid:218)(cid:202) minut, jako „oczekuj(cid:200)ce”. (cid:81) Wykorzystujesz mo(cid:285)liwo(cid:258)ci replikacji bazy danych, aby dla ka(cid:285)dego sharda nadrz(cid:218)dnego (ang. master shard) doda(cid:202) shard podrz(cid:218)dny (ang. slave shard). W ten sposób w wypadku awarii sharda nadrz(cid:218)dnego b(cid:218)dziesz mia(cid:239) kopi(cid:218) zapasow(cid:200). W shardzie podrz(cid:218)dnym nie b(cid:218)d(cid:200) przeprowadzane operacje zapisu, ale przynajm- niej klienci b(cid:218)d(cid:200) mogli nadal przegl(cid:200)da(cid:202) statystyki w aplikacji. My(cid:258)lisz sobie: „Na pocz(cid:200)tku zajmowa(cid:239)em si(cid:218) tworzeniem nowych funkcji dla klientów. Teraz wydaje si(cid:218), (cid:285)e ca(cid:239)y swój czas po(cid:258)wi(cid:218)cam jedynie na rozwi(cid:200)zywanie problemów z operacjami odczytu i zapisu danych”. Poleć książkęKup książkę 24 ROZDZIA(cid:224) 1. Nowy paradygmat dla Big Data 1.2.4. Problemy z uszkodzeniem danych Podczas pracy nad kodem „kolejka-proces roboczy” przypadkowo wdra(cid:285)asz w (cid:258)rodo- wisku produkcyjnym b(cid:239)(cid:200)d, który dla ka(cid:285)dego adresu URL zwi(cid:218)ksza liczb(cid:218) ods(cid:239)on strony o dwie zamiast o jedn(cid:200). Zauwa(cid:285)asz to 24 godziny pó(cid:283)niej, ale szkoda ju(cid:285) zosta(cid:239)a wyrz(cid:200)- dzona. Twoje cotygodniowe kopie zapasowe nie pomagaj(cid:200), poniewa(cid:285) nie ma mo(cid:285)li- wo(cid:258)ci dowiedzie(cid:202) si(cid:218), które dane zosta(cid:239)y uszkodzone. W(cid:239)o(cid:285)y(cid:239)e(cid:258) wiele pracy w to, aby uczyni(cid:202) swój system skalowalnym i odpornym na awarie maszyn, ale nie jest on odporny na b(cid:239)(cid:218)dy pope(cid:239)niane przez cz(cid:239)owieka. A je(cid:258)li w zakresie oprogramowania istnieje jaka(cid:258) gwarancja, to taka, (cid:285)e b(cid:239)(cid:218)dy nieuchronnie przenikn(cid:200) do (cid:258)rodowiska produkcyjnego, bez wzgl(cid:218)du na to, jak bardzo b(cid:218)dziesz si(cid:218) stara(cid:239) temu zapobiec. 1.2.5. Co posz(cid:225)o nie tak? Wraz z ewolucj(cid:200) prostej aplikacji do analizy internetowej system stawa(cid:239) si(cid:218) coraz bar- dziej z(cid:239)o(cid:285)ony: kolejki, shardy, replikacje, skrypty reshardinguj(cid:200)ce itd. Rozwijanie aplika- cji opieraj(cid:200)cej si(cid:218) na danych wymaga znacznie wi(cid:218)cej ni(cid:285) tylko znajomo(cid:258)ci schematu bazy danych. Twój kod musi „wiedzie(cid:202)”, jak komunikowa(cid:202) si(cid:218) z w(cid:239)a(cid:258)ciwymi shardami, a je(cid:258)li pope(cid:239)nisz b(cid:239)(cid:200)d, nic nie zapobiegnie sytuacjom odczytu z niew(cid:239)a(cid:258)ciwego sharda lub zapisu na nim. Jednym z problemów jest to, (cid:285)e baza danych nie jest (cid:258)wiadoma swojego rozpro- szonego charakteru, nie mo(cid:285)e wi(cid:218)c Ci pomóc upora(cid:202) si(cid:218) z shardami, replikacjami i roz- proszonymi zapytaniami. Ca(cid:239)a ta z(cid:239)o(cid:285)ono(cid:258)(cid:202) zosta(cid:239)a na Tobie wymuszona zarówno w kwe- stii obs(cid:239)ugi bazy danych, jak i rozwijania kodu aplikacji. Ale najwi(cid:218)kszym problemem jest to, (cid:285)e system nie zosta(cid:239) zaprojektowany z uwzgl(cid:218)d- nieniem ludzkich b(cid:239)(cid:218)dów. Wr(cid:218)cz przeciwnie: system staje si(cid:218) coraz bardziej z(cid:239)o(cid:285)ony, co zwi(cid:218)ksza prawdopodobie(cid:241)stwo pope(cid:239)niania b(cid:239)(cid:218)dów. B(cid:239)(cid:218)dy w oprogramowaniu s(cid:200) nieuniknione, je(cid:258)li wi(cid:218)c nie uwzgl(cid:218)dnisz ich w projekcie, mo(cid:285)esz równie dobrze pisa(cid:202) skrypty, które losowo uszkadzaj(cid:200) dane. Wykonywanie kopii zapasowych nie wystarczy. System musi by(cid:202) dok(cid:239)adnie przemy(cid:258)lany pod wzgl(cid:218)dem ograniczenia szkód, jakie mo(cid:285)e spowodowa(cid:202) ludzka pomy(cid:239)ka. Odporno(cid:258)(cid:202) na b(cid:239)(cid:218)dy cz(cid:239)owieka nie jest opcjonalna. Jest zasadnicz(cid:200) kwesti(cid:200), zw(cid:239)aszcza, gdy wielkie zbiory danych w tak du(cid:285)ym stopniu zwi(cid:218)k- szaj(cid:200) z(cid:239)o(cid:285)ono(cid:258)(cid:202) budowania aplikacji. 1.2.6. W jaki sposób techniki Big Data mog(cid:261) pomóc? Techniki Big Data, których si(cid:218) nauczysz, rozwi(cid:200)zuj(cid:200) te problemy skalowalno(cid:258)ci i z(cid:239)o(cid:285)o- no(cid:258)ci w radykalny sposób. Przede wszystkim bazy danych oraz systemy obliczeniowe u(cid:285)ywane dla wielkich zbiorów danych s(cid:200) (cid:258)wiadome swojego rozproszonego charakteru. Dlatego elementy takie jak sharding i replikacje s(cid:200) obs(cid:239)ugiwane za Ciebie. Nigdy nie znajdziesz si(cid:218) w sytuacji, w której przypadkowo b(cid:218)dziesz kwerendowa(cid:202) niew(cid:239)a(cid:258)ciwy shard, poniewa(cid:285) ta logika jest zinternalizowana w bazie danych. Kiedy dojdzie do ska- lowania, b(cid:218)dziesz po prostu dodawa(cid:202) w(cid:218)z(cid:239)y, a systemy automatycznie zrównowa(cid:285)(cid:200) obci(cid:200)(cid:285)enie, rozk(cid:239)adaj(cid:200)c je na nowe w(cid:218)z(cid:239)y. Kolejna podstawowa technika, któr(cid:200) poznasz, sprawia, (cid:285)eby dane by(cid:239)y niemutowalne. Zamiast przechowywania liczby ods(cid:239)on stron jako podstawowego zbioru danych, stale Poleć książkęKup książkę 1.3. NoSQL nie jest panaceum 25 podlegaj(cid:200)cego mutacji wraz z pojawianiem si(cid:218) nowych ods(cid:239)on, przechowywane s(cid:200) surowe informacje o ods(cid:239)onach stron. Te surowe informacje nigdy nie s(cid:200) modyfikowane. Kiedy wi(cid:218)c si(cid:218) pomylisz, mo(cid:285)esz zapisa(cid:202) z(cid:239)e dane, ale przynajmniej nie zniszczysz dobrych danych. Jest to o wiele silniejsza gwarancja odporno(cid:258)ci na ludzkie b(cid:239)(cid:218)dy ni(cid:285) w tradycyjnym systemie opartym na mutacji. W tradycyjnych bazach danych nale(cid:285)y ostro(cid:285)nie u(cid:285)ywa(cid:202) niemutowalnych danych, gdy(cid:285) takie zbiory danych b(cid:218)d(cid:200) szybko si(cid:218) powi(cid:218)ksza(cid:202). Poniewa(cid:285) jednak techniki Big Data pozwalaj(cid:200) skalowa(cid:202) do tak du(cid:285)ej ilo(cid:258)ci danych, mo(cid:285)esz inaczej projektowa(cid:202) systemy. 1.3. NoSQL nie jest panaceum W ci(cid:200)gu ostatnich 10 lat pojawi(cid:239)a si(cid:218) ogromna liczba innowacji w zakresie skalowalnych systemów danych. Nale(cid:285)(cid:200) do nich systemy oblicze(cid:241) wielkoskalowych, takie jak Hadoop, oraz baz danych, takie jak Cassandra i Riak. Te systemy mog(cid:200) obs(cid:239)ugiwa(cid:202) bardzo du(cid:285)e ilo(cid:258)ci danych, ale wymuszaj(cid:200) te(cid:285) powa(cid:285)ne kompromisy. Hadoop mo(cid:285)e na przyk(cid:239)ad czyni(cid:202) paralelnymi wielkoskalowe obliczenia wsadowe przeprowadzane na bardzo du(cid:285)ej ilo(cid:258)ci danych, ale obliczenia te maj(cid:200) spore opó(cid:283)nienia. Nie nale(cid:285)y u(cid:285)ywa(cid:202) Hadoopa w sytuacjach, w których wymagane s(cid:200) wyniki z nisk(cid:200) latencj(cid:200). Bazy danych NoSQL, takie jak Cassandra, osi(cid:200)gaj(cid:200) swoj(cid:200) skalowalno(cid:258)(cid:202), oferuj(cid:200)c znacznie bardziej ograniczony model danych ni(cid:285) ten, do którego przywyk(cid:239)e(cid:258) w wypadku SQL. Dostosowanie aplikacji do tych ograniczonych modeli danych mo(cid:285)e by(cid:202) bardzo z(cid:239)o(cid:285)one. A poniewa(cid:285) te bazy danych s(cid:200) mutowalne, nie zapewniaj(cid:200) odporno(cid:258)ci na ludzkie b(cid:239)(cid:218)dy. Te narz(cid:218)dzia same w sobie nie s(cid:200) panaceum. Jednak inteligentnie ze sob(cid:200) po(cid:239)(cid:200)czone mog(cid:200) tworzy(cid:202) skalowalne systemy do obs(cid:239)ugi dowolnych danych, charakteryzuj(cid:200)ce si(cid:218) odporno(cid:258)ci(cid:200) na ludzkie b(cid:239)(cid:218)dy i minimaln(cid:200) z(cid:239)o(cid:285)ono(cid:258)ci(cid:200). To jest w(cid:239)a(cid:258)nie architektura lambda, któr(cid:200) poznasz w tej ksi(cid:200)(cid:285)ce. 1.4. Pierwsze zasady Aby dowiedzie(cid:202) si(cid:218), jak prawid(cid:239)owo budowa(cid:202) systemy danych, nale(cid:285)y cofn(cid:200)(cid:202) si(cid:218) do pierwszych zasad. Co robi(cid:200) systemy danych na najbardziej podstawowym poziomie? Zacznijmy od intuicyjnej definicji: system danych odpowiada na pytania na pod- stawie informacji pozyskanych do momentu zadania pytania. Tak wi(cid:218)c profil na por- talu spo(cid:239)eczno(cid:258)ciowym odpowiada na pytania typu: „Jakie jest imi(cid:218) i nazwisko danej osoby?” oraz „Ilu znajomych ma dana osoba?”. Strona internetowa rachunku bankowego odpowiada na pytania takie jak: „Jakie jest moje bie(cid:285)(cid:200)ce saldo?” oraz „Jakie transakcje by(cid:239)y ostatnio przeprowadzane na moim koncie?”. Systemy danych nie tylko zapami(cid:218)tuj(cid:200) i zwracaj(cid:200) informacje. (cid:146)(cid:200)cz(cid:200) ze sob(cid:200) cz(cid:218)(cid:258)ci i kawa(cid:239)ki informacji, aby wygenerowa(cid:202) odpowiedzi. Saldo rachunku bankowego jest na przyk(cid:239)ad oparte na po(cid:239)(cid:200)czeniu informacji o wszystkich transakcjach przeprowadzonych na danym koncie. Poleć książkęKup książkę 26 ROZDZIA(cid:224) 1. Nowy paradygmat dla Big Data Kolejnym wa(cid:285)nym spostrze(cid:285)eniem jest to, (cid:285)e nie wszystkie cz(cid:218)(cid:258)ci informacji s(cid:200) sobie równe. Niektóre informacje pochodz(cid:200) z innych fragmentów informacji. Saldo rachunku bankowego opiera si(cid:218) na historii transakcji. Liczba znajomych jest obliczana na podstawie listy znajomych, a lista znajomych jest z kolei wypadkow(cid:200) wszystkich operacji dodawania i usuwania znajomych przez u(cid:285)ytkownika na jego profilu. Kiedy spróbujesz prze(cid:258)ledzi(cid:202) pochodzenie jakiej(cid:258) informacji, w ko(cid:241)cu dotrzesz do takiej, która nie pochodzi od (cid:285)adnej innej. Jest to najbardziej surowa informacja, jak(cid:200) masz: taka, któr(cid:200) uznajesz za prawdziw(cid:200) tylko dlatego, (cid:285)e istnieje. Nazwijmy t(cid:218) infor- macj(cid:218) danymi. Mo(cid:285)esz mie(cid:202) inn(cid:200) koncepcj(cid:218) dotycz(cid:200)c(cid:200) znaczenia s(cid:239)owa dane. Jest ono cz(cid:218)sto stoso- wane zamiennie ze s(cid:239)owem informacja. W pozosta(cid:239)ej cz(cid:218)(cid:258)ci tej ksi(cid:200)(cid:285)ki b(cid:218)dziemy jednak u(cid:285)ywa(cid:202) s(cid:239)owa dane, odwo(cid:239)uj(cid:200)c si(cid:218) do tej wyj(cid:200)tkowej informacji, od której pochodz(cid:200) wszystkie pozosta(cid:239)e. O ile system danych odpowiada na pytania na podstawie danych z przesz(cid:239)o(cid:258)ci, o tyle system danych najbardziej ogólnego zastosowania odpowiada na pytania na podstawie ca(cid:239)ego zbioru danych. Dlatego definicja najbardziej ogólnego zastosowania, jak(cid:200) mo(cid:285)emy sformu(cid:239)owa(cid:202) dla systemu danych, b(cid:218)dzie nast(cid:218)puj(cid:200)ca: zapytanie = funkcja(wszystkie dane) Wszystko, co kiedykolwiek móg(cid:239)by(cid:258) zechcie(cid:202) zrobi(cid:202) z danymi, mo(cid:285)e by(cid:202) wyra(cid:285)one w postaci funkcji przyjmuj(cid:200)cej jako informacje wej(cid:258)ciowe wszystkie posiadane przez Ciebie dane. Zapami(cid:218)taj to równanie, poniewa(cid:285) stanowi ono sedno wszystkiego, czego si(cid:218) nauczysz. B(cid:218)dziemy odwo(cid:239)ywa(cid:202) si(cid:218) do tego równania wielokrotnie. Architektura lambda zapewnia maj(cid:200)ce ogólne zastosowanie podej(cid:258)cie do implemen- tacji dowolnej funkcji na dowolnym zbiorze danych i zwracanie przez t(cid:218) funkcj(cid:218) wyni- ków z nisk(cid:200) latencj(cid:200). Nie oznacza to, (cid:285)e b(cid:218)dziesz stosowa(cid:202) te same technologie za ka(cid:285)dym razem, gdy b(cid:218)dziesz implementowa(cid:202) system danych. Konkretne, zastosowane technologie mog(cid:200) si(cid:218) zmienia(cid:202) w zale(cid:285)no(cid:258)ci od wymaga(cid:241). Architektura lambda defi- niuje jednak spójne podej(cid:258)cie do wyboru tych technologii i po(cid:239)(cid:200)czenia ich ze sob(cid:200) w celu spe(cid:239)nienia istniej(cid:200)cych wymaga(cid:241). Przejd(cid:283)my teraz do omówienia w(cid:239)a(cid:258)ciwo(cid:258)ci, którymi musi si(cid:218) charakteryzowa(cid:202) sys- tem danych. 1.5. Wymagane w(cid:225)a(cid:286)ciwo(cid:286)ci systemu Big Data W(cid:239)a(cid:258)ciwo(cid:258)ci, do których nale(cid:285)y d(cid:200)(cid:285)y(cid:202) w systemach Big Data, s(cid:200) zwi(cid:200)zane w równie du(cid:285)ym stopniu ze z(cid:239)o(cid:285)ono(cid:258)ci(cid:200), co ze skalowalno(cid:258)ci(cid:200). System Big Data musi by(cid:202) nie tylko wydajny oraz efektywny w kwestii wykorzystywania zasobów, ale powinien by(cid:202) tak(cid:285)e (cid:239)atwy do zrozumienia. Przyjrzyjmy si(cid:218) po kolei wszystkim w(cid:239)a(cid:258)ciwo(cid:258)ciom. 1.5.1. Niezawodno(cid:286)(cid:252) i odporno(cid:286)(cid:252) na b(cid:225)(cid:266)dy Budowanie systemów, „które robi(cid:200) to, co trzeba”, jest trudne w obliczu wyzwa(cid:241) syste- mów rozproszonych. Systemy musz(cid:200) zachowywa(cid:202) si(cid:218) w(cid:239)a(cid:258)ciwie bez wzgl(cid:218)du na losowe awarie maszyn, z(cid:239)o(cid:285)on(cid:200) semantyk(cid:218) spójno(cid:258)ci w rozproszonych bazach danych, zdupli- Poleć książkęKup książkę 1.5. Wymagane w(cid:239)a(cid:258)ciwo(cid:258)ci systemu Big Data 27 kowane dane, wspó(cid:239)bie(cid:285)no(cid:258)(cid:202) itd. Wyzwania te utrudniaj(cid:200) nawet zrozumienie tego, co system robi. Uzyskanie niezawodno(cid:258)ci systemu Big Data po cz(cid:218)(cid:258)ci polega na unikaniu tych zawi(cid:239)o(cid:258)ci, tak aby mo(cid:285)na by(cid:239)o (cid:239)atwo zrozumie(cid:202) dzia(cid:239)anie systemu. Jak omówiono wcze(cid:258)niej, imperatywem dla systemów jest odporno(cid:258)(cid:202) na ludzkie b(cid:239)(cid:218)dy. Jest to cz(cid:218)sto pomijana w(cid:239)a(cid:258)ciwo(cid:258)(cid:202) systemów, której nie b(cid:218)dziemy ignorowa(cid:202). W systemie produkcyjnym nieuniknione jest, (cid:285)e kto(cid:258) kiedy(cid:258) pope(cid:239)ni b(cid:239)(cid:200)d, na przyk(cid:239)ad poprzez wdro(cid:285)enie nieprawid(cid:239)owego kodu uszkadzaj(cid:200)cego warto(cid:258)ci w bazie danych. Je(cid:258)li wbudujesz w rdze(cid:241) systemu Big Data niemutowalno(cid:258)(cid:202) i zasad(cid:218) ponownego przeli- czania, system b(cid:218)dzie z natury odporny na b(cid:239)(cid:218)dy cz(cid:239)owieka w wyniku zapewnienia jasnego i prostego mechanizmu odzyskiwania. Zostanie to opisane szczegó(cid:239)owo w roz- dzia(cid:239)ach od 2. do 7. 1.5.2. Odczytywanie i aktualizowanie z nisk(cid:261) latencj(cid:261) Zdecydowana wi(cid:218)kszo(cid:258)(cid:202) aplikacji wymaga, aby operacje odczytu charakteryzowa(cid:239)y si(cid:218) bardzo niskim opó(cid:283)nieniem, zwykle w przedziale od kilku do kilkuset milisekund. Z drugiej strony wymagania dotycz(cid:200)ce opó(cid:283)nie(cid:241) aktualizacji bardzo si(cid:218) ró(cid:285)ni(cid:200) mi(cid:218)dzy aplikacjami. Niektóre aplikacje wymagaj(cid:200) natychmiastowej propagacji aktualizacji, ale w innych aplikacjach dopuszczalna jest latencja rz(cid:218)du kilku godzin. Niezale(cid:285)nie od tego powiniene(cid:258) by(cid:202) w stanie osi(cid:200)gn(cid:200)(cid:202) niskie opó(cid:283)nienia aktualizacji, gdy b(cid:218)dziesz ich potrzebowa(cid:202) w swoich systemach Big Data. Co wa(cid:285)niejsze, powiniene(cid:258) móc osi(cid:200)- gn(cid:200)(cid:202) niskie opó(cid:283)nienia odczytów i aktualizacji bez zagra(cid:285)ania niezawodno(cid:258)ci systemu. O tym, jak osi(cid:200)gn(cid:200)(cid:202) niskie opó(cid:283)nienia aktualizacji, dowiesz si(cid:218) podczas omawiania warstwy przetwarzania czasu rzeczywistego w rozdziale 12. 1.5.3. Skalowalno(cid:286)(cid:252) Skalowalno(cid:258)(cid:202) to zdolno(cid:258)(cid:202) do utrzymywania wydajno(cid:258)ci w obliczu rosn(cid:200)cej ilo(cid:258)ci danych lub wzrastaj(cid:200)cego obci(cid:200)(cid:285)enia — osi(cid:200)ga si(cid:218) j(cid:200) poprzez dodawanie zasobów do systemu. Architektura lambda jest skalowalna poziomo we wszystkich warstwach stosu systemo- wego: skalowanie odbywa si(cid:218) poprzez dodawanie kolejnych maszyn. 1.5.4. Uogólnienie Ogólny system mo(cid:285)e obs(cid:239)ugiwa(cid:202) szerok(cid:200) gam(cid:218) aplikacji. Ta ksi(cid:200)(cid:285)ka nie by(cid:239)aby w rze- czywisto(cid:258)ci zbyt u(cid:285)yteczna, je(cid:258)li nie uwzgl(cid:218)dnia(cid:239)aby systemów dla du(cid:285)ego zakresu zastosowa(cid:241)! Poniewa(cid:285) architektura lambda oparta jest na funkcji wszystkich danych, mo(cid:285)na uogólni(cid:202) j(cid:200) do wszystkich aplikacji, bez wzgl(cid:218)du na to, czy b(cid:218)d(cid:200) to systemy zarz(cid:200)dzania finansami, analizy mediów spo(cid:239)eczno(cid:258)ciowych, aplikacje naukowe, serwisy spo(cid:239)eczno(cid:258)ciowe, czy cokolwiek innego. 1.5.5. Rozszerzalno(cid:286)(cid:252) Nie chcia(cid:239)by(cid:258) by(cid:202) zmuszony do wymy(cid:258)lania ko(cid:239)a na nowo za ka(cid:285)dym razem, gdy doda- jesz jak(cid:200)(cid:258) powi(cid:200)zan(cid:200) funkcj(cid:218) lub wprowadzasz zmiany w sposobie dzia(cid:239)ania systemu. Systemy rozszerzalne pozwalaj(cid:200) na dodawanie funkcjonalno(cid:258)ci przy minimalnym koszcie programistycznym. Poleć książkęKup książkę 28 ROZDZIA(cid:224) 1. Nowy paradygmat dla Big Data Cz(cid:218)sto nowa funkcja lub zmiana w istniej(cid:200)cej funkcji wymaga migracji starych danych do nowego formatu. Uzyskanie rozszerzalno(cid:258)ci systemu polega po cz(cid:218)(cid:258)ci na u(cid:239)atwieniu przeprowadzania migracji na du(cid:285)(cid:200) skal(cid:218). Podstaw(cid:200) podej(cid:258)cia, którego si(cid:218) nauczysz, jest mo(cid:285)liwo(cid:258)(cid:202) szybkiego i (cid:239)atwego przeprowadzania wielkich migracji. 1.5.6. Zapytania ad hoc Mo(cid:285)liwo(cid:258)(cid:202) wykonywania zapyta(cid:241) ad hoc o dane jest niezwykle istotna. Prawie ka(cid:285)dy du(cid:285)y zbiór danych zawiera jak(cid:200)(cid:258) niespodziewan(cid:200) warto(cid:258)(cid:202). Mo(cid:285)liwo(cid:258)(cid:202) dowolnej eksplo- atacji jakiego(cid:258) zbioru danych pozwala na optymalizacje biznesowe i tworzenie nowych aplikacji. Ostatecznie nie b(cid:218)dziesz w stanie odkry(cid:202) ciekawych zastosowa(cid:241) dla swoich danych, je(cid:258)li nie b(cid:218)dziesz móg(cid:239) zadawa(cid:202) dowolnych pyta(cid:241) o te dane. O tym, jak wyko- nywa(cid:202) zapytania ad hoc, dowiesz si(cid:218) w rozdzia(cid:239)ach 6. i 7. podczas omawiania prze- twarzania wsadowego. 1.5.7. Minimalna konserwacja Konserwacja jest podatkiem na(cid:239)o(cid:285)onym na deweloperów. Jest to praca wymagana do utrzymania p(cid:239)ynnego dzia(cid:239)ania systemu. Konserwacja obejmuje przewidywanie, kiedy dodawa(cid:202) maszyny w celu skalowania, utrzymywanie dzia(cid:239)aj(cid:200)cych procesów oraz debu- gowanie wszelkich problemów wyst(cid:218)puj(cid:200)cych w (cid:258)rodowisku produkcyjnym. Wa(cid:285)nym elementem zwi(cid:200)zanym z minimalizowaniem czynno(cid:258)ci konserwacyjnych jest wybór takich elementów, które maj(cid:200) mo(cid:285)liwie najmniejsz(cid:200) z(cid:239)o(cid:285)ono(cid:258)(cid:202) implementa- cyjn(cid:200). Najlepiej jest polega(cid:202) na komponentach maj(cid:200)cych proste mechanizmy bazowe. W szczególno(cid:258)ci rozproszone bazy danych maj(cid:200) zwykle bardzo skomplikowane mecha- nizmy wewn(cid:218)trzne. Im bardziej z(cid:239)o(cid:285)ony system, tym wi(cid:218)ksze prawdopodobie(cid:241)stwo, (cid:285)e co(cid:258) pójdzie nie tak oraz tym wi(cid:218)ksza wymagana wiedza o systemie w celu jego zdebugowania i dostrojenia. Z(cid:239)o(cid:285)ono(cid:258)(cid:202) implementacji ogranicza si(cid:218), polegaj(cid:200)c na prostych algorytmach i kom- ponentach. Sztuczk(cid:200) wykorzystywan(cid:200) w architekturze lambda jest przesuni(cid:218)cie z(cid:239)o(cid:285)o- no(cid:258)ci z komponentów rdzenia na te elementy systemu, w których dane wyj(cid:258)ciowe mo(cid:285)na porzuci(cid:202) po kilku godzinach. Najbardziej z(cid:239)o(cid:285)one z wykorzystywanych kompo- nentów, takie jak rozproszone bazy danych odczytu/zapisu, znajduj(cid:200) si(cid:218) w tej warstwie, w której dane wyj(cid:258)ciowe s(cid:200) ostatecznie porzucane. Omówimy t(cid:218) technik(cid:218) szczegó(cid:239)owo podczas opisywania warstwy przetwarzania czasu rzeczywistego w rozdziale 12. 1.5.8. Debugowalno(cid:286)(cid:252) System Big Data musi zapewni(cid:202) informacje niezb(cid:218)dne do debugowania systemu, gdy co(cid:258) pójdzie nie tak. Kluczowa jest mo(cid:285)liwo(cid:258)(cid:202) (cid:258)ledzenia dla ka(cid:285)dej warto(cid:258)ci w systemie tego, co dok(cid:239)adnie spowodowa(cid:239)o, (cid:285)e ta warto(cid:258)(cid:202) jest w(cid:239)a(cid:258)nie taka. W architekturze lambda „debugowalno(cid:258)(cid:202)” osi(cid:200)ga si(cid:218) dzi(cid:218)ki funkcjonalnej naturze warstwy przetwarzania wsadowego oraz preferowaniu u(cid:285)ycia algorytmów ponownego przeliczania, kiedy tylko jest to mo(cid:285)liwe. Poleć książkęKup książkę 1.6. Problemy z architekturami w pe(cid:239)ni przyrostowymi 29 Osi(cid:200)gni(cid:218)cie wszystkich tych w(cid:239)a(cid:258)ciwo(cid:258)ci w jednym systemie mo(cid:285)e wydawa(cid:202) si(cid:218) zniech(cid:218)caj(cid:200)cym wyzwaniem. Je(cid:258)li jednak rozpoczniemy od pierwszych zasad, tak jak czyni to architektura lambda, w(cid:239)a(cid:258)ciwo(cid:258)ci te wy(cid:239)oni(cid:200) si(cid:218) w sposób naturalny z powsta(cid:239)ego projektu systemu. Zanim zag(cid:239)(cid:218)bimy si(cid:218) w architektur(cid:218) lambda, rzu(cid:202)my okiem na bardziej tradycyjne architektury (charakteryzuj(cid:200)ce si(cid:218) obliczeniami przyrostowymi) i zobaczmy, dlaczego nie s(cid:200) one w stanie zapewni(cid:202) wielu z tych w(cid:239)a(cid:258)ciwo(cid:258)ci. 1.6. Problemy z architekturami w pe(cid:225)ni przyrostowymi Na najwy(cid:285)szym poziomie tradycyjne architektury wygl(cid:200)daj(cid:200) tak, jak zosta(cid:239)o to pokazane na ry- sunku 1.3. Architektury te charakteryzuje sto- sowanie baz danych odczytu/zapisu i utrzymy- wanie w nich stanu w sposób przyrostowy wraz z pojawianiem si(cid:218) nowych danych. Rysunek 1.3. Architektura w pe(cid:225)ni przyrostowa Podej(cid:258)cie przyrostowe do zliczania na przyk(cid:239)ad ods(cid:239)on stron b(cid:218)dzie polega(cid:239)o na przetwarzaniu nowej ods(cid:239)ony strony poprzez dodanie warto(cid:258)ci jeden do licznika dla jej adresu URL. Ta charakterystyka architektur jest o wiele bardziej fundamentalna ni(cid:285) tylko porównanie relacyjno(cid:258)ci z nierelacyjno(cid:258)ci(cid:200) — w rzeczywisto(cid:258)ci ogromna wi(cid:218)kszo(cid:258)(cid:202) wdro(cid:285)e(cid:241) zarówno relacyjnych, jak i nierelacyjnych baz danych odbywa si(cid:218) z wyko- rzystaniem w pe(cid:239)ni przyrostowych architektur. Tak by(cid:239)o przez wiele dziesi(cid:218)cioleci. Warto podkre(cid:258)li(cid:202), (cid:285)e w pe(cid:239)ni przyrostowe architektury s(cid:200) tak powszechne, (cid:285)e wiele osób nie zdaje sobie sprawy, (cid:285)e mo(cid:285)na zapobiec zwi(cid:200)zanym z nimi problemom przez zastosowanie innej architektury. S(cid:200) to (cid:258)wietne przyk(cid:239)ady z(cid:239)o(cid:285)ono(cid:258)ci znajomej, czyli takiej, która jest tak mocno zakorzeniona, (cid:285)e nawet nie próbujemy znale(cid:283)(cid:202) sposobu na jej unikni(cid:218)cie. Problemy z w pe(cid:239)ni przyrostowymi architekturami s(cid:200) znacz(cid:200)ce. Zaczniemy nasze badanie tego tematu od przyjrzenia si(cid:218) ogólnym z(cid:239)o(cid:285)ono(cid:258)ciom generowanym przez dowoln(cid:200), w pe(cid:239)ni przyrostow(cid:200) architektur(cid:218). Nast(cid:218)pnie przeanalizujemy dwa odmienne rozwi(cid:200)zania tego samego problemu: jedno wykorzystuj(cid:200)ce mo(cid:285)liwie najlepsz(cid:200) archi- tektur(cid:218) w pe(cid:239)ni przyrostow(cid:200) oraz drugie wykorzystuj(cid:200)ce architektur(cid:218) lambda. Zoba- czysz, (cid:285)e w pe(cid:239)ni przyrostowa wersja jest znacznie gorsza pod ka(cid:285)dym wzgl(cid:218)dem. 1.6.1. Z(cid:225)o(cid:298)ono(cid:286)(cid:252) operacyjna Istnieje wiele z(cid:239)o(cid:285)ono(cid:258)ci zwi(cid:200)zanych z w pe(cid:239)ni przyrostowymi architekturami, wywo(cid:239)u- j(cid:200)cych trudno(cid:258)ci w operowaniu infrastruktur(cid:200) produkcyjn(cid:200). Skoncentrujemy si(cid:218) na jednej z nich, czyli na konieczno(cid:258)ci przeprowadzania kompaktowania online przez bazy danych odczytu/zapisu, oraz na tym, co trzeba zrobi(cid:202), aby wszystko dzia(cid:239)a(cid:239)o p(cid:239)ynnie. W wypadku bazy danych odczytu/zapisu, gdy indeks dysku jest przyrostowo dodawany i modyfikowany, cz(cid:218)(cid:258)ci tego indeksu s(cid:200) niewykorzystywane. Te niewyko- rzystane cz(cid:218)(cid:258)ci zajmuj(cid:200) miejsce, które ostatecznie musi zosta(cid:202) odzyskane, aby zapobiec Poleć książkęKup książkę 30 ROZDZIA(cid:224) 1. Nowy paradygmat dla Big Data zape(cid:239)nieniu dysku. Odzyskiwanie przestrzeni dysku od razu, gdy staje si(cid:218) ona niewy- korzystywana, jest zbyt kosztowne, wi(cid:218)c od czasu do czasu przestrze(cid:241) jest odzyskiwana hurtowo w procesie zwanym kompaktowaniem. Kompaktowanie to intensywna operacja. Podczas kompaktowania serwer znacznie zwi(cid:218)ksza zapotrzebowanie na wykorzystanie CPU oraz dysków, co w istotny sposób obni(cid:285)a w tym czasie wydajno(cid:258)(cid:202) danej maszyny. Bazy danych takie jak HBase i Cas- sandra s(cid:200) dobrze znane z tego, (cid:285)e wymagaj(cid:200) starannych konfiguracji i zarz(cid:200)dzania, aby unikn(cid:200)(cid:202) problemów lub zawieszania si(cid:218) serwera podczas kompaktowania. Utrata wydajno(cid:258)ci w trakcie kompaktowania to z(cid:239)o(cid:285)ono(cid:258)(cid:202), która mo(cid:285)e nawet spowodowa(cid:202) kaskadowe awarie — je(cid:258)li zbyt wiele maszyn kompaktuje w tej samej chwili, obs(cid:239)u- giwane przez nich obci(cid:200)(cid:285)enie b(cid:218)dzie musia(cid:239)o zosta(cid:202) obs(cid:239)u(cid:285)one przez inne maszyny w klastrze. Mo(cid:285)e to potencjalnie przeci(cid:200)(cid:285)y(cid:202) reszt(cid:218) klastra, powoduj(cid:200)c ca(cid:239)kowit(cid:200) awari(cid:218). Widzieli(cid:258)my wiele razy, jak przydarza si(cid:218) ten rodzaj awarii. Aby prawid(cid:239)owo zarz(cid:200)dza(cid:202) kompaktowaniem, nale(cid:285)y zaplanowa(cid:202) kompaktowania na ka(cid:285)dym w(cid:218)(cid:283)le w taki sposób, aby nie przeprowadza(cid:239)o ich jednocze(cid:258)nie zbyt wiele w(cid:218)z(cid:239)ów. Musisz mie(cid:202) (cid:258)wiadomo(cid:258)(cid:202) tego, jak d(cid:239)ugo trwa kompaktowanie (oraz jak bardzo mo(cid:285)e by(cid:202) zmienny czas jego trwania), aby unikn(cid:200)(cid:202) sytuacji, w której wykonuje je wi(cid:218)cej w(cid:218)z(cid:239)ów, ni(cid:285) zamierza(cid:239)e(cid:258). Musisz upewni(cid:202) si(cid:218), (cid:285)e masz wystarczaj(cid:200)co du(cid:285)(cid:200) pojem- no(cid:258)(cid:202) dysku na w(cid:218)z(cid:239)ach, aby utrzyma(cid:202) je mi(cid:218)dzy kompaktowaniami. Ponadto musisz si(cid:218) upewni(cid:202), (cid:285)e masz wystarczaj(cid:200)c(cid:200) pojemno(cid:258)(cid:202) w klastrze, aby nie zosta(cid:239) on przeci(cid:200)(cid:285)o- ny, gdy podczas kompaktowa(cid:241) zostan(cid:200) utracone zasoby. Wszystkim tym mo(cid:285)e zarz(cid:200)dza(cid:202) kompetentny personel operacyjny, ale uwa(cid:285)amy, (cid:285)e najlepszym sposobem radzenia sobie z ka(cid:285)dego rodzaju z(cid:239)o(cid:285)ono(cid:258)ci(cid:200) jest pozbycie si(cid:218) jej ca(cid:239)kowicie. Im mniej masz trybów awarii w systemie, tym mniejsze prawdopodobie(cid:241)- stwo, (cid:285)e do(cid:258)wiadczysz nieoczekiwanych przestojów. Konieczno(cid:258)(cid:202) radzenia sobie z kom- paktowaniem online jest z(cid:239)o(cid:285)ono(cid:258)ci(cid:200) zwi(cid:200)zan(cid:200) z w pe(cid:239)ni przyrostowymi architekturami, ale w architekturze lambda podstawowe bazy danych nie wymagaj(cid:200) kompaktowania online. 1.6.2. Ekstremalna z(cid:225)o(cid:298)ono(cid:286)(cid:252) osi(cid:261)gania spójno(cid:286)ci ostatecznej Kolejna z(cid:239)o(cid:285)ono(cid:258)(cid:202) architektur przyrostowych pojawia si(cid:218), gdy próbujemy zapewni(cid:202) wysok(cid:200) dost(cid:218)pno(cid:258)(cid:202) systemów. Wysoce dost(cid:218)pne systemy umo(cid:285)liwiaj(cid:200) wykonywanie zapyta(cid:241) i aktualizacji nawet w wypadku awarii maszyny lub cz(cid:218)(cid:258)ciowej awarii sieci. Okazuje si(cid:218), (cid:285)e osi(cid:200)gni(cid:218)cie wysokiej dost(cid:218)pno(cid:258)ci konkuruje bezpo(cid:258)rednio z inn(cid:200) wa(cid:285)n(cid:200) w(cid:239)a(cid:258)ciwo(cid:258)ci(cid:200), zwan(cid:200) spójno(cid:258)ci(cid:200). Spójny system zwraca wyniki, które uwzgl(cid:218)d- niaj(cid:200) wszystkie poprzednie operacje zapisu. Twierdzenie CAP (ang. Consistency, Ava- ilability, Partition tolerance — spójno(cid:258)(cid:202), dost(cid:218)pno(cid:258)(cid:202), odporno(cid:258)(cid:202) na podzia(cid:239)y) wykaza(cid:239)o, (cid:285)e niemo(cid:285)liwe jest osi(cid:200)gni(cid:218)cie w tym samym systemie jednocze(cid:258)nie wysokiej dost(cid:218)pno(cid:258)ci i spójno(cid:258)ci w wypadku wyst(cid:218)powania podzia(cid:239)ów sieci (ang. network partitions). Dlatego wysoce dost(cid:218)pny system zwraca czasem przestarza(cid:239)e wyniki w trakcie wyst(cid:218)powania stanu podzia(cid:239)u sieci. Twierdzenie CAP zostanie omówione szczegó(cid:239)owo w rozdziale 12. Tu chcemy sku- pi(cid:202) si(cid:218) na tym, w jaki sposób niemo(cid:285)no(cid:258)(cid:202) utrzymania przez ca(cid:239)y czas pe(cid:239)nej spójno(cid:258)ci i wysokiej dost(cid:218)pno(cid:258)ci wp(cid:239)ywa na zdolno(cid:258)(cid:202) do budowania systemów. Okazuje si(cid:218), (cid:285)e Poleć książkęKup książkę 1.6. Problemy z architekturami w pe(cid:239)ni przyrostowymi 31 je(cid:258)li wymagania biznesowe przedk(cid:239)adaj(cid:200) wysok(cid:200) dost(cid:218)pno(cid:258)(cid:202) nad pe(cid:239)n(cid:200) spójno(cid:258)(cid:202), b(cid:218)dziesz musia(cid:239) poradzi(cid:202) sobie z wysokim poziomem z(cid:239)o(cid:285)ono(cid:258)ci. Aby wysoce dost(cid:218)pny system powraca(cid:239) do stanu spójno(cid:258)ci po usuni(cid:218)ciu podzia(cid:239)u sieci (co jest znane jako spójno(cid:258)(cid:202) ostateczna, ang. eventual consistency), wymagane jest du(cid:285)e wsparcie ze strony aplikacji. We(cid:283)my na przyk(cid:239)ad podstawowy przypadek u(cid:285)ycia, jakim jest utrzymywanie zliczania w bazie danych. Oczywistym sposobem rozwi(cid:200)zania tej kwestii jest zapisanie w bazie danych pewnej liczby i zwi(cid:218)kszanie jej warto(cid:258)ci za ka(cid:285)- dym razem, gdy otrzymywane jest zdarzenie wymagaj(cid:200)ce zwi(cid:218)kszenia wskazania licznika. Mo(cid:285)esz by(cid:202) zaskoczony tym, (cid:285)e je(cid:258)li przyjmiesz takie podej(cid:258)cie, b(cid:218)dziesz do(cid:258)wiadcza(cid:239) masowej utraty danych w trakcie wyst(cid:218)powania stanu podzia(cid:239)u sieci. Wynika to ze sposobu, w jaki rozproszone bazy danych osi(cid:200)gaj(cid:200) wysok(cid:200) dost(cid:218)p- no(cid:258)(cid:202) — poprzez utrzymywanie wielu replik wszystkich przechowywanych informacji. Kiedy przechowujesz wiele kopii tej samej informacji, pozostaje ona dost(cid:218)pna nawet w wypadku awarii maszyny lub wyst(cid:200)pienia podzia(cid:239)u sieci, tak jak pokazano na ry- sunku 1.4. Podczas podzia(cid:239)u sieci klienty systemu, dla którego wybrano wysok(cid:200) dost(cid:218)p- no(cid:258)(cid:202), aktualizuj(cid:200) jakiekolwiek dost(cid:218)pne dla nich repliki. To powoduje, (cid:285)e repliki zaczy- naj(cid:200) si(cid:218) ró(cid:285)ni(cid:202) i odbiera(cid:202) odmienne zestawy aktualizacji. Dopiero po usuni(cid:218)ciu podzia(cid:239)u sieci repliki mog(cid:200) zosta(cid:202) scalone i otrzyma(cid:202) wspóln(cid:200) warto(cid:258)(cid:202). Rysunek 1.4. Wykorzystani
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Big Data. Najlepsze praktyki budowy skalowalnych systemów obsługi danych w czasie rzeczywistym
Autor:
,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: