Data

Компания EPAM давно работает с данными, первые крупные заказчики с проектами поBigDataпоявилисьв далёком 2001 году.В то время известные аналитические компанииGartnerиForrester, а также крупные поставщикиOracle,Microsoftи IBM отмечали, что компании должны двигаться в сторонуBigData, поскольку эти технологии незаменимы во всех областях, связанных с обработкой больших объёмов данных.С того времени команда экспертовEPAMпостепенно росла, работая над всё более сложными проектами и предлагая проверенные решения и качественные продукты для работы с большими данными. Сегодня только в российскомEPAMболее 500 человек работают вData-практике. О том, как всё начиналось, какие проекты встречались, какие провалы случались,к чему должны готовитьсяData-специалисты и о том, какие вообще бываютData-специалисты,я поговорила с руководителемData-практики EPAM в России Ильей Герасимовым.

Карьера

Расскажи, как ты пришёл в направление Data

ВEPAMя пришёл в 2006 годукакjunior-разработчикна .NETиMSSQLServer, до этого работал в продуктовойкомпаниии занимал должность тимлида, разрабатывал ПО для автоматизациигостиници ресторанов.Но вEPAMяначалкарьерус нуля.К 2013 году я дорос дотимлидаиискал новыевозможностисвоегоразвитиявEPAM,и именно в это времяявстретилсянаSECeв Минскес руководителем центра компетенцийBigData, и мы договорились о том, что в России надо развивать это направление.

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

Почему так долго работаешь в компании?

Ещё до Data я подумывал пару раз уйти, но что-то не отпускало меня. Сейчас я могу сказать точно, что здесь меня держат люди, с которыми пройдено много всего. И здесь всегда появляется что-то новое новые проекты, заказчики.

Почему именно Data?

Потому чтовесь мир этоData, и мы в нейData.:)

Что сейчас представляет собой Data-практика?

ПостепеннопоявлялисьновыеData-компетенции:Data Science,Machine Learning,Business Intelligence, Enterprise Search, DevOps in Data, Data Quality, Business Data Analysis.Сегодняв нашей практике более 500 человек это оченьбольшое подразделение сглубокойэкспертизойв разных областях.

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

Для любого крупного предприятия рано или поздно встает вопросData-менеджмента иData governance,т.е.понимания какие данные у предприятия есть в активе, какие данные они могут получить, как объединить эти данные, источниками которых являются разные подразделенияивнешние источники.Понять кто несёт за эти данные ответственность, кто имеет к ним доступ,как быстро данные устаревают, насколько они достоверны ит.д.

Более глубокое понимание качества данныхэто способ лучше понять бизнес клиента.

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

Проекты

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

Когда в 2013-2014 году мы начинали, у нас было буквально два-три проекта, мы работали с иностранной нефтегазовой компанией, с российским банком, потом появился проект с расшифровкой генома, а затем и первый проект с Data Science.

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

А самый большой провал и как справились с этим?

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

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

Помимо общего курса нашими специалистами разработано много внутренних курсов по разным направлениям Data Analytics, облачные решения, Data Engineering, Data Science и другие, доступных всем сотрудникам EPAM.

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

Про технологии

За чем сейчас будущее? На какие технологии появляется и сохраняется спрос?

Если я начну перечислять все технологии, то какие-то пропущу, какие-то не вспомню, на какие-то обращу больше внимания, чем они этого заслуживают. Технологий очень много, они быстро стареют и так же быстро появляются новые. Гнаться за суперсовременными технологиями не всегда получается, да и не всегда нужно. Зачастую новые решения появляются на рынке в довольно сыром состоянии. Однажды на одном проекте мы погнались за технологией Cadence, которая показалась заказчику приемлемой, но в итоге с ней постоянно возникало много проблем с производительностью, она не справлялась с тем объёмом данных, который был на проекте, и мы с трудом находили людей, которые могли бы быстро в ней разобраться.

Был ещё один кейс, на этот раз с технологией Reinforcement Learning. Один из наших заказчиков хотел внедрить систему с использованием этой технологии. Этому фреймворку на тот момент было около 2-х месяцев, он был довольно сырой. В целом было очень мало систем промышленного масштаба, где эта технология используется. В итоге ничего не получилось, и нам пришлось быстро откатить систему и создать решение, которое справлялось с задачей заказчика уже без использования Reinforcement Learning. Хотя технология очень перспективна, мы следим за её развитием и, возможно, даже уже в этом году мы сможем использовать её в проектах.

Но всё же существует некоторый золотой стандарт, который должны знать Data-специалисты. Причём этот стандарт тоже постоянно обновляется. На самом деле, в инкубаторе много проектов, которые завтра взлетят. Многие проекты, которые вошли в золотой стандарт это вчерашний инкубатор. Были, конечно, технологии, которые не взлетели. Так случилось, например, с технологией Theano, она появилась примерно в одно время с TensorFlow, но Theano куда-то исчезла.

• УApacheесть целый набор инструментов, технологий, которые нужно знать среди нихSpark,Cassandra,Elasticsearchи другие.

• Yarn, HDFS,MapReduce,Hive,Kafka,ZooKeeper этобазовые технологии, с которых всё начиналось.БазоваятехнологияHadoopникуда не делась,хотя онавыглядит немногоустаревшей, новсе принципы,которые в ней заложены,используются в современных технологиях.

• Вразличных облачныхтехнологиях вAmazon,MicrosoftAzure,JCPесть свои аналогиHadoop, с которыми мы работаем.

• Также актуальными являются инструменты защиты данных, такие какKerberos,Knox,Ranger.

• Понятно, что различныеNoSQLиNewSQLбазы данных Cassandra, например(ужене новая),Snowflake,AmazonRedshift,HBase,MongoDB,Teradata.

• DevOpsтехнологии Kubernetes, Docker, Jenkins.

• Технологии визуализации данных:PowerBI,Tableau,QlikView.

• ВDataScienceтоже множество различных фреймворков,напримерTensorFlowиGoogleBERT (который тоже ужевчерашний день, сегодняесть реализации лучше),PyTorch,Keras.

• Отдельно стоит перечислить технологииStreaming.Streamingэто новый вызовмираData, поэтомуинструментыстоит знать Spark Streaming, KafkaStreams, ApacheFlink, Apache Storm.

Во многом набор знаний зависит от направления специалиста.

Для всех обязательно знание SQL (стандартного и аналитического), теории DWH (какие типы организации хранилищ данных бывают звезда, снежинка,DataVault, как организовать историчность хранения справочников ит.д.), нормализации данных (чем отличаются первая, втораяи третья нормальные формы, что это такое вообще, в каких случаях полезна денормализация), и понимать, чем отличается DWH,DataMart,DataLake.

Для всех обязательно понимание процесса промышленной разработки, знание систем контроля версий. В последние годы обязательным становиться опыт работы с облаками, хотя бы с одним из наиболее популярных AWS,Azure, GCP.

Для тех, кто занимается ETL (загрузка и преобразование данных перед их использованием) обязательно понимание разницы ETL и ELT, стадий загрузки, способов проверки и очистки данных, понятияslowlychangeddimension. Также обязательно знание как минимум одного языка программирования для написания ETL вручную (PL/SQL, T-SQL,pgSQL,Python,Spark), оркестраторов для запуска процессов (например,Airflow), специализированных программ, каккомерческих, так и бесплатных (Talend,InformaticaPowerCenter,Pentaho,etc.).

