Что такое кровавый энтерпрайз

Java это не только кровавый энтерпрайз, но и быстрые latency-sensitive приложения

Я занимаюсь алгоритмической торговлей в Райффайзенбанке. Это довольно специфичная область банковской сферы. Мы делаем торговую платформу, работающую с низкими и предсказуемыми задержками. Успех приложения зависит, в том числе, и от скорости работы приложения, поэтому нам приходится заниматься всем стеком, задействованным в торговле: приватными сетевыми каналами, специальным аппаратным обеспечением, настройками ОС и специальной JVM, и, конечно же, самим приложением. Мы не можем остановиться на оптимизации исключительно самого приложения — настройки ОС или сети имеют не меньшее значение. Это требует технической экспертизы и эрудиции, чтобы понять, как через весь стек проходят данные, и где может быть задержка.

Не каждая организация/банк может позволить себе разработку подобного класса софта. Но мне повезло, что такой проект был запущен в стенах Райффайзенбанка, а у меня была подходящая специализация — я специализировался на производительности кода в Московской компиляторной лаборатории Intel. Мы делали компиляторы для С, С++ и Fortran. В Райффайзенбанке я перешел на Java. Если раньше я делал какой-то инструмент, которым потом пользовалось много людей, то сейчас я переместился на другую сторону баррикад и занимаюсь прикладным анализом производительности не только кода, но и всего стека приложения. Регулярно путь исследования перформансной проблемы лежит далеко за рамками кода, например, в ядре или настройках сети.

Java не для highload’а?

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

Давайте будем смотреть правде в лицо: С++ мире среды разработки (IDE) существенно отстают от IntellyJ и Eclipse. Если разработчик использует любую из этих сред, то скорость отладки, нахождение багов и написание сложной логики на порядок выше. В итоге получается, что проще подпилить в нужных местах Java, чтобы она работала достаточно быстро, чем делать всё с нуля и очень долго на С++. Самое занятное, что при написании конкурентного кода, подходы к синхронизации и в Java и C++ очень похожи: это либо примитивы уровня ОС (например, synchronized/std::mutex) или примитивы железа (Atomic*/std::atomic ). И очень важно видеть это сходство.

И вообще, мы разрабатываем не highload приложение))

В чем же разница между highload и low latency приложением?

Термин highload не до конца отражает специфику нашей работы — мы занимаемся именно latency-sentitive системами. В чем же разница? Для высоконагруженных систем важно работать в среднем достаточно быстро, полностью используя аппаратные ресурсы. На практике это означает, что каждый сотый/тысячный/../миллионный запрос к системе потенциально может работать очень медленно, ведь мы ориентируемся на средние значения и не всегда учитываем, что наши пользователи существенно страдают от тормозов.

Мы же занимаемся системами, для которых уровень задержки критически важен. Наша задача — сделать так, чтобы система всегда имела предсказуемый отклик. Потенциально latency-sensitive системы могут быть не высоконагруженными, в случае, если события происходят достаточно редко, но требуется гарантированное время отклика. И это не делает их разработку проще. Даже наоборот! Опасности подстерегают прямо повсюду. Подавляющее большинство компонентов современного железа и софта ориентированы на хорошую работу «в среднем», т.е. для throughput.

Взять хотя бы структуры данных. Мы используем хэш-таблицы, и если происходит ре-хэш всей структуры данных на критическом пути – это может привести к ощутимым тормозам для конкретного пользователя на единичном запросе. Или JIT компилятор – оптимизирует наиболее часто выполняющийся паттерн кода, пессимизируя редко исполняющийся паттерн кода. А ведь быстродействие именно этого редкого случая может быть очень важно для нас!

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

Как добиться предсказуемой длительности реакции?

На этот вопрос не получится ответить в двух фразах. В первом приближении важно понимать, есть ли какая-то синхронизация — synchronized, reentrantlock или что-то из java.util.concurrent. Зачастую приходится использовать синхронизацию на busy-spin’ах. Использование любого примитива синхронизации – это всегда компромисс. И важно понимать, как работают эти примитивы синхронизации и какие компромисы они несут. Также важно оценить сколько мусора генерирует тот или иной участок кода. Лучшее средство борьбы с garbage collector — не тригерить его. Чем меньше мы будем генерировать мусора, тем реже мы будем запускать сборщик мусора, и тем дольше проработает система без его вмешательства.

