Наверное имеет смысл рекомендовать клиентам собирать статистику для оценки доли соблюдения констрейнтов, тогда можно будет принимать решение о применимости описанного правила оптимизации.
Интересная инженерная задача, но я скорее соглашусь с сообществом: невозможно гарантировать выполнение констрейнтов в Data Lake.
Вы фактически сделали Vendor Lock-in на Data Lake для тех, кто будет внедрять ваше решение. Использование других инструментов может легко нарушать констрейнты. У меня, например, trino используется для перекачки данных в Apache Superset, очистка данных выполняется на Apache Spark.
Думаю, что более логичным шагом было бы внести предложения по констрейнтам в Delta Lake или Apache Iceberg или даже может в Hive Metastore, тогда можно было ожидать соблюдение гарантий констрейнта независимо от того, какой инструмент работает с данными в Data Lake
Хотя может я неправильно понял, может констрейнты влияют только на выбор плана исполнения, а фактические результат не будет отличаться независимо от того есть констрейнты или нет? В этом случае ваше решение действительно впечатляет как в инженерном плане, так и в уровне экспертизы.
Отличная статья, Роза, настройка пайплайнов для MLOps - достаточно творческая задача, полезно почерпнуть интересные подходы из твоего решения, которые, что очень ценно, были опробованы на практике.
Критерий разделения графа на части (какие ребра перекусывать) самому надо задавать, или для этого есть какие-то встроенные алгоритмы кластеризации?
Если граф не scale-free, а полносвязный или близкий к этому, как его разбивать на части?
Как было отмечено в статье, разбивать граф можно двумя способами: по вершинами и по ребрам, причём разбиение по вершинам более предпочтительно, т.к позволяет избежать проблем с перекосом (skew) данных. Разбиение по вершинам выполняется достаточно тривиально: просто делим таблицу с ребрами на части, хотя локальность данных будет не очень хорошая. Задача разбиения графа является NP-полной, но существуют несколько алгоритмов, которые позволяют найти приемлимое разбиение.
Я попробую осветить этот вопрос в одной из последующих статей, но, чтобы не ждать, предлагаю поискать в интернете информацию по слову "ParMeTiS" или найти статью "A Coarse-Grain Parallel Formulation of Multilevel k-way Graph Partitioning Algorithm" на Google Scholar.
Что, если данные, привязанные к графу, меняются по ходу обработки?
Итеративная природа алгоритмов на графах для Pregel не препятствует изменению графа в процессе, т.к программы обычно являются Stateless. Так, новые данные будут доступны на следующей итерации. GraphLab и PowerGraph используют разделяемую память и могут кэшировать какую-то информацию, поэтому отслеживание изменений в графе ложится на плечи разработчика алгоритма.
Я правильно понимаю, что Ваше решение делит все задачи на "правильные" и "неправильные"?
Монада IO используется для работы с внешним миром, а парсеры работают с чистыми функциями, на вход которых подаётся обычная строка. Помимо IO монадами так же являются список, Maybe, Either, функции и многие другие объекты, с ними тоже можно работать через do-нотацию.
Я не вижу смысла продолжать дискуссию в комментариях и предлагаю Вам реализовать свою библиотеку парсеров на базе Ваших идей, тогда можно будет оценить разницу в походах. Как говорил Линукс Торвальдс: "Talk is cheap, show me code".
А что если Вам нужно получить не весь номер целиком, а цифры в номере третью, седьмую и десятую? Предлагаемое Вами решение вынудит программиста каким-то образом индексировать элементы в подстроках. В моем решении можно просто игнорировать ненужные элементы (не создавать под них переменные).
Моё решение, кстати, можно использовать для эмуляции Вашего решения (нужен парсер комбинатор count), а значит является более гибким, т.к. подойти решению задачи можно любым способом: только программист знает, какой формат данных ему нужен.
Я занимаюсь парсерами уже долгое время, поэтому опыта у меня в этой области достаточно. Кстати, не подскажете почему Parsec, Megaparsec и другие библиотеки парсер комбинаторов в Haskell применяют именно описанный мной проход, а не тот, что Вы предлагаете? Свёртку функций авторы этих библиотек использовали бы при первом удобном случае.
даже скобочный синтаксис Lisp-а будет смотреться намного лучше...
не могу согласиться, потому что у каждого может быть свое мнение того, что "смотрится лучше". Инженерный подход к критике обычно содержит какие-то численные показатели, которые можно объективно сравнивать.
Мне нравится Ваша идея со сверткой функций, но как я сказал: этот подход упускает из виду основную цель - достать из текста нужную информацию.
Я не думаю что создание кучи переменных является хорошей идеей. Результатом разбора должна быть какая то коллекция...
почему коллекция? Потом как-то по индексам из коллекции нужно извлекать разобранные значения, а такое решение будет очень сложно поддерживать. Тут, очевидно, абстракция протекает в пользовательский код. Если получить "кучу переменных", то из них, например, можно создать датакласс, т.е. программист сам решает какие структуры данных наиболее удобны для его проекта.
Кажется по типам не совпадает: reduce берет первый элемент из последовательности в качестве инициализатора, и передает его а так же следущий элемент из последовательности на вход функции редюсеру, т.е and_then будет принимать две функции, а должен принять значение, разобранное предыдущим парсером и функцию (следущий парсер)
При использовании моих and_then или yield я могу обратиться к любому из ранее разнообразных значений (они находятся в переменных) и таким образом строить более сложные объекты, в предложенном вами варианте эта возможность отсутствует
В классической книге с драконом про разработку компиляторов есть глава (3.3.3 во втором издании), посвящённая регулярными выражениям, которые являются реализацией конечного автомата, а также одним из подходов к выделению токенов (лексем) из входной последовательности. Так, любой лексер имеет изоморфное ему регулярное выражение. Тот факт, что Вы видите регулярное выражение в примерах, лишь подчеркивает глубокую связь парсер генераторов с теорией разработки компиляторов.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Наверное имеет смысл рекомендовать клиентам собирать статистику для оценки доли соблюдения констрейнтов, тогда можно будет принимать решение о применимости описанного правила оптимизации.
Интересная инженерная задача, но я скорее соглашусь с сообществом: невозможно гарантировать выполнение констрейнтов в Data Lake.
Вы фактически сделали Vendor Lock-in на Data Lake для тех, кто будет внедрять ваше решение. Использование других инструментов может легко нарушать констрейнты. У меня, например, trino используется для перекачки данных в Apache Superset, очистка данных выполняется на Apache Spark.
Думаю, что более логичным шагом было бы внести предложения по констрейнтам в Delta Lake или Apache Iceberg или даже может в Hive Metastore, тогда можно было ожидать соблюдение гарантий констрейнта независимо от того, какой инструмент работает с данными в Data Lake
Хотя может я неправильно понял, может констрейнты влияют только на выбор плана исполнения, а фактические результат не будет отличаться независимо от того есть констрейнты или нет? В этом случае ваше решение действительно впечатляет как в инженерном плане, так и в уровне экспертизы.
Отличная статья, Роза, настройка пайплайнов для MLOps - достаточно творческая задача, полезно почерпнуть интересные подходы из твоего решения, которые, что очень ценно, были опробованы на практике.
Спасибо за замечание, ребра 5 -> 3 быть не должно, т.к. его нет в таблице ниже
Спасибо за интерес к моей статье.
Как было отмечено в статье, разбивать граф можно двумя способами: по вершинами и по ребрам, причём разбиение по вершинам более предпочтительно, т.к позволяет избежать проблем с перекосом (skew) данных. Разбиение по вершинам выполняется достаточно тривиально: просто делим таблицу с ребрами на части, хотя локальность данных будет не очень хорошая. Задача разбиения графа является NP-полной, но существуют несколько алгоритмов, которые позволяют найти приемлимое разбиение.
Я попробую осветить этот вопрос в одной из последующих статей, но, чтобы не ждать, предлагаю поискать в интернете информацию по слову "ParMeTiS" или найти статью "A Coarse-Grain Parallel Formulation of Multilevel k-way Graph Partitioning Algorithm" на Google Scholar.
Итеративная природа алгоритмов на графах для Pregel не препятствует изменению графа в процессе, т.к программы обычно являются Stateless. Так, новые данные будут доступны на следующей итерации. GraphLab и PowerGraph используют разделяемую память и могут кэшировать какую-то информацию, поэтому отслеживание изменений в графе ложится на плечи разработчика алгоритма.
Я правильно понимаю, что Ваше решение делит все задачи на "правильные" и "неправильные"?
Монада IO используется для работы с внешним миром, а парсеры работают с чистыми функциями, на вход которых подаётся обычная строка. Помимо IO монадами так же являются список, Maybe, Either, функции и многие другие объекты, с ними тоже можно работать через do-нотацию.
Я не вижу смысла продолжать дискуссию в комментариях и предлагаю Вам реализовать свою библиотеку парсеров на базе Ваших идей, тогда можно будет оценить разницу в походах. Как говорил Линукс Торвальдс: "Talk is cheap, show me code".
А что если Вам нужно получить не весь номер целиком, а цифры в номере третью, седьмую и десятую? Предлагаемое Вами решение вынудит программиста каким-то образом индексировать элементы в подстроках. В моем решении можно просто игнорировать ненужные элементы (не создавать под них переменные).
Моё решение, кстати, можно использовать для эмуляции Вашего решения (нужен парсер комбинатор
count), а значит является более гибким, т.к. подойти решению задачи можно любым способом: только программист знает, какой формат данных ему нужен.Я занимаюсь парсерами уже долгое время, поэтому опыта у меня в этой области достаточно. Кстати, не подскажете почему Parsec, Megaparsec и другие библиотеки парсер комбинаторов в Haskell применяют именно описанный мной проход, а не тот, что Вы предлагаете? Свёртку функций авторы этих библиотек использовали бы при первом удобном случае.
не могу согласиться, потому что у каждого может быть свое мнение того, что "смотрится лучше". Инженерный подход к критике обычно содержит какие-то численные показатели, которые можно объективно сравнивать.
Мне нравится Ваша идея со сверткой функций, но как я сказал: этот подход упускает из виду основную цель - достать из текста нужную информацию.
почему коллекция? Потом как-то по индексам из коллекции нужно извлекать разобранные значения, а такое решение будет очень сложно поддерживать. Тут, очевидно, абстракция протекает в пользовательский код. Если получить "кучу переменных", то из них, например, можно создать датакласс, т.е. программист сам решает какие структуры данных наиболее удобны для его проекта.
Кажется по типам не совпадает: reduce берет первый элемент из последовательности в качестве инициализатора, и передает его а так же следущий элемент из последовательности на вход функции редюсеру, т.е
and_thenбудет принимать две функции, а должен принять значение, разобранное предыдущим парсером и функцию (следущий парсер)При использовании моих
and_thenилиyieldя могу обратиться к любому из ранее разнообразных значений (они находятся в переменных) и таким образом строить более сложные объекты, в предложенном вами варианте эта возможность отсутствуетВ классической книге с драконом про разработку компиляторов есть глава (3.3.3 во втором издании), посвящённая регулярными выражениям, которые являются реализацией конечного автомата, а также одним из подходов к выделению токенов (лексем) из входной последовательности. Так, любой лексер имеет изоморфное ему регулярное выражение. Тот факт, что Вы видите регулярное выражение в примерах, лишь подчеркивает глубокую связь парсер генераторов с теорией разработки компиляторов.