Для репортеров (DataAnalyticsandVisualization), помимо знания хотя бы 2-х репортинговых программ (PowerBI,Tableau, TIBCOSpotfire,MicroStrategy,Pentaho, ит.д.) необходимо знание различных подходов в создании отчётов идашбордов(например,Storytelling).

А вы сами участвуете в разработке каких-то технологий?

Наши сотрудникиконтрибьютятвApache Spark, NiFi, Elasticsearch и многие другие. Любой сотрудник может принять участие в проекте. Даже врамках нашего обучающего курса, о котором ярассказывал,одно из заданий доработать какую-то фичу или исправить решение в Open Source проекте.

Кроме того,мы разрабатываемисвоиOpenSourceпродукты, например, Open Data Analytics Hub (ODAHU) проект, предоставляющий компоненты для создания систем автоматизации полного жизненного цикла ML моделей.

Какие технологии используются у вас на проектах?

Мы немного по-другому смотрим на то, как долженстроитьсяподход к управлению проектами в Data он основанненавыборетехнологий,ана методологиях. У нас есть несколько шаблонов (blueprint) для решения тех или иных задач. Это решения задач,с которыми мы часто сталкивались на наших проектах, ужепроверенныевременем.Грубо говоря, у нас естьшаблон,который мынаполняемтехнологиямив зависимостиот задач заказчика, от его приоритетов, инфраструктуры.

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

Отличаются ли подходы к проектам в разных отраслях?

Мыработаемснефтегазовой отраслью, с банками, сфармацевтическими компаниями,e-commerce,с медиа,со страховым бизнесом, в областиLifeScienceмногопроектоводним словом, в различных бизнес-направлениях.Может показаться, что всё это абсолютно разные направления задач,ноblueprintsпозволяют нам мыслить в одних шаблонах, решать разные задачи с помощью одних и тех же подходов.

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

Что изменил 2020 год?

Четкое осознание, что данные нужно уже не только копить, но и заставлять их работать на бизнесу компанийпоявилосьвXXIвеке.И2020 год подтолкнул компании, так называемое позднее большинство (latemajority), которые до этого сомневались вценности использования данных,к изменениямвзглядов и походов.

Про обучение

Как его лучше организовывать тем, кто интересуется датой: с чего начать, на что делать упор?

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

Чтобы начать учиться, необходимоиметьжелание,уверенность в будущемData, и умение программировать хотя бы на одном из языковJava,ScalaилиPython.

В тренинг-центре EPAM есть бесплатные курсы для начинающих специалистов, в том числе по направлениям Data Engineering, Data Science, BI, а также Python и другим языкам, которые помогут стартовать в профессии.

Что должен знать идеальный инженер, претендующий на место в команде Data в EPAM?

Выше подробно описан стек технологий. Если кратко, идеальныйDataгерой должен уметь программировать наJava,ScalaилиPython(вообще, большинство ребят полиглоты в терминах языков программирования),знатьSQL, понимать различные подходы к хранению и обработке данных, их плюсы и минусы, знать различные архитектуры построения гетерогенных систем, обязательно знатьDevOps-инструменты и методологии ведения проектов,умениеработать с облачными технологиямиипониманиеMachineLearningтакже приветствуются.

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

1. Когда считать, что набор опоздал?

2. Какие данные часто опаздывают?

3. По какой причине набор опоздал?

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

Данные запаздывают

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

Для своевременной поставки данных Airbnb мы стремимся к тому, чтобы владельцы каждого промежуточного шага фиксировали соглашения об уровне обслуживания (SLA) по доступности данных к конкретному времени. Например, владелец набора обещает, что метрика "бронирование" будет содержать самые актуальные данные к 5 утра по UTC, и если набор к этому времени недоступен, то он опоздал.

Как часто наборы опаздывают?

Сначала мы решили, что, опираясь на представление отчёта, Report поставщики данных должны понимать, когда данные выгружены и как часто они соответствуют SLA (рис. 1).

В этом представлении поставщики в реальном времени отслеживают ситуацию и видят тенденции по нескольким наборам, которыми владеют или которым уделяют внимание.

Мы также позаботились о том, чтобы инструмент был полезен даже при отсутствии формального заданного SLA, когда проявится типичное время выгрузки. При первом запуске инструмента SLA ещё не было, кроме того, есть наборы, которые используются не очень широко, то есть SLA им не требуется.

В Report используются традиционные списки объектов данных и небольшие визуальные эффекты, которые кратко обобщают типичное время выгрузки и исторические данные. Поставщики могут организовать наборы по спискам и работать со списками командно. Благодаря такому обобщению данных время выгрузки и производительность SLA понять так же просто, как курировать список наборов.

Отчётность только вершина айсберга

Хотя Report сильно упрощает понимание того, действительно ли набор опаздывает, это представление не решило главные проблемы SLA:

• Каково разумное SLA набора?

• Как понять причину опоздания?

Это проблемные вопросы, потому что наборы зависят друг от друга и возникают последовательно: сначала одно преобразование, затем другое (рис. 2).

Таким образом, наличие одного набора неразрывно связано с иерархически сложным "происхождением" других наборов. Чтобы установить реалистичное SLA, нужно учитывать дерево зависимостей, которое иногда состоит из 100 сущностей, а также их SLA.

Добавим к этому сложности: когда что-то идёт не так, попытка сопоставить иерархические зависимости со временной последовательностью даёт результат: SLA упущено и ничего не видно. Трудно рассуждать о причинах в такой ситуации. Инструментальная оснастка Airbnb позволила дата-инженерам выявлять проблемы в конвейере одной команды; сделать то же самое на конвейерах нескольких команд экспоненциально сложнее.

Почему набор опоздал?

Ранний дизайн

Чтобы поставщики данных видели зависимости набора и временные рамках этих зависимостей, разработано представление о происхождении набора Lineage.

Информация о происхождении данных это от 10 до 100 таблиц, а каждая таблица это 30 дней исторических данных, а также SLA и связей между ними, поэтому мы нуждались в краткой форме представления, а это от 1,000 до 10,000 отдельных точек данных.

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

Фокус на времени с помощью представления Timeline

Затем мы сместили акцент на последовательности во времени. Чтобы представлять последовательности, мы создали диаграмму Ганта, включающую зависимости (рис. 4) с такой функциональностью:

• Каждая строка представляет набор в смысле происхождения, конечный набор расположен наверху.

• У каждого набора есть горизонтальная полоса, отображающая начало, продолжительность и время окончания задачи обработки данных в пределах выбранных дат или времени.

• Если набор имеет SLA, время обозначается вертикальной линией.

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

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

• Выделенные дуги представляют важнейшие узкие места.

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

Ищем иголку в стоге сена "узкие" места

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

Погружение в историческое представление (Historical)

Итак, узкое место выявлено. Теперь важный вопрос вызвана задержка на этом этапе длительностью самой работы или замедлениями в зависимостях? Ответ на этот вопрос помогает поставщикам данных понять, нужно ли оптимизировать именно их конвейер, или, чтобы сократить время SLA, нужны переговоры с владельцами зависимостей. Чтобы позволить отслеживать причины, мы построили подробное представление выполнения выгрузки набора, показывающее длительность и выполнения, и задержки (рис. 6).

