Data Modeling to extract data from REST API for Kubernetes Reporting measures

[Inostranka_02]

Один из проэктов на работе -
создать модель данных для последующего создания расчетов (метрик) платформы Kubernetes (Agents related reports)

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

Ситуация такая:
У нас есть расчеты (measures - Agents Report) сделанные в Power BI в рез-тате такой частичной автоматизации:
1 Есть Azure Data Pipelines (если не ошибаюсь то именно они, уточню) которые достают таблицы из REST API (json format) и преобразуют их в .csv format
2 В Power BI человек коннецтится с этим .csv фаилом и построил модель небольшую, создал расчеты и установил data refresh - получились расчеты на основе свежих данных из API

Теперь моя задача - на основе имеющеися ad-hoc как бы модели, сделать комплексную где будут historical data about Agents /Pools, куда перенесем существующие и сделаем новые measures
Для этого имеется Azure Cosmos database. Первейшая задача - перенести таблицы из API -> Cosmos DB, автоматизировать етот процесс; дальше преобразовать их в реляционные с отношениями и перенести в Power BI, автоматизировать етот процесс. Дальше я знаю что делать.

Я раньше была BI Developer, работала с уже готовыми реляционными моделями и только достраивала их.
Все дело было в Ms SQL Server. Тут мало того что Azure, но и работа - несколько другая - создать все почти с 0. Времени у меня много - обстановка хорошая
Но нет уверенности что правильно делаю

Chat GPT выдает следующии алгоритм:

Step 1: Import Data from REST API to Azure Cosmos DB

Create and set up Azure Cosmos DB Account. - это есть, не проблема
Choose API and Create a Database: - есть
Decide on the API you want to use (SQL API for document-oriented data (JSON format)). - выбрала
Develop a Script / Automation for data collections: Вопрос - КАК именно develop? Какои тул, язык? (У нас имеются эти Azure Data pipelines - ими нельзя? Еше не изучала)
Write a script that pulls data from the REST API or Use the Azure Cosmos DB SDK or other tools to insert the data into the Cosmos DB - наверно ето ответ на вопрос - но все равно не ясно какпи скрипт
Automation:
Implement a schedule for regular data refreshes from the REST API to Cosmos DB.
This could be achieved using Azure Functions, Logic Apps, or other automation tools. - может тут кто знает посоветует - какие именно аппс, тулс?

Step 2: Transform Data for Power BI Measures

Define Data Model:
Understand the data structure and relationships required for your Power BI measures. - знаю, работаю над етим
Define the schema and structure for the transformed data. - знаю

Data Transformation:
Create a process to transform the document-oriented data from Cosmos DB into a structured, relational format- possibly using Azure Data Factory - что за зверь?

Maintain Keys and Relationships:
Automate Transformation Process (Optional) ETL - я так поняла из етои Azure Data Factory?

Step 3: Connect Power BI to Transformed Data
Connect to Azure Cosmos DB: dalьше я знаю

Еше - если кто-то изучал и знает хорошии курс по следуюшим темам (лучше Pluralsight LinkedIn Learning или в любом месте)

- Azure Data Factory
- NoSQL manual чтобы было для новичков и по сложнее - чтобы все там было
- Azure Data Pipelines - для чаиников -))
- Cosmos DB / Data Modeling много на Pluralsight

Все ето есть, просто мб тут кто-то знает что-то супер полезное по теме.
Спасибо!

[Inostranka_02]

Еше почему написала сюда -
Не инженеры наши
слышали где-то что таблицы можно в Космос етот просто drop фром API...
Что-то не похоже после ознакомления Или я ошибаюсь и никакои автоматизации не надо?

[Uzito]

Еше почему написала сюда -
Не инженеры наши
слышали где-то что таблицы можно в Космос етот просто drop фром API...
Что-то не похоже после ознакомления Или я ошибаюсь и никакои автоматизации не надо?

можно слабать скрпит на питоне из 20 строчек который будет засасывать данные из CSV в нужную табличку

[urod]

Вам нужно использовать timer based Azure functions - language of your choice - или Azure logic apps - больше как drag and drop, но, если, что посложнее - то там JavaScript.
Cosmos DB for SQL API - не все так просто. Много подводных камней. Нужно правильно выбрать partition key approach- single partition can hold only 20GB of data. Нужно правильно выбрать throughout - или будете либо платить очень много, или изучите что такое 429 hard way. Нужно знать, как делать запросы с учетом partition key. Если надо делать data refresh - надо будеть удалять и создавать контайнер заново - или изучать как удалять индивидуальные partitions. Нужно будет знать как правильно прикручивать индексы.
Удачи.

