Урок за Apache Sqoop: ArchiТекстура, команди и пример
Прафула Ранадив
⚡ Умно обобщение
Apache Sqoop премества масиви от данни между релационни бази данни и HDFS, използвайки конекторна архитектура, генерирайки MapReduce задачи, които импортират таблици в Hive или HBase и експортират обработените резултати обратно към изходната система.
Какво е SQOOP в Hadoop?
Апачи Скуп (SQL-to-Hadoop) е инструмент, предназначен да поддържа групов експорт и импорт на данни в HDFS от структурирани хранилища за данни, като релационни бази данни, корпоративни хранилища за данни и NoSQL системи. Това е инструмент за миграция на данни, базиран на конекторна архитектура, която поддържа плъгини за осигуряване на свързаност с нови външни системи.
Примерен случай на използване на Hadoop Sqoop е предприятие, което изпълнява нощен импорт на Sqoop, за да зареди данните за деня от производствена транзакционна RDBMS в Кошер хранилище на данни за допълнителен анализ.
След това в този урок за Apache Sqoop ще научим за архитектурата на Apache Sqoop.
Sqoop Archiтекстура
Всички съществуващи Системи за управление на бази данни са проектирани с SQL стандарт в ума. Въпреки това, всяка СУБД се различава до известна степен по отношение на диалекта. Така че тази разлика създава предизвикателства, когато става въпрос за трансфер на данни между системите. Sqoop Connectors са компоненти, които помагат за преодоляване на тези предизвикателства.
Трансферът на данни между Sqoop Hadoop и външна система за съхранение е възможен с помощта на конекторите на Sqoop.
Sqoop има конектори за работа с редица популярни релационни бази данни, включително MySQL, PostgreSQL, Oracle, SQL Server и DB2. Всеки от тези конектори знае как да взаимодейства със свързаната с него СУБД. Има и общ JDBC конектор за свързване към всяка база данни, която поддържа JavaJDBC протоколът на. В допълнение, Sqoop предоставя и оптимизиран MySQL намлява PostgreSQL конектори, които използват API, специфични за базата данни, за ефективно извършване на групови трансфери.
Диаграмата по-долу поставя Sqoop клиента между външното хранилище за данни и Hadoop клъстера, като конекторният слой е от едната страна, а HDFS, Hive и HBase - от другата.
Под слоя на конектора, Sqoop генерира Java клас, който отразява един ред от таблицата и след това изпраща само карта MapReduce задача. Всяка задача за картографиране чете собствения си сегмент от диапазона на разделените колони, така че пропускателната способност се мащабира с броя на картографите, а не с един единствен JDBC курсор.
В допълнение към това, Sqoop предлага различни конектори на трети страни за хранилища на данни, вариращи от корпоративни хранилища за данни (включително Netezza, Teradata и Oracle) към NoSQL магазини (като Couchbase). Тези конектори обаче не идват с пакета Sqoop; те трябва да се изтеглят отделно и могат лесно да се добавят към съществуваща инсталация на Sqoop.
Защо се нуждаем от Sqoop?
Аналитичната обработка с помощта на Hadoop изисква зареждане на огромни количества данни от различни източници в Hadoop клъстери. Този процес на масово зареждане на данни в Hadoop от разнородни източници и последващата им обработка идва с определен набор от предизвикателства. Поддържането и осигуряването на съгласуваност на данните и осигуряването на ефективно използване на ресурсите са някои фактори, които трябва да имате предвид, преди да изберете правилния подход за зареждане на данни.
Основни проблеми:
- Зареждане на данни с помощта на скриптове — Традиционният подход с използване на скриптове за зареждане на данни не е подходящ за зареждане на масиви от данни в Hadoop; този подход е неефективен и отнема много време.
- Директен достъп до външни данни чрез приложение Map-Reduce — Осигуряването на директен достъп до данните, намиращи се във външни системи (без зареждане в Hadoop), за приложения, работещи с map-reduce, усложнява тези приложения. Така че този подход не е осъществим.
В допълнение към способността си да работи с огромни количества данни, Hadoop може да работи с данни в няколко различни форми. Затова, за да се заредят такива хетерогенни данни в Hadoop, са разработени различни инструменти. Sqoop намлява воденичен улей са два такива инструмента за зареждане на данни.
След това в този урок за Sqoop с примери ще научим за разликата между Sqoop, Flume и HDFS.
Sqoop срещу Flume срещу HDFS в Hadoop
| Sqoop | воденичен улей | HDFS |
|---|---|---|
| Sqoop се използва за импортиране на данни от източници на структурирани данни като RDBMS. | Flue се използва за преместване на групови поточни данни в HDFS. | HDFS е разпределена файлова система, използвана от екосистемата Hadoop за съхраняване на данни. |
| Sqoop има архитектура, базирана на конектори. Конекторите знаят как да се свържат със съответния източник на данни и да извлекат данните. | Flume има базирана на агент архитектура. Тук е написан код (който се нарича „агент“), който се грижи за извличането на данни. | HDFS има разпределена архитектура, при която данните се разпределят между множество възли за данни. |
| HDFS е дестинация за импортиране на данни с помощта на Sqoop. | Данните протичат към HDFS през нула или повече канали. | HDFS е крайната дестинация за съхранение на данни. |
| Зареждането на данни от Sqoop не се управлява от събития. | Зареждането на данни на Flume може да бъде управлявано от събитие. | HDFS просто съхранява данни, предоставени му по какъвто и да е начин. |
| За да импортирате данни от източници на структурирани данни, трябва да използвате само команди на Sqoop, тъй като неговите конектори знаят как да взаимодействат с източници на структурирани данни и да извличат данни от тях. | За да заредите поточни данни като туитове, генерирани в Twitter или регистрационни файлове на уеб сървър, трябва да се използва Flume. Flume агентите са създадени за извличане на поточни данни. | HDFS има свои собствени вградени команди за съхранение на данни. HDFS не може да импортира стрийминг данни. |
Основни характеристики на Sqoop
Горното сравнение обяснява къде принадлежи Sqoop. Наборът от функции по-долу определя дали той е подходящ за конкретна задача за приемане.
- Пълно натоварване: Една команда копира цяла таблица и
import-all-tablesкопира всяка таблица в схемата наведнъж. - Инкрементално натоварване:
appendвид tracks монотонно нарастваща колона, като например сурогатен ключ, докатоlastmodifiedвид tracks колона с времеви отпечатък, така че се пренасят само нови или променени редове. - Паралелен трансфер: Разделената колона разделя ключовия диапазон между задачите за картографиране, а броят на картографите задава колко да се изпълняват едновременно.
- Импортиране на заявки в свободна форма: Резултатът от произволен SQL израз може да бъде импортиран вместо цяла таблица, което запазва съединенията и филтрите от страната на базата данни.
- Директно товарене в склада: Импортирането може да създаде и попълни Кошер таблица или да записвате директно в HBase таблица, вместо да спиратеping в сурови HDFS файлове.
- Компресия и файлови формати: Изходът може да бъде записан като текст с разделители, SequenceFile, Avro или Parquet, с опционална компресия на ниво кодек.
- Сигурност: Sqoop се интегрира с Kerberos и идентификационните данни могат да бъдат прочетени от файл с пароли или да бъдат поискани, вместо да бъдат въвеждани в командния ред.
Команди за импортиране и експортиране на Sqoop
И двете посоки на прехвърлянето се извършват чрез една помощна програма от командния ред. Инструментът за импортиране премества редове от базата данни в Hadoop, а инструментът за експортиране премества файлове от Hadoop обратно в таблица на базата данни.
Типичният импорт наименува JDBC връзката, таблицата източник, директорията местоназначение, разделената колона и броя на мапърите:
sqoop import \ --connect jdbc:mysql://localhost:3306/employees \ --username hadoop \ --password-file /user/hadoop/.mysql.password \ --table employees \ --target-dir /user/hadoop/warehouse/employees \ --split-by emp_no \ --num-mappers 4
Експортирането обръща потока. То чете файловете с разделители, които вече се намират в HDFS директория, и ги вмъква в съществуваща таблица, така че целевата таблица трябва първо да бъде създадена:
sqoop export \ --connect jdbc:mysql://localhost:3306/employees \ --username hadoop \ --password-file /user/hadoop/.mysql.password \ --table employee_summary \ --export-dir /user/hadoop/warehouse/employee_summary \ --input-fields-terminated-by ','
Една нощна задача рядко се нуждае от цялата таблица два пъти. Инкременталният импорт записва най-високата стойност, която вече е видял, и започва оттам при следващото изпълнение:
sqoop import \ --connect jdbc:mysql://localhost:3306/sales \ --table orders \ --incremental append \ --check-column order_id \ --last-value 15000 \ --target-dir /user/hadoop/warehouse/orders
Това са аргументите, които се появяват в почти всяка работа:
| аргумент | Какво контролира |
|---|---|
--connect |
JDBC URL на изходната или целевата база данни. |
--table |
Таблица, от която се чете при импортиране или в която се записва при експортиране. |
--target-dir |
HDFS директория, която получава импорт. Тя не трябва да съществува вече. |
--export-dir |
HDFS директория, чиито файлове се четат чрез експорт. |
--split-by |
Колона, чийто диапазон е разделен между задачите на картата. |
--num-mappers (-m) |
Брой паралелни задачи с картата. Стойността по подразбиране е четири. |
--incremental |
Избира append or lastmodified промяна tracцар. |
--hive-import |
Създава съответстващата таблица Hive и зарежда импортираните данни в нея. |
⚠️ Внимание: Експортирането не е единична транзакция. Всяка задача за картографиране записва свой собствен пакет, така че неуспех по средата може да остави част от данните в целевата таблица. Насочете записа през междинна таблица, когато натоварването трябва да бъде „всичко или нищо“.
Състояние на проекта Sqoop и съвременни алтернативи
Един детайл от версията е от значение, преди която и да е от горните команди да влезе в планировчика.
Разработчиците на Sqoop гласуваха за оттегляне на проекта през юни 2021 г. и преминаването към Таванско помещение Апачи завършено през юли 2021 г. Уебсайтът, пощенските списъци, git хранилището, проблемът tracker и файловете за изтегляне остават достъпни, но само за четене, и не се планират други издания. Последната производствена версия е Sqoop 1.4.7 от 2017 г.; отделната линия Sqoop 2 (1.99.x) никога не достигна паритет на функциите и никога не беше обявена за готова за производство.
Съществуващите задачи на Sqoop все още се изпълняват, а търговските дистрибуции на Hadoop продължават да доставят и поддържат инструмента в рамките на собствените си платформи. Новата работа по приемане на данни обаче обикновено се изгражда върху една от следните платформи:
| Алтернатива | Най-добро пасване |
|---|---|
| Spark с JDBC източника на данни | Таблица с партиди extracts, които вече се намират вътре в a Spark конвейер, с разделени четения вместо мапери. |
| Apache NiFi | Базирано на потоци, визуално конфигурирано маршрутизиране между много хетерогенни системи. |
| Kafka Connect с CDC конектор | Непрекъснато събиране на данни за промени вместо нощен пакетен прозорец. |
| Управлявани ETL платформи, като например Таленд | Предварително изградени конектори, планиране и произход без ръчно написани задачи. |