Процесс и оснастка

Почти год мы потратили на разработку концепции, проектирование, создание прототипов и внедрения SLA Tracker в производственную среду. Большая часть этого времени потрачена на разработку API данных в UI и на итерации Lineage.

Чтобы упростить Report, мы использовали статические конструкции и прототипы экранов с хот-спотами (инструмент Clickthrough Prototypes) и универсальные поддельные данные. В альфа- и бета-релизах мы выполняли итерации визуального языка, то есть визуализировали данные так, чтобы их было проще охватить и понять (рис. 8).

Совершенно иначе мы подошли к проектированию Lineage. Его информационная иерархия продиктована формой данных. Таким образом, критично прототипирование на выборках реальных данных. Мы разработали эти прототипы на TypeScript, используя низкоуровневый набор компонентов визуализации visx для React, этот набор позволяет повторно использовать код при внедрении в производственную среду (рис. 9).

После обретения уверенности в нашей визуализации, но до внедрения в производственную среду мы доработали визуальные элементы статических макетов в Figma (рис. 10).

Заключение

В этом проекте мы применили визуализацию данных и UI/UX-дизайн междисциплинарную область, которую называем "Data Experience", в отношении важных проблем своевременности данных, требующих глубокого понимания сложной временной и иерархической информации. Это позволило сделать анализ своевременности данных доступным даже в сложной экосистеме данных крупной компании. Для разработки сложных инструментов визуального анализа требуются время и итерации, но результат работы может принести большую пользу.
Если хотите научиться работать с данными не хуже специалистов из Airbnb то приходите учиться. Будет сложно, но интересно!

Узнайте, как прокачаться в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

К 2020 году вы не могли не заметить, что миром правят данные. И, как только речь заходит о работе с ощутимыми объёмами, появляется необходимость в сложном многоэтапном конвейере обработки данных.

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

В наших приложениях Badoo и Bumble конвейеры принимают информацию из самых разных источников: генерируемых пользователями событий, баз данных и внешних систем. Естественно, без тщательного обслуживания конвейеры становятся хрупкими: выходят из строя, требуют ручного исправления данных или непрерывного наблюдения.

Я поделюсь несколькими простыми правилами, которые помогают нам в работе с преобразованием данных и, надеюсь, помогут и вам.

Правило наименьшего шага

Первое правило сформулировать легко: каждое отдельное взятое преобразование должно быть как можно проще и меньше.

Допустим, данные поступают на машину с POSIX-совместимой операционной системой. Каждая единица данных это JSON-объект, и эти объекты собираются в большие файлы-пакеты, содержащие по одному JSON-объекту на строку. Пускай каждый такой пакет весит около 10 Гб.

Над пакетом надо произвести три преобразования:

1. Проверить ключи и значения каждого объекта.

2. Применить к каждому объекту первую трансформацию (скажем, изменить схему объекта).

3. Применить вторую трансформацию (внести новые данные).

Совершенно естественно всё это делать с помощью единственного скрипта на Python:

python transform.py < /input/batch.json > /output/batch.json

Блок-схема такого конвейера не выглядит сложной:

Проверка объектов в transform.py занимает около 10% времени, первое преобразование 70%, на остальное уходит 20% времени.

Теперь представим, что ваш стартап вырос и вам уже приходится обрабатывать сотни, а то и тысячи пакетов. И тут вы обнаружили, что в финальный этап логики обработки данных (занимающий 20% времени) закралась ошибка, и вам нужно всё выполнить заново.

В такой ситуации рекомендуется собирать конвейеры из как можно более мелких этапов:

python validate.py < /input/batch.json > /tmp/validated.jsonpython transform1.py < /input/batch.json > /tmp/transformed1.jsonpython transform2.py < /input/transformed1.json > /output/batch.json

Блок-схема превращается в симпатичный паровозик:

Выгоды очевидны:

• конкретные преобразования проще понять;

• каждый этап можно протестировать отдельно;

• промежуточные результаты отлично кешируются;

• систему легко дополнить механизмами обработки ошибок;

• преобразования можно использовать и в других конвейерах.

Правило атомарности

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

Давайте вернёмся к первому примеру. Есть входные данные, над которыми мы проводим преобразование:

python transform.py < /input/batch.json > /output/batch.json

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

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

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

В POSIX-совместимых файловых системах всегда есть атомарные операции (скажем, mv или ln), с помощью которых можно имитировать транзакции:

python transform.py < /input/batch.json > /output/batch.json.tmpmv /output/batch.json.tmp /output/batch.json

В этом примере испорченные промежуточные данные окажутся в файле *.tmp, который можно изучить позднее при проведении отладки или просто удалить.

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

Правило идемпотентности

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

Википедия

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

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

python transform.py < /input/batch.json > /output/batch1.jsonpython transform.py < /input/batch.json > /output/batch2.jsondiff /input/batch1.json /output/batch2.json# файлы те жеpython transform.py < /input/batch.json > /output/batch3.jsondiff /input/batch2.json /output/batch3.json# никаких изменений

На входе у нас /input/batch.json, а на выходе /output/batch.json. И вне зависимости от того, сколько раз мы применим преобразование, мы должны получить одни и те же данные:

Так что если только transform.py не зависит от каких-то неявных входных данных, этап transform.py является идемпотентным (своего рода перезапускаемым).

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

Чем важна идемпотентность? В первую очередь это свойство упрощает обслуживание конвейера. Оно позволяет легко перезагружать подмножества данных после изменений в transform.py или входных данных в /input/batch.json. Информация будет идти по тем же маршрутам, попадёт в те же таблицы базы данных, окажется в тех же файлах и т. д.

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

Правило избыточности

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

Пример:

python transform1.py < /input/batch.json > /tmp/batch-1.jsonpython transform2.py < /tmp/batch-1.json > /tmp/batch-2.jsonpython transform3.py < /tmp/batch-2.json > /tmp/batch-3.jsoncp /tmp/batch-3.json /output/batch.json.tmp # не атомарно!mv /output/batch.json.tmp /output/batch.json # атомарно

Сохраняйте сырые (input/batch.json) и промежуточные (/tmp/batch-1.json, /tmp/batch-2.json, /tmp/batch-3.json) данные как можно дольше по меньшей мере до завершения цикла работы конвейера.

Вы скажете мне спасибо, когда аналитики решат поменять алгоритм вычисления какой-то метрики в transform3.py и вам придётся исправлять данные за несколько месяцев.

Другими словами: избыточность избыточных данных ваш лучший избыточный друг.

Заключение

Давайте подведём итоги:

• разбивайте конвейер на изолированные маленькие этапы;

• стремитесь делать этапы атомарными и идемпотентными;

• сохраняйте избыточность данных (в разумных пределах).

Так обрабатываем данные и мы в Badoo и Bumble: они приходят через сотни тщательно подготовленных этапов преобразований, 99% из которых атомарные, небольшие и идемпотентные. Мы можем позволить себе изрядную избыточность, поэтому держим данные в больших холодном и горячем хранилищах, а между отдельными ключевыми преобразованиями имеем и сверхгорячий промежуточный кеш.

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

