Комментарии

Инвестиции в облака растут как на дрожжах. В Gartner отмечают, что объем рынка за последний год уже увеличился на 20,4%. Речь идет о 678,6 млрд долларов. Именно столько, по мнению аналитиков, конечные потребители потратят на облачные сервисы в 2024 году.

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

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

На вкус и цвет облака разные

Еще один тренд от Gartner — развитие отраслевых платформ. Универсальные облака все реже соответствуют требованиям разных сфер бизнеса. Именно поэтому возникает спрос на отраслевые виртуальные решения и услуги, в том числе предоставляемые по модели IaaS.

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

Из горячего — Web3

Как считают аналитики McKinsey, многое на рынке облачных технологий изменит интернет следующего поколения (что бы это ни значило). Эксперты называют его Web3 и связывают перемены с блокчейном.

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

Главное — не обжечься

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

Многие компании уже используют инфраструктуру с архитектурой нулевого доверия (zero-trust). Более 80% уже применяют этот подход в облаках. Во всяком случае, такие данные появились в недавнем исследовании MIT.

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

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

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

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

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

Миру уже хорошо известны ChatGPT, DELLE-2 и другие продукты с GenAI под капотом. Масштабы их использования в корпоративном сегменте будут стремительно расти, считают во многих аналитических агентствах.

По мнению Gartner, к 2026 году применять или развертывать модели GenAI в облаке будут 80% компаний по всему миру. И главная причина такого спроса — демократизация генеративного ИИ, к которой приводит сочетание облачных технологий и открытого кода.

Так в итоге и не понятно, зачем вам даталейк, если подшел в итоге вариант с реляционной ДБ

У нас несколько иной опыт работы со Snowflake. Нужен был data lake, а самописное решение на Postgress/RDS уже явно не тянуло.

Ребята из Snowflake аккуратно и правильно собрали все требования и выкатили кастомизированную презентацию, которая покрывала 97% проблем. Не было никаких продаванов и левых менеджеров. Было 2 программиста-ставших-сейлсами, которые очень грамотно и четко отвечали на все проблемы либо сами сразу, либо посовещавшись с командой разработки.

Прототип запилили тоже они, причем всего за пару недель.

В итоге осталось очень приятное впечатление. Единственный неприятный момент — негибкая система кредитов по принципу «use it or loose it», которая держит на коротком поводке.

Отчасти, поэтому и ушли в итоге на BigQuery, но это уже совсем другая история…

Databricks — это в первую очередь Spark и сопутсвующая экосистема, плюс сейчас инструменты для всяких ML/AI/Data Science. Данные они для вас тоже могут хранить, но это необязательно — мы, например, этой функциональностью не пользуемся. Никакую БД они не предлагают — lakehouse это другое, но SQL интерфейс у этого всего есть.

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

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

Model (модель) — получает данные от контроллера, выполняет необходимые операции и передаёт их виду.

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

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

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

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

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

Наверно три основные библиотеки, которые использую вместе с Django, это Celery для асинхронных тасков, Django Rest Framework для REST API и Python Social Auth для интеграции с соцсетями.

Спасибо познавательно.

Долго искал решение наподобие Django, на Nodejs, но так и не нашел, пробовал разные поделки типа keystone, feather JS и т.д, потом увлёкся Python и сейчас осваиваю Django, в целом нравится, пока делаю для себя блог, в дальнейшем есть планы на интернет магазин, да знаю что все уже давно есть на PHP, но PHP не хочется учить. Было бы неплохо увидеть статью, про то что используют разработчики при разработке различных проектов на Django, какие библиотеки есть для него и т.д.

вот тут то я и вижу основную проблему. очевидность это антоним TDD, так как если вы кейс тестами покрыли — то он для вас очевиден и предсказуем.

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

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

Рефакторинг через TDD помогает обезопасить себя от неочевидных ошибок, здесь также очень сильно зависит от того, насколько правильно разработчик понимает текущую бизнес-логику. Если тесты хорошо провалидированы, то промахов не возникает. Отмечу, что регрессионное тестирование всё равно проводится после написания тестов.

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

На словах оно всегда красиво, а на деле никакое tdd не спасет от рандомных или совсем неочевидных регрессий.

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

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

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

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

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

1. Длина доменного имени. Чем короче домен, тем лучше. Лучше, если адрес сайта будет состоять из 10–12 символов.
2. Правильные сокращения. Выбирайте логичные сокращения и избегайте неочевидных, а также сленга или других слов, которые будут непонятны основной аудитории.
3. Использование ключевых и ассоциативных слов. Этот вариант хорош по нескольким причинам:
это серьёзное преимущество при продвижении в поисковых системах;
такие домены проще запомнить.
4. Подбор правильных букв. Если вы хотите видеть в качестве адреса своего сайта какое-то слово или словосочетание на латинице, то подобрать доменное имя будет несложно.
5. Не используйте цифры и дефисы. Такие домены хуже воспринимаются пользователями и поисковыми системами.
6. Использование дополнительных слов. Иногда подобрать доменное имя бывает непросто из-за того, что желаемый домен уже занят. В этом случае вам помогут дополнительные слова.
7. Уникальность доменного имени. Хорошим решением будет выбрать уникальное доменное имя, непохожее на названия других компаний.
8. Не смешивайте слова из разных языков. Все домены со смешением плохо звучат, плохо запоминаются и негативно воспринимаются поисковыми системами.
9. Региональные зоны в доменном имени. Выбирать их следует в соответствии с назначением сайта и сферой деятельности компании.

