Jak poradzić sobie z tabelą danych i tabel danych BIG DATA? (240 milionów wierszy)

Question

Mamy klienta BI, który generuje około 40 milionów wierszy każdego miesiąca w swoich tabelach baz danych sprzedaży, generowanych z ich transakcji sprzedaży. Chcą zbudować Sales Data Mart z historycznymi danymi z 5 lat, co oznacza, że ​​ta tabela faktów będzie potencjalnie zawierać około 240 milionów wierszy. (40 x 12 miesięcy x 5 lat)

To jest dobrze uporządkowane dane.

Po raz pierwszy skonfrontowałem się z tą ilością danych, co zajęło mi przeanalizowanie pionowych narzędzi baz danych, takich jak Inforbright i inne. Ale wciąż z tego rodzaju oprogramowaniem proste zapytanie wymagałoby bardzo, bardzo długiego czasu działania.

Zajęło mi to przyjrzenie się Hadoopowi, ale po przeczytaniu kilku artykułów doszedłem do wniosku, że Hadoop nie jest najlepszą opcją (nawet z Hive) do stworzenia tabeli faktów, ponieważ w moim rozumieniu ma działać z niestrukturalnymi dane.

Moje pytanie brzmi: Jaki byłby najlepszy sposób na zbudowanie tego wyzwania? , Czy nie szukam odpowiedniej technologii? Jakie byłyby najlepsze czasy odpowiedzi na zapytania, jakie mogłem uzyskać w tak dużym zestawieniu faktów? ..lub Stawiam czoła prawdziwej ścianie tutaj i jedyną opcją jest zbudowanie zagregowanych tabel?

Answer 1

Można rozważyć pakowane rozwiązanie NoSQL/Analysis, takie jak DataStax Enterprise, które wykorzystuje Apache Cassandra w połączeniu z Hadoop i innymi przydatnymi narzędziami analitycznymi. Masz rację, że "domyślny" system plików HDFS Hadoop jest odpowiedni dla niestrukturalnych danych, ale integracja z magazynem danych NoSQL (jak Cassandra lub HBase) pozwoli ci łatwiej analizować dane strukturalne za pomocą MapReduce.

Answer 2

Misoop jest absolutnie odpowiedni dla takich dużych danych. Można go używać z hbase, co pozwala nam rozszerzyć się do milionów wierszy i miliardów kolumn, a także zapewnia doskonałą skalowalność poziomą, jak również nadaje się do losowania w czasie rzeczywistym odczytaj dostęp do zapisu ... w drugiej ręce ul jest dobry do przetwarzania wsadowego, dzięki czemu możesz uruchamiać prace ula na zapleczu dla innych zadań .. nie powinniśmy pomylić miodu jako alternatywy dla tradycyjnych RDBMS, ale to naprawdę pomocne w radzeniu sobie z ogromnymi zbiory danych .. możesz użyć innego projektu "sqoop", który pozwala nam importować nasze dane z istniejących baz danych do klastra hadoop bez większego bólu.

Answer 3

Najpierw przyjmuję jego 240m nie 2400m.

pierwsze przyjrzeć ssd.analytical-labs.com

Demo FCC ma 150m rekord tabelę faktów działa na Infobright, to podejrzewam, że na VW byłoby jeszcze szybciej.

Klucz jest prosty, pojawią się pytania, które spowalniają jego działanie, ale w dużej mierze są bardzo czułe.

Sugerowałbym, abyś myślał o agregatach, o tym, w jaki sposób wysyłasz zapytanie i co ważniejsze, o co pytasz.

Na przykład podzielić go na Marts dla wydajności, według produktu, marki, lat itp. Jeśli użytkownik chce po prostu zrobić zapytanie na < 1 lat wartości danych (co jest częściej niż w przypadku większości ludzi chciałbym myśleć) mogliby wtedy użyć o wiele mniejszej tabeli faktów.

Pamięć jest tania, więc nie ma znaczenia, szczególnie jeśli duplikuje się dane, o ile pozwala na szybką reakcję.

Oczywiście, jeśli korzystasz z OLAP, możesz skorzystać z wbudowanych tabel agregatów, aby upewnić się, że większość zapytań jest uruchamiana na znacznie bardziej akceptowalnym poziomie, zakładając, że zostały zwinięte.

