Урок за HBase: Въведение за HBase и казус на Facebook

Както споменахме в нашата блог, HBase е съществена част от нашата екосистема Hadoop. И така, сега бих искал да ви преведа през HBase tutorial, където ще ви запозная с Apache HBase, а след това ще преминем през казуса на Facebook Messenger. Ще разгледаме следните теми в този блог с уроци за HBase:

• История на Apache HBase
• Въвеждане на Apache HBase
• Бази данни NoSQL и техните типове
• HBase срещу Касандра
• Характеристики на Apache HBase
• HBase срещу HDFS
• Казус на Facebook Messenger

Урок за Apache HBase: История

Нека започнем с историята на HBase и да знаем как HBase е еволюирал през определен период от време.

• Apache HBase е моделиран след BigTable на Google, който се използва за събиране на данни и обслужване на заявки за различни услуги на Google като Maps, Finance, Earth и др.
• Apache HBase започна като проект на компанията Powerset за търсене на естествен език, която обработва масивни и оскъдни набори от данни.
• Apache HBase беше пуснат за първи път през февруари 2007 г. По-късно през януари 2008 г. HBase стана подпроект на Apache Hadoop.
• През 2010 г. HBase стана проект на Apache от най-високо ниво.

Урок за HBase | Бази данни NoSQL | Едурека

След като знаете за историята на Apache HBase, би ви било любопитно да разберете какво е Apache HBase? Нека да продължим напред и да погледнем.

Урок за Apache HBase: Въведение в HBase

HBase е отворен код, многоизмерен, разпределен, мащабируем и a База данни NoSQL написана на Java. HBase работи отгоре HDFS (Hadoop Distributed File System) и предоставя на Hadoop подобни на BigTable възможности. Той е проектиран да осигури устойчив на неизправности начин за съхраняване на голяма колекция от оскъдни набори от данни.

Тъй като HBase постига висока производителност и ниска латентност, като осигурява по-бърз достъп за четене / запис на огромни набори от данни. Следователно HBase е изборът за приложения, които изискват бърз и произволен достъп до голямо количество данни.

Той осигурява компресия, операции в паметта и Bloom филтри (структура на данните, която показва дали дадена стойност присъства в даден набор или не), за да изпълни изискването за бързо и произволно четене-запис.

Нека го разберем чрез пример: Реактивният двигател генерира различни видове данни от различни сензори като сензор за налягане, температурен датчик, сензор за скорост и т.н., което показва здравословното състояние на двигателя. Това е много полезно за разбиране на проблемите и състоянието на полета. Непрекъснатите операции на двигателя генерират 500 GB данни за полет и има приблизително 300 хиляди полета на ден. И така, Engine Analytics, приложен към такива данни в почти реално време, може да се използва за активно диагностициране на проблеми и намаляване на непланирания престой. Това изисква разпределена среда, с която да съхранявате голямо количество данни бързо произволно четене и писане за обработка в реално време. Тук HBase идва за спасяване. Ще говоря подробно за HBase Read and Write в следващия ми блог на HBase архитектура .

Както знаем, HBase е NoSQL база данни. Така че, преди да разберете повече за HBase, нека първо да обсъдим базите данни NoSQL и техните типове.

java низ за дата към дата

Урок за Apache HBase: Бази данни NoSQL

NoSQL означава Не само SQL . Базите данни NoSQL са моделирани по такъв начин, че да могат да представят данни, различни от таблични формати, unkile релационни бази данни. Той използва различни формати за представяне на данни в бази данни и по този начин има различни видове бази данни NoSQL въз основа на техния формат на представяне. Повечето бази данни NoSQL използват наличността и бързината в сравнение с последователността. Сега нека продължим напред и да разберем за различните типове бази данни NoSQL и техните формати на представяне.

Магазини Key-Value:

Това е база данни без схеми, която съдържа ключове и стойности. Всеки ключ, сочещ към стойност, която е масив от байтове, може да бъде низ, BLOB, XML и т.н. Lamborghini е ключ и може да сочи към стойност Gallardo, Aventador, Murciélago, Reventón, Diablo, Huracán, Veneno, Centenario и др.

Key-Value съхранява бази данни: Aerospike, Couchbase, Dynamo, FairCom c-treeACE, FoundationDB, HyperDex, MemcacheDB, MUMPS, Oracle NoSQL Database, OrientDB, Redis, Riak, Berkeley DB.

Случай за употреба

