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)