А у вас есть свои правила обработки данных?

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

Я уверен, что вы уже видели примеры, как с помощью записей превратить обычный POJO ...

class Range {private final int low;private final int high;public Range(int low, int high) {this.low = low;this.high = high;}public int getLow() {return low;}public int getHigh() {return high;}@Overridepublic boolean equals(Object o) {if (this == o)return true;if (o == null || getClass() != o.getClass())return false;Range range = (Range) o;return low == range.low &&high == range.high;}@Overridepublic int hashCode() {return Objects.hash(low, high);}@Overridepublic String toString() {return "[" + low + "; " + high + "]";}}

в одну строчку кода:

//          это компоненты записи (components)record Range (int low, int hight) { }

Конечно, аннотации @Data и @Value из Lombok обеспечивают аналогичную функциональность с давних пор, хоть и с чуть большим количеством строк:

@Dataclass Range {private final int low;private final int high;}

А если вы знакомы с Kotlin, то знаете, что то же самое можно получить, используя data-класс:

data class Range(val low: Int, val high: Int)

Получается, что это одно и то же? Нет. Уменьшение бойлерплейт кода не является целью записей, это следствие их семантики.

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

Семантика записей (records)

В JEP 395 говорится:

Записи (records) это классы, которые действуют как прозрачные носители неизменяемых данных.

Таким образом, создавая запись, вы говорите компилятору, своим коллегам, всему миру, что указанный тип хранит данные. А точнее, иммутабельные (поверхностно) данные с прозрачным доступом. Это основная семантика все остальное вытекает из нее.

Если такая семантика не применима к нужному вам типу, то не используйте записи. А если вы все равно будете их использовать (возможно, соблазнившись отсутствием бойлерплейта или потому что вы думаете, что записи эквивалентны @Data / @Value и data-классам), то только испортите свою архитектуру, и велики шансы, что это обернется против вас. Так что лучше так не делать.

(Извините за резкость, но я должен был это сказать.)

Прозрачность и ограничения

Давайте подробнее поговорим о прозрачности (transparency). По этому поводу у записей есть даже девиз (перефразированный из Project Amber):

API записей моделирует состояние, только состояние и ничего, кроме состояния.

Для реализации этого необходимы ряд ограничений:

• для всех компонент должны быть аксессоры (методы доступа) с именем, совпадающим с именем компонента, и возвращающие такой же тип, как у компонента (иначе API не будет моделировать состояние)

• должен быть конструктор с параметрами, которые соответствуют компонентам записи (так называемый канонический конструктор; иначе API не будет моделировать состояние)

• не должно быть никаких дополнительных полей (иначе API не будет моделировать состояние)

• не должно быть наследования классов (иначе API не будет моделировать состояние, так как некоторые данные могут находиться в другом месте за пределами записи)

И Lombok и data-классы Kotlin позволяют создавать дополнительные поля, а также приватные "компоненты" (в терминах записей Java, а Kotlin называет их параметрами первичного конструктора). Так почему же Java относится к этому так строго? Чтобы ответить на этот вопрос, нам понадобится вспомнить немного математики.

Математика

Множество (set) это набор некоторых элементов. Например, можно сказать, что C это множество всех цветов {синий, золотой, ...}, а N множество всех натуральных чисел {0, 1, ...}. Конечное множество {-2147483648, ..., 0, ..., 2147483647} это то, что в Java мы называем типом int. А если добавить к этому множеству null, то получим Integer. Аналогично бесконечное множество всех возможных строк (плюс null) мы называем String.

Итак, как вы поняли, тип это множество, значения которого допустимы для данного типа. Это также означает, что теория множеств "раздел математики, в котором изучаются общие свойства множеств" (как говорит Википедия), связана с теорией типов "академическим изучением систем типов" (аналогично), на которую опирается проектирование языков программирования.

class Pair {private final int first;private final int second;}

Можно назвать соответствующее множество Pair, и это будет работать. Давайте немного углубимся, так как теперь мы знаем о множествах. В частности, мы видим, что у нас получилось сочетание всех целых чисел со всеми целыми числами. В теории множеств это называется произведением и записывается как int int (каждый тип в произведении называется операндом).

Это здорово, потому что теория множеств может многое сказать о применении функций к произведениям. Одним из аспектов этого является то, как функции, работающие с одним операндом, могут комбинироваться с функциями, работающими с несколькими операндами, и какие свойства функций (инъективные, биективные и т. д.) остаются нетронутыми.

// given: bijective function from int to intIntUnaryOperator increment =i -> i == Integer.MAX_VALUE ? Integer.MIN_VALUE : ++i;// then: combining two `increment`s yields a bijective function//       (this requires no additional proof or consideration)UnaryOperator<Pair> incrementPair =pair -> new Pair(increment.applyAsInt(pair.first()),increment.applyAsInt(pair.second()));

Вы обратили внимание на аксессоры Pair::first и Pair::second? Их не было в классе выше, поэтому их пришлось добавить. Иначе нельзя было бы применить функции к отдельным компонентам / операндам, и использовать Pair в качестве пары целых чисел. Аналогично, но с другой стороны, мне нужен конструктор, принимающий в качестве аргументов оба целых числа, чтобы можно было воспроизвести pair.

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

На самом деле записи лучше кортежей. В JEP 395 говорится:

Записи можно рассматривать как номинативные кортежи.

Где "номинативность" означает, что записи идентифицируются по их именам, а не по их структуре. Таким образом, два типа записей, которые моделируют int int, например, Pair(int first, int second) и Range(int low, int high) будут разными типами. А также обращение к компонентам записи идет не по индексу (range.get1()), а по имени (record.low()).

Следствия

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

Итак, если подытожить:

• Аксессоры (методы доступа) генерируются компилятором.

• Мы не можем изменять их имена или возвращаемый тип.

• Мы должны быть очень осторожны с их переопределением.

• Компилятор генерирует канонический конструктор.

• Наследование отсутствует.

Преимущества записей

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

Деструктурирующие паттерны

if (range instanceof Range(int low, int high) && high < low)    return new Range(high, low);

Благодаря полной прозрачности записей мы можем быть уверены, что не пропустим скрытое состояние. Это означает, что разница между range и возвращаемым экземпляром это именно то, что вы видите: low и high меняются местами не более того.

Блок with

Range range = new Range(5, 10);// SYNTAX IS MADE UP!Range newRange = range with { low = 0; }// range: [5; 10]// newRange: [0; 10]

И, как и раньше, мы можем рассчитывать на то, что newRange будет точно таким же, как и range за исключением low: нет скрытого состояния, которое мы не перенесли. И синтаксически здесь все просто:

• объявить переменные для компонент (например, low, high) и присвоить значения с помощью аксессоров

• выполнить блок with

• передать переменные в канонический конструктор

(Обратите внимание, что этот функционал далек от реальности и может быть не реализован или быть значительно изменен.)

Сериализация

Для представления объекта в виде потока байт, JSON / XML-документа или в виде любого другого внешнего представления и обратной конвертации, требуется механизм разбивки объекта на его значения, а затем сборки этих значений снова вместе. И вы сразу же можете увидеть, как это просто и хорошо работает с записями. Они не только раскрывают все свое состояние и предлагают канонический конструктор, но и делают это структурированным образом, что делает использование Reflection API очень простым.