Магазините за ключ-стойност се справят добре с размера и са добри в обработката на постоянен поток от операции за четене / запис с ниска латентност. Това ги прави идеални заПотребителски предпочитания и магазини за профили,Препоръки за продукти, най-новите артикули, разгледани на уебсайта на търговеца за насочване на препоръки за бъдещи клиентски продуктиНавиците за обслужване на реклами на клиенти водят до персонализирани реклами, купони и др. За всеки клиент в реално време.

Ориентиран към документ :

Той следва същата двойка ключови стойности, но е полуструктуриран като XML, JSON, BSON. Тези структури се считат за документи.

Бази данни на базата на документи: Apache CouchDB, Clusterpoint, Couchbase, DocumentDB, HyperDex, IBM Domino, MarkLogic, MongoDB, OrientDB, Qizx, RethinkDB.

Случай за употреба

Тъй като документът поддържа гъвкава схема, бързото четене на запис и разделянето го прави подходящ за създаване на потребителски бази данни в различни услуги като Twitter, уебсайтове за електронна търговия и др.

Ориентирано към колона:

В тази база данни данните се съхраняват в клетка, групирана в колона, а не в редове. Колоните са логически групирани в семейства колони, които могат да бъдат създадени по време на дефинирането на схемата или по време на изпълнение.

Тези типове бази данни съхраняват цялата клетка, съответстваща на колона, като непрекъснато въвеждане на диска, като по този начин правят достъпа и търсенето много по-бързи.

Бази данни на базата на колони: HBase, Accumulo, Cassandra, Druid, Vertica.

Случай за употреба

Той поддържа огромно хранилище и позволява по-бърз достъп за четене и запис върху него. Това прави базирани на колони бази данни подходящи за съхраняване на поведението на клиентите в уебсайта за електронна търговия, финансови системи като Google Finance и данни за фондовия пазар, Google карти и т.н.

Графично ориентирано:

Това е перфектно гъвкаво графично представяне, използвано за разлика от SQL. Този тип бази данни лесно решават проблеми с мащабируемостта на адресите, тъй като съдържа ръбове и възел, които могат да бъдат разширени в съответствие с изискванията.

Графични бази данни: AllegroGraph, ArangoDB, InfiniteGraph, Apache Giraph, MarkLogic, Neo4J, OrientDB, Virtuoso, Stardog.

Случай за употреба

Това се използва основно за откриване на измами, механизми за препоръки в реално време (в повечето случаи електронна търговия), управление на основните данни (MDM), мрежови и ИТ операции, управление на самоличност и достъп (IAM) и др.

HBase и Cassandra са двете известни бази данни, ориентирани към колони. И така, сега говорейки на по-високо ниво, нека сравним и разберем архитектурните и работни разлики между HBase и Cassandra.

Урок за HBase: HBase VS Cassandra

• HBase е моделиран на BigTable (Google), докато Cassandra е базиран на DynamoDB (Amazon), първоначално разработен от Facebook.
• HBase използва Hadoop инфраструктура (HDFS, ZooKeeper), докато Cassandra еволюира отделно, но можете да комбинирате Hadoop и Cassandra според вашите нужди.
• HBase има няколко компонента, които комуникират заедно като HBase HMaster, ZooKeeper, NameNode, Region Severs. Докато Касандра е единичен тип възел, при който всички възли са равни и изпълнява всички функции. Всеки възел може да бъде координатор, който премахва единична точка на повреда.
• HBase е оптимизиран за четене и поддържа единични записи, което води до строга последователност. HBase поддържа сканиране въз основа на диапазон, което прави процеса на сканиране по-бърз. Докато Cassandra поддържа четене на един ред, което поддържа евентуална последователност.
• Cassandra не поддържа сканиране на редове, базирани на обхват, което забавя процеса на сканиране в сравнение с HBase.
• HBase поддържа подредено разделяне, в което редове от семейство колони се съхраняват в ред RowKey, докато в Casandra нареденото разделяне е предизвикателство. Поради разделянето на RowKey процесът на сканиране е по-бърз в HBase в сравнение с Cassandra.
• HBase не поддържа балансиране на натоварването при четене, един регионален сървър обслужва заявката за четене и репликите се използват само в случай на отказ. Докато Касандра поддържа балансиране на четенето на натоварване и може да чете същите данни от различни възли. Това може да компрометира консистенцията.
• В CAP (последователност, наличност и дял-толерантност) теорема HBase поддържа последователност и наличност, докато Касандра се фокусира върху наличност и дял-толерантност.

Сега нека да се потопим дълбоко и да разберем характеристиките на Apache HBase, което го прави толкова популярен.

Урок за Apache HBase: Характеристики на HBase

