Полезное чтение про данные и не только:
- WSJ пишет что метеорологическая служба США начала закупать данные у двух частных компаний чтобы заполнить пробелы в покрытии их спутников [1]. Статья о том что государство действует очень медленно в таких случаях, закупать данные у частного сектора госорганам непросто.
- научная статья о том как регулируется (ограничивается) ИИ в разных странах [2] статья под пэйволом, но весьма полезна и по сути построена на сравнении предпочтении граждан.
- критическая статья в Politico о том что предполагалось что ИИ изменит систему здравоохранения и о том почему этого не происходит [3]. Если коротко то - завышенные обещания, несовместимые системы и тд. Самое плотное применение ИИ в США сейчас в радиологии.

Ссылки:
[1] https://www.wsj.com/articles/u-s-government-effort-to-tap-private-weather-data-moves-along-slowly-11661335203
[2] https://www.tandfonline.com/doi/full/10.1080/13501763.2022.2094988?src=
[3] https://www.politico.com/news/2022/08/15/artificial-intelligence-health-care-00051828

#data #readings

Счетная палата РФ выпустила бюллетень N30 посвящённый государственным информационным системам [1], о нем уже написали TAdviser, РБК и много других изданий. РБК, например, делают акцент на критике Гостеха [2] в бюллетене, другие издания другие акценты, а я могу посоветовать почитать сразу весь бюллетень.

С точки зрения системного подхода к госинформатизации, не углубляясь в политические аспекты, это, безусловно, важный доклад с грамотными выводами что считать расходы на создание ГИСов сложно, что они плохо систематизированы, что ФГИС КИ в текущем состоянии весьма запущенная система и ещё много чего. В целом камни в огород здесь в адрес Минцифры в нынешней и прошлых инкарнациях этого органа власти.

1. Число государственных информационных систем в России несопоставимо с [не]доступностью данных из этих же информационных систем. Иначе говоря огромное число информационных систем существуют в полностью закрытом режиме и, в лучшем случае, по ним доступны только сведения перечисленные в их ТЗ размещённом на сайте госзакупок.

2. Архитектура многих информационных систем - это продолжение госполитики по сверхконцентрации полномочий в Москве и подмосковье. Георезервирования данных нет не только потому что на этом экономят или не умеют, но и по причине трансформации федеративного государства в техноунитарное. А то есть там где нельзя забрать полномочия у субъектов федерации вместо этого на стыке полномочий создается федеральная информационная система от которой региональной власти оказываются в критической зависимости (не могут без неё работать). Это не только про электронные учебники, это ещё и про системы Росреестра, ГИС Торги, портал госзакупок и ещё многие другие системы.

3. Лично мне не хватило в бюллетене отражение "успехов" Гостех в правительстве Москвы и в Казахстане. Но даже упоминание критичности зависимости платформы от воли Сбербанка - это достаточно существенная критика.

4. Мировой опыт, будем честными, отражён очень слабо. В бюллетене много упоминается опыт по планам цифровизации, а тут скорее про решения общестрановые по информатизации и создании инфраструктуры. В мире ключевое для государственных информационных систем сейчас - это процедуры соответствия облаков обязательным стандартам, их сертификация, сертификация ПО в этих облаках и, самое главное, широкое повторное использование открытого кода в госуправлении.

Я могу рассказывать про это всё довольно долго, о многом пишу в телеграм канале, а почитать бюллетень СП будет полезно, несомненно.

Ссылки:
[1] https://ach.gov.ru/statements/bulletin-sp-8-2022
[2] https://www.rbc.ru/technology_and_media/30/08/2022/630cc2709a7947836b2ef7c4

#government #it #digital #opengov

Дождались! Минэк расторг контракт на портал открытых данных.

Правда возникает вопрос, почему это не было сделано еще, например, в конце 2020 года, когда подрядчик в декабре 2020 года не провел хакатон, а Минэк в августе 2021 (!) его отменил доп. соглашением.

Интересно, что одна из причин расторжения - отсутствие банковской гарантии, срок действия которой истек в январе 2022 года. Но расторгли контракт только сейчас.

Напомню, что подрядчиком была петербургская компания, у которой было 3-4 клона с одинаковыми названиями, учредителями, адресами. И одну из этих компаний Минэк внес в РНП по предыдущему госконтракту на портал ОД.

Я довольно много писал про недокументированные API госорганов [1] и упоминал похожий гражданский проект в Германии [2].