Более подробно том, как записи изменили сериализацию, слушайте в подкасте Inside Java Podcast, episode 14 (также в Spotify). Если вы предпочитаете короткие тексты, то читайте твит.

Бойлерплейт код

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

• канонический конструктор

• аксессоры (методы доступа)

• отсутствие наследования

Я не сказал об этом явно, но было бы неплохо, если (0, 0) = (0, 0), то есть должна быть правильная реализация equals, которая сразу же требует реализации hashCode.

И все это генерируется компилятором (а также еще toString) не столько для того, чтобы избавить нас от написания этого кода, сколько потому, что это естественное следствие алгебраической структуры.

Недостатки записей

Семантика записей ограничивает возможности по работе с классами. Как уже говорилось, вы не можете добавлять скрытое состояние через добавление полей, не можете переименовывать аксессоры и изменять тип возвращаемого значения и, вероятно, не должны менять возвращаемое ими значение. Записи также не позволяют изменять значения компонент, так как соответствующие им поля объявлены final. И отсутствует наследование классов (хотя вы можете реализовать интерфейсы).

Так что же делать, если вам все это нужно? Тогда записи вам не подходят и вместо них следует использовать обычный класс. Даже если изменив только 10% функциональности, вы получите 90% бойлерплейта, от которого вы бы избавились с помощью записей.

Преимущества Lombok @Data/@Value

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

(При этом я не рекламирую Lombok. Он в значительной степени полагается на внутренние API компилятора, которые могут измениться в любой момент, а это означает, что проекты, использующие его, могут сломаться при любом незначительном обновлении Java. То, что он много делает для скрытия технического долга от своих пользователей, тоже не очень хорошо.)

Преимущества data-классов Kotlin

Вот что говорится в документации о data-классах:

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

Вы можете видеть, что здесь также присутствует семантика хранения данных, но она довольно слабая, и основное внимание уделяется получению функциональности, то есть генерации кода. Действительно, data-классы предлагают больше возможностей по работе с классами, чем записи (мутабельные "компоненты", скрытое состояние, ...), но в отличие от Lombok не все (не могут расширяться, нельзя создавать свой метод copy, ...). С другой стороны, data-классы не дают сильных гарантий как записи, поэтому Kotlin не может построить на их основе аналогичную функциональность. Это разные подходы с разной ценой и выгодой.

Некоторые указывали на @JvmRecord в Kotlin как на большую ошибку: "Видите, data-классы могут быть записями шах и мат ответ" (я перефразировал, но смысл был такой). Если у вас возникли такие же мысли, то я прошу вас остановиться и подумать на секунду. Что именно это дает вам?

Data-класс должен соблюдать все правила записи, а это значит, что он не может делать больше, чем запись. Но Kotlin все еще не понимает концепции прозрачных кортежей и не может сделать с @JvmRecord data-классом больше, чем с обычным data-классом. Таким образом, у вас есть свобода записей и гарантии data-классов данных худшее из обоих миров.

Для чего тогда нужен @JvmRecord? Просто для совместимости. Как говорится в proposal:

В Kotlin нет большого смысла использовать JVM-записи, за исключением двух случаев:

• перенос существующей Java-записи на Kotlin с сохранением ее ABI;

• генерация атрибута класса записи с информацией о компоненте записи для класса Kotlin для последующего чтения каким-либо фреймворком, использующим Java reflection для анализа записей.

Рефлексия

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

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

В преддверии старта курса "Java Developer. Professional" приглашаю всех желающих на бесплатный демоурок по теме: Система получения курсов валют ЦБ РФ.

• ЗАПИСАТЬСЯ НА ДЕМОУРОК. День 1

• ЗАПИСАТЬСЯ НА ДЕМОУРОК. День 2

Данные это один из наиболее важных компонентов геопространственных технологий и, пожалуй, любой другой отрасли. К управлению данными сейчас относятся серьезно во всех отраслях, поэтому знания по этой дисциплине имеют важное значение для карьеры ИТ-специалистов. Этот цикл статей задуман как универсальное руководство, в котором мы рассмотрим тему от и до, начиная с вопроса Что такое данные? и заканчивая изучением и применением геопространственных запросов.

Основные понятия баз данных

Что такое данные?

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

Что такое база данных?

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

Зачем нужна база данных?

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

Система управления базами данных (СУБД)

Итак, мы уже знаем, что данные и базы данных важны, но как осуществляется работа с базами данных в компьютерных системах? Вот тут на сцену и выходит СУБД. СУБД это программное обеспечение, предоставляющее нам способ взаимодействия с базами данных на компьютере для выполнения различных операций, таких как создание, редактирование, вставка данных и т.д. Для этого СУБД предоставляет нам соответствующие API. Редко какие программы не используют СУБД для работы с данными, хранящимися на диске.Помимо операций с данными СУБД также берет на себя резервное копирование, проверку допуска, проверку состояния базы данных и т.д. Поэтому рекомендуется всегда использовать СУБД при работе с базами данных.

Пространственные данные и база данных

Особое внимание мы уделим обработке пространственных данных, поэтому я хотел бы обсудить здесь этот тип данных. Пространственные данные несколько отличаются от остальных. Координаты необходимо сохранять в особом формате, который обычно указан в документации на веб-сайте о базе данных. Этот формат позволяет базе считывать и правильно воспринимать координаты. Если обычно для поиска данных мы используем запросы типа Получить все результаты, где возраст>15, то пространственный запрос выглядит как-то так: Получить все результаты в радиусе 10км от определенной точки.Поэтому пространственные данные необходимо хранить в надлежащем формате.

Типы баз данных

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

Реляционные базы данных и РСУБД

Допустим, ваш начальник просит вас создать электронную таблицу с важной информацией, включающей имена, местонахождения, адреса электронной почты, номера телефонов и должности всех сотрудников. Вы сразу же откроете таблицу Excel или Google Spreadsheets, напишете все эти названия столбцов и начнете собирать информацию.

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

Взаимосвязи в реляционных базах данных мы подробно рассмотрим позже.

По сравнению с базами данных NoSQL, недостатком реляционных баз данных является относительно медленное получение результатов, когда количество данных стремительно увеличивается (по мнению автора статьи прим. пер.). Еще один недостаток заключается в том, что при добавлении каждой записи нужно следовать определенным правилам (типы столбцов, количество столбцов и т.д.), мы не можем просто добавить отдельный столбец только для одной записи.В реляционных базах данных используется SQL(Structured Query Language язык структурированных запросов), с помощью которого пользователи могут взаимодействовать с данными, хранящимися в таблицах. SQL стал одним из наиболее широко используемых языков для этой цели. Мы подробнее поговорим об SQL чуть позже.Вот примеры некоторых известных и часто используемых реляционных баз данных: PostgreSQL, MySQL, MSSQL и т.д. У каждой крупной компании, занимающейся реляционными базами данных, есть собственная версия SQL. В большинстве аспектов они выглядят одинаково, но иногда требуется немного изменить какой-нибудь запрос, чтобы получить те же результаты в другой базе данных (например, при переходе из PostgreSQL в MySQL).

Нереляционные базы данных (NoSQL)