Также мы пользуемся широким спектром разных инструментов, которые позволяют нам анализировать не только усредненные показатели. Нам приходится очень пристально анализировать, насколько медленно работает система каждый сотый, каждый тысячный раз. Очевидно, что эти показатели будут хуже, чем медиана или среднее. Но нам очень важно знать, насколько. И показать это помогают такие инструменты как, к примеру, Grafana, Prometheus, HDR-гистограммы и JMH.

Можно ли удалять Unsafe?

Зачастую приходится использовать и то, что апологеты называют недокументированным API. Я говорю про знаменитый Unsafe. Я считаю, что unsafe де-факто стал частью публичного API Java-машин. Нет смысла это отрицать. Unsafe используют очень многие проекты, которые мы все активно применяем. И если мы от него откажемся, то что будет с этими проектами? Либо они останутся жить на старой версии Java, либо придется опять потратить очень много сил, чтобы все это переписать. Готово ли комьюнити на это? Готово ли оно потенциально потерять десятки процентов производительности? И главное, в обмен на что?

Косвенно мое мнение подтверждает очень аккуратное удаление методов из Unsafe — в Java11 были удалены самые бесполезные методы из Unsafe. Думаю, пока хотя бы половина из всех пользующихся Unsafe проектов не переедут на что-то другое, Unsafe будет доступен в том или ином виде.

Существует мнение: Банк + Java = кровавый закостенелый энтерпрайз?

В нашей команде таких ужасов нет. На Spring’е у нас написано, наверное, строчек десять, причем мною)) Мы стараемся не использовать большие технологии. Предпочитаем делать маленькое, аккуратное и быстрое, чтобы мы могли это осознать, контролировать и при необходимости модифицировать. Последнее очень важно для систем (вроде нашей), к которым предъявляются нестандартные требования, которые могут отличаться от требования 90% пользователей фреймворка. И в случае использования большого фреймворка, мы не сможем ни донести свои потребности комьюнити ни самостоятельно поправить поведение.

На мой взгляд, у разработчиков всегда должна быть возможность использовать все доступные инструменты. Я пришел в мире Java из C++ и мне очень сильно бросается в глаза разделение сообщества на тех, кто разрабатывает runtime виртуальной машины/компилятор или саму виртуальную машину и на прикладных разработчиков. Это прекрасно видно по коду стандартных классов JDK. Зачастую авторы JDK пользуются другим API. Потенциально это означает, что мы не можем добиться пиковой производительности. Вообще, я считаю, что использование одинакового API для написания и стандартной библиотеки и прикладного кода – отличный показатель зрелости платформы.

Еще кое-что

Думаю, всем разработчикам очень важно знать, как работает, если не весь стек, то хотя бы его половина: Java-код, байт-код, внутренности среды исполнения виртуальной машины и ассемблер, железо, ОС, сеть. Это позволяет шире посмотреть на проблемы.
Также стоит упомянуть производительность. Очень важно не замыкаться на средних показателях и всегда смотреть на показатели медианы и высоких перцентилей (худший из 10/100/1000/… замеров).

Обо всем этом буду рассказывать на встрече Java User Group 30 мая в Санкт-Петербурге. Встреча с Сергеем Мельниковым, это я как раз)) Зарегистрироваться можно по ссылке.

О чем будем говорить?

Источник

Как open-source побеждает «кровавый энтерпрайз»: битва за BPMS

Шестеренки современного банка крутятся в соответствии с финансовыми бизнес-процессами. Они сложнее обычных — это правило работает для всего, к чему вы добавите определение «финансовые». С одной стороны, все усложняют регуляторы, бессчетное количество согласований и вовлеченных сторон. С другой — неповоротливые монолитные BPMS (Business Process Management System). В этом посте мы расскажем, как успешно забросили одну такую систему и ушли в гибкий и функциональный open source.

Программисты отображают бизнес-процессы с помощью разных нотаций. Сейчас стандартом является BPMN (Business Process Model and Notation) — это XML-файлы с привязанными к ним изображениями. Для работы с этой нотацией создаются продукты BPMS — монолитные проприетарные системы, которые стараются вместить в себя максимум инструментов для разработки BPM: от редактора пользовательского интерфейса до системы контроля версий.

