Мы жывем у дзіўны час, калі можна хутка і проста сутыкаваць некалькі гатовых адкрытых інструментаў, наладзіць іх з «адключанай свядомасцю» па парадах stackoverflow, не ўнікаючы ў «шматлітар», запусціць у камерцыйную эксплуатацыю. А калі трэба будзе абнаўляцца/пашырацца ці хтосьці выпадкова перазагрузіць пару машын - усвядоміць, што пачаўся нейкі дакучлівы дурны сон наяве, усё рэзка ўскладнілася да непазнавальнасці, шляхі назад няма, будучыня імгліста і бяспечней, замест праграмавання, разводзіць пчол і рабіць сыр.
Нездарма ж, больш дасведчаныя калегі, з пасыпанай багамі і ад гэтага ўжо сівой галавой, сузіраючы непраўдападобна хуткае разгортванне пачкаў "кантэйнераў" у "кубіках" на дзясятках сервераў на "модных мовах" з убудаванай падтрымкай асінхронна-неблакіруючага ўводу-вываду. . І моўчкі працягваюць перачытваць "man ps", унікаюць да крывацёку з вачэй у зыходнікі "nginx" і пішуць-пішуць-пішуць юніт-тэсты. Калегі ведаюць, што самае цікавае будзе наперадзе, калі "ўсё гэта" аднойчы стане ноччу калом пад Новы год. І ім дапаможа толькі глыбокае разуменне прыроды unix, завучанай табліцы станаў TCP/IP і базавых алгарытмаў сартавання-пошуку. Каб пад бой курантаў вяртаць сістэму да жыцця.
Ах так, крыху адцягнуўся, але стан прадчування, спадзяюся, атрымалася перадаць.
Сёння я жадаю падзяліцца нашым досведам разгортвання зручнага і недарагога стэка для DataLake, вырашальнага большасць аналітычных задач у кампаніі для зусім розных структурных падраздзяленняў.
Некаторы час таму мы прыйшлі да разумення, што кампаніі ўсё мацней і мацней патрэбны плён як прадуктовай, так і тэхнічнай аналітыкі (не кажучы ўжо пра вішаньку на торце ў выглядзе machine learning) і для разумення трэндаў і рызык - трэба збіраць і аналізаваць усё больш і больш. больш метрык.
Базавая тэхнічная аналітыка ў "Бітрыкс24"
Некалькі гадоў таму, адначасова з запускам сэрвісу "Бітрыкс24", мы актыўна інвеставалі час і рэсурсы ў стварэнне простай і надзейнай аналітычнай платформы, якая б дапамагала хутка ўбачыць праблемы ў інфраструктуры і спланаваць бліжэйшы крок. Зразумела, прылады пажадана было ўзяць гатовыя і максімальна простыя і зразумелыя. У выніку быў абраны nagios для маніторынгу і munin для аналітыкі і візуалізацыі. Цяпер у нас тысячы праверак у nagios, сотні графікаў у munin і калегі штодня і паспяхова імі карыстаюцца. Метрыкі зразумелыя, графікі ясныя, сістэма працуе надзейна ўжо некалькі гадоў і ў яе рэгулярна дадаюцца новыя тэсты і графікі: уводзім новы сэрвіс у эксплуатацыю - дадаем некалькі тэстаў і графікаў. У добры шлях.
Рука на пульсе – пашыраная тэхнічная аналітыка
Жаданне атрымліваць інфармацыю аб праблемах "як мага хутчэй" прывяло нас да актыўных эксперыментаў з простымі і зразумелымі інструментамі – pinba і xhprof.
Pinba адпраўляла нам у UDP-пакетыках статыстыку аб хуткасці працы частак вэб-старонак на PHP і можна было ў рэжыме анлайн бачыць у сховішча MySQL (c pinba ідзе свой рухавічок MySQL для хуткай аналітыкі падзей) кароткі спіс праблем і рэагаваць на іх. А xhprof у аўтаматычным рэжыме дазваляў збіраць графы выканання найболей павольных PHP-старонак у кліентаў і аналізаваць, што да гэтага магло прывесці – спакойна, наліўшы гарбату ці чаго-небудзь мацней.
Некаторы час таму інструментарый быў папоўнены яшчэ адным даволі простым і зразумелым рухавіком на аснове алгарытму зваротнай індэксацыі, выдатна рэалізаваным у легендарнай бібліятэцы Lucene – Elastic / Kibana. Простая ідэя шматструменнага запісу дакументаў у інверсны індэкс Lucene на базе падзей у логах і хуткі пошук па іх з выкарыстаннем фасетнага дзялення – апынулася, і праўда, карысная.
Нягледзячы на даволі тэхнічны выгляд візуалізацый у Kibana з «працякаючымі ўверх» нізкаўзроўневымі канцэпцыямі тыпу «bucket» і нанава вынайдзеную мову зусім яшчэ не забытай рэляцыйнай алгебры – прылада стала добра нам дапамагаць у наступных задачах:
- Колькі было памылак PHP у кліента Битрикс24 на партале p1 за апошнюю гадзіну і якіх? Зразумець, прабачыць і хутка выправіць.
- Колькі было зроблена відэа-званкоў на парталах у Германіі за папярэднія 24 гадзіны, з якой якасцю і ці былі складанасці з каналам/сеткай?
- Наколькі добра працуе сістэмны функцыянал (наша пашырэнне на C для PHP), скампіляваны з зыходнікаў у апошнім абнаўленні сэрвісу і раскочаны кліентам? Ці няма segfaults?
- Ці змяшчаюцца дадзеныя кліентаў у памяць PHP? Ці няма памылак перавышэння вылучанай працэсам памяці: "out of memory"? Знайсці і абясшкодзіць.
Вось канкрэтны прыклад. Нягледзячы на дбайнае і шматузроўневую тэставанне, у кліента, пры вельмі нестандартным кейсе і пашкоджаных уваходных дадзеных з'явілася прыкрая і нечаканая памылка, загучала сірэна і пачаўся працэс яе хуткага выпраўлення:
Дадаткова, kibana дазваляе арганізаваць апавяшчэнне па паказаных падзеях і за кароткі час прыладай у кампаніі сталі карыстацца дзясяткі супрацоўнікаў з розных падраздзяленняў – ад тэхпадтрымкі і распрацоўкі да QA.
Актыўнасць любога падраздзялення ўнутры кампаніі стала зручна адсочваць і вымяраць - замест ручнога аналізу логаў на серверах, дастаткова адзін раз наладзіць парсінг логаў і іх адпраўку ў кластар elastic, каб атрымліваць асалоду ад, напрыклад, сузіраннем у дашбордзе kibana колькасці прададзеных двухгаловых кацянят, надрукаваных на 3-d друкарцы за мінулы месяцовы месяц.
Базавая бізнес-аналітыка
Усё ведаюць, што часта бізнэс-аналітыка ў кампаніях пачынаецца з экстрэмальна актыўнага выкарыстання, так, так, Excel. Але, галоўнае, каб яна ў ім не сканчалася. Масла ў агонь яшчэ добра падлівае хмарны Google Analytics - да добрага пачынаеш хутка прывыкаць.
У нашай, гарманічна якая развіваецца кампаніі, сталі то тут, то там, з'яўляцца "прарокі" больш інтэнсіўнай працы з буйнейшымі дадзенымі. Рэгулярна сталі з'яўляцца патрэбы ў больш глыбокіх і шматгранных справаздачах і намаганнямі рабят з розных падраздзяленняў некаторы час таму было арганізавана простае і практычнае рашэнне – звязак ClickHouse і PowerBI.
Даволі доўгі час гэтае гнуткае рашэнне выдатна дапамагала, але паступова стала прыходзіць разуменне, што ClickHouse – не гумовы і нельга над ім так здзекавацца.
Тут важна добра зразумець, што ClickHouse, як і Druid, як і Vertica, як і Amazon RedShift (які на базе postgres), гэта аналітычныя рухавічкі, аптымізаваныя на даволі зручную аналітыку (сумы, агрэгацыі, мінімум-максімум па калонцы і трошкі можна джойнаў ), т.я. арганізаваны для эфектыўнага захоўвання калонак рэляцыйных табліц, у адрозненне ад вядомага нам MySQL і іншых (row-oriented) баз дадзеных.
У сутнасці, ClickHouse толькі больш ёмістая «базка» дадзеных, з не вельмі зручнай кропкавай устаўкай (так задумана, усё ок), але прыемнай аналітыкай і наборам цікавых магутных функцый па працы з дадзенымі. Так, можна нават стварыць кластар - але, вы разумееце, што забіваць цвікі мікраскопам не зусім правільна і мы пачалі шукаць іншыя рашэнні.
Попыт на python і аналітыкаў
У нашай кампаніі шмат распрацоўшчыкаў, якія пішуць код амаль кожны дзень на працягу 10-20 гадоў на PHP, JavaScript, C#, C/С++, Java, Go, Rust, Python, Bash. Таксама шмат дасведчаных сістэмных адміністратараў, якія перажылі не адну зусім неверагодную катастрофу, якая не ўпісваецца ў законы статыстыкі (напрыклад, калі знішчаецца большасць дыскаў у raid-10 пры моцным удары маланкі). У такіх умовах доўгі час было незразумела, што такое "аналітык на python". Python жа як PHP, толькі назва крыху даўжэй і слядоў рэчываў, якія змяняюць прытомнасць, у зыходным кодзе інтэрпрэтатара крыху паменш. Аднак, па меры стварэння ўсё новых і новых аналітычных справаздач дасведчаныя распрацоўнікі ўсё глыбей сталі ўсведамляць важнасць вузкай спецыялізацыі ў прыладах тыпу numpy, pandas, matplotlib, seaborn.
Вырашальную ролю, хутчэй за ўсё, адыгралі раптоўныя непрытомнасці супрацоўнікаў ад спалучэння слоў "лагістычная рэгрэсія" і дэманстрацыя эфектыўнай пабудовы справаздач на аб'ёмных дадзеных з дапамогай так, так, pyspark.
Apache Spark, яго функцыянальная парадыгма, на якую выдатна кладзецца рэляцыйная алгебра і магчымасці зрабілі такое ўражанне на распрацоўнікаў, якія звыкнуліся да MySQL, што неабходнасць умацавання баявых шэрагаў дасведчанымі аналітыкамі стала яснай, як дзень.
Далейшыя спробы Apache Spark/Hadoop узляцець і што пайшло не зусім па сцэнары
Аднак, неўзабаве стала зразумела, што са Spark, мабыць, нешта сістэмна не зусім так ці трэба проста лепш мыць рукі. Калі стэк Hadoop/MapReduce/Lucene рабілі досыць дасведчаныя праграмісты, што відавочна, калі з прыхільнасцю паглядзець зыходнікі на Java ці ідэі Дуга Катынга ў Lucene, то Spark, раптам, напісаны на вельмі спрэчным з пункта гледжання практычнасці і цяпер не якая развіваецца экзатычнай мове Scala. А рэгулярнае падзенне вылічэнняў на кластары Spark з-за нелагічнай і не вельмі празрыстай працы з вылучэннем памяці пад аперацыі reduce (прылятае адразу шмат ключоў) – стварыла вакол яго арэол чагосьці, якому ёсць куды расці. Дадаткова сітуацыю пагаршала вялікая колькасць дзіўных адчыненых партоў, часавых файлаў, якія растуць у самых незразумелых месцах і пекла jar-залежнасцяў - што выклікала ў сістэмных адміністратараў адно і добра знаёмае з дзяцінства пачуццё: лютую нянавісць (а можа трэба было мыць рукі з мылам).
Мы, у выніку, "перажылі" некалькі ўнутраных аналітычных праектаў, актыўна выкарыстоўвалых Apache Spark (у тым ліку Spark Streaming, Spark SQL) і экасістэму Hadoop (і іншая і іншая). Нягледзячы на тое, што з часам навучыліся «гэта» нядрэнна рыхтаваць і маніторыць і «яно» практычна перастала раптоўна падаць з-за змены характару дадзеных і дызбалансавання раўнамернага хэшавання RDD, жаданне ўзяць нешта ўжо гатовае, якое абнаўляецца і адміністраванае дзесьці ў воблаку ўзмацнялася ўсё мацней і мацней. Менавіта ў гэты час мы паспрабавалі выкарыстаць гатовую хмарную зборку Amazon Web Services. і, пасля, імкнуліся вырашаць задачы ўжо на ёй. EMR гэта прыгатаваны амазонам Apache Spark з дадатковым софтам з экасістэмы, прыкладна як Cloudera/Hortonworks зборкі.
«Гумовае» файлавае сховішча для аналітыкі - вострае запатрабаванне
Вопыт "прыгатавання" Hadoop / Spark з апёкамі розных частак цела не прайшоў дарма. Стала ўсё выразней вымалёўвацца неабходнасць стварэння адзінага недарагога і надзейнага файлавага сховішча, якое было б устойліва да апаратных аварый і ў якім можна было б захоўваць файлы ў розным фармаце з розных сістэм і рабіць па гэтых дадзеных эфектыўныя і ў разумны час выкананыя выбаркі для справаздач.
Таксама хацелася, каб абнаўленне софту гэтай платформы не ператваралася ў навагодні начны кашмар з чытаннем 20-старонкавых Java трэйсаў і аналіз кіламетровых падрабязных логаў працы кластара з дапамогай Spark History Server і лупы з падсветкай. Жадалася мець простую і празрыстую прыладу, які не патрабуе рэгулярнага нырання пад капот, калі ў распрацоўніка перастаў выконвацца стандартны MapReduce запыт пры выпадзенні з памяці воркера reduce-дадзеных пры не вельмі ўдала абраным алгарытме партыцыянавання зыходных дадзеных.
Amazon S3 – кандыдат на DataLake?
Вопыт працы з Hadoop/MapReduce навучыў таму, што патрэбна і якая маштабуецца надзейная файлавая сістэма і над ёй якія маштабуюцца воркеры, «якія прыходзяць» бліжэй да дадзеных, каб не ганяць дадзеныя па сетцы. Воркеры павінны ўмець чытаць дадзеныя ў розных фарматах, але, пажадана, не чытаць лішнюю інфармацыю і каб можна было загадзя захоўваць дадзеныя ў зручных для воркераў фарматах.
Яшчэ раз - асноўная ідэя. Няма жадання «заліваць» вялікія дадзеныя ў адзіны кластарны аналітычны рухавічок, які ўсё роўна рана ці позна захлынецца і прыйдзецца яго брыдка шнардзіць. Жадаецца захоўваць файлы, проста файлы, у зразумелым фармаце і выконваць па іх эфектыўныя аналітычныя запыты рознымі, але зразумелымі прыладамі. І файлаў у розных фарматах будзе ўсё больш і больш. І лепш шнардзіць не рухавічок, а зыходныя дадзеныя. Нам патрэбен які пашыраецца і ўніверсальны DataLake, вырашылі мы…
А што калі захоўваць файлы ў звыклым і шматлікім вядомым якое маштабуецца хмарным сховішча Amazon S3, не займаючыся ўласнай падрыхтоўкай адбіўных з Hadoop?
Зразумела, перданныя «нізячы», але іншыя дадзеныя калі туды вынесці і «эфектыўна паганяць»?
Кластэрна-бігдата-аналітычная экасістэма Amazon Web Services – вельмі простымі словамі
Судзячы па нашым досведзе працы з AWS, тамака даўно і актыўна выкарыстоўваецца пад рознымі падліўкамі Apache Hadoop/MapReduce, напрыклад у сэрвісе DataPipeline (зайздрошчу калегам, вось навучыліся жа яго правільна рыхтаваць). Вось тут мы наладзілі бэкапы з розных сэрвісаў з табліц DynamoDB:
І яны рэгулярна выконваюцца на ўбудаваных кластарах Hadoop/MapReduce як гадзіннік ужо некалькі гадоў. «Настроіў і забыўся»:
Таксама, можна эфектыўна займацца датасатанізмам, падняўшы для аналітыкаў Jupiter-наўтбукі ў воблаку і выкарыстоўваць для навучання і дэплоінгу AI-мадэляў у бой сэрвіс AWS SageMaker. Вось як гэта выглядае ў нас:
І так, можна падняць сабе ці аналітыку наўтбук у воблаку і прычапіць яго да Hadoop/Spark кластару, палічыць і ўсё потым «прыбіць»:
Сапраўды зручна для асобных аналітычных праектаў і для некаторых мы паспяхова выкарыстоўвалі сэрвіс EMR для маштабных аблікаў і аналітыкі. А што наконт сістэмнага рашэння для DataLake, ці атрымаецца? У гэты момант мы былі на мяжы надзеі і роспачы і працягвалі пошук.
AWS Glue - акуратна спакаваны Apache Spark "на пазіцыі, метадалагічнай"
Аказалася, што ў AWS ёсць "свая" версія стэка "Hive / Pig / Spark". Роля Hive, г.зн. каталог файлаў і іх тыпаў у DataLake выконвае сэрвіс "Data catalog", які і не хавае аб сваёй сумяшчальнасці з фарматам Apache Hive. У гэты сэрвіс трэба дадаць інфармацыю аб тым, дзе ляжаць вашыя файлы і ў якім яны фармаце. Дадзеныя могуць быць не толькі ў s3, але і ў базе даных, але пра гэта не ў гэтым пасце. Вось як каталог дадзеных DataLake арганізаваны ў нас:
Файлы зарэгістраваны, выдатна. Калі файлы абнавіліся - запускаем альбо рукамі альбо па раскладзе crawlers, якія абновяць пра іх з возера інфармацыю і захаваюць. Далей даныя з возера можна апрацоўваць і вынікі кудысьці выгружаць. У самым простым выпадку - выгружаем таксама ў s3. Апрацоўку дадзеных можна рабіць дзе заўгодна, але прапануецца наладзіць працэс апрацоўкі на кластары Apache Spark з выкарыстаннем пашыраных магчымасцяў праз API AWS Glue. Па сутнасці, можна ўзяць стары добры і звыклы код на python з выкарыстаннем бібліятэчкі pyspark і наладзіць яго выкананне на N нодах кластара нейкай магутнасці з маніторынгам, без капання ў вантробах Hadoop і цяганні докер-мокер кантэйнераў і ўхіленні канфліктаў залежнасцяў.
Яшчэ раз - простая ідэя. Не трэба наладжваць Apache Spark, трэба толькі напісаць код на python для pyspark, пратэставаць яго лакальна на працоўным стале і затым запусціць на вялікім кластары ў воблаку, паказаўшы дзе ляжаць зыходныя дадзеныя і куды пакласці вынік. Часам гэта трэба і карысна і вось як гэта настроена ў нас:
Такім чынам, калі трэба нешта аблічыць на Spark-кластары на дадзеных у s3 - пішам на python/pyspark код, тэстуем і ў добры шлях у воблака.
А што з аркестроўкай? А калі заданне ўпала і прапала? Так, прапануецца зрабіць прыгожы пайплайн у стылі Apache Pig і мы нават паспрабавалі іх, але вырашылі пакуль выкарыстоўваць сваю глыбока кастамізаваную аркестроўку на PHP і JavaScript (я разумею, узнікае кагнітыўны дысананс, але працуе, гадамі і без памылак).
Фармат захоўваемых у возеры файлаў - ключ да прадукцыйнасці.
Вельмі, вельмі важна зразумець яшчэ два ключавыя моманты. Каб запыты па дадзеных файлаў у возеры выконваліся максімальна хутка і прадукцыйнасць не дэградавала пры даданні новай інфармацыі, трэба:
- Калонкі файлаў захоўваць асобна (каб не трэба было прачытаць усе радкі, каб зразумець, што ў калонках). Для гэтага мы ўзялі фармат parquet са сціскам
- Вельмі важна шаляваць файлы па татачках у духу: мова, год, месяц, дзень, тыдзень. Рухавікі, якія разумеюць гэты тып шардзіравання, будуць глядзець толькі ў патрэбныя татачкі, не пералапачваючы праз сябе ўсе дадзеныя запар.
У сутнасці, такім спосабам, вы выкладваеце ў найболей эфектыўным выглядзе зыходныя дадзеныя для навешваемых зверху аналітычных рухавічкоў, якія і ў шалёныя татачкі ўмеюць выбарча заходзіць і чытаць з файлаў толькі патрэбныя калонкі. Не трэба нікуды, атрымаюцца, "заліваць" дадзеныя (сховішча ж проста лопне) - проста адразу разумна іх пакладзяце ў файлавую сістэму ў правільным фармаце. Зразумела, тут павінна быць зразумела, што захоўваць у DataLake велізарны csv-файл, які трэба спачатку ўвесь парадкова прачытаць кластарам, каб выняць калонкі – не вельмі мэтазгодна. Падумайце над двума вышэйпаказанымі пунктамі яшчэ раз, калі пакуль незразумела навошта ўсё гэта.
AWS Athena - «чорт» з табакеркі
І тут, ствараючы возера, мы, неяк мімаходзь, натыкнуліся на Amazon Athena. Раптам апынулася, што акуратна склаўшы па шардах-татачкам у правільным (parquet) калоначным фармаце нашы файлы велізарных логаў - можна вельмі хутка па іх рабіць вельмі інфарматыўныя выбаркі і будаваць справаздачы БЕЗ, без Apache Spark/Glue кластара.
Рухавічок Athena, які працуе на дадзеных у s3, заснаваны на легендарным - Прадстаўніку сямейства MPP (massive parallel processing) падыходаў да апрацоўкі дадзеных, які бярэ дадзеныя там, дзе яны ляжаць, ад s3 і Hadoop да Cassandra і звычайных тэкставых файлікаў. Трэба проста папрасіць Athena выканаць SQL-запыт, а далей усё "працуе хутка і само". Важна адзначыць, што Athena «разумная», ходзіць толькі ў патрэбныя шардаваныя тэчкі і счытвае толькі патрэбныя ў запыце калонкі.
Тарыфікуюцца запыты да Athena таксама цікава. Мы плацім за . Г.зн. не за лік машын у кластары штохвілінна, а… за рэальна прасканаваныя на 100-500 машынах толькі неабходныя для выканання запыту дадзеныя.
А запытваючы толькі патрэбныя калонкі з правільна шардаваных тэчак, аказалася, што сэрвіс Athena нам абыходзіцца ў дзясяткі даляраў месяц. Ну цудоўна ж, амаль бясплатна, у параўнанні з аналітыкай на кластарах!
Вось, дарэчы, як мы шалуем свае дадзеныя ў s3:
У выніку, за кароткі час, у кампаніі зусім розныя падраздзяленні, ад інфармацыйнай бяспекі да аналітыкі, сталі актыўна рабіць запыты да Athena і хутка, за секунды, атрымліваць карысныя адказы з "вялікіх" дадзеных за даволі вялікія перыяды: месяцы, паўгоддзе і т.д. п.
Але мы пайшлі далей і сталі хадзіць за адказамі ў воблака : аналітык у звыклай кансолі піша SQL-запыт, які на 100-500 машынах за капейкі шарсціць дадзеныя ў s3 і вяртае адказ звычайна за адзінкі секунд. Зручна. І хутка. Да гэтага часу не верыцца.
У выніку, прыняўшы рашэнне захоўваць дадзеныя ў s3, у эфектыўным калоначным фармаце і з разумным шардированием дадзеных па татачках ... мы атрымалі DataLake і хуткі і танны аналітычны рухавічок - бясплатна. І ён стаў вельмі папулярным у кампаніі, т.я. разумее SQL і працуе на парадкі хутчэй, чым праз запускі/прыпынку/налады кластараў. "А калі вынік аднолькавы, навошта плаціць больш?"
Запыт да Athena выглядае прыкладна так. Пры жаданні, вядома, можна сфарміраваць дастаткова , Але мы абмяжуемся простай групоўкай. Паглядзім, якія коды адказаў былі ў кліента некалькі тыдняў таму ў логах працы вэб-сервера і пераканаемся, што памылак няма:
Высновы
Прайшоўшы, не сказаць што доўгі, але балючы шлях, увесь час адэкватна ацэньваючы рызыкі і ўзровень складанасці і кошт падтрымкі, мы знайшлі рашэнне для DataLake і аналітыкі, якое нас не перастае цешыць як хуткасцю, так і коштам валодання.
Аказалася, што пабудаваць эфектыўнае, хуткае і таннае ў эксплуатацыі DataLake для патрэб зусім розных падраздзяленняў кампаніі – цалкам па сілах нават дасведчаным распрацоўнікам, ніколі не якія працуюць архітэктарамі і не ўмелым маляваць квадрацікі на квадраціках са стрэлачкамі і дасведчаным 50 тэрмінаў з экасістэмы Hadoop.
У пачатку шляху галава расколвалася ад мноства дзікіх заапаркаў адкрытага і закрытага софту і разумення грузу адказнасці перад нашчадкамі. Проста пачынайце будаваць свой DataLake ад простых прылад: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3 …, збіраючы зваротную сувязь і глыбока разумеючы фізіку адбывалых працэсаў. Усё складанае і каламутнае - аддавайце ворагам і канкурэнтам.
Калі вы не жадаеце ў воблака і кахаеце падтрымліваць, абнаўляць і патчыць адчыненыя праекты, можна пабудаваць аналагічную нашай схему лакальна, на офісных недарагіх машынках з Hadoop і Presto зверху. Галоўнае - не спыняцца і ісці наперад, лічыць, шукаць простыя і ясныя рашэнні і ўсё абавязкова атрымаецца! Удачы ўсім і да новых сустрэч!
Крыніца: habr.com