дитетко, ни в одном банке ты не найдешь nosql процессящих транзакции. и поменьше слушай блогеров, software bug завалит все ноды nosql точно так же. я лично на хадупе проверял.
школоло, пойди сначала разберись, чем фин транкции отличаются от веба, с его примитивными инсертами на IL RC. там и мусору неоткуда взяться.
по рац, блогер с бэкраундом постгреса слышал «at least qualified Oracle experts tell me so» (тм). аргумент суръезный. зачет.
нет. хадуп и гит банки используют ровно там где они лучшие и никакие распилы этому не помеха. в обработке транзакций лучший оракл, потому используют оракл. будет хадуп с kudu лучше оракла транзакции процессить, переключаться на хадуп. и никакие распилы хадуп не остановят.
у постгреса просто не подходящая архитектура с уборкой мусора, не подходящая под тяжелый поток транзакций, нет настоящего кластера. у оракла же волшебный UNDO и RAC. вот причина, распилы тут не причем.
только по факту на бесплатном линуксе и хадупе строить системы банк ответственности не боится. апач, томкат, гит, свн… нормальным опенсоурс системам в банке никакие распилы не мешают.
да. ораклу за именно за это волшебство и платят миллиарды, что выключение питание и ни одного разрыва. а постгрес бесплатен, потому как выключение и он теряет транзакции. банку пофигу сколько там стоит постгрес и спец, если эта комбинация не способна при простом выключении пары нод клстера хоть чего либо гарантировать. у orace rac есть кэш, распределяющийся по нодам кластера, есть шаред диск, гарантирующий запись на все 100.000%. в постгресе же нет ничего похожего. потому в банке оракл, с его волшебством.
маркетниг тут не причем, отставание у мсскл и постгрес от оракла 8 вышедшего лет 20 назад все еще огромно. ни у того ни у другого нет даже примитивных пакетов, нет отслеживания зависимостей, нет кластера, у постгреса нет даже партишенинга нормального или многоболочного чтения под капотом. мсскл прилепили версионность сбоку, но в таком виде (версии в темпдб) это скорее пародия, чем конкурент, хотя в зазуре это уже дефолтный уровень изолированности.
шардинг в 12ю версию оракла завезли.
дата лейк на mysql где тоже нет ни колончатых таблиц и многоблочного чтения, да — глупость.
мне не жалко, а вот банку эти 3 рубля комиссии с коммуналки нафиг не нужны, т.к. он делал для своих клиентов отделение. а тут выходит конкурент забил на отделения и пытается повесить обсуживать своих клиентов на сбер. конкурент то ради столь шикарной комиссии не стал отделение строить.
я тоже слегка озадачен дизайном. с хадупа бомбить хттп реквестами !? это же противоречит идеям бигдаты. менее велосипедно было бы наверно jppml дергать прямо из датафреймов спарка
хм… заинтригован. а кто у вас заботиться за хранение? как я понимаю нечто не в облаке, причем не в облаке от того что в облаке хранить чудовщно дорого.
изначально я рассуждал с точки зрения мелкого бизнеса, но сам то сейчас в энтерпрайз проекте: 20+ стран, 20+ тысяч хомячков.
у нас сделано не шибко оптимально, но вина в том дешевизна ресурсов, которые маскируют любой наш абсурд.
пока у нас по большому счету калька с ораклвого dwh и вполне похоже на ваш воркфлоу. единсвенно батчи приходят уже в стандартизованном виде, т.е. уже не шибко похожие на сырые. батчи обрабатываются, вычисляется дельта, то что хоть как-то распарсилось импортируется в хранилище. как и увас витрины строяться из хранилища. за витринами стоит bi/qlik, который не замечает что ему на 10 раз на день всю витрину каждый раз с нуля строят. qlik имеет свое хитрое хранилище с ориентацией на все пихать в память, нагрузка на витрины от qlik вообще нулевая.
прикрутить speed layer на spark/kafka и писать обогощенные данные точно в такие же паркеты как и витрины совершенно не проблема. на мой взгляд элегантно это можно лишь на том же кластере, т.к. обработка на лету потребует джоинить с витринами.
от статьи попахивает дремучестью.
1. фишка exadata умение разбирать SQL, а не выступать тупым блочным сториджем для которого субд просто набор файликов. понятно что у вы не альтернатива oracle exadata.
2. к чему там hdfs упомянут? у вас тупой сторидж без ничего. какое отношение стоидж без ничего к бигдате и hdfs? суть hdfs в том что оно интегрировано в ядро хадупа, который запускает код на том же узле, где лежат данные. у вас же просто сторидж.
престо лучше только на двух простых запросах в параллель. в современном мире обычно это BI инструмент на себя берет, как по мне судя по графику там никто не справился, респонс под 40 секунд.
про тапок не понял, у меня в проекте клоудера, в том числе и спарк имеется. все вполне управляемо, правда пришлось самим писать оркестровку поверх спринга.
по gdpr — мы получаем персональные данные клиентов наших клиентов. многим контрактам 20 и более лет. передавать их данные еще куда-то незаконно. мы даже не можем для себя строить модели на их данных, т.к. их клиенты передали свои перс данные под другие цели. данные есть, но мы отказываемся по ним строить модели даже своими силами.
т.е. по любому если я захочу витрины на чем-то сранимым с импалой это космические деньги за redshift. при этом я с задачами где витрины нужны были бы лишь на время не пересекался. у нас везде витрины или нужны или нет, посему не совсем понимаю о чем речь на счет удалять redshift кластер.
про лямбду слышал, собственно на нее и намекал. kinesis, aws emr конечно класно, но как видим если строить что-то современное с возможностями реалтайма, то мы вынуждены лепить именно «как у меня в DC было».
aws emr это цена… тот же разрыв со своей железкой в 5 раз, что и accenture для google dataproc насчитала. железячка 1x16 ядер тредриппера стоит порядка $5к, на интельных по 2x8 ядер порядка $6k, полно предложений арендовать такое за $300 в месяц. т.е. 5 нод это что-то около $1500 в месяц за железо + 1.5 админа на зарплате. на мой вкус это ближе к уровеню малого бизнеса. kinesis, aws emr, redshift, s3 стрридж способный посорвноваться с теми пяти нодами явно вытянут на счета $10+ тысяч. я понимаю что можно ужаться там, рискнуть со spot и прочее. но по большому счету у них облачные цены подогнаны на их зарплаты, на их электричество. так что однозначного плюса в облаках на нашей широте не будет, при этом, например, у нас я вижу большие юридические вопросы. персональные данные, gdpr, согласие клиентов передавать данные третьим лицам.
по рац, блогер с бэкраундом постгреса слышал «at least qualified Oracle experts tell me so» (тм). аргумент суръезный. зачет.
у постгреса просто не подходящая архитектура с уборкой мусора, не подходящая под тяжелый поток транзакций, нет настоящего кластера. у оракла же волшебный UNDO и RAC. вот причина, распилы тут не причем.
шардинг в 12ю версию оракла завезли.
дата лейк на mysql где тоже нет ни колончатых таблиц и многоблочного чтения, да — глупость.
логика ущербна.
msropendata.com/categories
например Economics уже нет
изначально я рассуждал с точки зрения мелкого бизнеса, но сам то сейчас в энтерпрайз проекте: 20+ стран, 20+ тысяч хомячков.
у нас сделано не шибко оптимально, но вина в том дешевизна ресурсов, которые маскируют любой наш абсурд.
пока у нас по большому счету калька с ораклвого dwh и вполне похоже на ваш воркфлоу. единсвенно батчи приходят уже в стандартизованном виде, т.е. уже не шибко похожие на сырые. батчи обрабатываются, вычисляется дельта, то что хоть как-то распарсилось импортируется в хранилище. как и увас витрины строяться из хранилища. за витринами стоит bi/qlik, который не замечает что ему на 10 раз на день всю витрину каждый раз с нуля строят. qlik имеет свое хитрое хранилище с ориентацией на все пихать в память, нагрузка на витрины от qlik вообще нулевая.
прикрутить speed layer на spark/kafka и писать обогощенные данные точно в такие же паркеты как и витрины совершенно не проблема. на мой взгляд элегантно это можно лишь на том же кластере, т.к. обработка на лету потребует джоинить с витринами.
1. фишка exadata умение разбирать SQL, а не выступать тупым блочным сториджем для которого субд просто набор файликов. понятно что у вы не альтернатива oracle exadata.
2. к чему там hdfs упомянут? у вас тупой сторидж без ничего. какое отношение стоидж без ничего к бигдате и hdfs? суть hdfs в том что оно интегрировано в ядро хадупа, который запускает код на том же узле, где лежат данные. у вас же просто сторидж.
про тапок не понял, у меня в проекте клоудера, в том числе и спарк имеется. все вполне управляемо, правда пришлось самим писать оркестровку поверх спринга.
по gdpr — мы получаем персональные данные клиентов наших клиентов. многим контрактам 20 и более лет. передавать их данные еще куда-то незаконно. мы даже не можем для себя строить модели на их данных, т.к. их клиенты передали свои перс данные под другие цели. данные есть, но мы отказываемся по ним строить модели даже своими силами.
cdn2.hubspot.net/hubfs/488249/Asset%20PDFs/Benchmark_BI-on-Hadoop_Performance_Q4_2016.pdf
т.е. по любому если я захочу витрины на чем-то сранимым с импалой это космические деньги за redshift. при этом я с задачами где витрины нужны были бы лишь на время не пересекался. у нас везде витрины или нужны или нет, посему не совсем понимаю о чем речь на счет удалять redshift кластер.
про лямбду слышал, собственно на нее и намекал. kinesis, aws emr конечно класно, но как видим если строить что-то современное с возможностями реалтайма, то мы вынуждены лепить именно «как у меня в DC было».
aws emr это цена… тот же разрыв со своей железкой в 5 раз, что и accenture для google dataproc насчитала. железячка 1x16 ядер тредриппера стоит порядка $5к, на интельных по 2x8 ядер порядка $6k, полно предложений арендовать такое за $300 в месяц. т.е. 5 нод это что-то около $1500 в месяц за железо + 1.5 админа на зарплате. на мой вкус это ближе к уровеню малого бизнеса. kinesis, aws emr, redshift, s3 стрридж способный посорвноваться с теми пяти нодами явно вытянут на счета $10+ тысяч. я понимаю что можно ужаться там, рискнуть со spot и прочее. но по большому счету у них облачные цены подогнаны на их зарплаты, на их электричество. так что однозначного плюса в облаках на нашей широте не будет, при этом, например, у нас я вижу большие юридические вопросы. персональные данные, gdpr, согласие клиентов передавать данные третьим лицам.