Все базы данных, не являющиеся реляционными, относятся к категории нереляционных баз данных. Обычно данные хранятся в нетабличном формате, например:

1. Пара ключ-значение

2. Формат JSON, XML

3. Графовый формат

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

База данных NoSQL реального времени в Google Firebase

При использовании баз данных NoSQL пользователям иногда приходится прописывать собственную логику, чтобы добавить уникальный ключ к каждой записи и тем самым обеспечить доступ к записям. В большинстве стандартных баз данных NoSQL, таких как Firebase и MongoDB, для хранения данных используется формат JSON. Благодаря этому очень легко и удобно выполнять операции с данными из веб-приложений, используя JavaScript, Python, Ruby и т.д.

Рекомендации по выбору типа базы для хранения пространственных данных

Очевидно, что нам хотелось бы сохранить точку, линию, многоугольник, растры и т.д. так, чтобы это имело смысл, вместо того чтобы сохранять просто координаты. Нам нужна СУБД, которая позволяет не только сохранять данные, но и запрашивать их пространственными методами (буфер, пересечение, вычисление расстояния и т.д.). На сегодняшний день для этого лучше всего подходят реляционные базы данных, поскольку в SQL есть функции, помогающие выполнять подобные операции. Использование таких дополнительных средств, как PostGIS для PostgreSQL, открывает разработчикам возможности для написания сложных пространственных запросов. С другой стороны, NoSQL тоже работает в области геопространственных технологий: например, MongoDB предоставляет кое-какие функции для выполнения геопространственных операций. Однако реляционные базы данных все же лидируют на рынке с большим отрывом.

Работа с РСУБД

Основное внимание мы уделим РСУБД, так как именно эти системы в большинстве случаев мы будем использовать для хранения пространственных данных и работы с ними. В качестве примера мы будем использовать PostgreSQL, поскольку это самая перспективная реляционная база данных с открытым исходным кодом, а ее расширение PostGIS позволяет работать и с пространственными данными. Вы можете установить PostgreSQL, следуя инструкциям из документации. Помимо PostgreSQL рекомендуется также загрузить и установить pgAdmin. Платформа pgAdmin предоставляет веб-интерфейс для взаимодействия с базой данных. Также для этого можно загрузить и установить какое-либо другое совместимое ПО или использовать командную строку.

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

Создание базы данных. Нам нужно создать базу данных (в идеале должно быть по одной базе данных для каждого проекта).

В инструменте запросов (Query Tool) база данных создается следующим образом:

CREATE DATABASE <database_name>

Создание таблиц. Создание таблицы требует некоторых дополнительных соображений, поскольку именно здесь нам нужно определить все столбцы и типы данных в них. Все типы данных, которые можно использовать в PostgreSQL, вы найдете здесь.

pgAdmin позволяет нам выбрать в таблице различные ключи и ограничения, например Not Null (запрет на отсутствующие значения), Primary Key (первичный ключ) и т.д. Обсудим это подробнее чуть позже.

Заметьте, что мы не добавляли столбец первичного идентификатора в список столбцов, поскольку PostgreSQL делает это автоматически. Мы можем создать сколько угодно таблиц в одной базе данных. После того как таблицы созданы, мы можем установить связи между разными таблицами, используя определенные столбцы (обычно столбцы с идентификаторами).В инструменте запросов таблица создается следующим образом:

CREATE TABLE <table_name> (<column_1> <datatype>,<column_2> <datatype>,.....<column_n> <datatype>PRIMARY KEY (<column>));

CRUD-операции с данными в таблицах

CRUD-операции (создание, чтение, обновление и удаление Create, Retrieve, Update, Delete) это своего рода hello world в мире СУБД. Поскольку эти операции используются наиболее часто, команды для их выполнения одинаковы во всех РСУБД. Мы будем писать и выполнять запросы в инструменте запросов в pgAdmin, который вызывается следующим образом:

1. Создание новой записи

Для добавления новой записи в таблицу используйте следующую команду:

INSERT INTO <tablename> (column1, column2, column3,...) VALUES (value1, value2, value3,...);

INSERT, INTO, VALUE являются ключевыми словами в SQL, поэтому их нельзя использовать в качестве переменных, значений и т.д. Чтобы добавить новую запись в нашу таблицу пользователей, мы напишем в инструменте запросов следующий запрос:

INSERT INTO users(name, employed, address) VALUES ('Sheldon Cooper', true, 'Pasadena');

Обратите внимание: строки всегда следует заключать в'' (одинарные кавычки), а не в"" (двойные кавычки).

2. Получение записей (всех или нескольких)

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

select <column1, column2 ,...> from <tablename> 

Этот код извлекает весь набор данных. Если вы хотите получить только 20записей, напишите:

select <column1, column2 ,...> from <tablename> limit 20

Если вы хотите получить данные из всех столбцов, то вместо перечисления названий всех столбцов можно написать:

select * from <tablename>

Если вы хотите получить результат с определенным условием, используйте ключевое слово WHERE, как показано ниже:

select * from <tablename> where <key> = <value>

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

--Retrieving Specific columns for all usersselect name,employed from users--Retrieving all columns for all usersselect * from users--Retrieving all columns for first 3 usersselect * from users limit 3--Retrieving all columns for all users where employed = trueselect * from users where employed = true

3. Обновление записей (всех или нескольких)РСУБД позволяет нам обновить все или только некоторые записи данных, указав новые значения для столбцов.

UPDATE <tablename> SET <column1> = <value1>, <column2> = <value2> 

Если вы хотите обновить определенные строки, добавьте условия с использованием ключевого слова WHERE:

UPDATE <tablename> SET <column1> = <value1>, <column2> = <value2>WHERE <column> = <value> 

В нашем случае мы обновим таблицы с помощью следующих запросов:

-- Make all rows as  employed = trueupdate users set employed = true-- change employed = false for entries with address = 'nebraska'update users set employed = false where address = 'nebraska'

4. Удаление записей (всех или нескольких)Удалять записи в SQL легко. Пользователь может удалить либо все строки, либо только определенные строки, добавив условие WHERE.

-- Deleting all entries Delete from <tablename> -- Deleting entries based on conditionsDelete from <tablename> where <column> = <value> 

-- Deleting all entries Delete from users-- Deleting entries based on conditionsDelete from users where employed = false

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

Перевод подготовлен в рамках курса Базы данных. Все желающих приглашаем на бесплатный двухдневный онлайн-интенсив Бэкапы и репликация PostgreSQL. Практика применения. Цели занятия: настроить бэкапы; восстановить информацию после сбоя. Регистрация здесь.

Как быть уверенным в своих рабочих процессах, конвейер за конвейером

В преддверии старта онлайн-курса "Data Engineer" подготовили перевод материала.

Если вы начинающий дата-инженер, вот несколько важных технологий и фреймворков, которые вам следует знать. Построить конвейер данных? Легко. Очистить, преобразовать и смоделировать ваши данные? Легко. Предотвратить нарушение рабочих процессов до того, как вы получите неприятный звонок от генерального директора по поводу ее недостающих данных? Ну, может не так легко.

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

