Не прятать, а выносить из кода во внешний файл, чтобы код не усложнялся с усложнением проекта. Это всего лишь развитие идеи параметризации проекта. Во внешний файл выносим не список источников, а чуть больше.
2. Можно ведь сделать отдельные spark-приложения и тем же oozie настроить их последовательный запуск.
Oozie запускает Spark Action в отдельных сессиях. Тогда промежуточные данные придется сохранять на диск. Во-первых, это место. Во-вторых, тогда весь смысл spark оптимизации теряется.
3. Опять же oozie поддерживает запуск Hive скриптов, где чистый SQL без всякой обвязки.
Hive пока работает на map-reduce и на схожих задачах на порядке медленней spark.
Справедливый вопрос. Может показаться, что мы, не зная ничего о разработке, выдумали свое решение и радуемся. Это не совсем так. Дело в том, что spark-ETL проекты делаются немного не так, как обычные приложения. В обычном случае вы пишете код, при появлении сложностей или повторяющихся кусков применяете паттерны, покрываете это все тестами. Проект усложняется, но его ведет либо одна команда, либо новые люди набираются подходящего уровня и обучаются в проекте.
А разработка на ETL процессов на spark выглядит несколько иначе. Сначала заказчики хотят витрину. По ходу добавляются еще пожелания, витрин становится больше. И вот тут важный момент — резко растет объем проекта. Что делается в этом случае? Обычно, применяются подходы, усложняющие код, как при разработке обычных приложений.
То есть команда проекта должна усложнить код.
Но людей, способных разрабатывать spark на подходящем уровне крайне мало, а набрать новых нереально, так как это очень дорого и долго. Что получается? Надо на проекте постоянно держать команду spark разработчиков высокого класса. А где они?
А людей, знающих SQL, и имеющих начальные знания и разработке много.
Вот и хочется быть уверенным, что можно осилить проект где обрабатывается не пять источников, как предполагалось сначала, а пятьсот. А это можно сделать, если код проекта остается простым, при этом обеспечивая и увеличение объема проекта, и возможность отладки.
Все правильно. Об этом и сказано в самом начале. Только разбиение проекта на части, и покрытие их тестами означает превращение в полноценный проект. Именно это и превратит простой проект в сложный.
И в результате резко возрастают требования к команде.
Но в этом нет необходимости.
По сути рост сложности спарк проекта, это всего лишь добавление новых датасетов.
Да и что тут покрывать тестами? Есть такой датасет или нет?
Поэтому если идти указанным в самом начале путем, тем, про который вы говорите, это усложнение, которого можно избежать.
Это именно спарк. Он добавляет в папку флаг успешности завершения и метаданные. Если дописывать партицию отдельно, то в ней появятся эти файлы, и прочитать всю папку будет нельзя. И отключается это именно в настройках спарка.
Вопросы деперсонализации данных и организации контролируемого хранилища или хранилища по типу неконтролируемой помойки лежат за рамками темы статьи. Почему вы решили, что данные там открыты и что хранилище неуправляемое? В статье рассматривается всего лишь небольшой вопрос о создании витрины из слабо структурированных данных. Есть там персональная информация или нет, правильно сделано хранилище или нет, это не влияет на необходимость парсить данные и предоставлять их в виде доступном для аналитиков. О подводных камнях этой маленькой задачи и написана статья.
Не прятать, а выносить из кода во внешний файл, чтобы код не усложнялся с усложнением проекта. Это всего лишь развитие идеи параметризации проекта. Во внешний файл выносим не список источников, а чуть больше.
Oozie запускает Spark Action в отдельных сессиях. Тогда промежуточные данные придется сохранять на диск. Во-первых, это место. Во-вторых, тогда весь смысл spark оптимизации теряется.
Hive пока работает на map-reduce и на схожих задачах на порядке медленней spark.
А разработка на ETL процессов на spark выглядит несколько иначе. Сначала заказчики хотят витрину. По ходу добавляются еще пожелания, витрин становится больше. И вот тут важный момент — резко растет объем проекта. Что делается в этом случае? Обычно, применяются подходы, усложняющие код, как при разработке обычных приложений.
То есть команда проекта должна усложнить код.
Но людей, способных разрабатывать spark на подходящем уровне крайне мало, а набрать новых нереально, так как это очень дорого и долго. Что получается? Надо на проекте постоянно держать команду spark разработчиков высокого класса. А где они?
А людей, знающих SQL, и имеющих начальные знания и разработке много.
Вот и хочется быть уверенным, что можно осилить проект где обрабатывается не пять источников, как предполагалось сначала, а пятьсот. А это можно сделать, если код проекта остается простым, при этом обеспечивая и увеличение объема проекта, и возможность отладки.
И в результате резко возрастают требования к команде.
Но в этом нет необходимости.
По сути рост сложности спарк проекта, это всего лишь добавление новых датасетов.
Да и что тут покрывать тестами? Есть такой датасет или нет?
Поэтому если идти указанным в самом начале путем, тем, про который вы говорите, это усложнение, которого можно избежать.