• Атомно четене и писане: На ниво ред, HBase осигурява атомно четене и запис. Може да се обясни, че по време на един процес на четене или запис всички други процеси са възпрепятствани да извършват каквито и да било операции за четене или запис.
• Последователно четене и записване: HBase осигурява последователно четене и запис поради горната функция.
• Линейна и модулна мащабируемост: Тъй като наборите от данни се разпространяват през HDFS, по този начин той е линейно мащабируем между различни възли, както и модулно мащабируем, тъй като е разделен между различни възли.
• Автоматично и конфигурируемо заличаване на таблици: Таблиците HBase са разпределени между клъстери и тези клъстери са разпределени между региони. Тези региони и клъстери се разделят и се преразпределят с нарастването на данните.
• Лесен за използване API на Java за клиентски достъп: Той осигурява лесен за използване Java API за програмен достъп.
• Икономичен шлюз и REST-пълни уеб услуги: Той също така поддържа Thrift и REST API за не-Java интерфейси.
• Блокиране на кеш и Bloom филтри: HBase поддържа Block Cache и Bloom Filters за оптимизиране на заявки с голям обем.
• Поддръжка на автоматична повреда: HBase с HDFS осигурява WAL (Write Ahead Log) през клъстери, което осигурява автоматична поддръжка на откази.
• Сортирани клавиши: Тъй като търсенето се извършва по редица редове, HBase съхранява клавиши на редове в лексикографски ред. Използвайки тези сортирани клавиши и клеймо за време, можем да изградим оптимизирана заявка.

Сега напред в този урок за HBase, нека ви кажа какви са случаите на употреба и сценариите, при които HBase може да се използва и след това ще сравня HDFS и HBase.

Бих искал да насоча вниманието ви към сценариите, в които HBase е най-подходящ.

Урок за HBase: Къде можем да използваме HBase?

• Трябва да използваме HBase, когато разполагаме с големи масиви от данни (милиони или милиарди или редове и колони) и се нуждаем от бърз, произволен и в реално време, достъп за четене и запис върху данните.
• Наборите от данни са разпределени в различни клъстери и се нуждаем от висока мащабируемост за обработка на данни.
• Данните се събират от различни източници на данни и са полуструктурирани или неструктурирани данни или комбинация от всички. С него може лесно да се работи с HBase.
• Искате да съхранявате ориентирани към колони данни.
• Имате много версии на наборите данни и трябва да съхранявате всички.

Преди да премина към казус на Facebook messenger,нека ви кажа какви са разликите между HBase и HDFS.

Урок за HBase: HBase VS HDFS

HDFS е разпределена файлова система, базирана на Java, която ви позволява да съхранявате големи данни в множество възли в клъстер Hadoop. И така, HDFS е основна система за съхранение за съхранение на данните в разпределената среда. HDFS е файлова система, докато HBase е база данни (подобно на NTFS и MySQL).

Както HDFS, така и HBase съхраняват всякакъв вид данни (т.е. структурирани, полуструктурирани и неструктурирани) в разпределена среда, така че нека да разгледаме разликите между HDFS файловата система и HBase, база данни NoSQL.

• HBase осигурява достъп с ниска латентност до малки количества данни в рамките на големи масиви от данни, докато HDFS осигурява операции с висока латентност.
• HBase поддържа произволно четене и запис, докато HDFS поддържа WORM (Писане веднъж прочетено многократно или многократно).
• HDFS е достъпен основно или предимно чрез задания MapReduce, докато HBase е достъпен чрез команди на черупки, Java API, REST, Avro или Thrift API.

HDFS съхранява големи набори от данни в разпределена среда и използва пакетната обработка на тези данни. Напр. това би помогнало на уебсайт за електронна търговия да съхранява милиони данни на клиента в разпределена среда, която нараства в продължение на дълъг период от време (може да бъде 4-5 години или повече). След това използва групова обработка на тези данни и анализира поведението, модела, изискванията на клиентите. Тогава компанията може да разбере какъв тип продукт, покупка на клиента през кои месеци. Той помага да се съхраняват архивирани данни и да се извършва групова обработка над тях.

Докато HBase съхранява данните по начин, ориентиран към колона, където всяка колона се съхранява заедно, така че четенето става по-бързо, като се използва обработката в реално време. Напр. в подобна среда за електронна търговия той съхранява милиони данни за продукти. Така че, ако търсите продукт сред милиони продукти, той оптимизира заявката и процеса на търсене, като резултатът се получава незабавно (или можете да кажете в реално време). Подробното HBase архитектурно обяснение , Ще отразявам в следващия си блог.

Както знаем, че HBase се разпространява през HDFS, така че комбинацията от двете ни дава чудесна възможност да използваме предимствата и на двете, в съобразено решение, както ще видим в по-долу казус на Facebook messenger.