Джесси Андерсон, управляющий директор Big Data Institute и автор книги Команды инженерии данных: создание успешных Big Data команд и продуктов, и Барр Мозес, соучредитель и генеральный директор Monte Carlo, делятся всем, что вам нужно знать, чтобы начать работу на этом новом уровне стека данных.

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

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

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

Slack в середине встречи от лида по маркетингу: рентабельность инвестиций в мою кампанию в этом месяце невысока. Я думаю, что что-то не так с данными атрибуции.

Сообщение, которое вы никогда не получите: данные в этом отчете идеальны. Так держать!

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

Один из способов выбраться из это порочного круга ночных писем - наблюдаемость данных (Data Observability).

#1. Что такое наблюдаемость данных и почему это важно

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

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

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

#2. Как DevOps заложил наблюдаемость данных

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

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

Следуя структуре наблюдаемости в разработке приложений, наблюдаемость данных разбита на пять столпов: свежесть, распределение, объем, схема и происхождение.

• Свежесть (Freshness) показывает, насколько актуальны ваши таблицы данных.

• Распределение (Distribution) сообщает вам, попадают ли ваши данные в ожидаемый диапазон.

• Объем (Volume ) предполагает понимание полноты ваших таблиц данных и состояния ваших источников данных.

• Схема (Schema) позволяет понять, кто и когда вносит изменения в таблицы данных.

• Происхождение (Lineage) сопоставляет вышестоящие источники и нижележащие приемники ваших данных, помогая определить, где произошли ошибки или сбои.

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

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

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

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

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

#4. Наблюдаемость данных - это больше, чем просто тщательное тестирование и мониторинг

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

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

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

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

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

#5. Когда дело доходит до ваших данных, иметь в основном плохие данные хуже, чем их вообще не иметь

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

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

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

- Узнать подробнее о курсе "Data Engineer"

Привет, Хабр! Сегодня поговорим о том, как нейронные сети могут помочь в распознавании деталей и зачем это вообще нужно. Недавно к нам обратился один из наших клиентов - крупная промышленная компания, производитель грузовых автомобилей и их комплектующих. Детали насчитывали большое количество возможных наименований. Из-за этого при визуальном распознавании сотрудники совершали ошибки. Решили создать приложение на основе компьютерного зрения и нейронных сетей. С его помощью стали проверять правильный ли выбор сделал рабочий (рис 1). Так же дополнительно было необходимо сверять наименование распознанной детали с наименованием, указанным в накладной на заказ.

Данные

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

Выбор модели

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

Использовать только ограничивающие рамки (Bounding Box) было бы недостаточно (Object detection). Они могли сильно перекрывать друг друга при разметки, обучении и распознавании, поэтому для обучения решили выбрать одну из моделей, с поддержкой метода сегментации изображения (Image segmentation) . (Рис. 2)

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

В нашем случае разметка объектов на изображении выполнялась вручную на стороннем облачном сервисе. Он предоставлял возможность нескольким сотрудникам размечать один и тот же набор данных удаленно и после завершения разметки скачивать весь набор данных. (Рис. 3, 4, 5, 6)

После разметки достаточного количества фотографий для экспериментов проводилось обучение первых моделей для распознавания деталей на сервере HPE DL380 c двумя видеокартами NVIDIA Tesla v100. В среднем, на обучение первых моделей было затрачено от 8 до 12 часов.

По результатам обучения, были выявлены проблемы, которые препятствовали распознаванию:

1. На фотографиях некоторых деталей были обнаружены лики, (объекты, не являющиеся частью деталей, но на которые модель обращает внимание при определении класса). Это способствовало неверному обучению сети.

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

Что делать с ликами?

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

На фотографиях ниже (рис. 7 и 8) приведен пример ликов. На первой серии фотографий изображены детали первого класса при ярком освещении. На второй - детали второго класса при более темном освещении. На таком наборе данных при определении класса модель будет обращать внимание на фон и освещение. Это будет происходить, так как части изображения у первого и второго классов различны. Стоит заметить, что такая работа модели является некорректной: необходимо стремиться, чтобы при классификации модель опиралась на структуру деталей.

Что делать с зеркальными деталями?

Чтобы решить проблему с распознаванием зеркальных деталей, мы решили использовать ансамбль моделей. Первая модель классифицировала детали на зеркальные и незеркальные, причем каждая симметричная деталь распознавалась как два объекта. Далее зеркальные детали отправлялись в следующие модели, которые были обучены для распознавания только зеркальных деталей. То есть под каждую пару зеркальных деталей была создана своя модель, которая классифицировала деталь как левую или правую (рис. 9).

Как создать модель для разметки

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

Разметка такого большого количества фотографий потребовала бы много времени. Кроме того, 4000 фотографий использовалось в одной модели, распознающей зеркальные детали, а всего таких моделей было много: для каждой зеркальной детали уникальная. Решили сделать модель, которая выделяет маски и сохраняет их в необходимом виде. Вручную разметили 120 фотографий каждого класса, и на них обучили модель. После того как были размечены детали, неточная разметка была подкорректирована вручную. Такой подход сократил временные затраты и избавил от необходимости размечать большое количество изображений с нуля.

После этого модели для распознавания были обучены и подобраны параметры. (Рис. 10, 11).

Распознавание бирок и накладных

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

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

Для удобного развёртывания моделей весь backend был перенесен на SAP Data Intelligence.

Интерфейс и SAP Data intelligence

SAP Data Intelligence позволяет не только публиковать и встраивать модели, но и создавать на их базе новые собственные операторы (например, от python оператора). Это помогает переиспользовать существующие модели и встраивать их в необходимых форматах (батч-обработка, стриминг, или публикация REST-сервисов). Кроме этого, основанный на flow-based подходе пайплайн может быть быстро адаптирован под меняющиеся условия. Например, если в будущем потребуется интеграция с ERP / MES или любой другой системой, это будет сделать довольно просто. Также все получаемые фотографии можно собирать в используемое Озеро Данных для дообучения модели и улучшения качества распознавания. Если потребуется масштабировать данный сервис, это будет сделать легко. Достаточно настроить уровень параллелизма (параметр multiplicity) и под модель будет поднято соответствующее количество реплик на уровне kubernetes. Есть встроенные инструменты для отладки пайплайна, логирования, трассировки, мониторинга.

Кстати, нужно пару слов сказать о том, на какой платформе собирался данный проект. Так как система в будущем должна пойти в промышленную эксплуатацию, желательно использовать оборудование промышленного класса надежности. Компания Cisco предоставила для пилота гиперконвергентную систему Cisco Hyperflex, про которую ранее на Хабре уже писали здесь, здесь и здесь .

Так как SAP Data Intelligence полностью построен на контейнерах, важно, чтобы были решены задачи отказоустойчивости кластера Kubernetes и его интеграция с сетями центра обработки данных, в котором будет развернуто решение. Фактически, мы полностью повторили в лаборатории типовой валидированный дизайн Cisco&SAP, описанный здесь и голова за инфраструктуру у нас больше не болела.

В SAP Data Intelligence был создан контейнер со всеми необходимыми библиотеками. Для публикации сервиса использовался стандартный оператор OpenAPI. Весь backend работал в контейнере на сервере. Пайплайн можно было так же запускать на любом другом сервере Data Intelligence (рис. 12).

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

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

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