Расширить их могут только разработчики, которые уже давно работают с этими системами. В энтерпрайзных BPMS предусмотрены REST API, то есть к системам можно обращаться и получать в ответ данные. Но модификация и глубокая настройка самой BPMS практически невозможны. Работать с такими BPMS возможно только через ограниченный производителем набор инструментов — проприетарную систему контроля версий, компилятор, деплоер — обычно для каждой крупной BPMS разрабатывается целый набор. Эти инструменты развиваются медленно, от релиза к релизу могут сохраняться одни и те же проблемы, поскольку в работе задействовано не так много человек, как в случае с open source. В целом, возможности энтерпрайзных BMPS и потребности их пользователей совпадают очень редко.

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

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

Изменения разного масштаба в бизнес-процессы нам приходится вносить частенько. Раньше у нас был BPM-процесс для клиентских менеджеров, которые сидят в дополнительных офисах. В 2015 году мы часть офисов закрыли, а менеджеров перевели на выездную работу. Это потребовало больших изменений в BPM-процессах, нужно было вводить другие роли, действия. Или, например, изменился регламент службы экономической безопасности, и вместо двух согласующих теперь стало три.

Сначала мы вносили изменения через BPMS IBM Lombardi. Собрав типичные недостатки систем своего класса, она отличалась еще и отсутствием упорядоченной документации. Создавалось впечатление, что после покупки Lombardi Software софтверный гигант взглянул на аморфное облако сопроводительных статей и решил ничего не трогать. И даже перечитав всю документацию, нельзя было сделать многие вещи. Например, вызвать REST-запрос с HTTPS-аутентификацией по пользовательскому сертификату. К счастью, поиски альтернативы увенчались успехом.

Camunda решает проблемы

После работы с IBM BPM мы пришли к тому, что разные группы пользователей должны уметь менять бизнес-процессы. Что-то незначительное в онлайн-режиме могут вносить обычные сотрудники бизнес-подразделений. Системные аналитики изменяют последовательность задач в бизнес-процессах. Новые интеграции, изменения в UI и программный код остаются на стороне разработчиков. А чтобы поддерживать такую гибкость, вся BPMS должна быть развернута на микросервисах.

Такой подход мы можем обеспечить с помощью open-source BPMS Camunda. Она представляет собой форк проекта Activity, который группа разработчиков решила сделать более продаваемым. Они привели в порядок документацию и стали развивать Camunda отдельно, зарабатывают на продаже поддержки.

BPMS Camunda позволяет редактировать бизнес-процессы с помощью обычного Java и поддерживает разделение на микросервисы. Переход BPMS на микросервисы дает сразу несколько преимуществ:

Наша первая версия Camunda стояла на Websphere и по сути мало чем отличалась от IBM Lombardi. Сами приложения, к которым обращался сервис, мы решили написать на Spring Boot. Они деплоились на Tomcat и самостоятельно не работали. Потом оказалось, что Camunda может работать на Tomcat, была разработана версия для Spring Boot. Там же уже стала доступна полноценная микросервисная архитектура. Все приложения, с которыми работал бизнес-процесс, были реализованы на микросервисной архитектуре на основе Spring Cloud.

Затем выяснилось, что быстро менять функциональность можно не только в сервисах, которые обслуживают бизнес-процесс. Сам движок BPM можно подключить к любому springboot-приложению в виде библиотеки.

Camunda как микросервис

Возник вопрос: сколько микросервисов поднимать? Можно было делать на каждый процесс один сервер, и там расположить все микросервисы, либо под каждую задачу сделать свой микросервис и в нем отдельный бизнес-процесс. Второе было бы удобнее, но пришлось бы организовать взаимодействие процессов, разбросанных по отдельным микросервисам. Мы попробовали несколько вариантов и остановились на решении, когда несколько микросервисов отвечает за определенную тематику и там сгруппированы несколько процессов. Общение происходит либо через REST, либо через Rabbit MQ. Сейчас еще запустили пилот на Kafka.

Перспективы BPMS

Бизнес-процессы не только отображают бизнес-воркфлоу, но реагируют на события, происходящие в остальных системах. У нас эти события аккумулирует отдельное подразделение Big Data. По итогам анализа этих событий создаются новые бизнес-процессы или изменяются уже существующие — это происходит постфактум, с периодичностью, например, раз в сутки.