[Inostranka_02]

Вам нужно использовать timer based Azure functions - language of your choice - или Azure logic apps - больше как drag and drop, но, если, что посложнее - то там JavaScript.
Cosmos DB for SQL API - не все так просто. Много подводных камней. Нужно правильно выбрать partition key approach- single partition can hold only 20GB of data. Нужно правильно выбрать throughout - или будете либо платить очень много, или изучите что такое 429 hard way. Нужно знать, как делать запросы с учетом partition key. Если надо делать data refresh - надо будеть удалять и создавать контайнер заново - или изучать как удалять индивидуальные partitions. Нужно будет знать как правильно прикручивать индексы.
Удачи.

Спасибо за подробности!
Сейчас не могу ответить - чуть позже напишу возможные вопросы

[Mad Hatter]

Чисто интересно, о каком объёме данных идёт речь?

[oraclejava]

Один из проэктов на работе -
создать модель данных для последующего создания расчетов (метрик) платформы Kubernetes (Agents related reports)

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

Ситуация такая:

Step 1: Import Data from REST API to Azure Cosmos DB

Step 2: Transform Data for Power BI Measures
Create a process to transform the document-oriented data from Cosmos DB into a structured, relational format- possibly using
Step 3: Connect Power BI to Transformed Data
Connect to Azure Cosmos DB: dalьше я знаю

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

1. читаем сырые данные через рест
2. скидываем в очередь (QUEUE TBD)
3. сервис или функция берет данные из очереди, трансформирует и кидает в реляционную БД (TBD) или ADX (azure data explorer)

шаги 3 и 2 могут быть одним.
Вопрос был правильный ранее - какие объемы?
и добавлю - интересует обе цифры - как общий объем ожидаемых хранимых данных так и INGRESS/min/hour/day

[Mad Hatter]

Для, озвученной задачи идеально подходит Splunk. Но он хочет денюх $$$

[Inostranka_02]

Один из проэктов на работе -
создать модель данных для последующего создания расчетов (метрик) платформы Kubernetes (Agents related reports)

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

Ситуация такая:

Step 1: Import Data from REST API to Azure Cosmos DB

Step 2: Transform Data for Power BI Measures
Create a process to transform the document-oriented data from Cosmos DB into a structured, relational format- possibly using
Step 3: Connect Power BI to Transformed Data
Connect to Azure Cosmos DB: dalьше я знаю

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

1. читаем сырые данные через рест
2. скидываем в очередь (QUEUE TBD)
3. сервис или функция берет данные из очереди, трансформирует и кидает в реляционную БД (TBD) или ADX (azure data explorer)

шаги 3 и 2 могут быть одним.
Вопрос был правильный ранее - какие объемы?
и добавлю - интересует обе цифры - как общий объем ожидаемых хранимых данных так и INGRESS/min/hour/day

Сорри за не совсем компетентные ответы - я совсем новичек во всех етих Azure etc.

не понятен шаг 1 - зачем сырые данные закидывать в космос?
В Cosmos потому что начальство так хочет. У нас Azure portal, Azure DevOps, Ну и они взяли эту базу.
Она у них была еще до моего прихода...
Как я понимаю, они думают, что в Cosmos легче закинуть данные.
Говорили мне что они слышали что там просто можно to drop all the tables и все, без всякой автоматизации.
Начальство, к сожалению, вообще не from data / programming background.

Почму выбор космос дб для реляционной модели данных? она не совсем подходит для этого. Точнее совсем не для этого.
А для чего она вообще нужна? Можете коротко рассказать?
Я думала, они выбрали Cosmos этот, т.к нужно же из API брать таблицы и думала что как раз Cosmos для этого подходит...

Вопрос был правильный ранее - какие объемы?
и добавлю - интересует обе цифры - как общий объем ожидаемых хранимых данных так и INGRESS/min/hour/day
Я пока не знаю, но как только узнаю -напишу...

Чтобы вы понимали - я была 6 лет BI developer. Работала ТОЛЬКО с реляционной моделью данных, с готовой (+ достраивала немного).