Сегодня мы рассказали вам о создании приложения по распознаванию деталей с помощью нейронных сетей. Остался ли производитель грузовых автомобилей и комплектующих доволен? Думаю, да. Ведь приложение позволило значительно сократить ошибки, которые допускали сотрудники при самостоятельном распознавании деталей. Вообще, за последние несколько лет на основе нейронных сетей было создано большое количество моделей и систем для применения прогнозирования или оценки каких-либо параметров: состояние предприятия, вероятность поломки оборудования, оценка и предсказание доходов и расходов. Но нейронные сети с распознаванием изображений распространены не так сильно, так как не многие предприятия знают, как можно внедрить эту технологию в свои процессы с пользой для компании. И этот пример отлично иллюстрирует, что не зависимо от задачи, зная слабые и сильные стороны нейронных сетей, можно добиться прироста в эффективности, увеличить автоматизацию всего предприятия, а также уменьшить нагрузку на персонал.

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

НО изначально необходимо очертить проблему, которую можно решить при помощи этого сервиса.

Проблема генерации тестовых данных

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

Почему "минимально возможных"? Потому что тут вспоминаются "Классы эквивалентности", которые сокращают количество тестовых данных от бесконечности до полезного набора.

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

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

Функциональность идеального сервиса генерации данных

Идеальный сервис по генерации тестовых данных должен иметь возможность:

• генерировать данные в разных форматах (JSON, XML, CSV и т.д.)

• генерировать данные с зависимостями (parent, child)

• генерировать сложные зависиммые данные (if a then 1 or 2 else 3 or 5)

• генерировать большие обьемы данный за небольшой промежуток времени

Хотелось бы иметь возможность:

• загрузки данные в прямо в БД

• интерграции в CI/CD

• создавать модель данных автоматом из схем

GenRocket университет

Сервис GenRocket предоставяет тренинг-университет, пройдя который вы ознакомитесь с основным базовым функционалом, установкой и настройкой.

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

GenRocket сервис

GenRocket - это сервис для генерации данных, созданный в 2011 году Hycel Taylor и Garth Rose для решения проблемы создания реалистичных тестовых данных для любой модели данных. Сервис обладает функциональностью генерировать данные для автоматического тестирования, для тестирования нагрузки, тестирования безопасности и др.

Сервис состоит из двух частей: web часть и программная cli часть. В web части происходит создание сценария-инструкции для генерации данных, в программной cli части на самой машине происходит генерация данных.

Что бы начать работу с GenRocket пользователь должен быть авторизирован, затем что бы начать работу с GenRocket необходимо скачать архив для Runtime* для cli части, распаковать его и прописать в системных переменных путь к папке с GenRocket в переменную GEN_ROCKET_HOME и в переменно PATH прописать %GEN_ROCKET_HOME%\bin значение.

Затем открываем командную строку, набираем genrocket и видим картинку ниже.

GenRocket cli часть работает в двух режимах on-line и off-line, но для работы с off-line надо скачать сертификат, который будет валиден только 24 часа.

GenRocket домен и его атрибуты

Первые два из основных компонентов - это Домен и Атрибуты домена. Домен - это существительное, например, пользователь: адрес, кредитная карта и т.д. Каждый домен описывается атрибутами, например: имя, фамилия, e-mail, пароль и день рождения. На картинке ниже вы видите домент User (1), описанный атрибутами (2) и пример сгенерированных данных (3).

Атрибуты к домену могут добавляться вручную по одному (2), с помощью блокнота или импортируя DDL, CSV, JSON или другие форматы. Если мы говорим о табличных данных, то можно сказать, что домен - это таблица, а атрибуты - это клонки этой таблицы.

GenRocket генераторы

Следующий компонент - генератор (generator) - это функциональность, которая непосредственно отвечает за генерацию данных в различных форматах. Генераторов в GenRocket 150+ для различных типов данных. Например:

Каждому атрибуту домена GenRocket назначает свой генератор, опираясь на имя атрибута, автоматом. Например, для атрибута, который содержит слово Name, будет подобран генератор NameGen, а для атрибута с SSN будет подобран генератор SSNGen.

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

GenRocket получатель (receiver)

Следующий компонент - получатель (receiver) - это функциональность, которая отвечает за выгрузку данных в необходимом формате: XML, JSON, SQL, CSV, JDBC, REST, SOAP. В GenRocket 35+ подобных получателелей.

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

GenRocket сценарий (scenarios)

Следующий компонент - сценарий (scenarios) - это набор инструкций, которые определяют сколько и в каком порядке будут созданы данные. Сценарии бывают одиночные (2) и сценарии-цепочки (1), которые позволяют генерировать данные для несколько связанных доменов одновременно. За количество данных отвечает переменная loopCount в настройках домена. Причем у каждого домена значение этой переменной устаналивается отдельно, что позволяет генерировать разное количество данных для каждого домена в сценариях-цепочках.

Сценарий выгружается в виде grs файла (3) и должен быть исполнен на машине, где был установлен GenRocket. Открываем командную строку и выполняем сценарий при помощи команды genrocket -r UserInsertScenario.grs.

При выполнении сценария видим результат, в котором отображатеся время генерации данных. На изображении ниже 10 тыс записей были вставлены в таблицу за 26 сек:

Применение GenRocket на реальном проекте

Возьмем небольшую схему данных, в которой есть таблицы user, grantHistory и notificationSetting.

Используя импорт DDL создадим домен для user.

create table `user` ( id int(10) not null auto_increment,  external_id varchar(50) not null unique,  first_name varchar(25) not null,  last_name varchar(25) not null,  middle_initial char(1),  username varchar(100) not null,  ssn varchar(15) not null,  password varchar(255) not null,  activation_date date,  primary key (id));

После создания доменов GenRocket подбирает подходящие генераторы для каждого атрибута. При необходимости настраиваем специфичные генераторы или модифицируем существующие. Например, изменяем generationType на random и сохраняем изменения.

Аналогичные действия проделываем для grant_history и notification_setting. Сгенерированные данные будут сохраняться в базу данных, для которой настроено JBDC соединение.

driver=org.h2.Driveruser=sapassword=saurl=jdbc:h2:file:~/lms_course/lms_alpha;AUTO_SERVER=TRUE;batchCount=1000

И так же для этой базы настраивается специфичные получатели H2InsertV2Receiver для вставки и SQLUpdateV2Receiver для модификации.

После всех манипуляций с настройками получаем файлы сценарии InsertScenarioChain.grs для вставки и UpdateScenarioChain.grs для модификации, после выполнения которых получаем картинку ниже.

И вуаля, данные в таблицах:

Заключение

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

• бесплатный сервис, ограниченный в количестве генерируемых данных для несложных моделей данных

• платный сервис с неограниченным количеством генерируемых данных и подходящие для сложных моделей данных, который может предоставляет ограниченный бесплатный функционал

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

Ниже расценка на доступ для GenRocket

Для сравнения я приготовила несколько ссылок бесплатных сервисов:

https://www.datprof.com/solutions/test-data-generation/ - только 14 дней бесплатного использования, похоже что цена договорная

http://generatedata.com/ - бесплатно, но возможна генерация только 100 записей

https://www.mockaroo.com/ - бесплатна возможна генерация только 1000 записей, остальное платно - для самого дорогого доступа $5000/year