За последние несколько лет инструменты бизнес-аналитики (BI) проникли практически во все виды бизнеса, и науке о данных уделяется все больше внимания и ресурсов.
Если говорить об ИТ-компаниях, то большинство людей, вероятно, понимают цель бизнес-аналитики и ценность внутреннего анализа данных для компании.
В Playrix мы уделяем значительное количество ресурсов подготовке и анализу данных; мы стараемся использовать передовые технологии и серьезно относимся к обучению сотрудников.
Компания входит в тройку крупнейших разработчиков мобильных игр в мире, поэтому мы стараемся поддерживать соответствующий уровень в анализе данных и, в частности, в бизнес-аналитике.
Поскольку более 27 миллионов пользователей ежедневно играют в наши игры, эта цифра может дать вам примерное представление об объеме данных, генерируемых мобильными устройствами каждый день.
Кроме того, данные берутся с десятков сервисов в различных форматах, после чего агрегируются и загружаются в наши хранилища.
В качестве озера данных мы работаем с AWS S3, а хранилище данных на AWS Redshift и PostgreSQL используется ограниченно.
Мы используем эти базы данных для аналитики.
Redshift быстрее, но дороже, поэтому самые популярные данные мы храним там.
PostgreSQL дешевле и медленнее; он хранит либо небольшие объемы данных, либо данные, скорость чтения которых не имеет решающего значения.
Для предварительно агрегированных данных мы используем кластер Hadoop и Impala. Основным инструментом BI в Playrix является Tableau. Этот продукт достаточно известен в мире и обладает широкими возможностями по анализу и визуализации данных и работе с различными источниками.
Кроме того, простые аналитические задачи не требуют написания кода, поэтому вы можете научить пользователей из разных отделов независимо анализировать свои бизнес-данные.
Вендор инструмента Tableau Software также позиционирует свой продукт как инструмент для самостоятельного анализа данных, то есть для самообслуживания.
Существует два основных подхода к анализу данных в BI:
- Фабрика отчетов .
При таком подходе существует отдел и/или люди, которые разрабатывают отчеты для бизнес-пользователей.
- Самообслуживание.
При таком подходе бизнес-пользователи сами создают отчеты и строят аналитику своих процессов.
Второй подход является относительно новым, особенно для России.
Это хорошо, потому что данные проверяют сами бизнес-пользователи — они гораздо лучше знают свои локальные процессы.
Это помогает избавить разработчиков от необходимости каждый раз погружаться в специфику командных процессов и создавать простейшие отчеты.
Это помогает решить, пожалуй, самую большую проблему — проблему преодоления разрыва между бизнес-пользователями и разработчиками.
Ведь основная проблема подхода Reporting Factory как раз и заключается в том, что большая часть отчетов может остаться невостребованной только потому, что программисты неправильно понимают проблемы бизнес-пользователей и, соответственно, создают ненужные отчеты, которые либо переделываются потом, либо просто не используются.
В Playrix отчеты компании изначально разрабатывали программисты и аналитики, то есть специалисты, ежедневно работающие с данными.
Но компания развивается очень быстро, и поскольку потребности пользователей в отчетах росли, разработчики отчетов уже не могли вовремя выполнять все задачи, связанные с их созданием и поддержкой.
Тогда встал вопрос либо о расширении группы разработки BI, либо о передаче компетенций другим отделам.
Направление Самообслуживание Нам это показалось перспективным, поэтому мы решили научить бизнес-пользователей самостоятельно создавать собственные проекты и анализировать данные.
В Playrix подразделение бизнес-аналитики (BI Team) решает следующие задачи:
- Сбор, подготовка и хранение данных.
- Развитие сервисов внутренней аналитики.
- Интеграции с внешними сервисами.
- Разработка веб-интерфейсов.
- Разработка отчетности в Tableau.
Нашу структуру можно упростить с помощью диаграммы: 
Мини-BI-команды
Прямоугольники здесь представляют мини-команды.
Слева — задние команды, справа — передние команды.
Каждый из них обладает достаточными компетенциями, чтобы работать с задачами смежных команд и брать их на себя, когда другие команды перегружены.
BI Team имеет полный цикл разработки: от сбора требований до внедрения в среду продукта и последующей поддержки.
В каждой мини-команде есть свой системный аналитик, разработчики и инженеры по тестированию.
Они выполняют функцию Фабрика отчетов , подготовка данных и отчетов для внутреннего использования.
Здесь важно отметить, что в большинстве проектов Tableau мы разрабатываем не простые отчеты, которые обычно показываются на демонстрациях, а инструменты с богатым функционалом, большим набором элементов управления, обширными возможностями и подключением внешних модулей.
Эти инструменты постоянно совершенствуются и добавляются новые функции.
Однако есть и простые локальные проблемы, которые может решить сам заказчик.
Передача компетенций и запуск пилотного проекта
По нашему опыту работы и общения с другими компаниями, основными проблемами при передаче компетенций по работе с данными бизнес-пользователям являются:- Нежелание самих пользователей изучать новые инструменты и работать с данными.
- Отсутствие поддержки со стороны руководства (инвестиции в обучение, лицензии и т. д.).
У пользователей также есть желание научиться работать с данными и Tableau — это интересно ребятам, плюс анализ данных сейчас — это очень значимый навык, который большинству обязательно понадобится в будущем.
Внедрение новой идеологии сразу во всей компании обычно требует много ресурсов и нервов, поэтому мы начали с пилота.
Пилотный проект «Самообслуживание» был запущен в отделе привлечения пользователей полтора года назад, и в ходе пилотного процесса накапливались ошибки и опыт, чтобы в дальнейшем передать их другим отделам.
Направление User Acquisition работает над увеличением аудитории наших продуктов, анализирует способы покупки трафика и выбирает, в какие направления привлечения пользователей стоит вкладывать средства компании.
Раньше отчеты по этому направлению готовила команда BI, либо ребята сами обрабатывали загрузки из базы с помощью Excel или Google Sheets. Но в динамичной среде разработки такой анализ влечет за собой задержки, а количество анализируемых данных ограничено возможностями этих инструментов.
На старте пилота мы провели базовое обучение сотрудников работе с Tableau, создали первый общий источник данных — таблицу в базе данных Redshift, имевшую более 500 миллионов строк и необходимые метрики.
Следует отметить, что Redshift — это столбчатая (или столбчатая) база данных, и эта база данных возвращает данные гораздо быстрее, чем реляционные базы данных.
Пилотная таблица в Redshift была очень большой для людей, которые никогда не работали более чем с 1 миллионом строк одновременно.
Но ребятам было непросто научиться работать с данными таких объемов.
Мы знали, что по мере усложнения отчетов начнутся проблемы с производительностью.
Мы не давали пользователям доступ к самой базе данных, а реализовали источник на сервере Tableau, подключенный в реальном времени к таблице в Redshift. Пользователи имели лицензии Creator и могли подключаться к этому источнику либо с Tableau Server, разрабатывая там отчеты, либо с Tableau Desktop. Надо сказать, что при разработке отчетов в вебе (в Tableau есть режим веб-редактирования) есть некоторые ограничения на сервере.
В Tableau Desktop таких ограничений нет, поэтому мы в первую очередь разрабатываем для Desktop. Кроме того, если анализ нужен только одному бизнес-пользователю, не обязательно публиковать такие проекты на сервере — можно работать локально.
Образование
В нашей компании принято проводить вебинары и обмен знаниями, на которых каждый сотрудник может рассказать о новых продуктах, функциях или возможностях инструментов, с которыми он работает или исследует. Все подобные действия фиксируются и сохраняются в нашей базе знаний.В нашей команде этот процесс тоже работает, поэтому мы периодически тоже делимся знаниями или готовим фундаментальные обучающие вебинары.
Для всех пользователей, имеющих лицензии Tableau, мы провели и записали получасовой вебинар по работе с сервером и дашбордами.
Речь шла о проектах на сервере, работе с родным управлением всех дашбордов - это верхняя панель (обновление, пауза,.
).
Об этом необходимо рассказать всем пользователям Tableau, чтобы они могли полноценно работать с нативными возможностями и не делать запросов на разработку фич, повторяющих работу нативных элементов управления.
Главным препятствием на пути к освоению инструмента (да и вообще чего-то нового) обычно является страх, что вы не сможете разобраться и работать с этим функционалом.
Поэтому обучение — пожалуй, самый важный этап внедрения подхода BI самообслуживания.
От этого во многом будет зависеть результат внедрения этой модели – приживется ли она вообще в компании и если да, то как быстро.
На стартовых вебинарах как раз необходимо снимать барьеры к использованию Tableau. Есть две группы вебинаров, которые мы провели для людей, незнакомых с базами данных:
- Начальный набор знаний для новичка:
- Связь данных, типы соединений, типы данных, базовые преобразования данных, нормализация данных (1 час).
- Базовые визуализации, агрегирование данных, базовые расчеты (1 час).
- Связь данных, типы соединений, типы данных, базовые преобразования данных, нормализация данных (1 час).
- Сложные расчеты и основные приемы/элементы, принятые в компании (2 часа).
На этом же вебинаре мы объясняем работу JOIN, UNION, PIVOT, а также затрагиваем Blending. На первом вебинаре мы почти не затрагиваем визуализацию данных; его цель — объяснить, как работать и преобразовывать ваши данные для Tableau. Важно, чтобы люди понимали, что данные первичны и большинство проблем возникает на уровне данных, а не на уровне визуализации.
Второй вебинар по Самообслуживанию призван рассказать о логике создания визуализаций в Tableau. Tableau сильно отличается от других инструментов BI тем, что имеет собственный движок и логику.
Другие системы, например PowerBI, имеют набор готовых визуалов (дополнительные модули можно скачать из магазина), но эти модули не подлежат настройке.
В Tableau у вас, по сути, есть чистый лист, на котором вы можете построить что угодно.
Конечно, в Tableau есть ShowMe — меню базовых визуализаций, но все эти графики и диаграммы можно и нужно строить по логике Tableau. На наш взгляд, если вы хотите научить кого-то работать с Tableau, то вам не нужно использовать ShowMe для построения диаграмм — большинство из них на старте людям не пригодятся, но вам нужно научить их логике работы.
создание визуализаций.
Для бизнес-дашбордов достаточно знать, как строить:
- Временная последовательность.
Линейные/областные диаграммы (линейные диаграммы),
- гистограммы,
- Scatter Plots (диаграммы рассеяния),
- Таблицы.
Временные ряды: очень часто используются в бизнесе, поскольку интересно сравнивать показатели за разные периоды времени.
В нашей стране, наверное, все сотрудники компании смотрят на результаты бизнеса во времени.
Мы используем гистограммы для сравнения показателей по категориям.
Диаграммы рассеяния используются редко, обычно для поиска корреляций между показателями.
Таблицы: то, от чего мы не можем полностью избавиться в бизнес-дашбордах, но стараемся по возможности минимизировать их количество.
В таблицах собираем числовые значения метрик по категориям.
То есть мы отпускаем людей после 1 часа обучения работе с данными и 1 часа обучения базовым расчетам и визуализациям.
Потом ребята какое-то время сами работают со своими данными, сталкиваются с проблемами, набираются опыта и просто совершенствуются.
Этот этап занимает в среднем 2-4 недели.
Естественно, в этот период есть возможность проконсультироваться с командой BI, если что-то не получится.
После первого этапа коллегам необходимо совершенствовать свои навыки и изучать новые возможности.
Для этого мы подготовили углубленные обучающие вебинары.
В них мы показываем, как работать с функциями LOD, табличными функциями, скриптами Python для TabPy. Мы работаем с реальными данными компании, это всегда интереснее, чем поддельные данные или данные из базового набора данных Superstore Tableau. На этих же вебинарах мы рассказываем об основных функциях и приемах Tableau, которые используются на дашбордах продуктов, например:
- Sheet Swapping (замена листов),
- Агрегация графиков по параметрам,
- Форматы даты и метрик,
- Отбрасывание неполных периодов для еженедельных/месячных агрегаций.
Для расчета некоторых внутренних метрик мы используем Python-скрипты, все скрипты уже готовы, и для Самообслуживания нужно понимать, как их вставлять в свои расчеты.
Таким образом, для запуска Самообслуживания мы проводим всего 4 часа вебинаров, и этого обычно достаточно мотивированному человеку, чтобы начать работать с Tableau и самостоятельно анализировать данные.
Кроме того, у нас есть свои вебинары для аналитиков данных, они находятся в открытом доступе и вы можете с ними ознакомиться.
Разработка источников данных для Самообслуживания
После пилотного проекта мы сочли его успешным и расширили количество пользователей Самообслуживания.Одной из больших задач была подготовка источников данных для разных команд. Ребята из Self-Service умеют работать с 200+ миллионами строк, поэтому команде Data Engineering пришлось придумать, как реализовать такие источники данных.
Для большинства аналитических задач мы используем Redshift из-за скорости чтения данных и простоты использования.
Но давать доступ к базе данных каждому человеку из Самообслуживания было рискованно с точки зрения информационной безопасности.
Первой идеей было создание источников с живым подключением к базе данных, то есть на Tableau Server публиковалось несколько источников, которые смотрели либо в таблицы, либо в подготовленные представления Redshift. В данном случае мы не хранили данные на сервере Tableau, а сами пользователи переходили со своего Tableau Desktop (клиентов) в базу данных через эти источники.
Это работает, когда таблицы небольшие (один миллион) или запросы Tableau не слишком сложны.
По мере развития ребята стали усложнять свои дашборды в Tableau, использовать LODы, кастомные сортировки и скрипты на Python. Естественно, это привело к замедлению работы некоторых панелей самообслуживания.
Поэтому через несколько месяцев после запуска Самообслуживания мы пересмотрели подход к работе с источниками.
Новый подход, который мы используем до сих пор, включал выдержки, опубликованные на сервере Tableau. Надо сказать, что у Самообслуживания постоянно появляются новые задачи, и к ним поступают запросы на добавление новых полей в источник; естественно, источники данных постоянно изменяются.
Мы разработали следующую стратегию работы с источниками:
- Согласно спецификации источника, Самообслуживание собирает данные в таблицах базы данных.
- В тестовой схеме базы данных Redshift создается нематериализованное представление.
- Отправленная информация проверяется на корректность данных командой контроля качества.
- Если результат теста положительный, представление переводится на производственную диаграмму Redshift.
- Команда Data Engineering берет на себя задачу поддержки — подключаются скрипты для анализа достоверности данных, сигналы тревоги ETL, права чтения предоставляются команде самообслуживания.
- Источник (экстракт), подключенный к этому представлению, публикуется на сервере Tableau.
- Сигналы ETL генерируются для запуска извлечения.
- Источник описан в базе знаний.
- Описание источника, вся информация для подключения и работы передается команде Самообслуживания.
Это охватывает ряд задач.
В нашем случае таблицы собираются с использованием данных различных провайдеров, в том числе.
Соответственно, если один провайдер или наш внутренний сервис не успел обновить свою часть данных, то вся таблица считается недействительной.
То есть вы не можете просто установить расписание на фиксированное время.
Поэтому мы используем API Tableau для запуска извлечений, когда таблицы готовы.
Сигналы запуска извлечения генерируются нашей службой ETL после того, как она убедится, что все новые данные поступили и действительны.
Такой подход позволяет получить свежие, достоверные данные в извлечении с минимальной задержкой.
Публикация информационных панелей самообслуживания на сервере Tableau
Мы намеренно не ограничиваем людей в экспериментах со своими данными и разрешаем им публиковать и делиться своими книгами.Внутри каждой команды, если человек считает, что его дашборд полезен другим или этому сотруднику нужен дашборд на сервере, он может его опубликовать.
Команда BI не вмешивается во внутренние эксперименты команд; соответственно, всю логику дашбордов и расчетов они отрабатывают сами.
Бывают случаи, когда из Самообслуживания вырастает интересный проект, который затем полностью передается на поддержку команды BI и переходит к дальнейшему развитию.
Это и есть эффект Самообслуживания, когда люди, хорошо понимая свои бизнес-задачи, начинают работать со своими данными и формируют новую стратегию своей работы.
Исходя из этого, мы сделали следующую схему проектов на сервере: 
Диаграмма проекта на сервере Tableau
Каждый пользователь с лицензией Creator может публиковать свои книги на сервере или выполнять анализ локально.
Для Самообслуживания мы создали собственную песочницу со своими проектными группами.
Сайты в Tableau идеологически разделены, чтобы пользователи одного сайта не видели контент другого, поэтому мы разделили сервер на сайты по направлениям, которые не пересекаются: например, игровая аналитика и финансы.
Мы используем групповой доступ.
На каждом сайте есть проекты, в которых наследуются права на их книги и исходники.
То есть группа пользователей Группа 1 видит только свои книги и источники данных.
Исключением из этого правила является сайт Sandbox, у которого также есть подпроекты.
Мы используем Sandbox для прототипирования, разработки новых информационных панелей, их тестирования и для нужд самообслуживания.
Любой, у кого есть доступ к публикации своего проекта Sandbox, может публиковать свои прототипы.
Источники мониторинга и информационные панели на сервере Tableau
Поскольку мы перенесли нагрузку запросов дашборда самообслуживания из базы данных на сервер Tableau, мы работаем с большими источниками данных и не ограничиваем людей по запросам к опубликованным источникам, возникла еще одна проблема — мониторинг работоспособности таких дашбордов и мониторинг созданных источников..
Мониторинг работоспособности дашбордов и производительности серверов Tableau — задача, с которой сталкиваются средние и крупные компании, поэтому о производительности дашбордов и их настройке написано довольно много статей.
Мы не пионеры в этой области; наш мониторинг состоит из нескольких панелей мониторинга, основанных на внутренней базе данных PostgreSQL Tableau Server. Этот мониторинг работает со всем контентом, но вы можете выбрать панели самообслуживания и просмотреть их производительность.
Команда BI периодически решает проблемы оптимизации дашбордов.
Пользователи иногда приходят с вопросом «Почему дашборд работает медленноЭ», и нам необходимо понять, что такое «медленно» с точки зрения пользователя и какими числовыми критериями можно характеризовать это «медленно».
Чтобы не опрашивать пользователя и не отнимать его рабочее время на подробный пересказ проблем, мы отслеживаем и анализируем http-запросы, находим самые медленные и выясняем причины.
Затем оптимизируем дашборды, если это может привести к повышению производительности.
Понятно, что при живом подключении к источникам будут задержки, связанные с формированием представления в базе данных и задержкой получения данных.
Также бывают сетевые задержки, которые мы расследуем вместе с нашей командой, поддерживающей всю ИТ-инфраструктуру, но в этой статье мы не будем на них останавливаться.
Немного о http-запросах
Каждое взаимодействие пользователя с панелью управления в браузере инициирует собственный HTTP-запрос, который отправляется на сервер Tableau. Вся история таких запросов хранится во внутренней базе данных PostgreSQL Tableau Server; срок хранения по умолчанию составляет 7 дней.Этот период можно увеличить, изменив настройки Tableau Server, но нам не хотелось увеличивать таблицу http-запросов, поэтому мы просто каждый день собираем инкрементальный экстракт, содержащий только свежие данные, не перезаписывая старые.
Это хороший способ с минимумом ресурсов сохранить исторические данные в виде экстракта на сервере, которого больше нет в базе данных.
Каждый http-запрос имеет свой тип (action_type).
Например, _bootstrap — это первоначальная загрузка представления,relative-date-filter — фильтр даты (ползунок).
Большинство типов можно идентифицировать по названию, поэтому понятно, что каждый пользователь делает с дашбордом: кто-то больше смотрит на всплывающие подсказки, кто-то меняет параметры, кто-то создает свой custom_view, а кто-то загружает данные.
Ниже представлена наша панель управления сервисом, которая позволяет вам определять медленные панели мониторинга, типы медленных запросов и пользователей, которым приходится ждать.
Дашборд для мониторинга http-запросов
Мониторинг сессий VizQL
При открытии дашборда в браузере на сервере Tableau запускается сессия VizQL, в рамках которой отрисовываются визуализации, а также выделяются ресурсы для поддержания сессии.По умолчанию такие сеансы сбрасываются после 30 минут бездействия.
По мере увеличения количества пользователей на сервере и внедрения самообслуживания мы получили несколько запросов на увеличение лимитов сеансов VizQL. Проблема для пользователей заключалась в том, что они открывали информационные панели, устанавливали фильтры, что-то смотрели и переходили к другим своим задачам за пределами Tableau Server. Через некоторое время они вернулись к открытым дашбордам, но были сброшены к виду по умолчанию, и их пришлось создавать заново.
мелодия.
Нашей задачей было сделать работу пользователя более комфортной и сделать так, чтобы нагрузка на сервер не возрастала критически.
Следующие два параметра на сервере можно изменить, но вы должны понимать, что нагрузка на сервер может увеличиться.
Количество минут простоя, после которого сеанс VizQL может быть отменен, если процессу VizQL начинает не хватать памяти.vizqlserver.session.expiry.minimum 5
vizqlserver.session.expiry.timeout 30 Количество минут простоя, после которого сеанс VizQL отменяется.
Поэтому мы решили мониторить сессии VizQL и отслеживать:
- Количество сеансов
- Количество сессий на пользователя,
- Средняя продолжительность сеансов
- Максимальная продолжительность сеансов.
В результате получается вот такая панель: 
Панель мониторинга сеансов VizQL
С начала января этого года мы начали постепенно увеличивать лимиты и следить за продолжительностью сессий и нагрузкой.
Средняя продолжительность сессии увеличилась с 13 до 35 минут – это видно на графиках средней продолжительности сессии.
Окончательные настройки такие: vizqlserver.session.expiry.minimum 120
vizqlserver.session.expiry.timeout 240
После этого мы получили положительные отзывы пользователей о том, что работать стало намного приятнее — сессии перестали затухать.
Тепловые карты этой информационной панели также позволяют нам планировать работы по техническому обслуживанию в часы минимальной нагрузки на сервер.
Следим за изменением нагрузки на кластер — ЦП и ОЗУ — в консоли Zabbix и AWS. Никаких существенных изменений нагрузки в процессе увеличения таймаутов мы не зафиксировали.
Если говорить о том, что может серьезно наломать ваш сервер Tableau, то это может быть, например, неоптимизированный дашборд. Постройте, например, в Tableau таблицу из десятков тысяч строк для категорий и id каких-то событий, а в Measure используйте LOD-расчеты на уровне id. С большой вероятностью отобразить таблицу на сервере не получится, и вы получите вылет с Unexpected Error, так как все LODы в минимальной степени детализации будут потреблять много памяти, и очень скоро процесс достигнет 100% памяти.
потребление.
Этот пример приведен здесь, чтобы было понятно, что одна неоптимальная панель мониторинга может потреблять все ресурсы сервера, и даже 100 сеансов VizQL оптимальных панелей мониторинга не будут потреблять столько ресурсов.
Мониторинг источников данных сервера
Выше мы отмечали, что для Самообслуживания мы подготовили и опубликовали на сервере несколько источников данных.Все источники представляют собой экстракты данных.
Опубликованные исходники сохраняются на сервере, и доступ предоставляется ребятам, которые работают с Tableau Desktop. Tableau имеет возможность помечать источники как сертифицированные.
Именно этим занимается команда BI при подготовке источников данных для самообслуживания.
Это гарантирует, что сам источник был протестирован.
Опубликованные источники могут достигать 200 миллионов строк и 100 полей.
Для Самообслуживания это очень большой объём, так как не у многих компаний есть источники таких объёмов для самоаналитики.
Естественно, собирая требования для формирования источника, мы смотрим, как можно уменьшить объем данных в источнике, группируя категории, разбивая источники по проектам или ограничивая сроки.
Но все равно, как правило, исходники получаются из 10 миллионов строк.
Поскольку исходники большие, занимают место на сервере и используют ресурсы сервера для обновления выдержек, за всеми ними необходимо следить, чтобы видеть, как часто они используются и как быстро растут в объеме.
Для этого мы провели мониторинг опубликованных источников данных.
Он показывает пользователей, подключающихся к источникам и книгам, которые используют эти источники.
Это позволяет вам найти нерелевантные источники или проблемные источники, из которых невозможно собрать экстракт. 
Панель мониторинга источника
Нижняя граница
Мы используем подход Самообслуживания уже 1,5 года.За это время 50 пользователей начали работать с данными самостоятельно.
Это снизило нагрузку на BI Team и позволило ребятам не ждать, пока BI Team приступит к своей конкретной задаче по разработке дашборда.
Около 5 месяцев назад мы начали подключать к независимой аналитике другие направления.
В наши планы входит обучение грамотности в области данных и лучшим практикам визуализации.
Важно понимать, что процесс Самообслуживания невозможно внедрить быстро во всей компании; это займет некоторое время.
Если процесс перехода будет органичным, без шокирования сотрудников, то через пару лет внедрения можно получить принципиально разные процессы работы с данными в разных подразделениях и областях компании.
Теги: #ИТ-инфраструктура #Программное обеспечение #Анализ и проектирование систем #анализ данных #таблица #бизнес-аналитика #бизнес-аналитика #Playrix
-
История, Хранящаяся В Днк
19 Oct, 24 -
От Ста До Пятисот Цифр Числа Пи На Колене
19 Oct, 24 -
Еще Раз О Преимуществах «Мобильного Рабства»
19 Oct, 24 -
Динамические Роли И Права
19 Oct, 24 -
Хэш-Алгоритмы
19 Oct, 24 -
Решение Для Пакетной Обработки Файлов (Php)
19 Oct, 24 -
«Образование» Отстает
19 Oct, 24 -
Идея Для Поисковых Систем
19 Oct, 24