Так вот скажу что этих самых недокументированных API к государственным и окологосударственным системам, сайтам, порталам значительно больше чем может показаться со стороны.

Причём есть всего несколько причин их появления:
- наличие API как продукта редкие случаи, когда API изначально было предусмотрено, но в силу многих причин его создатель не может, не умеет или не хочет его нормально документировать.
- наличие API как следствие архитектуры приложения, как правило это следствие применение подходов вроде JAMSTACK когда вызовы к API осуществляются из Javascript на фронтэнде
- наличие API по умолчанию это когда API есть у продукта который используется для конкретной цели, но его пользователь об этом не знает

Всех этих API великое, нет огромное количество.

Какое-то время назад я размещал на сервисе Postman коллекцию с документацией таких API [3]․ Там их немного, 6 государственных систем, около пары-тройки десятков точек подключения. Все они идут по 1-й или по 2-й категории API, а есть немало API которые просто являются частью продукта и вот их примеры.

Есть такой продукт DSpace используемый ВУЗами для создания репозиториев научных результатов. Он много где установлен в мире, в основном университетами, но даже открытые библиотека НАТО и Мирового банка тоже работают на DSpace. В России он используется, например, в СПбГУ.

У DSpace по умолчанию есть интерфейс раскрытия данных по стандарту OAI-PMH, это такой стандарт архивации научных и библиотечных знаний. Поэтому, к примеру, у инсталляции DSpace есть API интерфейс для доступа [4], подробнее о нём и как работать с протоколом OAI-PMH легко гуглится. Специалисты, как правило, о таких интерфейсах знают заранее. Неспециалисты очень удивляются когда неожиданно обнаруживают.

Другой пример, у Wordpress есть API, идущее практически по умолчанию в новых инсталляциях. Оно сводится к точке подключения /wp-json/ через который можно выкачать. Это полезно, например, для цифровой архивации. Я специально для такого сделал утилиту wparc [5] позволяющую архивировать данные из инсталляций Wordpress. В России, например, Wordpress, используется на сайте Госкомиссии по Арктике и, конечно, wp-json там активирован [6].

Таких примеров много, они не описываются на порталах открытых данных и инициативах вроде bund.dev или нашей коллекции госAPI.

Ссылки:
[1] https://t.me/begtin/3550
[2] https://t.me/begtin/4194
[3] https://www.postman.com/infoculture/workspace/infoculture-public/documentation/1428203-a769e0a6-0cc9-4de4-bdcc-5f8a0fa06e36
[4] https://dspace.spbu.ru/oai/
[5] https://github.com/ruarxive/wparc
[6] https://arctic.gov.ru/wp-json/

#api #openapi #government #undocumented

Рубрика "Циничное законописательство"
После вчерашней публикации Счетной палатой отчета по ЭАМ про ГИСы и Бюллетеня на ту же тему Минцифры решило хайпануть на теме и продемонстрировать, как быстро оно умеет отрабатывать рекомендации уважаемого Высшего органа государственного аудита.
Уже сегодня на Регулейшене появился проект внесения изменений в 149-ФЗ, в котором сделана очередная обреченная на провал попытка определения термина "государственная информационная система". Ссылку на Регулейшен и цитаты из "законопроекта" я не даю, потому что этот "законопроект" написан исключительно с целью ИБД (ИБД - имитация бурной деятельности, а не что-то про информационную безопасность). Шансов на то, что этот проект попадет в Госдуму, практически ноль - скорее всего, его зарубят на этапе антикоррупционной экспертизы еще на Регулейшене (там коррупциогенность не в терминологии, а в другом пункте - про приостановку финансирования ГИС).
В Минцифры не могут понять главного - любые попытки внесения в 149-ФЗ каких-либо изменений, относящихся к крайне немногочисленным в этом законе положениям про ИС и ГИС (если не считать статьи про ЕБС, которая вообще должна была стать отдельным законом, а не уродливым "горбом" у 149-ФЗ), являются ничем иным, как разновидностью гальванизации трупа. 149-ФЗ как субъект регулирования именно госИТ давно и бесповоротно убит Роскомнадзором, превратившим его в закон о запрете информации.
Сфера госИТ нуждается в своем отдельном федеральном законе - примерно таком в концептуальном смысле, каким был светлой памяти 24-ФЗ от 1995 года. И вот уже в рамках этого, отделенного от цензуры и надзора закона, нужно давать определения ГИС, ГИР (государственных информационных ресурсов), цифровых платформ, Гостеха и т.п.
Но для написания такого закона сейчас нет экспертного ресурса - ни среди юристов по информационному праву, ни среди ИТшников, способных генерировать правильные с технической и юридической точек зрения определения. Вот только я один и остался из экспертов - как три тополя на Плющихе.
А начать следовало бы вообще с узаконивания очень простой мысли - любая информационная система, созданная, развиваемая и эксплуатируемая за счет бюджета, является государственной информационной системой, независимо от целей ее создания, сферы применения, реализуемой функциональности и т.д. Все используемые сегодня определяющие критерии для ГИС должны определять не то, ГИС перед нами или не-ГИС, а конкретную категорию ГИС - ГИС госуслуг, ГИС полномочий, ГИС инфраструктуры, ГИС взаимодействия, ГИС поддержки процессов и т.п. Но это уже будет классификация второго рода. А классификация первого рода очень простая - "чьи деньги в системе?".
Вот и всё. Будет время, распишу эти мысли подробнее. А пока вот так

