Это сбор и обработка данных по своим инвестициям, с более детальной аналитикой, чем предоставляет Брокер.
К примеру, можно купить бумагу за 100р три года назад, получать каждый год дивиденды в размере 10р. Через три года, инвестор решает продать эту бумагу, но текущая рыночная цена составляет 80р.
Вопрос, терзающий инвестора: продаю по текущей цене — это фиксация убытка по этой бумаге за весь срок инвестирования или небольшого дохода с учетом дивидендов и иных выплат?
Брокер не дает такую аналитику, приходится вручную парсить отчеты.
Ps. У них сейчас добавилась «фишка» отображения дивидендов и купонов за период, но она оторвана от бумаг в портфеле и не влияет на отображаемый финрез по позиции.
Можно сразу нарезать нужные пробросы портов или засунуть контейнеры в нужные докер-сети для внутренней коммуникации
Соглашусь с комментарием, однако, в статье основная мысль — реализация алгоритма сверки данных и лично мне было не сложно прописать ip-адрес в конфиге, запустив перед этим:
docker inspect pg
Docker network здесь выглядит оверхедом.
По SQL — почему не используется подстановка аргументов на уровне SQL, а они жестко вшиваются format'ом в строчку на уровне самого python?
Вы имеете в виду передачу имени объектов (схемы и таблицы) в качестве параметров курсору? Если да, то так делать не рекомендуется документацией psycopg
если в лоб писать в несколько процессов — они могут писать вразнобой, в результате — файл будет содержать записи вперемешку, и что хуже — сами записи будут разбиты) и как чтение — потому что чтение по границе 5МБ может повредить (разорвать) одну строчку CSV
Этот кусок кода должен помочь понять как реализовано чтение файла:
with open(self.file_name_raw, 'rb') as file:
chunk_end = file.tell()
while True:
chunk_start = chunk_end
file.seek(size, 1)
file.readline()
Тут одна хитрость, мы смещаемся при помощи seek(size, 1) на 5 мегабайт относительно текущей позиции, но readline() дочитывает до конца строки для избежания «поломки». Т.е. всегда генератором chunkify перед процессом чтения разбивается файл по ~5Мб так, что каждый чанк будет примерно одинакового размера, но при этом нет опасений, что какой-либо фрагмент будет начинаться с середины строки или заканчиваться не в конце.
Можете на примере пояснить, что это за база такая и зачем она?
Подозреваю, что под «промежуточной БД» имелся в виду стейджинг, куда сливаются данные из источников в исходном качестве без обработки.
а про ELT «Промежуточная база данных отсутствует»
Популярным кейсом является хранение данных на HDFS, который не требует дизайна схемы. А уже в момент чтения, обозначаем нужную смеху поверх сырых исходных данных.
Цельнастоящей статьи — дать вернеуровневый обзор по теме, без подробной детализации.
плюс перевод ещё больше местами путает
Буду признателен, если укажете на ошибки и неточности перевода.
спорных интерпретаций различных понятий (например, ETL)
Насчет описания ETL с Вами соглашусь: данные извлечаются далеко не только из транзакционных БД. Это могут быть всевозможные источники, от текстовых файлов, заканчивая любыми экзотическими решениями. Позволю себе отойти от оригинального текста и исправлю текст.
Все правильно, у Лямбды (как у любого другого сервиса Amazon) есть некоторые ограничения (AWS Lambda Limits) по умолчанию — 1000 параллельных запусков. Для увеличения лимита — необходимо обратиться в поддержку с просьбой об увеличении лимита сервиса в конкретном регионе.
Инструменты, которые используются в статье, Amazon в официальной документации позиционирует как «бессерверные», и каждый раз указывает на это как на преимущество: AWS Lambda — бессерверный сервис вычислений, AWS API Gateway — бессерверные автомасштабируемые API.
Вы использовали Лямбду совместно с API Gateway? Дело в том, что у вызова API Gateway могут быть заданы ограничения по количеству запусков в день/неделю/месяц:
Основная идея статьи — это дать представление как можно создавать облачный API используя сервисы Amazon AWS API Gateway, без привязки к какой-либо конкретной реализации это API. Если Вы обратили внимание, то в статье упомянуто, что информация для текущих целей не столь важна.
Ps. Вы правы, пагинация выдаваемой информации из базы данных, наверное, смотрелась бы более эффектно, но цель статьи, еще раз повторюсь, показать простоту процесса создания автомасштабируемого API.
Буду благодарен, если Вы поделитесь более эффективным способом считывания информации из текстового файла :)
Браво!
А имеется связь ли между правильным подходом к сотруднику и результатами его работы?
К примеру, можно купить бумагу за 100р три года назад, получать каждый год дивиденды в размере 10р. Через три года, инвестор решает продать эту бумагу, но текущая рыночная цена составляет 80р.
Вопрос, терзающий инвестора: продаю по текущей цене — это фиксация убытка по этой бумаге за весь срок инвестирования или небольшого дохода с учетом дивидендов и иных выплат?
Брокер не дает такую аналитику, приходится вручную парсить отчеты.
Ps. У них сейчас добавилась «фишка» отображения дивидендов и купонов за период, но она оторвана от бумаг в портфеле и не влияет на отображаемый финрез по позиции.
Docker network здесь выглядит оверхедом.
Вы имеете в виду передачу имени объектов (схемы и таблицы) в качестве параметров курсору? Если да, то так делать не рекомендуется документацией psycopg
Этот кусок кода должен помочь понять как реализовано чтение файла:
Тут одна хитрость, мы смещаемся при помощи seek(size, 1) на 5 мегабайт относительно текущей позиции, но readline() дочитывает до конца строки для избежания «поломки». Т.е. всегда генератором chunkify перед процессом чтения разбивается файл по ~5Мб так, что каждый чанк будет примерно одинакового размера, но при этом нет опасений, что какой-либо фрагмент будет начинаться с середины строки или заканчиваться не в конце.
Прямо так сразу «неправильно»? Вы знакомы с прямым подходом, когда исполнители Spark читают данные непосредственно из Kafka?
Популярным кейсом является хранение данных на HDFS, который не требует дизайна схемы. А уже в момент чтения, обозначаем нужную смеху поверх сырых исходных данных.
Буду признателен, если укажете на ошибки и неточности перевода.
Насчет описания ETL с Вами соглашусь: данные извлечаются далеко не только из транзакционных БД. Это могут быть всевозможные источники, от текстовых файлов, заканчивая любыми экзотическими решениями. Позволю себе отойти от оригинального текста и исправлю текст.
Приставки Без-/Бес-
Примеры широкого использования формулировки «бессерверный»:
Википедия
Amazon
AWS Lambda Runtimes
Благодарю за внимательность!
Большое спасибо за ссылку! Очень интересно!
Рекомендую для краткого ознакомиться здесь:
Так же у AWS достаточно подробная документация с примерами.
Ps. Вы правы, пагинация выдаваемой информации из базы данных, наверное, смотрелась бы более эффектно, но цель статьи, еще раз повторюсь, показать простоту процесса создания автомасштабируемого API.
Буду благодарен, если Вы поделитесь более эффективным способом считывания информации из текстового файла :)