![](https://webcf.waybackmachine.org/web/20211118182435im_/https://habrastorage.org/getpro/habr/upload_files/550/82f/5ca/55082f5cab6c63fd3356314ef0764fce.png)
Простая задача из экзамена по SQL в университете оказалась сложной. Нужно было всего лишь сгенерировать месяц, который указывает пользователь. Вывести день, год и день недели. Что может пойти не так? Давайте разбираться.
Формальный непроцедурный язык программирования
Простая задача из экзамена по SQL в университете оказалась сложной. Нужно было всего лишь сгенерировать месяц, который указывает пользователь. Вывести день, год и день недели. Что может пойти не так? Давайте разбираться.
Правила игры очень просты: надо построить цепочку слов от начального (МУХА) до конечного (СЛОН), на каждом шаге меняя только одну букву. При этом могут использоваться только русские 4-буквенные нарицательные существительные в начальной форме: например, слова БАЗА, НОЧЬ, САНИ допускаются, а слова ЛИТЬ, ХОТЯ, РУКУ, НОЧИ, САНЯ, ОСЛО, АБВГ, ФЦНМ — нет.
Эта игра под названием «Дублеты» приобрела известность благодаря Льюису Кэрроллу — не только автору книг про Алису, но ещё и замечательному математику. В марте 1879 года он начал раз в неделю публиковать в журнале «Ярмарка тщеславия» по три задания в форме броских фраз: «Turn POOR into RICH» — «Преврати бедного в богатого», «Evolve MAN from APE» — «Выведи человека из обезьяны», «Make TEA HOT» — «Сделай чай горячим». В том же году он выпустил брошюру «Дублеты», подробно описал в ней правила и предложил читателям попрактиковаться на нескольких десятках примеров.
Александр Пиперски, "Из мухи — слона", «Квантик» №2, 2019 и №3, 2019
Сегодня мы научимся реализовывать на SQL волновой алгоритм, решив заодно классический пример из этой игры для конкретного словаря.
Всё началось с использования ML в BigQuery — оказалось это совсем не больно, и очень эффективно.
Мы в GFN.RU используем модель K-Means для поиска аномалий в работе сервиса. Ведь невозможно кожаному мешку смотреть десятки графиков по тысячам игр ежедневно. Пусть электрический болван подсказывает куда нужно глянуть.
Как добиться необходимого контроля, удобства и даже скорости при подготовке тестовых данных для микросервисов и тестов производительности? В каких случаях лучше не генерировать XML и JSON файлы с помощью конкатенации строк? Зачем анализировать статистику по SQL запросам?
Меня зовут Вячеслав Смирнов, и я ускоряю дистанционное банковское обслуживание юридических лиц, а еще поддерживаю чат QA — Load & Performance в Телеграм, где сообщество инженеров по тестированию производительности обсуждает тестирование нагрузки.
Статья получилась длинной, поэтому сегодня я расскажу про подготовку тестовых данных для тестирования производительности и про то, как с помощью SQL, Pandas и Java эти данные готовить. Поговорим про анализ метрик и логов с точки зрения данных и с использованием InfluxDB, Grafana и прочих инструментов, А ещё о том, как может выглядеть хороший отчет по системе, в которой много данных. В следующих частях перейду к генерации и анализу тестовых данных для нагрузки.
Мы уже больше года публикуем в своих соцсетях интересные задачки по программированию, Data Science, аналитике и другим темам. За все это время мы неоднократно сталкивались с такими мыслями, когда планировали очередную задачу:
Ну нет, это слишком легко и очевидно, люди от нас просто отпишутся за такие плевые задачи.
Однако, все оказалось иначе.
Мы собрали для Вас 10 интересных мини-задачек по Python и SQL, которые кажутся очень простыми, но большинство опрошенных (около 76%) дали неправильные ответы. Вот такая вот суровая статистика ¯\_(ツ)_/¯
Проверьте - а сколько задачек Вы решите правильно?
Замечание. Вся трилогия (часть 1 тут, часть 2 тут) о велосипедостроении с sqlite, xml, csv только для совсем маленьких Питоньих кодеров. Не для крутых кодеров, они умрут от скуки в нашем опусе и ничего нового не увидят. В третьей части заканчиваем все, что начали ранее.
Начинаем изыски причины и местонахождения ошибки.
Итак: правильный ответ: ошибки в коде нет. Ну точнее ошибка возникает при работе кода из-за ошибки данных в файлах.
Чтобы убедиться, что это так, добавим в код обработку исключений.
Совсем немного поправим наш код, добавим обработку и вывод на печать исключений:
В мае 2021 года меня похитили инопланетяне и приказали разработать сервис аналитики данных, в простонародье именуемый “self-service BI (business intelligence)”. И не просто какой-то аналог Redash или Superset в масштабе 1:43, а с нормальной поддержкой загрузки данных из файлов (локальных и через веб), ну и, конечно, с коннекторами к популярным базам данным. Например, чтобы можно было импортировать содержимое файлов json, xml или логов, а потом сджойнить их с выгрузкой из clickhouse. И ещё чтобы графики рисовались. Дашборды тоже было бы неплохо, но можно и без них.
Вот что они мне нарисовали в качестве ТЗ:
Как сейчас помню, понедельник 25е октября, я заступаю на дежурство по проду и с самого утра мне прилетает задача: сегодня в ночь с 24 на 25 ноября, наблюдалась проблема с недоступностью приложения. Глянув сентри я увидел кучу ошибок от базы со statement timeout, а так же непонятные ActiveRecord::ConnectionNotEstablished: No connection pool with 'primary' found
С мыслью "база не отвечала, проблема не на нашей стороне" я спокойно отдал задачу на разбирательство админам, а сам параллельно глянул графики, может там был всплеск каких-нибудь джобок или запросов, но ничего криминального в графане небыло: тяжеловесных джобок в 12 не запускается, а те, что запускаются отработали очень быстро.
В мире IT есть много разных концепций и подходов, которые облегчают процесс разработки, расширения архитектуры и создания прочных продуктов. KISS, DRY, SOLID и прочие умные слова - это то, что должен знать программист для того, чтобы считаться как минимум неплохим. Но в данном посте будет затронута и без того известная тема - все эти подходы это рекомендации, а не безукоризненный закон.
Понедельник, 9 утра, сообщение в рабочем чате: "Всё сломалось, почините". Согласитесь, неприятная ситуация, особенно когда это ваш первый месяц работы, а сломалось что-то в функционале, с которым вы ещё ни разу не контактировали, да и не трогал его уже никто месяцами.
Привет, Хабр! Меня зовут Азат Якупов, я работаю Data Architect в компании Quadcode. Сегодня хочу поговорить о реляционных СУБД, которые играют важную роль в современном IT-мире. О том, что они собой представляют и для чего нужны, понимают, вероятно, большинство читателей.
Но вот как и почему появились реляционные СУБД? Об этом многие из нас знают лишь приблизительно. А ведь история создания технологии весьма интересна, она позволяет лучше понять основу цифрового мира. Если вам интересна эта тема — прошу под кат.
В статье будет рассмотрен процесс экспорта данных в Hadoop из различных РСУБД посредством фреймворка Spark. Для взаимодействия с фреймворком Spark будет использован язык программирования Python с применением api pySpark.
Примечание. Как и первая часть эта тоже для совсем маленьких кодеров-велосипедостроителей на Питоне. Для прожженных кодеров будет скучно. Изначально хотели внести исправления сразу в первую статью по мере нахождения ошибок, но после некоторого раздумия решили, что это неудобно. Ошибки исчезнут совсем, а именно ошибки приносят максимальную пользу для начинающего кодера. А посему ошибки оставляем в первой части, а в этой начинаем от них избавляться.
Меня зовут Елизавета Добрянская и я Frontend-разработчица в компании Домклик.
В этой статье я хочу рассказать, как мы танцевали с бубном при настройке алертов на клиентские метрики. Как, зачем и с чем мы столкнулись в этой задаче - читайте далее 🙂
Чтобы разработать свой распределенный SQL-движок, можно написать свой SQL-оптимизатор для построения движков. Вам придется сделать парсер, семантический анализатор и придумать правила трансформации и оптимизации. Всё протестировать, а потом как-то интегрировать в свою систему. Но можно пойти более быстрым путем — внедрить для этого готовый инструмент.
Владимир Озеров, бывший инженер Hazelcast, а сейчас руководитель Querify Labs, на конференции HighLoad++ 2021 поделился опытом разработки и проектирования с нуля распределенного SQL-движка для продукта Hazelcast IMDG. Видео его выступления можно посмотреть здесь.
Сегодня статья о том, для чего в Hazelcast IMDG понадобилась эта разработка, и в чем преимущества и недостатки фреймворка Apache Calсite. Как на нем были реализованы встроенные оптимизации, выбор вторичных индексов и планирование перемещения данных в кластере. И как справились с описанием запросов произвольной сложности, кооперативной многозадачностью и оптимизированием сетевого протокола.
Привет, Хабр! Меня зовут Сергей Барановский, я руководитель проектов по аналитике в Блоке по клиентскому опыту и сервису и сегодня я хочу поделиться наболевшим. Джойн таблиц — одна из самых базовых вещей в аналитике. Казалось бы, допустить здесь ошибку почти невозможно. И правда! Что может быть проще, чем стыковать таблицы ключ к ключу?! Ковыряться в носу и то сложнее — можно ненароком кровеносный сосуд задеть. И, потеряв бдительность из-за простоты процедуры, можно набрать корзину проблем на самых базовых вещах. Под катом — познавательный кейс для тех, кто ходит тропами SQL.
В предыдущей статье мы поговорили про роль Data Engineer в Х5, какие задачи он решает и с каким технологическим стеком работает. Рассмотрели структуру собеседования, основные направления, по которым мы оцениваем кандидатов, и подробно разобрали базовые требования, предъявляемые нами к уровню владения Python.
В данной статье мы разберём требования к ключевым для Data Engineer в X5 навыкам: распределённые системы и вычисления на Hadoop / Spark, а также SQL и проектирование схемы данных.
Добрый день, меня зовут Павел Поляков, я Principal Engineer
в каршеринг компании SHARE NOW, в Гамбурге в 🇩🇪 Германии. А еще я автор Telegram-канала Хороший разработчик знает, где рассказываю обо всем, что должен знать хороший разработчик.
Сегодня хочу поговорить о том стоит ли хранить данные в JSONB
полях в PostgreSQL
. Как это влияет на производительность?
Часто возникает проблема: одна из таблиц в базе данных сильно выросла и время выполнения запросов к этой таблице увеличилось. Одним из вариантов решения подобной проблемы в PostgreSQL является партицирование. В статье затронем не только техническую реализацию, но и опишем этапы подготовки к партицированию.
Представим, что у нас есть батон хлеба. Порежем его на части. Каждый отрезанный кусочек — часть целого батона, но не сам батон. То есть мы поделили целое на части — это и есть партицирование. Батон как целое соответствует таблице, а кусочки батона как части — партициям этой таблицы.