Полезное чтение про данные, стартапы и технологии:
- Developer Experience Infrastructure (DXI) [1] о том как создавать продукты для разработчиков и что разработчики от них ждут. Похоже на подходы User Experience, только пользователи тут особые
- The Good Research Code Handbook [2] о том как реорганизовать код в при исследовательском проекте. Я бы сказал что это надо студентам прям преподавать, но полезно не только им
- StarTree подняли $47M инвестиций [3] и развивают свой продукт по облачной аналитике. Это та команда что создала Apache Pinot и делают теперь его корпоративный вариант.
- Data Governance Checklist [4] сильно связанный с регулированием, персональными данными и иными законами в США. Что не мешает ему быть актуальным не только в США

Ссылки:
[1] https://kenneth.io/post/developer-experience-infrastructure-dxi
[2] https://goodresearch.dev/index.html
[3] https://www.startree.ai/blog/a-new-phase-of-growth-for-startree-and-the-real-time-user-facing-analytics-movement
[4] https://medium.com/@corymaklin/data-governance-checklist-152a3a691002

#readings #data #startups

Периодическая таблица элементов открытых данных [1] от Open Data Policy Lab. В ней ничего про технологии и много про организацию процесса, ответственных, взаимодействие с пользователями, нормативное закрепление и так далее.

Сложно сказать насколько это применимо в России и сейчас, скорее не применимо, но для тех стран, регионов, городов и организаций которые в открытые данные вкладывают время и силы - это безусловно полезно, в первую очередь, для структуризации собственных мыслей.

По ссылке кроме этой таблицы подробный опросник.

Ссылки:
[1] https://periodictable.opendatapolicylab.org/

#opendata #opengov #data #datamanagement

Полезное чтение про данные, технологии и не только:

Данные
- State of gender data [1] есть такая большая тема - учет гендерных особенностей в системах регистрации статистики, учетных системах или, как упоминают авторы, "data systems". Текст о том что учет гендерных данных недостаточен.
- One Data Point Can Beat Big Data [2] о том что не всё решается большими данными и понимание данных и тщательная их фильтрация, избавление от шума, могут дать больше чем просто расширение источников и объёмов данных
- Making Government Data Publicly Available: Guidance for Agencies on Releasing Data Responsibly [3] руководство о том почему и как публиковать открытые данные от Center for Democracy and Technology. Адресовано органам власти (агентствам) в США, но актуально для всех
- Closing the Data Divide for a More Equitable U.S. Digital Economy [4] о неравенстве в доступе к данным и что с этим делать на примере экономики США. В основном рекомендации для регуляторов. Акценты на том что есть многие сообщества (в нашем понимании муниципалитеты) качество данных по которым невелико и они выпадают из многих госпрограмм поддержки. Тема важная, подход системный, но, конечно, инфраструктура и экономика США от других стран существенно отличаются.

ИИ и умные города
- Why Japan is building smart cities from scratch [5] о том почему в Японии создают умные города с нуля. На самом деле в статье именно на этот вопрос ответа нет, есть рассказ про несколько городов в Японии построенных с нуля. Это интересно, хотя я подозреваю что в Китае в в этом направлении даже больший прогресс.