В идеале бизнес-процессы должны переходить к тому, чтобы изменяться в режиме онлайн — например при увеличении спроса на определенные услуги автоматически приоритезировать их выполнение и перераспределять ресурсы. Этого можно достичь с помощью автоматизации, взаимодействия, например, Kafka и Camunda, но это вопрос как минимум нескольких лет. Пожалуй, сейчас в сторону изменений в онлайн-режиме больше всего продвинулся полностью онлайновый английский Monzo Bank. И мы тоже над этим работаем.

Источник

enternet

Паша (Paul)

Господа, откуда есть пошел русский айтишный мем «кровавый энтерпрайз»?

Залез на лукоморье – нету. Погуглил – всякий шлак лезет. Ну чего в нем кровавого, кроме глаз? Да и то раз в год. Плаваю в нем много лет.

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

Ну и на работу нужно ходить к 9:00, а то заказчики могут очень удивиться. Это типа как политику нельзя публично в носу поковырять – профессиональные издержки.

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

Edited at 2015-04-29 11:47 am (UTC)

Термин возник у меня в журнале 2007-08-15

После этой даты термин встречается 2й раз, ссылка еще осталась:

Edited at 2015-04-29 12:02 pm (UTC)

Кровавость ынтыпрайза подверждается! )

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

Теоретически да. Но я не знаю таких мест, где бы без эпизодического привлечения разработчиков обходилось бы. Например, мы сейчас кое-что автоматизируем у некоторых российских монополистов, так и то, мне, как ведущему разработчику, иногда нужно съездить посидеть на совещаниях. Есть даже внутренняя шутка про «пора уже в Кремль на совещания ездить» ) Партнеры делают ровно так же, всегда присутствует технический специалист. Это на самом деле удобно и создает определенный фон доверия. Психологически комфортно. А когда всё сводится только к скайпу, письмам и баг-трекеру, то этот фон разрушается и начинается напряг. Ну и про прямое общение айти-структур без менеджмента тоже забывать не нужно, это просто удобно потому что разговор идет на одном языке.

Короче, я бы не назвал это «доставать». Подавальщиков ключей никто доставать не будет, но с ростом ответственности в проекте будет и общение. Нормальный процесс для небольшой компании.

Источник

Миграция данных в кровавом энтерпрайзе: что анализировать, чтобы не завалить проект

Типичный проект системной интеграции для нас выглядит так: у заказчика вагон систем для учета клиентов, задача — собрать клиентские карточки в единую базу. И не только собрать, а еще очистить от дублей и мусора. Чтобы на выходе получились чистые, структурированные, полные карточки клиентов.

Для начинающих поясню, что миграция идет по такой схеме: источники → преобразование данных (отвечает ETL или шина) → приемник.

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

Работали так:

Советы пригодятся тестировщикам, внедренцам enterprise-продуктов, системным интеграторам-аналитикам. Приемы универсальны для реляционных баз, а во всю мощь раскрываются на объемах от миллиона клиентов.

Но сначала — об одном из главных мифов системной интеграции.

Документация и архитектор помогут (на самом деле нет)

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

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

Документация врет. Типичная enterprise-система работает 5–20 лет. Все эти годы изменения в ней документируют самые разные подразделения и подрядчики. Каждый со своей колокольни. Поэтому целостности в документации нет, никто до конца не понимает логику и структуру хранения данных. Не говоря о том, что сроки вечно горят и на документирование не хватает времени.

Обычная история: в таблице клиентов есть поле «СНИЛС», на бумаге очень важное. Но когда я смотрю в данные, то вижу — поле пустое. В итоге заказчик соглашается, что целевая база обойдется без поля для СНИЛС, раз данных все равно нет.

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

Бизнес-процессы безупречны лишь на бумаге. Ранним утром в оперофис банка на окраине Выксы заходит невыспавшийся оператор Анатолий. Под окном всю ночь орали, а с утра Анатолий поругался с девушкой. Он ненавидит весь мир.

Нервы еще не пришли в порядок, и Анатолий целиком вбивает ФИО нового клиента в поле для фамилии. Про день рождения начисто забывает — в форме остается дефолтное «01.01.1900 г». Наплевать на регламенты, когда все вокруг так бесит.

Хаос побеждает бизнес-процессы, очень стройные на бумаге.