Sprzęt jest również bardzo ważny, upewnij się, że masz szybkie dyski, czyli prawie zawsze szyjka butelki, tym szybciej można uzyskać dane z dysków, tym szybciej będą one wyświetlane użytkownikowi końcowemu.

Projektowanie schematów jest również ważne, nowoczesne bazy danych kolumn znacznie preferują denormalizowany stół z 0 sprzężeniami, gdzie to możliwe, znalazłem w przeszłości, mając 1 zdormowaną tabelę dla 90% zapytań, a następnie mając kilka tabel łączenia (data dim na przykład) dla przypadków specjalnych dla większości przypadków użycia.

W każdym razie to jest moje 2 centy. Ping mnie na Twitterze, jeśli chcesz o czymś skype lub coś takiego.

Tom

Edit:

Także tu jest nie naukowy znak ława wykonać kopię zapasową co JVD mówił:

• ssd na fizycznym polu: 175,67 MB/s
• SATA fizyczna skrzynka: 113,52 MB/s
• ec2: 75,65 MB/s
• raid ec2 eb: 89,36 MB/s ec

Jak widać, istnieje duża różnica w prędkości odczytu.

Answer 4

Kolejną kombinacją technologii, które z powodzeniem zastosowałem w przypadku bardzo dużego hurtowni danych jest Hadoop + Hive. Dane zostały zmanipulowane za pomocą Map/Reduce jobs i zaprezentowane Hive jako zewnętrzne tabele. Aktualizacje zostały wykonane przez zamianę partycji między sceną i obszarami hurtowni danych.

Wielką zaletą tego podejścia było to, że można uruchomić (prawie) normalne zapytania SQL na danych. Wada - nie można podłączyć Hive back end do interaktywnego interfejsu użytkownika. Ale jeśli wszystko, co robisz, uruchamia codzienne raporty i datamining, to powinno działać.

Answer 5

Myślę, że istnieje kilka podejść tu

1) Należy spróbować zbiorcze tabele na Mondriana, minusem stołów AGG jest to, że trzeba wiedzieć wcześniej przypadków użycia dla większości nawracających zapytaniami, jeśli ciebie w takim razie nie jest łatwo to dostroić, a otrzymasz długi czas odpowiedzi na zapytania, które nie zoptymalizowały tabeli zbiorczej.

2) Inną opcją jest podział danych tabeli faktów, być może według roku, tworzenie różnych schematów dla każdego roku i wirtualnego sześcianu dla całej historii. Jeśli masz odpowiednie oprogramowanie, możesz również utworzyć zmaterializowany widok (jeśli masz Oracle) lub indeksowany widok, jeśli masz MS SqlServer.

Późne podejście przyniosło mi bardzo dobre efekty, z zauważalną poprawą czasów zapytań. Poza tym nie wpłynęło to na proces ETL (w opcji 1 trzeba utworzyć dodatkowy proces budowania i konserwacji tabel agregujących), ponieważ RDMBS dba o proces aktualizacji danych na każdej partycji.

Answer 6

Czy wypróbowałeś usługę Google BigQuery (płatny serwis Premium), który będzie odpowiadał Twoim potrzebom.To jest tak proste, jak

1. Załaduj dane w formacie CSV (rozdzielany przez nową linię do zapisu lub konfigurowalnym char na polu). Plik może być w formacie gzip. Możesz również dołączyć do istniejącej tabeli.

2. Rozpocznij kwerendę przy użyciu instrukcji SQL (ograniczone wyrażenie sql), a wyniki są zwracane w sekundach z wielu milionów wierszy.

3. Wyodrębnienie danych do pliku CSV lub innej tabeli (podobny do warstwy agregacji)

Sprawdź tutaj. https://developers.google.com/bigquery/

Pierwsze 100 GB do przetwarzania danych jest bezpłatne. Możesz zacząć już teraz, a także zintegrować się z Arkuszem kalkulacyjnym Google, który pozwoli Ci tworzyć wizualizacje, takie jak wykresy i wykresy itp. Do zarządzania. Możesz wyeksportować arkusz kalkulacyjny Google jako Microsoft Excel/PDF.

Google twierdzi, że może skalować do wielu terrabitek i zapewnia kwerendy w czasie rzeczywistym (kilka sekund odpowiedzi).