Технологии и программирование
- Building modern Python API backends in 2022 [6] о структуре и архитектуре современных бэкэндов приложений на Python. Конечно, на самом деле, альтернатив куда больше, но прикладной стек расписан хорошо.
- Ruff [7] очень быстрый проверятель (linter) исходного кода для Python, написанный на Rust. Показывают производительность выше в 10-100 раз чем другие аналогичные инструменты вроде flake8, pylint и т.д.
—
P.S. Я подумываю выделить рубрику чтение (#readings) в какой-то отдельный формат, например, еженедельную рассылку, в отличие от моей личной рассылки которую я веду не регулярно или же скорректировать личную рассылку (begtin.substack.com) и добавить туда еженедельной регулярности.

Ссылки:
[1] https://data2x.org/state-of-gender-data/
[2] https://behavioralscientist.org/gigerenzer-one-data-point-can-beat-big-data/
[3] https://cdt.org/insights/making-government-data-publicly-available-guidance-for-agencies-on-releasing-data-responsibly/
[4] https://datainnovation.org/2022/08/closing-the-data-divide-for-a-more-equitable-u-s-digital-economy/
[5] https://www.nature.com/articles/d41586-022-02218-5
[6] https://backfill.dev/blog/2022-08-21-modern-python-backends/
[7] https://github.com/charliermarsh/ruff

#opendata #data #government #policy #tech #programming #readings

Купище державное

Я чувствую уже что слишком часто пишу про инициативы Минцифры РФ, гораздо реже стал писать в последнее время про госзакупки или другие органы власти, а чаще про них и про технологии. Вот недавно на Regulation выложили свежий проект постановления Пр-ва РФ [1] с обновлённым положением ГосТех'а и положением о ФГИС "ГосМаркет".

Во первых, не могу не посетовать на неизобретательность авторов. Сплошные англицизмы, а могли бы назвать imperium foro (на латыни) или купище державное / державное купище (почти старославянский). Но это ирония, будем честными, ничего другого мы и не ждали.

Сама идея того что называют Госмаркетом в том чтобы у производителей ПО была бы возможность продажи своих продуктов госорганам в режиме магазина. Зашёл, кликнул, получил, начал работать.

Очень простая схема для продуктов поставляемых в конкурентных рынках, по оферте с типовыми условиями.

В чём проблема с "ГосМаркетом" в России?

С тем что заказчики покупают не продукты, а по сути лицензии. Чаще всего на основе этих лицензий идёт последующая доработка софта или его кастомизация даже для таких, казалось бы, типовых решений как сайты госорганов.

Поэтому в мире, как минимум в развитых странах, произошла эволюция понятия government marketplace в каталог аттестованных/сертифицированных продуктов поддерживаемый владельцем облачной платформы.

Например, Azure Government Marketplace [2] и AWS GovCloud с руководствами по публикации там приложений [3].

В чем особенность ГосМаркета?
1. Зависимость от ГосТех'а что довольно странно поскольку сам ГосТех выглядит "големимсто". В том смысле что НПА вокруг него уже принято больше чем видно реального результата.
2. Оторванность от ГосОблака - кто-то ещё помнит, а такой проект был и никуда не делся. Но с суетой вокруг ГосТех'а его куда-то задвинули на второй или третий план.
3. Отсутствие сертификации соответствия облачных решений. Вообще обычно вначале их разрабатывают и актуализируют и только потом уже создают платформы вроде Державного купища

Я на эту тему могу рассуждать и писать ещё долго, но пока ограничусь напоминанием что портал ГосУслуг в России запускали трижды. Сколько раз будут запускать ГосТех и ГосМаркет?

Денег в стране ещё много, я делаю
ставку что больше двух раз;)

Ссылки:
[1] https://regulation.gov.ru/projects#npa=131116
[2] https://docs.microsoft.com/ru-ru/azure/azure-government/documentation-government-manage-marketplace
[3] https://aws.amazon.com/ru/blogs/awsmarketplace/category/public-sector/government/

#government #digital

Просто таки замечательный текст [1] о том насколько уже сейчас можно использовать генераторы изображений с помощью ИИ такие как Stable Diffusion для создания видео. Краткий ответ - можно уже сейчас.

Приложенная картинка сгенерирована автором с помощью DeepNostalgia [2] движка от MyHeritage по оживлению фотографий.

Автор там разбирает много других уже существующих способов генерации видео из изображений, рекомендую прочитать текст до конца и, конечно, важный акцент на рынке порнографии.

Как скоро появятся сервисы "Загрузи фото своей бывшей/актрисы/игрового персонажа и получи порно по заданным параметрам?". Ещё вопрос, станет ли это явление массовым и убьёт рынок рынок порнографии в текущем виде, или будет как со многими нынешними продуктами. Бесплатные сервисы и "более продвинутые" платные аналоги. Но то что именно этот рынок ждёт революция у меня лично сомнений не вызывает.