Урок за HBase: Казус на Facebook Messenger

Платформа за съобщения във Facebook премина от Apache Cassandra към HBase през ноември 2010 г.

Facebook Messenger съчетава съобщения, имейл, чат и SMS в разговор в реално време. Facebook се опитваше да изгради мащабируема и стабилна инфраструктура за обработка на набор от тези услуги.

По това време инфраструктурата за съобщения обработва над 350 милиона потребители, изпращащи над 15 милиарда съобщения от човек на човек на месец. Услугата за чат поддържа над 300 милиона потребители, които изпращат над 120 милиарда съобщения на месец.

Чрез наблюдение на употребата те откриха, че се появяват два общи модела на данни:

пример за променлива на екземпляр в java

• Кратък набор от временни данни, които са склонни да бъдат променливи
• Непрекъснато нарастващ набор от данни, до които рядко се достига

Facebook искаше да намери решение за съхранение на тези два модела на използване и те започнаха разследване, за да намерят заместител на съществуващата инфраструктура за съобщения.

По-рано през 2008 г. те използваха база данни с отворен код, т.е. Cassandra, която е хранилище за ключ-стойност с евентуална последователност, което вече беше в производство, обслужващо трафик за Inbox Search. Техните екипи имаха страхотни познания в използването и управлението на база данни MySQL, така че смяната на някоя от технологиите беше сериозна грижа за тях.

Те прекараха няколко седмици в тестване на различни рамки, за да оценят клъстерите на MySQL, Apache Cassandra, Apache HBase и други системи. В крайна сметка те избраха HBase.

Тъй като MySQL не успя да се справи ефективно с големите набори от данни, тъй като индексите и наборите от данни нараснаха, производителността пострада. Те откриха, че Касандра не може да се справи с труден модел, за да съгласува новата си инфраструктура за съобщения.

Основните проблеми бяха:

• Съхраняване на големите набори непрекъснато нарастващи данни от различни услуги на Facebook.
• Изисква база данни, която може да използва висока обработка върху нея.
• Висока производителност, необходима за обслужване на милиони заявки.
• Поддържане на последователност в съхранението и производителността.

Фигура: Предизвикателства, пред които е изпратен Facebook messenger

За всички тези проблеми Facebook излезе с решение, т.е. HBase. Facebook прие HBase за обслужване на Facebook messenger, чат, имейл и др. Поради различните му функции.

HBase се предлага с много добра скалируемост и производителност за това натоварване с по-прост модел на последователност от Cassandra. Въпреки че установиха, че HBase е най-подходящата от гледна точка на техните изисквания като автоматично балансиране на натоварването и срив, поддръжка на компресия, множество парчета на сървър и т.н.

HDFS, която е основната файлова система, използвана от HBase, също им предоставя няколко необходими функции, като например контролни суми от край до край, репликация и автоматично балансиране на натоварването.

Фигура: HBase като решение за Facebook messenger

Докато приемаха HBase, те също се съсредоточиха върху предаването на резултатите на самата HBase и започнаха да работят в тясно сътрудничество с Apache общността.

Тъй като съобщенията приемат данни от различни източници като SMS, чатове и имейли, те написаха сървър за приложения, за да се справят с вземането на всички решения за съобщението на потребителя. Той взаимодейства с голям брой други услуги. Прикачените файлове се съхраняват в Haystack (който работи на HBase). Те също така написаха услуга за откриване на потребители на върха на Apache ZooKeeper, която говори с други инфраструктурни услуги за връзки с приятели, проверка на имейл акаунт, решения за доставка и решения за поверителност.

Екипът на Facebook отдели много време, за да потвърди, че всяка от тези услуги е стабилна, надеждна и осигурява добра производителност за работа със система за съобщения в реално време.

Надявам се, че този урок на HBase е информативен и ви е харесал. В този блог се запознахте с основите на HBase и неговите функции.В следващия ми блог на , Ще обясня архитектура на HBase и работата на HBase, което го прави популярен за бързо и произволно четене / запис.

След като разбрахте основите на HBase, разгледайте от Edureka, доверена компания за онлайн обучение с мрежа от над 250 000 доволни учащи, разпространени по целия свят. Курсът за обучение по сертифициране на големи данни Hadoop на Edureka помага на обучаващите се да станат експерти в HDFS, прежди, MapReduce, Pig, Hive, HBase, Oozie, Flume и Sqoop, като използват случаи в реално време за търговия на дребно, социални медии, авиация, туризъм, финанси

Имате въпрос към нас? Моля, споменете го в раздела за коментари и ние ще се свържем с вас.