Она и не нужна. Если подходить так, придется писать полноценный транслятор по каждому инструменту.
Но мы же решаем свою собственную задачу. Зачем нам полноценный транслятор?
Пример:
В проекте есть есть sqoop скрипты, которые выглядят так:
sqoop --query "select * from b1.t1 join b1.t2 on t1.id = t2.t1_id" --table b2.t3
То есть логика датафлоу запакована внутрь sqoop и там внутрь sql.
Но ведь для данного проекта, чтобы получить данные о датафлоу нужно всего лишь выполнить примерно такой условный скрипт:
val tables = sqoopScript.splitBy([' ', ',', '(', ')']).match('[a-z]/.[a-z]')
не уверен что синтаксис правильный, но суть в чем - разбить содержимое файла на токены и оставить из них только те, где токен это два слова разделенных символом точка. мы получим b1.t1, b2.t2, b2.t3
То есть мы проанализировали проект. Нашли в нем пачку скриптов, и для данного конкретного случая записали такое простое правила парсинга. Это правило для данного конкретного случая, а не общий парсер инструмента. В этом суть. И тогда это работает.
Все правильно. Те же самые опасения были и у нас. Вообще, всего в статье не опишешь, но проект начинался с немного другой архитектурой. Предполагалось, что мы для себя, для наших проектов, изобретем правила, когда логику будем выносить во внешний файл, где будут имена таблиц и логика обработки. Вот этот внешний файл и предполагалось парсить и отображать в виде диаграммы. Но постепенно выяснилось, что этого не требуется. Парсить с десяток языков для извлечения из них информации по датафлоу не так уж и страшно. Реальные трудозатраты на это вполне умеренные, особенно, по сравнению с трудозатратами на сам проект.
Да, все правильно. Именно об этом и статья, что проект обычно получается сложный, и что делать с ним не ясно. Но в реальности, как показывает практика, эта сложность разбивается на 3-5 вполне себе прозрачных варианта, что и позволяет извлечь информацию и построить dataflow проекта. Да, такие диаграммы не описывают всю сложность, как и data catalog, но то, что получается, это набор диаграмм из реальных артефактов проекта, и это намного лучше, чем ничего отсутствие документации вообще.
Что касается вариантов представления информации о таблицах, я сам их могу привести штук 20 не из головы, а из реальных проектов. И вот тут, как раз, и находится основание для такого проекта. Этих вариантов не 500 и не 5000, а намного меньше, то есть столько, что позволяет построить набор правил для парсинга исходников и извлечения из них информации о dataflow.
Как выглядит обычный проект развивавшийся года 3-4? Несколько сотен файлов исходников, несколько десятков таблиц. Что с этим делать? Да вот написать 5-6 правил, которые позволят построить диаграммы dataflow. Это и есть наш проект.
Да, схемы на выходе из одного и входе в другой датасет мы не проверяем, такая проблема есть. Но отсутствие проверки схем основано на том, что в spark вообще поддерживается 'select * from table1'. По крайней мере в нашем случае эта проблема не сильно портит картину. Как раз для валидации запросов и есть в нашем подходе отладка — возможность прогнать задачу до нужного датасета. Но вообще вопрос поставлен верно. Если на основе описанного нами подхода делать серьезный инструмент, то валидацию схем туда надо бы прикрутить. Но как раз необходимости серьезного инструмента мы и хотели избежать.
Не прятать, а выносить из кода во внешний файл, чтобы код не усложнялся с усложнением проекта. Это всего лишь развитие идеи параметризации проекта. Во внешний файл выносим не список источников, а чуть больше.
2. Можно ведь сделать отдельные spark-приложения и тем же oozie настроить их последовательный запуск.
Oozie запускает Spark Action в отдельных сессиях. Тогда промежуточные данные придется сохранять на диск. Во-первых, это место. Во-вторых, тогда весь смысл spark оптимизации теряется.
3. Опять же oozie поддерживает запуск Hive скриптов, где чистый SQL без всякой обвязки.
Hive пока работает на map-reduce и на схожих задачах на порядке медленней spark.
Справедливый вопрос. Может показаться, что мы, не зная ничего о разработке, выдумали свое решение и радуемся. Это не совсем так. Дело в том, что spark-ETL проекты делаются немного не так, как обычные приложения. В обычном случае вы пишете код, при появлении сложностей или повторяющихся кусков применяете паттерны, покрываете это все тестами. Проект усложняется, но его ведет либо одна команда, либо новые люди набираются подходящего уровня и обучаются в проекте.
А разработка на ETL процессов на spark выглядит несколько иначе. Сначала заказчики хотят витрину. По ходу добавляются еще пожелания, витрин становится больше. И вот тут важный момент — резко растет объем проекта. Что делается в этом случае? Обычно, применяются подходы, усложняющие код, как при разработке обычных приложений.
То есть команда проекта должна усложнить код.
Но людей, способных разрабатывать spark на подходящем уровне крайне мало, а набрать новых нереально, так как это очень дорого и долго. Что получается? Надо на проекте постоянно держать команду spark разработчиков высокого класса. А где они?
А людей, знающих SQL, и имеющих начальные знания и разработке много.
Вот и хочется быть уверенным, что можно осилить проект где обрабатывается не пять источников, как предполагалось сначала, а пятьсот. А это можно сделать, если код проекта остается простым, при этом обеспечивая и увеличение объема проекта, и возможность отладки.
Все правильно. Об этом и сказано в самом начале. Только разбиение проекта на части, и покрытие их тестами означает превращение в полноценный проект. Именно это и превратит простой проект в сложный.
И в результате резко возрастают требования к команде.
Но в этом нет необходимости.
По сути рост сложности спарк проекта, это всего лишь добавление новых датасетов.
Да и что тут покрывать тестами? Есть такой датасет или нет?
Поэтому если идти указанным в самом начале путем, тем, про который вы говорите, это усложнение, которого можно избежать.
Это именно спарк. Он добавляет в папку флаг успешности завершения и метаданные. Если дописывать партицию отдельно, то в ней появятся эти файлы, и прочитать всю папку будет нельзя. И отключается это именно в настройках спарка.
Вопросы деперсонализации данных и организации контролируемого хранилища или хранилища по типу неконтролируемой помойки лежат за рамками темы статьи. Почему вы решили, что данные там открыты и что хранилище неуправляемое? В статье рассматривается всего лишь небольшой вопрос о создании витрины из слабо структурированных данных. Есть там персональная информация или нет, правильно сделано хранилище или нет, это не влияет на необходимость парсить данные и предоставлять их в виде доступном для аналитиков. О подводных камнях этой маленькой задачи и написана статья.
Она и не нужна. Если подходить так, придется писать полноценный транслятор по каждому инструменту.
Но мы же решаем свою собственную задачу. Зачем нам полноценный транслятор?
Пример:
В проекте есть есть sqoop скрипты, которые выглядят так:
sqoop --query "select * from b1.t1 join b1.t2 on t1.id = t2.t1_id" --table b2.t3
То есть логика датафлоу запакована внутрь sqoop и там внутрь sql.
Но ведь для данного проекта, чтобы получить данные о датафлоу нужно всего лишь выполнить примерно такой условный скрипт:
val tables = sqoopScript.splitBy([' ', ',', '(', ')']).match('[a-z]/.[a-z]')
не уверен что синтаксис правильный, но суть в чем - разбить содержимое файла на токены и оставить из них только те, где токен это два слова разделенных символом точка. мы получим b1.t1, b2.t2, b2.t3
То есть мы проанализировали проект. Нашли в нем пачку скриптов, и для данного конкретного случая записали такое простое правила парсинга. Это правило для данного конкретного случая, а не общий парсер инструмента. В этом суть. И тогда это работает.
Все правильно. Те же самые опасения были и у нас. Вообще, всего в статье не опишешь, но проект начинался с немного другой архитектурой. Предполагалось, что мы для себя, для наших проектов, изобретем правила, когда логику будем выносить во внешний файл, где будут имена таблиц и логика обработки. Вот этот внешний файл и предполагалось парсить и отображать в виде диаграммы. Но постепенно выяснилось, что этого не требуется. Парсить с десяток языков для извлечения из них информации по датафлоу не так уж и страшно. Реальные трудозатраты на это вполне умеренные, особенно, по сравнению с трудозатратами на сам проект.
Да, все правильно. Именно об этом и статья, что проект обычно получается сложный, и что делать с ним не ясно. Но в реальности, как показывает практика, эта сложность разбивается на 3-5 вполне себе прозрачных варианта, что и позволяет извлечь информацию и построить dataflow проекта. Да, такие диаграммы не описывают всю сложность, как и data catalog, но то, что получается, это набор диаграмм из реальных артефактов проекта, и это намного лучше, чем ничего отсутствие документации вообще.
Что касается вариантов представления информации о таблицах, я сам их могу привести штук 20 не из головы, а из реальных проектов.
И вот тут, как раз, и находится основание для такого проекта. Этих вариантов не 500 и не 5000, а намного меньше, то есть столько, что позволяет построить набор правил для парсинга исходников и извлечения из них информации о dataflow.
Как выглядит обычный проект развивавшийся года 3-4? Несколько сотен файлов исходников, несколько десятков таблиц. Что с этим делать? Да вот написать 5-6 правил, которые позволят построить диаграммы dataflow. Это и есть наш проект.
docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_remove.html +
docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/close-account.html
Автоматизировать процесс подготовки аккаунта перед удалением пока не планируется.
Не прятать, а выносить из кода во внешний файл, чтобы код не усложнялся с усложнением проекта. Это всего лишь развитие идеи параметризации проекта. Во внешний файл выносим не список источников, а чуть больше.
Oozie запускает Spark Action в отдельных сессиях. Тогда промежуточные данные придется сохранять на диск. Во-первых, это место. Во-вторых, тогда весь смысл spark оптимизации теряется.
Hive пока работает на map-reduce и на схожих задачах на порядке медленней spark.
А разработка на ETL процессов на spark выглядит несколько иначе. Сначала заказчики хотят витрину. По ходу добавляются еще пожелания, витрин становится больше. И вот тут важный момент — резко растет объем проекта. Что делается в этом случае? Обычно, применяются подходы, усложняющие код, как при разработке обычных приложений.
То есть команда проекта должна усложнить код.
Но людей, способных разрабатывать spark на подходящем уровне крайне мало, а набрать новых нереально, так как это очень дорого и долго. Что получается? Надо на проекте постоянно держать команду spark разработчиков высокого класса. А где они?
А людей, знающих SQL, и имеющих начальные знания и разработке много.
Вот и хочется быть уверенным, что можно осилить проект где обрабатывается не пять источников, как предполагалось сначала, а пятьсот. А это можно сделать, если код проекта остается простым, при этом обеспечивая и увеличение объема проекта, и возможность отладки.
И в результате резко возрастают требования к команде.
Но в этом нет необходимости.
По сути рост сложности спарк проекта, это всего лишь добавление новых датасетов.
Да и что тут покрывать тестами? Есть такой датасет или нет?
Поэтому если идти указанным в самом начале путем, тем, про который вы говорите, это усложнение, которого можно избежать.