тут важный момент — параллелизм: если есть сотня железяк, то я бы не взялся просто так соревноваться в обработке данных со sparkом (особенно — согласен — учитывая удобство)…
По бигдате — надо поискать, должна где-то быть (сам пока не искал, но скоро начну).
а как я был скептичен (в юности разрабатывал параллельную файловую систему для немецких MPP суперкомпьютеров): распределенная файловая система? на Java? В user space? да ладно!
Но — блин мне — работает. Особенно радует spark: как он так быстро молотит, до сих пор удивляюсь.
Будет задачка (просто так обычно не получается ощутить) — попробуйте, интересно.
Производительность dataframe и sql подходов эквивалентна (об этом пишу), оба компилируются в rdd (по определению), из этого следует, что теоретически можно написать такие трансформации rdd, которые невозможно будет выразить через sql/dataframe.
Но практика — наверное — в том, что оно не всегда того стоит (писать на низком уровне), у меня (пока) нет данных, чтобы нормально дискутировать дальше в этом направлении...
Пример есть пример (договора страхования), он не меняет сути
Многие наши "консультанты" так и говорят — "зачем вам Hadoop, у вас данных мало...". Категорически не согласен: учиться плавать нужно на мелкой воде (не видел ни одного живого, кто делал наоборот, вопреки поговорке), сделать "много" данных мы можем (договоров — не так много, но это не единственная сущность), но что мы с ними будем делать (как только они не смогут быть переработаны "промышленной СУБД")
Полностью поддерживаю комментарий ниже — hadoop не только база, но и возможность параллельной обработки. Консультанты (особенно со стороны "промышленных СУБД") часто про это зачем-то забывают.
511 никто не выбирал :-), это максимально возможное при использовании дельта-кодирования количество значений в одном run-е…
В колонке Y все симметрично, просто там шаг другой (не 1, а 3), рекомендую посмотреть jupyter notebook — обновил статью, вставил ссылку на гитхаб, где лежит книжка с разбором формата: там все подробно (и можно попробовать самому)
В-целом Вы верно поняли, чуть уточню: Ливи "инжектит" python код в driver, он там и исполняется (со всеми вытекающими). Очень похоже на jupyter — с помощью Ливи мы "добрасываем" операторы в конец нашего кода.
На "драйвере" живет сессия, сами данные (dataframe-ы) живут в worker-ах, их жизнью управляет Spark и они доступны в Spark-программе по именам (как обычно).
Про "высокий порог" — напишите кратенько, как сделать что-то подобное с помощью плагина (чтобы можно было дрессировщику змей взять и попробовать)?
Про поддержку вопрос дискуссионный: любая разработка — потенциальная проблема для поддержки. Размер проблемы определяется качеством кода. Плагины в этом смысле, на мой взгляд, отличаются тем, что они могут не заработать много где (неизвестно где) за счет своей универсальности. Расширение через html — локальное, решает локальную задачу и не заработает там, где оно установлено. Опять же код проще (за счет не универсальности).
Мир не черно белый, я описал возможность, пользоваться ей или нет — вопрос филосовский и сильно зависит от конкретных условий (в компании).
про сжатие достаточно объяснимо (чудес не бывает), разные алгоритмы сжатия по-разному работают на разных данных — тоже понятно.
Сравню, напишу — согласен, "итого" напрашивается, только еще раз подчеркну — сравнивать получится не форматы, а то, как hive (видимо, сравнивать буду на нем) "умеет" ими пользоваться.
Понял про интерес к сравнению, с csv сравнивать можно только как с самым худшим из возможных случаев (медленный и большой). Сравнение с паркетом последует.
Да, конечно, 10 тыс строк — это не про хадуп… Прекрасно понимаю, но просто абсолютные цифры поразили воображение (и подтолкнули разобраться).
На больших файлах получается тоже неплохо: CSV — 38 ГБ, ORC — 5.7 ГБ, какой вклад внесло просто сжатие (этот ORC, конечно же, его использует), какой — кодирование, сколько "съели" индексы — надо разбираться.
С паркетом сравню, про Impala — да, это так. Причина, как мне кажется, как раз в том, что воспользоваться всеми возможностями ORC сложно. Научатся со временем (надеюсь...).
формат ORC поддерживает транзакции, реализации формата (например, Hive) — проверьте свою версию (в нашем кластере Hive поддерживает транзакции). Почитать можно там же — вот короткая ссылка (https://orc.apache.org/docs/acid.html), достаточно подробно написано.
Если совсем кратко — то перезаписывается конечно же не весь файл (на то есть партиции), с поддержкой ACID в HDFS появляются базовые файлы и дельты. Почитайте, я погружусь в это чуть позже, если будет о чем написать — поделюсь.
Библиотека рукописная — кто же напишет код в формате Robot Remote Server??? Я посматривал интернет и пару раз писал в Robot Framework сообщество про то, что мы используем робот для автоматического тестирования SAP, что-то никто не заинтересовался… Мы есть в списке клиентов робота на их сайте, впочем. Этого я добился (и даже — в первом ряду, но это — алфавит так лег, я думаю).
Библиотека базируется на документированном SAP-ом протоколе взаимодействия с SAP GUI (название документа я привел — он существует, проверил перед публикацией).
Вопрос про "скрещивание" слишком открытый (=широкий): SAP допускает исполнение python-кода (где-то в дебрях ABAP, т.е. можно писать на python-е вместо ABAP-а), мы смотрели — не поняли, зачем нам это нужно (точно ограничений и граблей много разложено...). Эту тему лучше погуглить, но в-целом, насколько мы поняли, пересечений python-а и SAP ERP нет и не планируется.
Вроде как, SAP поддерживает все "открытые" инструменты в части ML (в своей BigData платформе), там должен быть python, но это — другая область...
У SAP-а есть свои инструменты для создания инструкций (название могу перепутать, поэтому опущу), они даже интегрированы с автотестами (но только eCATT, если не ошибаюсь). Но хотелось большего (в плане модульности), и более простого.
У нас эта часть находится в развитии — то, что сделано, еще не финал...
Робот ориентирован на BDD, ниже процитирую из документации Robot Framework (сорри за английский), а от себя так — да, я перевел все свои автотесты по той веб разработке, которую упоминал, в этот формат. Он структурирует "поток сознания", мне понравилось. Бизнес впрочем не понял такого переформатирования и остался равнодушен (кстати, типично)...
Наверное это не прозвучало в статье, робот — достаточно серьезная разработка, они проводят конференции пользователей, развивают его — живой продукт. Рекомендую (как миниум посмотреть).
Цитата:
It is also possible to write test cases as requirements that also non-technical project stakeholders must understand. These executable requirements are a corner stone of a process commonly called Acceptance Test Driven Development (ATDD) or Specification by Example.
One way to write these requirements/tests is Given-When-Then style popularized by Behavior Driven Development (BDD). When writing test cases in this style, the initial state is usually expressed with a keyword starting with word Given, the actions are described with keyword starting with When and the expectations with a keyword starting with Then. Keyword starting with And or But may be used if a step has more than one action.
*** Test Cases ***
Valid Login
Given login page is open
When valid username and password are inserted
and credentials are submitted
Then welcome page should be open
Про CBTA — я ходил на однодневный семинар в SAP, внимательно слушал и вникал. Поймите меня правильно — давно это было, вот что осталось в памяти:
Свой большой мир. Чтобы начать тестировать (условно — создать убыток) нужно этот мир освоить и настроить под свою специфику. Это проходимо, но (мой случай) опыта в SAP было мало, для меня это был минус.
Ориентация на запись. Наши тестировщики на тот момент меня убедили — инструменты, которые «пишут» действия пользователя, неэффективны в долгой перспективе. Записанные скрипты сложно менять. Мне хотелось иметь инструмент, который позволяет оперировать с тестами как с программой (потенциально — генерировать ее), создавать свои абстракции и таким образом бороться со сложностью. Мне показалось (могу ошибаться — высказываю свое мнение), что CBTA таких возможностей не представляет.
Представьте себе: как Вы будете обсуждать с бизнесом сценарий использования планируемой доработки в случае использования CBTA? Я, конечно, в ATDD полез, но эта мысль/цель тогда тоже была. В случае робота мы прямо из ВЕБ интерфейса печатаем текст и идем обсуждать, «крыжить» по бумажке. А потом наращиваем этот текст реальным «мясом»…
Ссылки на github с примерами пока нет, примеры чего именно Вам интересны? GitHub — это исходники на языках программирования (как правило), если туда выложить тесты на нашем языке (робота) — вряд ли это интересно. Если речь идет о библиотеке управления SAP GUI, то да, ее выложу (надо немного «причесать»).
Про инструменты:
CBTA — мой косяк (опечатка, исправил), я вместо него написал TAO…
eCATT: это все же программирование (своего рода) на ABAP, не хотел туда углубляться (и «углублять» наших тестировщиков). Представьте сложные случаи — в нашем случае убыток по ПВУ создается руками примерно за 10 минут, уложить это в «портянку» на eCATT — вряд ли. Нужно будет что-то конструировать, что мы и сделали (вне SAP).
TestComplete (насколько я помню — уже года 4 прошло от начала) на тот момент не мог управлять SAP GUI напрямую, именно он использовался нашими тестировщиками для регресса всего остального нашего софта, и именно в нем они никак не могли тогда научиться тестировать SAP.
UFT и много другое смотрели «по диагонали» — в гугловой выдаче с минимальным погружением. Я искал простой, максимально универсальный и SAP-онезависимый способ. В процессе поиска мне показали, как из Excel-а заполняют документы (партнер SAP в каком-то из проектов для просто автоматизации рутинной операции), видя это желание осваивать какой-то лицензионно обременный продукт автоматизированного тестирования отошло на второй план.
тут важный момент — параллелизм: если есть сотня железяк, то я бы не взялся просто так соревноваться в обработке данных со sparkом (особенно — согласен — учитывая удобство)…
По бигдате — надо поискать, должна где-то быть (сам пока не искал, но скоро начну).
а как я был скептичен (в юности разрабатывал параллельную файловую систему для немецких MPP суперкомпьютеров): распределенная файловая система? на Java? В user space? да ладно!
Но — блин мне — работает. Особенно радует spark: как он так быстро молотит, до сих пор удивляюсь.
Будет задачка (просто так обычно не получается ощутить) — попробуйте, интересно.
Производительность dataframe и sql подходов эквивалентна (об этом пишу), оба компилируются в rdd (по определению), из этого следует, что теоретически можно написать такие трансформации rdd, которые невозможно будет выразить через sql/dataframe.
Но практика — наверное — в том, что оно не всегда того стоит (писать на низком уровне), у меня (пока) нет данных, чтобы нормально дискутировать дальше в этом направлении...
спасибо за мысли! думаем и работаем дальше :-)
Ваш п.3: согласен, это важно, про это забывают (почему-то)
511 никто не выбирал :-), это максимально возможное при использовании дельта-кодирования количество значений в одном run-е…
В колонке Y все симметрично, просто там шаг другой (не 1, а 3), рекомендую посмотреть jupyter notebook — обновил статью, вставил ссылку на гитхаб, где лежит книжка с разбором формата: там все подробно (и можно попробовать самому)
В-целом Вы верно поняли, чуть уточню: Ливи "инжектит" python код в driver, он там и исполняется (со всеми вытекающими). Очень похоже на jupyter — с помощью Ливи мы "добрасываем" операторы в конец нашего кода.
На "драйвере" живет сессия, сами данные (dataframe-ы) живут в worker-ах, их жизнью управляет Spark и они доступны в Spark-программе по именам (как обычно).
Про "высокий порог" — напишите кратенько, как сделать что-то подобное с помощью плагина (чтобы можно было дрессировщику змей взять и попробовать)?
Про поддержку вопрос дискуссионный: любая разработка — потенциальная проблема для поддержки. Размер проблемы определяется качеством кода. Плагины в этом смысле, на мой взгляд, отличаются тем, что они могут не заработать много где (неизвестно где) за счет своей универсальности. Расширение через html — локальное, решает локальную задачу и не заработает там, где оно установлено. Опять же код проще (за счет не универсальности).
Мир не черно белый, я описал возможность, пользоваться ей или нет — вопрос филосовский и сильно зависит от конкретных условий (в компании).
про сжатие достаточно объяснимо (чудес не бывает), разные алгоритмы сжатия по-разному работают на разных данных — тоже понятно.
Сравню, напишу — согласен, "итого" напрашивается, только еще раз подчеркну — сравнивать получится не форматы, а то, как hive (видимо, сравнивать буду на нем) "умеет" ими пользоваться.
Понял про интерес к сравнению, с csv сравнивать можно только как с самым худшим из возможных случаев (медленный и большой). Сравнение с паркетом последует.
Да, конечно, 10 тыс строк — это не про хадуп… Прекрасно понимаю, но просто абсолютные цифры поразили воображение (и подтолкнули разобраться).
На больших файлах получается тоже неплохо: CSV — 38 ГБ, ORC — 5.7 ГБ, какой вклад внесло просто сжатие (этот ORC, конечно же, его использует), какой — кодирование, сколько "съели" индексы — надо разбираться.
С паркетом сравню, про Impala — да, это так. Причина, как мне кажется, как раз в том, что воспользоваться всеми возможностями ORC сложно. Научатся со временем (надеюсь...).
формат ORC поддерживает транзакции, реализации формата (например, Hive) — проверьте свою версию (в нашем кластере Hive поддерживает транзакции). Почитать можно там же — вот короткая ссылка (https://orc.apache.org/docs/acid.html), достаточно подробно написано.
Если совсем кратко — то перезаписывается конечно же не весь файл (на то есть партиции), с поддержкой ACID в HDFS появляются базовые файлы и дельты. Почитайте, я погружусь в это чуть позже, если будет о чем написать — поделюсь.
Библиотека рукописная — кто же напишет код в формате Robot Remote Server??? Я посматривал интернет и пару раз писал в Robot Framework сообщество про то, что мы используем робот для автоматического тестирования SAP, что-то никто не заинтересовался… Мы есть в списке клиентов робота на их сайте, впочем. Этого я добился (и даже — в первом ряду, но это — алфавит так лег, я думаю).
Библиотека базируется на документированном SAP-ом протоколе взаимодействия с SAP GUI (название документа я привел — он существует, проверил перед публикацией).
Вопрос про "скрещивание" слишком открытый (=широкий): SAP допускает исполнение python-кода (где-то в дебрях ABAP, т.е. можно писать на python-е вместо ABAP-а), мы смотрели — не поняли, зачем нам это нужно (точно ограничений и граблей много разложено...). Эту тему лучше погуглить, но в-целом, насколько мы поняли, пересечений python-а и SAP ERP нет и не планируется.
Вроде как, SAP поддерживает все "открытые" инструменты в части ML (в своей BigData платформе), там должен быть python, но это — другая область...
Да, посмотрел ссылки — здорово!
У SAP-а есть свои инструменты для создания инструкций (название могу перепутать, поэтому опущу), они даже интегрированы с автотестами (но только eCATT, если не ошибаюсь). Но хотелось большего (в плане модульности), и более простого.
У нас эта часть находится в развитии — то, что сделано, еще не финал...
Нет, не изобретали. Да, рассматривали…
Робот ориентирован на BDD, ниже процитирую из документации Robot Framework (сорри за английский), а от себя так — да, я перевел все свои автотесты по той веб разработке, которую упоминал, в этот формат. Он структурирует "поток сознания", мне понравилось. Бизнес впрочем не понял такого переформатирования и остался равнодушен (кстати, типично)...
Наверное это не прозвучало в статье, робот — достаточно серьезная разработка, они проводят конференции пользователей, развивают его — живой продукт. Рекомендую (как миниум посмотреть).
Цитата:
It is also possible to write test cases as requirements that also non-technical project stakeholders must understand. These executable requirements are a corner stone of a process commonly called Acceptance Test Driven Development (ATDD) or Specification by Example.
One way to write these requirements/tests is Given-When-Then style popularized by Behavior Driven Development (BDD). When writing test cases in this style, the initial state is usually expressed with a keyword starting with word Given, the actions are described with keyword starting with When and the expectations with a keyword starting with Then. Keyword starting with And or But may be used if a step has more than one action.
Про CBTA — я ходил на однодневный семинар в SAP, внимательно слушал и вникал. Поймите меня правильно — давно это было, вот что осталось в памяти:
Свой большой мир. Чтобы начать тестировать (условно — создать убыток) нужно этот мир освоить и настроить под свою специфику. Это проходимо, но (мой случай) опыта в SAP было мало, для меня это был минус.
Ориентация на запись. Наши тестировщики на тот момент меня убедили — инструменты, которые «пишут» действия пользователя, неэффективны в долгой перспективе. Записанные скрипты сложно менять. Мне хотелось иметь инструмент, который позволяет оперировать с тестами как с программой (потенциально — генерировать ее), создавать свои абстракции и таким образом бороться со сложностью. Мне показалось (могу ошибаться — высказываю свое мнение), что CBTA таких возможностей не представляет.
Представьте себе: как Вы будете обсуждать с бизнесом сценарий использования планируемой доработки в случае использования CBTA? Я, конечно, в ATDD полез, но эта мысль/цель тогда тоже была. В случае робота мы прямо из ВЕБ интерфейса печатаем текст и идем обсуждать, «крыжить» по бумажке. А потом наращиваем этот текст реальным «мясом»…
Про инструменты:
CBTA — мой косяк (опечатка, исправил), я вместо него написал TAO…
eCATT: это все же программирование (своего рода) на ABAP, не хотел туда углубляться (и «углублять» наших тестировщиков). Представьте сложные случаи — в нашем случае убыток по ПВУ создается руками примерно за 10 минут, уложить это в «портянку» на eCATT — вряд ли. Нужно будет что-то конструировать, что мы и сделали (вне SAP).
TestComplete (насколько я помню — уже года 4 прошло от начала) на тот момент не мог управлять SAP GUI напрямую, именно он использовался нашими тестировщиками для регресса всего остального нашего софта, и именно в нем они никак не могли тогда научиться тестировать SAP.
UFT и много другое смотрели «по диагонали» — в гугловой выдаче с минимальным погружением. Я искал простой, максимально универсальный и SAP-онезависимый способ. В процессе поиска мне показали, как из Excel-а заполняют документы (партнер SAP в каком-то из проектов для просто автоматизации рутинной операции), видя это желание осваивать какой-то лицензионно обременный продукт автоматизированного тестирования отошло на второй план.