Сайты на доменах Ру/Рф вполне могут стоять выше в выдаче Гугла, чем «крутые» доткомы. Если запрос идет из России, то никакой разницы нет, какая там доменная зона. Крайне не советую тратить деньги на импортные домены и сеошников, которые разводят на их регистрацию «ради продвижения».

Три базовых правила:

Подбирайте название сайта и доменную зону под ваш бренд. Желательно, чтобы название компании было включено в имя.

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

Сразу регистрируйте имена в разных доменных зонах, настраивайте редирект на один основной домен.

Регистрируйте домен в зоне com у нормального зарубежного регистратора и не будете иметь проблем

Озеро данных

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

Некоторые компании будут использовать термин «Озеро данных» для обозначения не только уровня хранения, но и всех связанных с ним инструментов, от приема данных, ETL, анализа, машинного обучения, аналитики, вплоть до стеков хранилищ данных и, возможно, даже BI и инструментов визуализации. Однако, как архитектор больших данных, я нахожу такое использование термина запутанным и предпочитаю говорить об озере данных и инструментах вокруг него как об отдельных компонентах с отдельными возможностями и обязанностями. Таким образом, ответственность озера данных заключается в том, чтобы быть центральным хранилищем с высокой надежностью для любого типа данных, которые вы, возможно, захотите сохранить в состоянии покоя.

По мнению большинства, термин «озеро данных» был введен Джеймсом Диксоном, основателем и техническим директором Pentaho, который описывает его следующим образом:

“Если вы представляете datamart как хранилище бутилированной воды – очищенной, упакованной и структурированной для удобства потребления, – то озеро данных — это большой водоем в более естественном состоянии. Содержимое озера данных поступает из источника для заполнения озера, и различные пользователи озера могут приходить, чтобы исследовать его, нырять в воду или брать пробы ”.

Amazon Web Services определяет это на своей странице «Что такое озеро данных»:

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

Из Википедии:

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

И, наконец, Gartner:

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

В локальных кластерах озеро данных обычно относится к основному хранилищу в кластере в распределенной файловой системе, обычно HDFS, хотя существуют и другие файловые системы, такие как GFS, используемая в Google, или файловая система MapR в кластерах MapR.

В облаке озера данных обычно хранятся не в кластерах, поскольку постоянно поддерживать работу кластера экономически невыгодно, а в надежных облачных хранилищах, таких как Amazon S3, Azure ADLS или Google Cloud Storage. Затем вычислительные кластеры можно запускать по запросу и беспрепятственно подключать к облачному хранилищу для выполнения преобразований, машинного обучения, аналитических заданий и т.д.

Я не могу сказать, что раньше сталкивался с термином «большое хранилище», но, отвечая на первоначальный вопрос, нет, data lake и big data — это не одно и то же, хотя, честно говоря, ими часто пользуются, и определения различаются в зависимости от того, кого вы спрашиваете, но я попробую попробовать:
Большие данные

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

Иногда это может быть вопросом самого объема данных: как только вы достигаете сотен терабайт или петабайт, ваши старые добрые базы данных RDBMS, как правило, отказываются работать, и мы вынуждены распределять наши данные по множеству дисков, а не только по одному большому. И на этих объемах мы захотим распараллелить наши рабочие нагрузки, что приведет к созданию таких вещей, как базы данных MPP, экосистема Hadoop и обработка на основе DAG.

Однако сам по себе объем не говорит всей истории. Популярное определение больших данных описывается так называемыми «4 Против»: объем, разнообразие, скорость и достоверность. В двух словах:

Объем — как упоминалось выше, относится к трудностям, вызванным размером данных

Разнообразие — относится к внутренней сложности работы с разрозненными типами данных; некоторые из ваших данных будут структурированными (например, таблицы данных SQL), в то время как другие данные могут быть либо полуструктурированными (XML-документы), либо неструктурированными (файлы изображений raw), и технология для работы с этим разнообразием нетривиальна

Скорость — относится к скорости, с которой могут генерироваться новые данные; при сборе событий реального времени, таких как данные Интернета вещей, или веб-трафик, или финансовые транзакции, или изменения в базе данных, или что-либо еще, что происходит в режиме реального времени, «скорость» поступления данных в ваши системы (а во многих случаях и из них) может легко превысить возможности традиционных технологий баз данных, что требует какой-либо масштабируемой шины сообщений (Kafka) и, возможно, сложной инфраструктуры обработки событий (такой как Spark Streaming или Apache Flink).

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

В этом определении «большие данные» — это данные, которые из-за особых проблем, связанных с 4 V, непригодны для обработки с помощью традиционных технологий баз данных; в то время как «инструменты для обработки больших данных» — это инструменты, специально разработанные для решения этих проблем.