Я не совсем понимаю - что это за зверь API... -( Уже немного "играюсь" с этим, но принцип пока не совсем понимаю.

Как понять какой обьем данных у нас?
Все что я знаю - парень (инженер вроде) использовал Azure Data Pipelines - сделал .csv фаил берущий таблицы из API.
Как я поняла - Azure Data Pipelines нормализовали эти таблицы - но мб ошибаюсь - я уточню как именно он нормализовал их.
Затем он вручную коннектед .csv в Power BI и там сделал расчеты.

API таблицы - это Agent List, Pool List - для kubernetes...Я их конечно умею смотреть...
Но - как я поняла, там же только последние / свежие записи? Или нет? Как мне узнать наш объем данных?


Сорри, за глупые вопросы -
1. читаем сырые данные через рест - можно подробнее про это? Или мб ссылу на мануал какой...?
2. скидываем в очередь (QUEUE TBD) Тоже я не знаю что это...
3. сервис или функция берет данные из очереди, трансформирует и кидает в реляционную БД (TBD) или ADX (azure data explorer)


ПС-
Это новая для меня роль (на интервью речь шла об обычнои разработке расчетов в реляц модели. Точнее те люди кто хоть
немного етим занимался меня интервьюировали). А выяснилось вот это.
Но мне интересно. Каких-то особых дедлаинов нет у меня... Начальники сами не знают что хотят и поручили мне все вот ето -))

Короче - мне надо все ето постепенно осваивать

[Mad Hatter]

Новичкам обычно поручают работу которую в тиме никто не хочет делать

[urod]

Главная цель Cosmos DB (как и любой другой NoSql db) - быстрый поиск в огромных объемах данных.
Для этого был введен принцип partition key.
Скажем у вас 10^12 records. В случее традиционного SQL - вам нужно будет сканировать индекс для 10^12 records.
В NoSql db вы разбиваете данные по partitions - скажем 10^6 partitions.
Любой запрос в NoSql db - выливается в два запроса - первый - найти нужный partition out of 1 million - и второй - найти нужную запись внутри конкретного partition (а там будет не 10^12 records, а только миллион - в миллион раз меньше)
Если не вы не включили в запрос partition key - будет сканироваться все - и это будет супер долго и супер дорого.
Для аналитики - Cosmos DB хорош, если у вас один и только один тип данных - например orders - где купленные items идут как Json array внутри order. Если у вас есть другой тип данных (customers например) - вы не сможете сделать JOIN как в SQL.
JOIN в Cosmos DB - это поиск внутри одного типа данных.

[elpresidente*]

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

Ответьте сами себе на вопросы:
1. Какие именно данные (формат, средний размер фаилов) вы имеете на входе?
2. Как и откуда поступают оригинальные данные и как часто это происходит (несколько раз в день/час/секунду)?
3. Ожидаемый финальный результат (Power BI reports?)

Как правило такие задачи сводятся к сбору данных [1], как вам уже посоветовали вы можете использовать lambda function для сохранения оригинальных данных (файлов) в S3 bucket.
В зависимости от обьема данных и необходимой частоты загрузки вы можете сделать lambda function на таймере для загрузки данных [2] из S3 bucket в ваши БД или ту-же самую lambda function повесить на триггер для оперативной загрузки данных в выбраную БД.
Как и где вы будете обрабатывать данные [3] решать вам, большой обьем данных которые надо отображать в near-real-time скорее всего будет лучше работать с CosmosDB, если данных мало и/или он хорошо структурированы и/или данные обрабатываются раз/два в день то скорее всего лучше подойдет классический Azure SQL.

Обратите внимание что при таком подходе ваш процесс будет разбит на (как минимум) три независимых задачи которые вы можете решать отдельно. Дополнительный плюс в том что после того как данные сохранены в S3 вы может сделать несколько pilot проетков и поиграть с тем как и куда их загружать для [3]. Если что-то пойдет не так вы всегда можете закачать весь обьем данных с нуля из S3. В принципе если данных "мало" (<GB) Power BI может грузить их прямо из S3, имейте это ввиду.

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

[VikKur]

Главная цель Cosmos DB (как и любой другой NoSql db) - быстрый поиск в огромных объемах данных.
Для этого был введен принцип partition key.
Скажем у вас 10^12 records. В случее традиционного SQL - вам нужно будет сканировать индекс для 10^12 records.
В NoSql db вы разбиваете данные по partitions - скажем 10^6 partitions.
Любой запрос в NoSql db - выливается в два запроса - первый - найти нужный partition out of 1 million - и второй - найти нужную запись внутри конкретного partition (а там будет не 10^12 records, а только миллион - в миллион раз меньше)
Если не вы не включили в запрос partition key - будет сканироваться все - и это будет супер долго и супер дорого.
Для аналитики - Cosmos DB хорош, если у вас один и только один тип данных - например orders - где купленные items идут как Json array внутри order. Если у вас есть другой тип данных (customers например) - вы не сможете сделать JOIN как в SQL.
JOIN в Cosmos DB - это поиск внутри одного типа данных.