Системный архитектор знает не все. Дело снова в почтенном сроке жизни enterprise-систем. За годы, что они работают, архитекторы меняются. Даже если поговорить с действующим, решения предыдущих всплывут сюрпризами во время проекта.

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

Интеграция «по приборам», без анализа данных — ошибка. Я покажу, как мы в HFLabs изучаем данные при системной интеграции. В последнем проекте я анализировала только выгрузки из ETL. Но когда заказчик выдает доступ к исходным данным, их обязательно проверяю по тем же принципам.

Заполненность полей и null-значения

Самые простые проверки — на заполненность таблиц в целом и на заполненность отдельных полей. С них и начинаю.

Сколько всего заполненных строк в таблице. Самый простой запрос из возможных.

Получаю первый результат.

Здесь смотрю на адекватность данных. Если в выгрузке для крупного банка пришло только два миллиона клиентов, явно что-то не так. Но пока все выглядит ожидаемо, двигаюсь дальше.

Сколько строк заполнены по каждому полю отдельно. Проверяю все столбцы таблицы.

Первым попалось поле с днем рождения, и сразу любопытно: данные почему-то вообще не пришли.

Если в выгрузке все значения в поле — «NULL», первым делом смотрю в исходную систему. Возможно, там данные хранятся исправно, но их потеряли при миграции.

Вижу, что в системе-источнике дни рождения на месте. Иду к интеграторам: ребята, ошибка. Выяснилось, что в ETL-процессе неправильно отработала функция «decode». Код поправили, в следующей выгрузке проверим изменения.

Иду дальше, к полю с ИНН.

В базе 100 миллионов человек, а ИНН заполнены только у 65 тысяч — это 0,07%. Такая слабая заполненность — сигнал, что поле в базе-приемнике, быть может, не нужно вовсе.

Проверяю систему-источник, все верно: ИНН похожи на актуальные, но их почти нет. Значит, дело не в миграции. Осталось выяснить, нужно ли заказчику в целевой базе почти пустое поле под ИНН.

Добралась до флага удаления клиента.

Флаги не заполнены. Это что же, компания не удаляет клиентов? Смотрю в исходную систему, разговариваю с заказчиком. Выходит, что да: флаг формальный, вместо удаления клиентов удаляют их счета. Нет счетов — клиента как бы удалили.

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

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

Проверяю заполненность составляющих адреса.

Адреса заполнены неоднородно, но выводы делать рано: сначала спрошу у заказчика, для чего они нужны. Если для сегментации по странам, все отлично: данных достаточно. Если для почтовых рассылок, тогда проблема: дома́ почти не заполнены, квартир нет.

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

Во время анализа на заполненность я особняком ставлю поля, ссылающиеся на справочники. Условие «IS NOT NULL» с ними не работает: вместо «NULL» в ячейке обычно «0». Поэтому поля-справочники проверяю отдельно.

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

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

Заполненность всех полей.

Между выгрузками исчезли 5 миллионов записей. Иду к интеграторам, задаю типовые вопросы:

А вот дни рождения в новой выгрузке появились, как я и ожидала.

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

Что проверять, в двух словах.

Длина значений в строковых полях

Я следую одному из базовых правил тестирования — проверяю граничные значения.

Какие значения слишком короткие. Среди самых коротких значений полно мусорных, поэтому здесь интересно копнуть.

Таким способом я проверяю ФИО, телефоны, ИНН, ОКВЭД, адреса сайтов. Всплывает бессмыслица вроде «A*1», «0», «11», «-» и «. ».

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

Таким способом я нашла в поле с типом документа строку «Свидетельство о регистрации ходатайства иммигранта о признании ег». Рассказала интеграторам, длину поля поправили.

Как значения распределяются по длине. В HFLabs таблицу распределения строк по длине мы называем «частотка».

Здесь я выискиваю аномалии в распределении по длине. Например, вот частотка для таблицы с почтовыми адресами.

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

Что проверять, в двух словах.

Популярные значения

Я делю на три категории значения, попадающие в топ популярных:

Популярные значения я ищу в полях трех типов:

Для строковых полей — каковы топ-100 популярных значений. Если хочется, можно взять и побольше, но в первые сто значений обычно помещаются все аномалии.

Я проверяю таким способом поля:

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

Попутно такой анализ покажет скрытые поля-справочники. Этим полям по логике вроде как не положено быть справочниками, но фактически в базе они таковыми являются. Например, выбираю популярные значения из поля «Должность», а их всего пять.

