Идеологически более верно дать людям "удочку" и научить их самим парсить эти базы, вместо того, что зависеть еще от одной третьей стороны, которая перегоняет новые базы в старый формат, тем более, что ваша статья вышла уже через месяц после такого перехода.
Да, мы сначала рассматривали вариант, чтобы дать конвертер для самостоятельного парсинга. Конвертер писался на скорую руку, и в данный момент использует часть уже имеющейся у нас инфраструктуры, которую мы не можем выложить в открытый доступ. А для того чтобы подготовить, выложить все опенсорс и описать, нужно потратить определенное время и ресурсы команды. И ресурсов на это уйдет больше, чем выкладывать справочник.
Поэтому решение о временном выпуске справочника «ФИАС» из конвертера удобно для пользователей и для поддержки.
В конечном итоге, все должны прийти к тому, чтобы использовать ГАР, который предоставляет ФНС, а не жить постоянно с конвертером из ГАР в «ФИАС».
Привет! Меня зовут Таня, я развиваю продукт «Единый адрес» в HFLabs. Статья очень ценная, информации про ГАР не так много, спасибо что поделилась своими наработками.
Но, судя по тексту, чем занимается HFLabs, похоже, не совсем понятно :(
Есть компании, перепродающие ФИАС, иногда с дополнениями (DaData) или собирающие ваши данные (HFLabs). Несомненно, работа по очистке, поддержка, сбор координат из росреестра или другого источника, чего-то стоят, и кто-то не готов ее сам чистить и поддерживать, но готов заплатить, в том числе своими данными, и это нормально. Как относиться к тому, что в таком случае они не указывают первоисточник данных, где можно тупо скачать базу без вопросов, решайте сами.
HFLabs работает с крупными заказчиками, софт и БД разворачивается у заказчика в контуре, есть NDA и законодательство, все данные живут у заказчика. Сервис DaData сделан нашей командой для тех, кому энтерпрайз-решение не нужно. Формат ФИАС (а скоро перейдем на ГАР), используем в наших сервисах и не скрываем этого.
1 сентября 2021 года ФНС перестала выпускать справочник в формате ФИАС с dbf, а оставила только ГАР в xml. Мы сделали конвертер из ГАР в ФИАС и стали раздавать всем желающим справочник в формате «ФИАС», т.к. не все системы успели поддержать формат ГАР в xml.
Чтобы получить справочник «ФИАС» из ГАР мы просим указать емейл, писали про это в статье «Сделали «ФИАС» на основе ГАР». Емейлы нужны, чтобы оценить потенциальную нагрузку на сервера, с которых будет скачиваться справочник и чтобы понять, а нужна ли вообще кому-то эта выгрузка. А то может желающих миллионы, и нам надо бежать, наращивать серверные мощности, чтобы держать регулярную нагрузку. Или, наоборот, никому справочник не нужен, так зачем его вообще поддерживать? :-)
Мы не перепродаем ФИАС. Наоборот, раздаем сделанный на основе ГАР справочник в формате ФИАС бесплатно и делимся знаниями про ГАР в телеграм и на ютьюб-канале.
Конечно можно использовать специальные средства профилирования, если они у вас есть и вы умеете ими пользоваться.
Мой посыл скорее в том, как дешево и сердито (табличными редакторами и sql) сделать аналитику и не страдать, что нет подручных программ.
Спасибо за отличные вопросы! По пунктам:
1. Что считать «типичной миграцией»? В каждом проекте исторические миграции данных занимают разное время. Почему? Основные факторы, от которых зависит длительность миграции:
— характеристики железа
— сложность ETL-трансформаций и особенности БД системы-источника
— объем загружаемых данных
— полнота загружаемых данных
На одном из проектов оба этапа миграции (ETL + обработка в нашем продукте) для 100 млн клиентов, но более полмиллиарда сущностей — счета, адреса, связи, заняли 20 дней — 10 дней ETL, 10 дней нашей обработки.
Бюрократизированность сильно зависит от конкретного заказчика. Обычно все решается письмами или звонками. Иногда сталкивалась с тем, что на предоставление доступов к таблицам БД или на необходимую железку заводят заявки, срок выполнения индивидуален — от нескольких минут до нескольких дней, смотря, что попросишь. Заказчики тоже заинтересованы в результате.
2. Вы подняли животрепещущий вопрос, который мы с коллегами в чате обсуждали. Тоже все очень сильно зависит от заказчика. При старте проекта мы подписываем NDA и другие соглашения. Данные смотрим на серверах заказчиков, если обе стороны заинтересованы в том, чтобы улучшить качество данных. Про проверку каждого запроса ничего не скажу, возможно в фоновом режиме мониторинг идет. На предоставление доступа к конкретным таблицам я писала заявки с обоснованием необходимости.
Еще раз подчеркну, все очень сильно зависит от заказчика и его внутренних процессов.
Спасибо. Проверки, проверками — этим аналитики или QA займутся, а хорошие ETL-джобы должен кто-то писать. Вот и хотим себе ETL-разработчика, который параллелями в 32 потока не будет доводить DBA до седых волос)
1. Специально не стала писать про системные представления и служебные таблицы, т.к. доступ к ним на уровне системы-источника обычно не дают. Если доступ есть, то это отличная альтернатива экселю! Спасибо за комментарий!
2. ETL делают или системные интеграторы со стороны заказчика, или отдельные компании, которые приходят со своими ETL-продуктами или шиной, например, Data Stage или Tibco. Т.е. в нашей БД мы видим уже конечный результат трансформаций, который происходит «где-то».
Но мы сейчас как раз в поиске своего ETL-разработчика, чтобы сэкономить время на коммуникациях и объяснениях, как вы и написали.
С финансовыми показателями не работала, поэтому не могу ничего сказать. Если у вас есть интересные примеры, то расскажите, пожалуйста. Но мне казалось, что при миграции финансовых показателей, все со всех сторон тестами покрыто заранее, чтобы дебет с кредитом точно сошелся.
Очень интересно, спасибо! Поделитесь, как вы организовываете интеграцию из БД в QlikView? Напрямую или через файлики? Вы работаете с данными из разных баз?
Хороший вопрос, тоже о нем думаю. Особенно, когда переименования такие:
или такие
Это же как минимум все таблички надо поменять и дорожные знаки.
Да, мы сначала рассматривали вариант, чтобы дать конвертер для самостоятельного парсинга. Конвертер писался на скорую руку, и в данный момент использует часть уже имеющейся у нас инфраструктуры, которую мы не можем выложить в открытый доступ. А для того чтобы подготовить, выложить все опенсорс и описать, нужно потратить определенное время и ресурсы команды. И ресурсов на это уйдет больше, чем выкладывать справочник.
Поэтому решение о временном выпуске справочника «ФИАС» из конвертера удобно для пользователей и для поддержки.
В конечном итоге, все должны прийти к тому, чтобы использовать ГАР, который предоставляет ФНС, а не жить постоянно с конвертером из ГАР в «ФИАС».
Привет! Меня зовут Таня, я развиваю продукт «Единый адрес» в HFLabs. Статья очень ценная, информации про ГАР не так много, спасибо что поделилась своими наработками.
Но, судя по тексту, чем занимается HFLabs, похоже, не совсем понятно :(
HFLabs работает с крупными заказчиками, софт и БД разворачивается у заказчика в контуре, есть NDA и законодательство, все данные живут у заказчика. Сервис DaData сделан нашей командой для тех, кому энтерпрайз-решение не нужно. Формат ФИАС (а скоро перейдем на ГАР), используем в наших сервисах и не скрываем этого.
1 сентября 2021 года ФНС перестала выпускать справочник в формате ФИАС с dbf, а оставила только ГАР в xml. Мы сделали конвертер из ГАР в ФИАС и стали раздавать всем желающим справочник в формате «ФИАС», т.к. не все системы успели поддержать формат ГАР в xml.
Чтобы получить справочник «ФИАС» из ГАР мы просим указать емейл, писали про это в статье «Сделали «ФИАС» на основе ГАР». Емейлы нужны, чтобы оценить потенциальную нагрузку на сервера, с которых будет скачиваться справочник и чтобы понять, а нужна ли вообще кому-то эта выгрузка. А то может желающих миллионы, и нам надо бежать, наращивать серверные мощности, чтобы держать регулярную нагрузку. Или, наоборот, никому справочник не нужен, так зачем его вообще поддерживать? :-)
Мы не перепродаем ФИАС. Наоборот, раздаем сделанный на основе ГАР справочник в формате ФИАС бесплатно и делимся знаниями про ГАР в телеграм и на ютьюб-канале.
Мой посыл скорее в том, как дешево и сердито (табличными редакторами и sql) сделать аналитику и не страдать, что нет подручных программ.
1. Что считать «типичной миграцией»? В каждом проекте исторические миграции данных занимают разное время. Почему? Основные факторы, от которых зависит длительность миграции:
— характеристики железа
— сложность ETL-трансформаций и особенности БД системы-источника
— объем загружаемых данных
— полнота загружаемых данных
На одном из проектов оба этапа миграции (ETL + обработка в нашем продукте) для 100 млн клиентов, но более полмиллиарда сущностей — счета, адреса, связи, заняли 20 дней — 10 дней ETL, 10 дней нашей обработки.
Бюрократизированность сильно зависит от конкретного заказчика. Обычно все решается письмами или звонками. Иногда сталкивалась с тем, что на предоставление доступов к таблицам БД или на необходимую железку заводят заявки, срок выполнения индивидуален — от нескольких минут до нескольких дней, смотря, что попросишь. Заказчики тоже заинтересованы в результате.
2. Вы подняли животрепещущий вопрос, который мы с коллегами в чате обсуждали. Тоже все очень сильно зависит от заказчика. При старте проекта мы подписываем NDA и другие соглашения. Данные смотрим на серверах заказчиков, если обе стороны заинтересованы в том, чтобы улучшить качество данных. Про проверку каждого запроса ничего не скажу, возможно в фоновом режиме мониторинг идет. На предоставление доступа к конкретным таблицам я писала заявки с обоснованием необходимости.
Еще раз подчеркну, все очень сильно зависит от заказчика и его внутренних процессов.
2. ETL делают или системные интеграторы со стороны заказчика, или отдельные компании, которые приходят со своими ETL-продуктами или шиной, например, Data Stage или Tibco. Т.е. в нашей БД мы видим уже конечный результат трансформаций, который происходит «где-то».
Но мы сейчас как раз в поиске своего ETL-разработчика, чтобы сэкономить время на коммуникациях и объяснениях, как вы и написали.