с nosql не работал, но ещё в 2000 на курсе по ораклу нам рассказывали про то, как отключить индекс(а это надо делать) для выборки low cardinality данных (если выбирается больше 1/4 обьёма. там простая арифметика - индексы это b-trees. для нахождения значения надо 3 раза обратиться к индексу и 1 к самой базе. если быбираешь много - быстрее full table scan ). сейчас вроде oracle умеет сам это делать (все эти analyze table и тд)...да и использование partitions в оракле очень приветствовалось...

[Inostranka_02]

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

Ответьте сами себе на вопросы:
1. Какие именно данные (формат, средний размер фаилов) вы имеете на входе?
2. Как и откуда поступают оригинальные данные и как часто это происходит (несколько раз в день/час/секунду)?
3. Ожидаемый финальный результат (Power BI reports?)

Как правило такие задачи сводятся к сбору данных [1], как вам уже посоветовали вы можете использовать lambda function для сохранения оригинальных данных (файлов) в S3 bucket.
В зависимости от обьема данных и необходимой частоты загрузки вы можете сделать lambda function на таймере для загрузки данных [2] из S3 bucket в ваши БД или ту-же самую lambda function повесить на триггер для оперативной загрузки данных в выбраную БД.
Как и где вы будете обрабатывать данные [3] решать вам, большой обьем данных которые надо отображать в near-real-time скорее всего будет лучше работать с CosmosDB, если данных мало и/или он хорошо структурированы и/или данные обрабатываются раз/два в день то скорее всего лучше подойдет классический Azure SQL.

Обратите внимание что при таком подходе ваш процесс будет разбит на (как минимум) три независимых задачи которые вы можете решать отдельно. Дополнительный плюс в том что после того как данные сохранены в S3 вы может сделать несколько pilot проетков и поиграть с тем как и куда их загружать для [3]. Если что-то пойдет не так вы всегда можете закачать весь обьем данных с нуля из S3. В принципе если данных "мало" (<GB) Power BI может грузить их прямо из S3, имейте это ввиду.

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

Пока только пытаюсь разбираться. Ничего не делаю...

Ответьте сами себе на вопросы:
1. Какие именно данные (формат, средний размер фаилов) вы имеете на входе?
json document, не большие файлы. Кажется 1к записей или меньше 1к-5к или даже меньше

2. Как и откуда поступают оригинальные данные и как часто это происходит (несколько раз в день/час/секунду)?
Из API - есть автоматизация (Azure pipelines) которая берет API данные и закачивает в .csv файл.
Как часто - сеичас кажется pipeline refresh отключен . А планируется refresh где-то раз в день

3. Ожидаемый финальный результат (Power BI reports?)
Да !!! Ето то что знаю 100%


По написанному вами ниже, несколько concerns -

lambda function - что за зверь такой? (Я конечно почитаю и надеуись разберусь) Но у меня только реляц базы данных бакграунд
How complex this is?

Судя по всему, Azure sql может лучше подоити.

Вопрос - КАК-откуда его взять-установить? У нас имеется Azure DevOps platform, Azure Portal - если ето как-то поможет мне
Главное за что я опасаюсь - не вполне понимаю - Как из формата JSON потом преобразовать данные в реляционную БД - в формат пригодный для создания расчетов в Power BI?
КАК именно автоматизировать? С помощю етого Azure SQL?


<Вам имеет смысл сделать презентацию на 5-6 страниц с тем как вы будете реализовывать данный проект (см выше), описать основные шаги и все pros/cons предлагаемых решений. Это поможет вам лучше оценить задачу и после того как вы представите это вашему босу и тем с кем вы работаете на этом проекте собрать критику и полезные коментарии.>
looks like it Allmouth it's a bit messy in my head now, I hope to clarify my prospective steps

[elpresidente*]

Azure functions это примерно как ETL в MSSQL/Power BI, очень полезная вещь в Cloud Computing.
Вам похоже вообще не надо никакой БД, обьем данных скорее всего не превысит сотни MB в год. Вы можете грузить данные прямо из Аure Blob Storage в Power BI, что-то типа этого.
ПС
AWS | Azure
S3 | Аure Blob Storage
Lambda Function | Azure function

[Inostranka_02]

Azure functions это примерно как ETL в MSSQL/Power BI, очень полезная вещь в Cloud Computing.
Вам похоже вообще не надо никакой БД, обьем данных скорее всего не превысит сотни MB в год. Вы можете грузить данные прямо из Аure Blob Storage в Power BI, что-то типа этого.
ПС
AWS | Azure
S3 | Аure Blob Storage
Lambda Function | Azure function

