Как да започнете да изучавате BigData
Здравейте, хора. Реших да се превърна от маймуна в човек. Всъщност реших отдавна, но не разбирах как трябва да изучавам алгоритми и структури от данни, така че да е направо интересно до ужас. Е, нямам нужда от тях в ежедневието, оказва се, и някак забравям да се занимавам с тях.
Моят опит е Java, Android + малко Clojure, съвсем малко.
И ето го решението, от което като добри хора може да искате да ме разубедите. Вече някъде, но BigData алгоритмите и структурите от данни са централната тема. Може, разбира се, да греша, но ми се струва, че вероятността е малка. Но откъде да започнем? Google, разбира се, е добро решение, но можете да изберете не какво, а искате това, коетовиесте, директно, сигурен със сигурност.
Искам да отбележа, че задачата тук не е да стана световен гений в тази област, просто така, за себе си, искам да упражня мозъка си, така да се каже. Но не изключвам перспективата за пълно прилагане в тази област, защо не. Основното е да започнете правилно и да изберете правилните материали.
Наистина очаквам вашите съвети, приятели, и обобщение:
Струва ли си изобщо да изучавате BigData? Откъде да започна?
BigData всъщност не е свързан със структурите от данни - основно това е разнообразие от пространствени структури, по-скоро е свързано повече с NLP, класификация и алгоритми за машинно обучение.
На първо място, трябва да изберете средство за обработка и съхранение. В случая на Java това е HBase Cassandra HBase - когато има много писане в базата данни и повечето индекси са "самоизработени". Cassandra - когато съотношението четене/запис е 4:3, тъй като Cassandra вече има инструменти за индексиране на колони.
В случай на истинско високо натоварване, това е ScyllaDB - има същите функции като HBase, но C ++ 11 и Share-nothing подход и откоето е 6-7 пъти по-бързо.
За база данни до 200 GB ще е достатъчен банален MySQL с индекс на R-дърво и Engine Archive. PostgreSQL, когато е правилно конфигуриран, тихо изгражда индекси на B-дърво за обеми от данни от 500-700Gb, което е невъзможна задача за MySQL. Е, в PostgreSQL често трябва да добавяте C-wise функции за агрегиране и да изграждате различни индекси върху тях, понякога пространствени (gin/gist).
Ето малък преглед на различните видове индекси.
От себе си също ще добавя MVP-дърво за търсене на подобни перцептивни хешове и Fusion-дърво като по-годна за консумация версия на дървото Van Emde Boas.
Относно хипстърския култ около MongoDB, ще кажа, че PostgreSQL с индекси на хеш таблици и малки набори от документи е 1,5-3 пъти по-бърз, защото "Building Index with Vodka". И нормалното репликиране и разделяне директно зависи от принципите за решаване на проблема с консенсуса във всяко конкретно приложение и без да разбирате работата на Raft / Paxos, не трябва да разчитате на чудесата на същия MongoDB или PostgreSQL, те не са нищо повече от инструменти за решаване на този проблем.
MongoDB е много добър за базирани на Meteor реактивни проекти, а GoldenHammer™ за всичко останало.
Е, след като разбрахме какво и къде и как да съхраняваме, сега можем да помислим за обработка. Има една древна книга "Алгоритми на интелигентния интернет" и "Програмиране на колективния разум" Въпреки че заглавията са преведени на български доста странно и звучат доста наивно, това е добро въведение в прости инструменти за обработка и анализ на данни.
За машинното обучение можете да вземете курса на Андрю Нг в курса.
Има Southern DataScience-central, там има много полезни неща. Може да се чете. Има и повърхностни CheetSheets, виждах по-добри, но не ги намерих.
какDeepLearning адепт, съветвам ви да се справите с Theano и описаните тук методи. В производството това нещо е безобразно небрежно и видях другари, които повече или по-малко успешно слязоха от Neon.
Ако влезете в Java, тогава като използвате Spotify като пример, Apache Kafka -> Apache HBase -> Apache Storm -> Apache Spark (mllib) -> Apache HBase -> Apache Phoenix -> Хибернация + всякакви MVC рамки и т.н.
Естествено, относително висока производителност и добро вертикално мащабиране са изключени, ако вземете C++11 ScyllaDB -> Неонът е добре профилиран и завършен, може да се получи 3-5 пъти по-висока производителност и съответно много по-ниски забавяния, но обикновено всичко е счупено. REST API за това обикновено се опитват да бъдат написани в syah (без плюсове) под формата на разширения за Nginx, което е доста чистокръвно извращение - в повечето случаи банален golang / netty ще бъде достатъчен.
В Hadoop вече е обичайно стекът да не се изкачва, тъй като е много „интерактивен“ и без добра поддръжка и допинг от доставчици в реални проекти просто не може да се използва, така че почти всички, в една или друга степен, отбелязаха върху него. Например, същият Spotify.
Можете да видите много srach за HA и Zookeeper, особено в Netflix, така че за управление на висока наличност е по-добре да използвате техните решения - eureka или Hystrix за отказоустойчивост. Въпреки че не мога да кажа, че това са достатъчно зрели проекти - те също имат достатъчно недостатъци, но са много по-бързи от другите Apache занаяти.
Не можете да правите устойчиви на грешки и високодостъпни приложения едновременно - защото CAP теоремата има своето място.
Има и много тънък момент с Java като цяло - трябва да минимизирате времето за събиране на боклука и да отидете в offheap, струва си да погледнете какбуферите са имплементирани в netty - това е разпределител на арена, подобен на това, което се използва от jemalloc и различни misc.unsafe ереси. Можете също да опитате Hazelcast / Terracotta, но в общи линии същото, само срещу заплащане и "разпространено".
За REST API най-често използвам Vert.x и vanilla Java. Разходите на Scala са доста големи, а времето за компилиране е просто скандално. Безопасно е да използвате Groovy с @Immutable и @CompileStatic, за да минимизирате копирането и поставянето. Но във Vert.x всичко е "динамично":
Не мога да кажа нищо за производителността на Clojure, на места е малко надinvokeDynamic. Естествено, ваниловата Java ще е по-бърза, но нямам идея с колко.