Возможно, компания обслуживает только пять профессий. Не очень похоже на правду, верно? Скорее, в форме для операторов вместо строки сделали справочник и забыли отсыпать значений. Важный вопрос здесь: разумно ли вообще заполнять должности через справочник. Так через анализ данных я выхожу на возможные проблемы с операторским софтом.

Для полей-справочников и классификаторов проверяю, какова популярность всех значений. Для начала разбираюсь, какие поля — справочники. Скриптами здесь не обойтись, беру документацию и прикидываю. Обычно справочники создают для значений, число которых конечно и относительно невелико:

Обычно в строковых-полях справочниках лежит такое.

Популярные значения в полях-классификаторах я проверяю, чтобы отловить недостаток вариантов. Сталкивалась с такими случаями.

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

Что проверять, в двух словах.

Консистентность и кросс-сверки

От анализа данных внутри таблиц перехожу к анализу связей.

Связаны ли данные, которым положено быть связанными. Этот параметр мы называем «консистентность». Беру подчиненную таблицу, например, с телефонами. К ней в пару — родительскую таблицу клиентов. И смотрю, сколько в подчиненной таблице айдишников клиентов, которых нет в родительской.

Если запрос дал дельту, значит, не повезло — в выгрузке есть несвязанные данные. Так я проверяю таблицы с телефонами, договорами, адресами, счетами и так далее. Однажды во время проекта нашла 23 миллиона номеров, просто висевших в воздухе.

В обратную сторону тоже работает — ищу клиентов, у которых почему-то нет ни одного договора, адреса, телефона. Иногда это нормально — ну нет адреса у клиента, что такого. Здесь нужно выяснять у заказчика, документация запросто обманет.

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

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

Если таблиц со схожими сущностями несколько, делаю кросс-сверку: проверяю пересечение идентификаторов. Пересекаются — клеим заплатку. Например, собираем айдишники для единой таблицы по схеме «название исходной таблицы + ID».

Что проверять, в двух словах.

Что еще проверить

Нет ли латинских символов там, где им не место. Например, в фамилиях.

Так я отлавливаю замечательную латинскую букву «C», которая совпадает с кириллической. Ошибка неприятная, потому что по ФИО с латинской «C» оператор никогда не найдет клиента.

Не затесались ли посторонние символы в строковые поля, предназначенные для цифр.

Проблемы всплывают в полях с номером паспорта РФ или ИНН. Телефоны — то же самое, но там я разрешаю плюс, скобки и дефис. Запрос выявит и букву «O», которую поставили вместо нуля.

Насколько данные адекватны. Никогда не знаешь, где всплывет проблема, поэтому я всегда настороже. Встречала такие случаи:

Все, что нужно — SQL и Excel

Чтобы анализировать данные, дорогое ПО не нужно. Хватает старого доброго Excel и знания SQL.

Excel я использую, чтобы собрать длинный запрос. Например проверяю поля на заполненность, а в таблице их 140. Писать руками буду до морковкиного заговения, поэтому собираю запрос формулами в excel-табличке.

_{В столбец «A» вставляю названия полей, беру их в документации или служебных таблицах. В колонке «B» — формула для склеивания запроса}

Вставляю названия полей, пишу первую формулу в колонке «B», тяну за уголок — и готово.

_{Работает и в Excel, и в Google Docs, и в Excel Online (доступен на «Яндекс.Диске»)}

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

Не цифры, а выводы

Что я собираю для отчета:

Иногда заказчик, увидев проблему, отвечает: «Не парьтесь, не обращайте внимания. Закупим лишний терабайт памяти, да и все. Так дешевле, чем оптимизировать». Соглашаться на такое нельзя: если забирать все подряд, качества в приемнике не будет. Мигрируют все те же замусоренные избыточные данные.

Поэтому мы мягко, но неуклонно просим: «Расскажите, как будете использовать именно эти данные в целевой системе». Не «зачем нужны», а именно «как будете использовать». Ответы «потом придумаем» или «это на всякий случай» не годятся. Рано или поздно заказчик понимает, без каких данных можно обойтись.

Главное — найти и разрешить все вопросы, пока систему не запустили в прод. На живую менять архитектуру и модель данных — с ума сойдешь.

На этом с базовыми проверками все, изучайте данные!

Источник