Может уже пора делать стартапы по персонифицированной порнографии? Уже появились венчурные фонды со специализацией в этой теме?

Ссылки:
[1] https://metaphysic.ai/stable-diffusion-is-video-coming-soon/
[2] https://blog.myheritage.com/2021/02/deep-nostalgia-goes-viral/

#ai #video #stablediffusion

Хороший обзор прослеживаемости данных (data lineage) [1] от Borja Vazquez из Monzo Bank

Прослеживаемость данных - это важная тема, актуальная особенно в корпоративной развитой аналитике и в научной среде, где важна достоверность результатов, или, хотя бы понимаемые уровни отклонения, и важна воспроизводимость результатов. Воспроизводимость результатов особенно актуальна при публикации научных работ, связанных с ними данных и тд.

Автор делает акцент на картографии данных в разных разрезах - пользовательского использования, качества данных, производительности и тд. в разных формах картографии данных, в основном вокруг DAG (directed acyclic graph) и потоков обработки данных.

Текст короткий, постановка проблем и подходов вполне понятные.

Когда-то я также активно занимался картированием данных, в основном для задач, обнаружения данных (data discovery).

Это другой подход, его задача идентифицировать основные источники данных в целях:
а) Внутреннего аудита
б) Создания дата-продукта

В итоге вместо того чтобы многие карты данных мы собрали общедоступные источники данных в datacatalogs.ru [2]

Ключевая разница между картографией данных на уровне прослеживаемости и картами данных для их обнаружения - в зрелости объектов анализа. В корпоративном мире, как правило, есть возможность влиять на потоки данных, источники данных, процедуры и тд. Ключевой вопрос: "Где проблемы? Как организовать процесс чтобы решать проблемы оперативно?"

В работе с открытыми источниками ключевые вопросы: "Как найти источник? Как получить к нему доступы?"

Ссылки:
[1] https://medium.com/data-monzo/the-many-layers-of-data-lineage-2eb898709ad3
[2] https://datacatalogs.ru

#data #dataquality #datamaps #opendata #datalineage

В рубрике что почитать и посмотреть, о том как устроены индексы в базах NoSQL от команды ByteByteGo [1] и, от них же, о том почему Redis работает быстро [2] и о том почему Kafka работает быстро [3].

У них отличный канал и про другие общеупотребимые технологии [4], рассылка [5] и онлайн курс [6]․

По многим вопросам стандартной современной архитектуры софтверных продуктов и проектов - это замечательный источник.

Рабочая реальность, зачастую, немного или даже сильно отличается наличием унаследованных архитектуры и кода, потребности в миграции, сопровождении нескольких версий сразу нескольких продуктов и тд, что не означает отсутствия необходимости знать о проектировании систем.

Ссылки:
[1] https://www.youtube.com/watch?v=I6jB0nM9SKU
[2] https://www.youtube.com/watch?v=5TRFpFBccQM
[3] https://www.youtube.com/watch?v=UNUz1-msbOM
[4] https://www.youtube.com/c/ByteByteGo/videos
[5] https://bit.ly/3tfAlYD
[6] https://bit.ly/3mlDSk9

#systemarchitecture #data #designpatterns

В рубрике интересных наборов данных о России вне России, открытые данные и каталоги данных о нефтегазовом рынке:

Resource Projects [1]
Проект NRGI с данными нефтяных проектов, нефтяных компаний и их профилей. Профиль ряда постсоветскихстран: Россия [2], Азербайджан [3], Казахстан [4], Украина [5], Грузия [6], Армения [7]. Из любопытного - почему-то ничего нет по Саудовской Аравии.
Там же профили компаний и их проектов.

National Oil Company Data [8]
База показателей по нефтегазовым компаниям. Ещё один проект NRGI, данных там много, последние данные за 2021 год.

JodiData [9]

Совместный проект нескольких международных агентств по отчетности по добыче и другим показателям по нефти и газу. Данные довольно актуальные, последние данные по России за июнь 2022 г.

Resource Data [10]

Проект с базой первичных документов по нефтегазовому сектору и добыче полезных ископаемых. Всё разделено по темам и по странам, по России документов немного, приоритет на развивающиеся страны.

IEA Data [11]

Данные международного энергетического агентства, не только по нефти и газу, и сразу в машиночитаемых форматах. Что-то бесплатно, что-то только за деньги.