Спасибо за подсказки
У нас сеичас выходные, и у меня домашние дела, we'll resume on Tue
Если можно, я хочу написать вам кое-какие вопросы - для етого мне нужно пару дней и work pc
Хочу написать + в картинках показать мои вопросы (нужно чуть больше веремени + норм доступ к work links, pc etc.) - тогда смогу дальше идти

Zaranee spasibo!

[Inostranka_02]

Захотелось написать update по теме, с чем в результате я (мы) стали работать

1 API данные собираются с помощью PowerShell, в .csv файл (имеющий связи Agents / Pools в одном файле)
Azure Pipeline обновляет етот .csv
Файл хранится на SharePoint

Этот пункт будет заменен - в Fabric Lakehouse Notebook с помощью Python можно сделать то же самое что в п1.
и сформировать таблицу с raw data как .csv


2 Fabric Dataflow берет .csv (в моем случае 2 шт) -> destination Fabric Warehouse

3 в Fabric Warehouse создаются Dim-Fact tables

4 Fabric Pipeline берет данные из Dataflow (Dataflow command) -> Lookup (Lookup command, куда вставляется SQL code которыи распредиляет данные в Dim-Fact tables из Dataflow table) - scheduled refresh

5 Power BI Desktop связывет с Lakehouse SQL Endpoint, где разработчик создает measures, и публикует в PBI portal
Semantic Model scheduled refresh


Чтобы не создавать .csv - будем использовать Python in Notebook для сбора API data - в Lakehouse
Мне болъше нравится Fabric Warehouse - там имеется нормальныи SQL, и больше деиствии разрешено
V Lakehouse нельзя create table, drop table, и у меня лично проблемы с scheduling (но возможно временные)

А так уже проверила, презентовала - для маленьких или мизерных обемов, для небольших и где мало таблиц - все работает
Впоследствии можно будет переити на Azure Data Factory, тем более что код я все равно пишу в Azure SQL Visual Studio
В Фабриках только выполняю


Доп вопрос -
Посоветуйте пожалуиста материалы самые лучшие (хорошие) для изучения Python - ето мне надо

Также, попросили материалы для изучения Dimension Fact tables, DB relations -
(ето сотрудник кто из "мира scripting" попросил - а я училась на работе, в проектах - не по manuals. Или основы очень много лет назад)

Если тут вопрос не увидят, напишу отдельно

Спасибо, как всегда!

[Uzito]

Посоветуйте пожалуиста материалы самые лучшие (хорошие) для изучения Python - ето мне надо

Для разных манипуляций с данными обычно используется pandas.
Типа взять большой файл / json из REST API, разбрать на составные части, сделать эти самые таблички с фактами/измерениями, объединить с имеющимеся измерениями, записать всё в базу / создать файлы для загрузки в базу другиме методом.

К сожалению конкретного курса на udemy привести не могу, брал их с рабочего аккаунта на прошлой работе.

[voyager3]

https://www.oreilly.com/library/view/fl ... 492056348/

[Inostranka_02]

Посоветуйте пожалуиста материалы самые лучшие (хорошие) для изучения Python - ето мне надо

Для разных манипуляций с данными обычно используется pandas.
Типа взять большой файл / json из REST API, разбрать на составные части, сделать эти самые таблички с фактами/измерениями, объединить с имеющимеся измерениями, записать всё в базу / создать файлы для загрузки в базу другиме методом.

К сожалению конкретного курса на udemy привести не могу, брал их с рабочего аккаунта на прошлой работе.

Насколько я поняла, у нас возможно и есть Pandas (будет training session кто меня немного научит) - ето можно использовать в Fabric Lakehouse. Я не знала, что с помоью Python можно делать Dim Fact таблицы, и потом туда данные записывать, тк я не знаю Python.

Интересно, а с помощью Python можно ли использовать операции сложнее INSERT INTO?
Например, динамическии UNPIVOT или CROSS JOIN?

Мы пока не используем именно real базу данных. А только Fabric Warehouse - но, если что, я умею переписывать данные (именно replace) - из Lakehouse (где етот самый Python) в Warehouse


PS-
Сеичас почитала...
Оказывается в PySpark этом - Python в Ms Lakehouse - деиствительно можно создавать таблицы и делать почти все не сложные манипуляции такие как INSERT INTO, TRUNCATE, JOIN etc - а если надо DELETE FROM и удалить все записи, то можно TRUNCATE использовать.

И Warehouse возможно и не нужен - по кр мере в нашем случае- с минимум таблиц и минимальными размерами ...