Спаибо, вот только до стадии получения данных еще нужно продраться через авгиевы конюшни бюрократии яндекса. Например, надо зачем-то создать приложение, чтобы получить токен (зачем, Карл?!), но и этого мало! Надо еще подать заявление, чтобы разрешили использовать сервисы директа этим приложением, при этом объяснить, с какой целью и в каком объеме! Еще немного - и потребуют прописку и справку из дурдома.
Эта функция появилась не просто так. Математики хотели максимально подробно изучить класс всех частично-рекурсивных функций, т.е. вычислимых. Оказалось, что аккермановская функция не является ПРФ, но остается ЧРФ, мало того, она еще и тотальна (всюду определена). Но и теории алгоритмов, и в основаниях математики нас больше интересует доказуемость тотальности, т.е. доказательство того, что алгоритм сходится на любом входе. И вот тут начинаются проблемы.
Про ПРФ и Аккермана мы можем не более чем двумя вложенными индукциями доказать их тотальность. Но если мы теперь в схеме построения рекурсий в качестве базовой функции вместо S(x)=x+1 возьмем аккермана и точно так же выстроим последовательность быстрорастущих функций, то для доказательства их тотальности потребуется еще больше вложенных индукций. И так далее.
Сложность этих функций и соответствующих им формальных арифметических теорий, способных доказывать их тотальность, измеряется ординалами. Так, аксиоматика EA позволяет строить рекурсии только до ординала \omega^\omega, а арифметика Пеано первого порядка (PA) — до ординала \epsilon_0.
Оказывается, что класс доказуемо тотальных функций арифметики PA хоть и большой (он включает ПРФ и аккермана), но не покрывает все вычислимые функции.
Если мы в описанной иерархии дойдем до функции с номером epsilon_0, то она уже не будет лежать в данном классе.
Тем самым мы умеем сравнивать силу формальных систем с помощью ординалов. Этими вопросами занимается ординальная теория доказательств. На основе этой шкалы мы также можем судить, каким формализмом (читай — языком программирования) лучше пользоваться, если мы хотим гарантировать сходимость алгоритмов.
PS. Функция Гудстейна, например, имеет такую скорость роста, что ее тотальность недоказуема в арифметике первого порядка. Поэтму и сама теорема Гудстейна являет нам пример недоказуемого и неопровержимого утверждения для арифметики Пеано.
первые два я бы тоже отнес (по крайней мере, с точки зрения общей теории) к связанным товарам (даже если эти товары — нетовары, например, мы так использовали каталог компьютерных интерфейсов)
а вот артикулы — это по сути ключи, по которым производится стыковка с внешними данными, т.е. это часть операторв импорта/экспорта, хотя, конечно, можно ряд атрибутов назвать ключевыми, и их использовать в том числе и таким образом.
мы у себя такие поля как партномер, артикул, прайсовое название, EAN-коды и т.п. не рассматриваем как часть информационной модели, а как атрибуты сущностей в смысле теории баз данных, т.е. это более низкий уровень информациио о товаре. В частности, есть альтернативные значения данных полей для более успешной работы системы матчинга по ключевым полям (правила матчинга используют сравнение ключевых полей с помощью нескольких видов сравнений).
Да, если вспомнить типизацию из языков, то можно далеко зайти) Я бы все-таки даты и логические относил к числовым, т.к. на них есть очевидная арифметика и линейное упорядочение (по сути это Z и Z/2Z). А все остальные шкалы пойдут уже в категориальные.
Комбинированные ни разу не приходилось использовать, хотя вполне можно себе представить их. Но я бы их все равно расплиил на более простые внутри рабочей системы, а на стороне проекта уже бы склеивал в нужные комбинации экспортными шаблонами.
Ну да, согласен, тут еще все зависит и от целей, и от возможностей, и того, как мы хотим действовать)
Когда я тестил функции, встроенные в BQ, у меня была несколько иная задача — там требовалось почистить отчет, выгружаемый из 1С, а точнее, восстановить некоторые поля (хз почему, но там не всегда, когда надо, стояли даты оплаты, хотя сумма полной оплаты была прописана. Кроме того, по некоторым специальным контрагентам требовалась еще кое-какая доработка. И, наконец, был такой замечательный кейс с перекодированием клиентов для того, чтобы присвоить им уникальные id и скрыть их персональные данные, и, кроме того, разбить их на специальные классы на основе анализа их названий. В общем, на питоне мне это было сделать проще и быстрее, но за 6 минут такая функция не справлялась.
Ну а дальше просто уже тему развивал достраиванием предобработки.
Кстати, по поводу монстров. В результате своего собственного развития я тоже потом удивлялся, как можно было изначально написать такой тупой код предобработки. Думаю, что еще через какое-то время я снова так подумаю)) Так что… tempora mutantis et nos mutamus in illis
А кроме того, надо не забывать, что в разных компаниях очень разная организация разделения труда. Если, например, программисты 1С или разработчики сайтов не в твоем отделе и перегружены более другими задачами, то приходится изловчиться, чтобы все сделать ювелирно и быстро, не ломая никакие параллельные процессы. Это также накладывает ограничения на выбор методов.
Ага, ну то есть либо какие-то вещи делаешь еще «дома», и потом уносишь в BQ финальный вариант, либо дома ничего не делаешь (например, если права ограничены для аналитика), но тогда все танцы на стороне BQ или по дороге к нему.
Кстати, Datastudio очень тормозит на больших данных, так что под нее в любом случае лучше готовить где-то агрегацию под нужные листы отчета. Я это делаю шедулером BQ или в процессе прокачки средствами пандас на питоне.
А у меня основная таблица (с большими данными) обновляется реже, чем через 90 минут, несколько часов проходит.
А вот та таблица, которая 2 раза в час обновляется (она нужна для рассылки алертов при анализе потока заказов и для отображения графиков текущего состояния потока), эта таблица небольшая (там срез данных только за 28 последних дней, причем далеко не все поля), она не партицирована, и каждый раз я ее полностью перетираю (write_truncate).
Иначе говоря, под более скорострельные задачи создаются более другие таблицы, и с ними нет проблем запаздываний.
Надеюсь, ответил…
Я может невнятно написал, но как раз append мне не подходит, т.к. уже в ранее загруженных строках происходят со временем изменения. Например, сначала заказ создан, потом он оплачен, потом доставлен. В исходной БД это все отражается параметрами в одной и той же строке. Поэтому приходится мержить, а не аппендить.
Дальше, а чем кидать файл CSV в GCS? Все равно на серваке скрипт вешать, так не лучше ли сразу в BQ кидать? Вместо файла CSV появляется таблица temporary.
Про функции тоже написал, те, которые в BQ — там времени мало дается на исполнение (часто мне гугл писал, что время на исполнение вышло). Я сначала именно этими функциями и пользовался. Только язык выбрал не JS, а Python, т.к. на нем проще работать. Не впечатлило, в общем.
И, кстати, аналогичными функциями на том же самом серваке я теперь еще обращаюсь к апи стороннего сервиса, забираю данные, собираю из них общую таблицу и кладу в BQ точно так же. Этот скрипт уже работает порядка 3х часов. Сомневаюсь, что функциями, встроенными в BQ, это можно сделать. И, кстати, если пользуешься кодом, лежащим на Гугле, токены доступа к сервисам компании тоже гуглу доверяешь? Я бы так не рисковал.
Спаибо, вот только до стадии получения данных еще нужно продраться через авгиевы конюшни бюрократии яндекса. Например, надо зачем-то создать приложение, чтобы получить токен (зачем, Карл?!), но и этого мало! Надо еще подать заявление, чтобы разрешили использовать сервисы директа этим приложением, при этом объяснить, с какой целью и в каком объеме! Еще немного - и потребуют прописку и справку из дурдома.
Про ПРФ и Аккермана мы можем не более чем двумя вложенными индукциями доказать их тотальность. Но если мы теперь в схеме построения рекурсий в качестве базовой функции вместо S(x)=x+1 возьмем аккермана и точно так же выстроим последовательность быстрорастущих функций, то для доказательства их тотальности потребуется еще больше вложенных индукций. И так далее.
Сложность этих функций и соответствующих им формальных арифметических теорий, способных доказывать их тотальность, измеряется ординалами. Так, аксиоматика EA позволяет строить рекурсии только до ординала \omega^\omega, а арифметика Пеано первого порядка (PA) — до ординала \epsilon_0.
Оказывается, что класс доказуемо тотальных функций арифметики PA хоть и большой (он включает ПРФ и аккермана), но не покрывает все вычислимые функции.
Если мы в описанной иерархии дойдем до функции с номером epsilon_0, то она уже не будет лежать в данном классе.
Тем самым мы умеем сравнивать силу формальных систем с помощью ординалов. Этими вопросами занимается ординальная теория доказательств. На основе этой шкалы мы также можем судить, каким формализмом (читай — языком программирования) лучше пользоваться, если мы хотим гарантировать сходимость алгоритмов.
PS. Функция Гудстейна, например, имеет такую скорость роста, что ее тотальность недоказуема в арифметике первого порядка. Поэтму и сама теорема Гудстейна являет нам пример недоказуемого и неопровержимого утверждения для арифметики Пеано.
а вот артикулы — это по сути ключи, по которым производится стыковка с внешними данными, т.е. это часть операторв импорта/экспорта, хотя, конечно, можно ряд атрибутов назвать ключевыми, и их использовать в том числе и таким образом.
мы у себя такие поля как партномер, артикул, прайсовое название, EAN-коды и т.п. не рассматриваем как часть информационной модели, а как атрибуты сущностей в смысле теории баз данных, т.е. это более низкий уровень информациио о товаре. В частности, есть альтернативные значения данных полей для более успешной работы системы матчинга по ключевым полям (правила матчинга используют сравнение ключевых полей с помощью нескольких видов сравнений).
Комбинированные ни разу не приходилось использовать, хотя вполне можно себе представить их. Но я бы их все равно расплиил на более простые внутри рабочей системы, а на стороне проекта уже бы склеивал в нужные комбинации экспортными шаблонами.
Когда я тестил функции, встроенные в BQ, у меня была несколько иная задача — там требовалось почистить отчет, выгружаемый из 1С, а точнее, восстановить некоторые поля (хз почему, но там не всегда, когда надо, стояли даты оплаты, хотя сумма полной оплаты была прописана. Кроме того, по некоторым специальным контрагентам требовалась еще кое-какая доработка. И, наконец, был такой замечательный кейс с перекодированием клиентов для того, чтобы присвоить им уникальные id и скрыть их персональные данные, и, кроме того, разбить их на специальные классы на основе анализа их названий. В общем, на питоне мне это было сделать проще и быстрее, но за 6 минут такая функция не справлялась.
Ну а дальше просто уже тему развивал достраиванием предобработки.
Кстати, по поводу монстров. В результате своего собственного развития я тоже потом удивлялся, как можно было изначально написать такой тупой код предобработки. Думаю, что еще через какое-то время я снова так подумаю)) Так что… tempora mutantis et nos mutamus in illis
А кроме того, надо не забывать, что в разных компаниях очень разная организация разделения труда. Если, например, программисты 1С или разработчики сайтов не в твоем отделе и перегружены более другими задачами, то приходится изловчиться, чтобы все сделать ювелирно и быстро, не ломая никакие параллельные процессы. Это также накладывает ограничения на выбор методов.
Кстати, Datastudio очень тормозит на больших данных, так что под нее в любом случае лучше готовить где-то агрегацию под нужные листы отчета. Я это делаю шедулером BQ или в процессе прокачки средствами пандас на питоне.
А вот та таблица, которая 2 раза в час обновляется (она нужна для рассылки алертов при анализе потока заказов и для отображения графиков текущего состояния потока), эта таблица небольшая (там срез данных только за 28 последних дней, причем далеко не все поля), она не партицирована, и каждый раз я ее полностью перетираю (write_truncate).
Иначе говоря, под более скорострельные задачи создаются более другие таблицы, и с ними нет проблем запаздываний.
Надеюсь, ответил…
Дальше, а чем кидать файл CSV в GCS? Все равно на серваке скрипт вешать, так не лучше ли сразу в BQ кидать? Вместо файла CSV появляется таблица temporary.
Про функции тоже написал, те, которые в BQ — там времени мало дается на исполнение (часто мне гугл писал, что время на исполнение вышло). Я сначала именно этими функциями и пользовался. Только язык выбрал не JS, а Python, т.к. на нем проще работать. Не впечатлило, в общем.
И, кстати, аналогичными функциями на том же самом серваке я теперь еще обращаюсь к апи стороннего сервиса, забираю данные, собираю из них общую таблицу и кладу в BQ точно так же. Этот скрипт уже работает порядка 3х часов. Сомневаюсь, что функциями, встроенными в BQ, это можно сделать. И, кстати, если пользуешься кодом, лежащим на Гугле, токены доступа к сервисам компании тоже гуглу доверяешь? Я бы так не рисковал.