Ссылки:
[1] https://resourceprojects.org
[2] https://resourceprojects.org/country/RU
[3] https://resourceprojects.org/country/AZ
[4] https://resourceprojects.org/country/KZ
[5] https://resourceprojects.org/country/UA
[6] https://resourceprojects.org/country/GE
[7] https://resourceprojects.org/country/AM
[8] https://www.nationaloilcompanydata.org/
[9] https://www.jodidata.org
[10] https://www.resourcedata.org/
[11] https://www.iea.org/data-and-statistics

#opendata #datasets #oil #gas #energy

В рубрике интересных наборов данных COYO-700M: Image-Text Pair Dataset [1] набор данные в виде пар изображение-текст собранный из базы Common Crawl, крупнейшего открытого поискового индекса в мире.

В наборе данных более 700 миллионов изображений полученных после анализа 10 миллиардов ссылок с упоминанием изображений.

Изображения только к текстам на английском, без картинок для взрослых, прошедшие интенсивную фильтрацию и так далее.

Набор данных можно скачать по ссылке [2].

Ссылки:
[1] https://github.com/kakaobrain/coyo-dataset
[2] https://huggingface.co/datasets/kakaobrain/coyo-700m

#opendata #datasets

По поводу свежего распоряжение Правительства РФ об использовании соцсетей Вконтакте и Одноклассники где органы власти должны заводить свои аккаунты [1] мне есть что сказать.

Важно разделять открытость и "открытость". Первое имеет природу и право получать ответы на вопросы, второе про то как "не быть, но казаться". Наличие аккаунта в соцсетях не даёт гарантии или даже высокой вероятности публикации там чего-либо кроме того что сейчас публикуется в новостях на сайтах этих организаций. А то есть потоков довольно бессмысленных публикаций.

Поэтому пишу кратко и тезисно:
1. В России государственных и муниципальных организаций около 200 тысяч, это означает что в соцсети пойдет много контента который ранее там не оказывался потому что никому не был нужен.
2. Правительство РФ - это орган федеральной исполнительной власти, но выпускает распоряжение затрагивающее региональные, муниципальные власти, а также суды.
3. Главные кто будут в выигрыше от этого решения - это соцсети и пиар агентства. Первые получат поток контента (хоть и так себе), вторые начнут, уже начали, продавать свои услуги.
4. Обязательно найдутся псевдообщественники которые начнут накатывать жалобы на то что какой-нибудь детский сад или поликлиника г. Резиножопска не завела аккаунт в соц сетях.

Никакого отношения к реальной открытости органов власти и государства в целом это всё, конечно же, отношения не имеет.

P.S. Просто не могу не отметить деградацию нормотворчества. В распоряжении Правительства поленились даже правильно написать реквизиты закона которые должны быть Федерального закона "Об обеспечении доступа к информации о деятельности государственных органов и органов местного самоуправления" от 09.02.2009 N 8-ФЗ вместо этого написано просто Федерального закона "Об обеспечении доступа к информации о деятельности государственных органов и органов местного самоуправления".

Поленились указать дату и номер закона. Всё это очень печалит

Ссылки:
[1] http://government.ru/news/46448/

#openness #government #social #transparency

7 Best Practices for Data Ingestion

Полезная заметка для тех кто занимается сбором и обработкой данных [1]. Автор собрал несколько практик используемых при загрузке данных.

Если кратко их пересказать:
1. Отслеживайте ошибки в первоисточнике (настраивайте предупреждения).
2. Сохраняйте копию первичных данных до преобразования.
3. Заранее устанавливайте сроки и ожидания пользователей. Загрузка данных не так уж проста.
4. Автоматизируйте трубы данных, устанавливайте SLA используйте системы оркестрации.
5. Трубы загрузки данных должны быть идемпотентны (результат их работы должен повторяться)
6. Создавайте шаблоны, используйте их повторно
7. Документируйте Ваши трубы данных.

Всё кажется очень очевидным и ни с чем не поспоришь. Я бы только добавил что 7-й пункт документируйте Ваши трубы данных должен быть 1-м пунктом. Сколько я не сталкиваюсь с продуктами на данных, вокруг данных, связанных с работой с данными и др. все формы data product недостаток документации есть у всех.

Кто-то скажет, что писать документацию работа не творческая, это так, потому что она производственная. Один из важнейших профессиональных навыков который повсеместно недооценивается.

Ссылки:
[1] https://medium.com/codex/7-best-practices-for-data-ingestion-f336c6b5128c

#data #datapipelines