Tunaishi katika wakati wa kushangaza ambapo unaweza kuunganisha haraka na kwa urahisi zana kadhaa za chanzo-wazi zilizotengenezwa tayari, kuziweka na "fahamu zako zimezimwa" kulingana na ushauri wa stackoverflow, bila kuzama kwenye "herufi nyingi", na kuzindua. wao katika shughuli za kibiashara. Na wakati unahitaji kusasisha / kupanua au mtu huwasha tena mashine kadhaa kwa bahati mbaya - unagundua kuwa aina fulani ya ndoto mbaya imeanza katika ukweli, kila kitu kimekuwa ngumu zaidi ya kutambuliwa, hakuna kurudi nyuma, siku zijazo hazieleweki. na salama, badala ya programu, kuzaliana nyuki na kufanya jibini.
Sio bure kwamba wenzako wenye uzoefu zaidi, vichwa vyao vikiwa na mende na kwa hivyo tayari ni kijivu, wakitafakari uwekaji wa haraka sana wa pakiti za "vyombo" katika "cubes" kwenye seva nyingi katika "lugha za mtindo" zilizo na usaidizi uliojengwa ndani. Asynchronous isiyozuia I/O, tabasamu kwa kiasi. Na wao kimya kuendelea kusoma tena "man ps", delve katika "nginx" code code mpaka macho yao damu, na kuandika, kuandika, kuandika vipimo vya kitengo. Wenzake wanajua kwamba jambo la kuvutia zaidi litakuja wakati "yote haya" siku moja yatawekwa usiku wa usiku wa Mwaka Mpya. Na watasaidiwa tu na uelewa wa kina wa asili ya unix, jedwali la hali ya TCP/IP lililokaririwa na algoriti za msingi za kutafuta. Ili kurejesha mfumo uzima wakati sauti za kengele zinapiga.
Ndio, nilichanganyikiwa kidogo, lakini natumai niliweza kuwasilisha hali ya kutarajia.
Leo nataka kushiriki uzoefu wetu katika kupeleka safu rahisi na ya bei rahisi kwa DataLake, ambayo hutatua kazi nyingi za uchanganuzi katika kampuni kwa migawanyiko tofauti kabisa ya kimuundo.
Wakati fulani uliopita, tulielewa kuwa makampuni yanazidi kuhitaji matunda ya bidhaa na uchambuzi wa kiufundi (bila kutaja icing kwenye keki katika mfumo wa kujifunza mashine) na kuelewa mwelekeo na hatari - tunahitaji kukusanya na kuchambua. vipimo zaidi na zaidi.
Uchanganuzi wa kimsingi wa kiufundi katika Bitrix24
Miaka kadhaa iliyopita, wakati huo huo na uzinduzi wa huduma ya Bitrix24, tuliwekeza kikamilifu wakati na rasilimali katika kuunda jukwaa la uchanganuzi rahisi na la kutegemewa ambalo lingesaidia kuona haraka matatizo katika miundombinu na kupanga hatua inayofuata. Bila shaka, ilipendekezwa kuchukua zana zilizopangwa tayari ambazo zilikuwa rahisi na zinazoeleweka iwezekanavyo. Kwa hivyo, nagios ilichaguliwa kwa ufuatiliaji na munin kwa uchanganuzi na taswira. Sasa tuna maelfu ya hundi katika nagios, mamia ya chati katika munin, na wenzetu wanazitumia kwa mafanikio kila siku. Metrics ni wazi, grafu ni wazi, mfumo umekuwa ukifanya kazi kwa uaminifu kwa miaka kadhaa na vipimo vipya na grafu huongezwa mara kwa mara: tunapoweka huduma mpya katika uendeshaji, tunaongeza vipimo na grafu kadhaa. Bahati njema.
Kidole kwenye Pulse - Uchanganuzi wa Kina wa Kiufundi
Tamaa ya kupokea habari kuhusu matatizo "haraka iwezekanavyo" ilituongoza kwenye majaribio ya kazi na zana rahisi na zinazoeleweka - pinba na xhprof.
Pinba ilitutumia takwimu katika pakiti za UDP kuhusu kasi ya utendakazi wa sehemu za kurasa za wavuti katika PHP, na tuliweza kuona mtandaoni kwenye hifadhi ya MySQL (Pinba inakuja na injini yake ya MySQL kwa uchanganuzi wa matukio ya haraka) orodha fupi ya matatizo na kujibu yao. Na xhprof ilituruhusu kiotomatiki kukusanya grafu za utekelezaji wa kurasa za polepole zaidi za PHP kutoka kwa wateja na kuchambua ni nini kinachoweza kusababisha hii - kwa utulivu, kumwaga chai au kitu chenye nguvu zaidi.
Muda fulani uliopita, zana ya zana ilijazwa tena na injini nyingine rahisi na inayoeleweka kulingana na algoriti ya kuelekeza kinyume, iliyotekelezwa kikamilifu katika maktaba ya hadithi ya Lucene - Elastic/Kibana. Wazo rahisi la kurekodi hati zenye nyuzi nyingi katika faharasa ya Lucene iliyo kinyume kulingana na matukio kwenye kumbukumbu na utafutaji wa haraka kupitia kwao kwa kutumia mgawanyiko wa sehemu iligeuka kuwa muhimu sana.
Licha ya mwonekano wa kiufundi wa taswira katika Kibana yenye dhana za kiwango cha chini kama "ndoo" "inatiririka juu" na lugha iliyobuniwa upya ya aljebra ya uhusiano ambayo bado haijasahaulika kabisa, zana ilianza kutusaidia vyema katika kazi zifuatazo:
- Je, mteja wa Bitrix24 alikuwa na makosa mangapi ya PHP kwenye tovuti ya p1 katika saa iliyopita na yapi? Kuelewa, kusamehe na kurekebisha haraka.
- Je, ni simu ngapi za video zilizopigwa kwenye lango nchini Ujerumani katika saa 24 zilizopita, kwa ubora gani na kulikuwa na matatizo yoyote kwenye kituo/mtandao?
- Je, utendakazi wa mfumo (kiendelezi chetu cha C kwa PHP), kilichokusanywa kutoka chanzo katika sasisho la hivi punde la huduma na kusambazwa kwa wateja, hufanya kazi vizuri kwa kiasi gani? Je, kuna makosa?
- Je, data ya mteja inafaa kwenye kumbukumbu ya PHP? Kuna makosa yoyote kuhusu kuzidi kumbukumbu iliyotengwa kwa michakato: "nje ya kumbukumbu"? Tafuta na ubadilishe.
Hapa kuna mfano halisi. Licha ya upimaji wa kina na wa viwango vingi, mteja, akiwa na kesi isiyo ya kawaida na data iliyoharibiwa ya pembejeo, alipokea kosa la kukasirisha na lisilotarajiwa, king'ora kilisikika na mchakato wa kuirekebisha haraka ulianza:
Zaidi ya hayo, kibana inakuwezesha kuandaa arifa za matukio maalum, na kwa muda mfupi chombo katika kampuni kilianza kutumiwa na wafanyakazi kadhaa kutoka idara tofauti - kutoka kwa msaada wa kiufundi na maendeleo hadi QA.
Shughuli ya idara yoyote ndani ya kampuni imekuwa rahisi kufuatilia na kupima - badala ya kuchambua magogo kwenye seva, unahitaji tu kusanidi magogo mara moja na kuwatuma kwa nguzo ya elastic ili kufurahiya, kwa mfano, kutafakari kwenye kibana. dashibodi idadi ya paka waliouzwa wenye vichwa viwili waliochapishwa kwenye kichapishi cha 3-D kwa mwezi uliopita wa mwandamo.
Uchanganuzi wa Msingi wa Biashara
Kila mtu anajua kwamba uchanganuzi wa biashara katika makampuni mara nyingi huanza na matumizi ya kazi sana ya, ndiyo, Excel. Lakini jambo kuu ni kwamba haina mwisho huko. Google Analytics inayotokana na wingu pia huongeza mafuta kwenye moto - unaanza kuzoea mambo mazuri haraka.
Katika kampuni yetu inayoendelea kwa usawa, "manabii" wa hapa na pale wa kazi kubwa zaidi na data kubwa walianza kuonekana. Haja ya ripoti za kina zaidi na nyingi zilianza kuonekana mara kwa mara, na kupitia juhudi za wavulana kutoka idara tofauti, wakati fulani uliopita suluhisho rahisi na la vitendo lilipangwa - mchanganyiko wa ClickHouse na PowerBI.
Kwa muda mrefu sana, suluhisho hili linalobadilika lilisaidia sana, lakini polepole uelewa ulianza kuja kwamba ClickHouse sio mpira na haiwezi kudhihakiwa hivyo.
Hapa ni muhimu kuelewa vizuri kwamba ClickHouse, kama Druid, kama Vertica, kama Amazon RedShift (ambayo ni msingi wa postgres), ni injini za uchanganuzi zilizoboreshwa kwa uchanganuzi unaofaa (jumla, muunganisho, kiwango cha chini zaidi kwa safu wima na viungo vichache vinavyowezekana. ), kwa sababu iliyopangwa kwa uhifadhi mzuri wa safu wima za majedwali ya uhusiano, tofauti na MySQL na hifadhidata nyingine (zinazoelekezwa kwa safu mlalo) tunazozijua.
Kwa asili, ClickHouse ni "database" yenye uwezo zaidi, na uingizaji usiofaa sana wa hatua kwa hatua (ndivyo inavyokusudiwa, kila kitu ni sawa), lakini uchanganuzi wa kupendeza na seti ya kazi za kuvutia za kufanya kazi na data. Ndio, unaweza hata kuunda nguzo - lakini unaelewa kuwa kugonga kucha na darubini sio sahihi kabisa na tulianza kutafuta suluhisho zingine.
Mahitaji ya chatu na wachambuzi
Kampuni yetu ina watengenezaji wengi ambao huandika msimbo karibu kila siku kwa miaka 10-20 katika PHP, JavaScript, C #, C/C++, Java, Go, Rust, Python, Bash. Pia kuna wasimamizi wengi wa mfumo wenye uzoefu ambao wamepata maafa zaidi ya moja ya kushangaza kabisa ambayo hayaendani na sheria za takwimu (kwa mfano, wakati diski nyingi kwenye uvamizi-10 zinaharibiwa na mgomo mkali wa umeme). Katika hali kama hizi, kwa muda mrefu haikuwa wazi ni "mchambuzi wa chatu" ni nini. Python ni kama PHP, jina pekee ni refu zaidi na kuna athari kidogo ya vitu vinavyobadilisha akili katika msimbo wa chanzo wa mkalimani. Hata hivyo, ripoti zaidi za uchanganuzi zilipoundwa, wasanidi programu wenye uzoefu walianza kuelewa zaidi umuhimu wa utaalam finyu katika zana kama vile numpy, pandas, matplotlib, seaborn.
Jukumu la kuamua, uwezekano mkubwa, lilichezwa na kuzirai kwa ghafla kwa wafanyikazi kutoka kwa mchanganyiko wa maneno "urekebishaji wa vifaa" na maonyesho ya kuripoti kwa ufanisi juu ya data kubwa kwa kutumia, ndiyo, ndiyo, pyspark.
Apache Spark, dhana yake ya kiutendaji ambayo aljebra ya uhusiano inafaa kikamilifu, na uwezo wake uliwavutia watengenezaji waliozoea MySQL hivi kwamba hitaji la kuimarisha safu na wachambuzi wazoefu likadhihirika kila siku.
Majaribio zaidi ya Apache Spark/Hadoop kuondoka na yale ambayo hayakuenda kabisa kulingana na hati.
Walakini, hivi karibuni ikawa wazi kuwa kuna kitu hakikuwa sawa na Spark, au ilikuwa muhimu kuosha mikono yako vizuri. Ikiwa safu ya Hadoop/MapReduce/Lucene ilitengenezwa na waandaaji wa programu wenye uzoefu, ambayo ni dhahiri ikiwa utaangalia kwa karibu msimbo wa chanzo katika Java au maoni ya Doug Cutting huko Lucene, basi Spark, ghafla, imeandikwa kwa lugha ya kigeni Scala, ambayo ni. utata sana kutoka kwa mtazamo wa vitendo na kwa sasa hauendelei. Na kushuka kwa mara kwa mara kwa mahesabu kwenye nguzo ya Spark kutokana na kazi isiyo na mantiki na isiyo ya uwazi sana na mgao wa kumbukumbu kwa ajili ya shughuli za kupunguza (funguo nyingi hufika mara moja) imeunda halo karibu nayo ya kitu ambacho kina nafasi ya kukua. Zaidi ya hayo, hali hiyo ilichochewa na idadi kubwa ya bandari za ajabu zilizo wazi, faili za muda zinazokua katika sehemu zisizoeleweka zaidi na kuzimu kwa utegemezi wa mitungi - ambayo ilisababisha wasimamizi wa mfumo kuwa na hisia moja ambayo ilijulikana tangu utoto: chuki kali (au labda. walihitaji kunawa mikono kwa sabuni).
Kwa hivyo, "tumenusurika" miradi kadhaa ya uchambuzi wa ndani ambayo inatumia kikamilifu Apache Spark (ikiwa ni pamoja na Spark Streaming, Spark SQL) na mfumo ikolojia wa Hadoop (na kadhalika na kadhalika). Licha ya ukweli kwamba baada ya muda tulijifunza kuandaa na kufuatilia "hiyo" vizuri, na "hiyo" ilisimama ghafla kwa sababu ya mabadiliko ya asili ya data na usawa wa sare ya RDD, hamu ya kuchukua kitu tayari tayari. , iliyosasishwa na kusimamiwa mahali fulani katika wingu ilikua na nguvu zaidi. Ilikuwa wakati huu ambapo tulijaribu kutumia mkusanyiko wa wingu uliotengenezwa tayari wa Huduma za Wavuti za Amazon - na, baadaye, alijaribu kutatua matatizo kwa kutumia. EMR ni Apache Spark iliyotayarishwa na Amazon ikiwa na programu ya ziada kutoka kwa mfumo wa ikolojia, kama vile Cloudera/Hortonworks inavyojenga.
Hifadhi ya faili ya mpira kwa uchanganuzi ni hitaji la dharura
Uzoefu wa "kupika" Hadoop / Spark na kuchomwa kwa sehemu mbalimbali za mwili haukuwa bure. Haja ya kuunda hifadhi ya faili moja, isiyo ghali na inayotegemewa ambayo ingeweza kuhimili hitilafu za maunzi na ambayo ingewezekana kuhifadhi faili katika miundo tofauti kutoka kwa mifumo tofauti na kufanya sampuli zinazofaa na zinazotumia wakati kwa ripoti kutoka kwa data hii ilizidi kuongezeka. wazi.
Pia nilitaka kusasisha programu ya jukwaa hili kusigeuke kuwa ndoto mbaya ya Mwaka Mpya kwa kusoma ufuatiliaji wa Java wa kurasa 20 na kuchambua kumbukumbu za kina za urefu wa kilomita za nguzo kwa kutumia Seva ya Historia ya Spark na kioo cha kukuza nyuma. Nilitaka kuwa na zana rahisi na ya uwazi ambayo haikuhitaji kupiga mbizi mara kwa mara chini ya kofia ikiwa ombi la kawaida la MapReduce la msanidi liliacha kutekeleza wakati mfanyakazi wa kupunguza alipoteza kumbukumbu kwa sababu ya algorithm isiyochaguliwa vizuri ya kugawa data ya chanzo.
Je, Amazon S3 ni mgombea wa DataLake?
Uzoefu wa Hadoop/MapReduce ulitufundisha kwamba tunahitaji mfumo wa faili unaoweza kubadilika, unaotegemeka na wafanyakazi wenye hali mbaya zaidi juu yake, "wanaokuja" karibu na data ili tusiendeshe data kwenye mtandao. Wafanyakazi wanapaswa kuwa na uwezo wa kusoma data katika miundo tofauti, lakini ikiwezekana wasisome maelezo yasiyo ya lazima na waweze kuhifadhi data mapema katika miundo inayofaa kwa wafanyakazi.
Kwa mara nyingine tena, wazo la msingi. Hakuna hamu ya "kumwaga" data kubwa kwenye injini moja ya uchambuzi ya nguzo, ambayo mapema au baadaye itasonga na itabidi uikate mbaya. Ninataka kuhifadhi faili, faili tu, katika muundo unaoeleweka na kufanya maswali ya uchambuzi juu yao kwa kutumia zana tofauti lakini zinazoeleweka. Na kutakuwa na faili zaidi na zaidi katika umbizo tofauti. Na ni bora kugawa sio injini, lakini data ya chanzo. Tunahitaji DataLake inayoweza kupanuka na ya ulimwengu wote, tuliamua...
Je, ikiwa utahifadhi faili katika hifadhi ya wingu inayojulikana na inayojulikana ya Amazon S3, bila kulazimika kuandaa chops zako mwenyewe kutoka Hadoop?
Ni wazi kwamba data ya kibinafsi ni "chini", lakini vipi kuhusu data nyingine ikiwa tutaiondoa na "kuiendesha kwa ufanisi"?
Mfumo ikolojia wa cluster-bigdata-analytics wa Amazon Web Services - kwa maneno rahisi sana
Kwa kuzingatia uzoefu wetu na AWS, Apache Hadoop/MapReduce imetumika kwa bidii huko kwa muda mrefu chini ya michuzi mbalimbali, kwa mfano katika huduma ya DataPipeline (ninawaonea wivu wenzangu, walijifunza jinsi ya kuitayarisha kwa usahihi). Hapa tunaweka nakala rudufu kutoka kwa huduma tofauti kutoka kwa jedwali la DynamoDB:
Na zimekuwa zikiendesha mara kwa mara kwenye vikundi vya Hadoop/MapReduce vilivyopachikwa kama vile saa kwa miaka kadhaa sasa. "Weka na uisahau":
Unaweza pia kujihusisha na ushetani wa data kwa kusanidi kompyuta za mkononi za Jupiter kwenye wingu kwa wachambuzi na kutumia huduma ya AWS SageMaker kutoa mafunzo na kupeleka miundo ya AI vitani. Hivi ndivyo inavyoonekana kwetu:
Na ndio, unaweza kujichukulia kompyuta yako ndogo au mchambuzi kwenye wingu na kuiambatanisha na nguzo ya Hadoop/Spark, fanya mahesabu kisha upige kila kitu chini:
Rahisi sana kwa miradi ya uchanganuzi binafsi na kwa baadhi tumefaulu kutumia huduma ya EMR kwa hesabu kubwa na uchanganuzi. Vipi kuhusu suluhisho la mfumo kwa DataLake, litafanya kazi? Wakati huu tulikuwa kwenye hatihati ya matumaini na kukata tamaa na kuendelea na utafutaji.
Gundi ya AWS - iliyopakiwa vizuri Apache Spark kwenye steroids
Ilibadilika kuwa AWS ina toleo lake la safu ya "Hive/Pig/Spark". Jukumu la Hive, i.e. Katalogi ya faili na aina zao katika DataLake inafanywa na huduma ya "Katalogi ya data", ambayo haifichi utangamano wake na umbizo la Apache Hive. Unahitaji kuongeza maelezo kwenye huduma hii kuhusu wapi faili zako ziko na ziko katika umbizo gani. Data inaweza kuwa sio tu katika s3, lakini pia katika hifadhidata, lakini hiyo sio mada ya chapisho hili. Hivi ndivyo saraka yetu ya data ya DataLake imepangwa:
Faili zimesajiliwa, nzuri. Ikiwa faili zimesasishwa, tunazindua programu za kutambaa kwa mikono au kwa ratiba, ambayo itasasisha maelezo kuzihusu kutoka ziwani na kuzihifadhi. Kisha data kutoka kwa ziwa inaweza kuchakatwa na matokeo kupakiwa mahali fulani. Katika hali rahisi, tunapakia pia kwa s3. Usindikaji wa data unaweza kufanywa popote, lakini inapendekezwa kwamba usanidi uchakataji kwenye nguzo ya Apache Spark kwa kutumia uwezo wa hali ya juu kupitia API ya Glue ya AWS. Kwa kweli, unaweza kuchukua msimbo mzuri wa zamani na unaojulikana wa chatu ukitumia maktaba ya pyspark na usanidi utekelezwaji wake kwenye nodi za N za nguzo ya uwezo fulani na ufuatiliaji, bila kuchimba ndani ya matumbo ya Hadoop na kuburuta vyombo vya pikipiki na kuondoa mizozo ya utegemezi. .
Kwa mara nyingine tena, wazo rahisi. Hakuna haja ya kusanidi Apache Spark, unahitaji tu kuandika msimbo wa python kwa pyspark, ijaribu ndani ya eneo lako kwenye desktop yako na kisha uikimbie kwenye nguzo kubwa kwenye wingu, ukibainisha wapi data ya chanzo iko na wapi kuweka matokeo. Wakati mwingine hii ni muhimu na muhimu, na hivi ndivyo tunavyoiweka:
Kwa hivyo, ikiwa unahitaji kuhesabu kitu kwenye nguzo ya Spark kwa kutumia data katika s3, tunaandika nambari katika python/pyspark, ijaribu, na bahati nzuri kwa wingu.
Vipi kuhusu okestra? Je, ikiwa kazi itaanguka na kutoweka? Ndio, inapendekezwa kutengeneza bomba nzuri katika mtindo wa Nguruwe wa Apache na tulijaribu hata, lakini kwa sasa tuliamua kutumia orchestration yetu iliyoboreshwa kwa undani katika PHP na JavaScript (Ninaelewa, kuna dissonance ya utambuzi, lakini inafanya kazi, kwa miaka na bila makosa).
Umbizo la faili zilizohifadhiwa katika ziwa ndio ufunguo wa utendakazi
Ni muhimu sana kuelewa mambo mawili muhimu zaidi. Ili hoja kuhusu data ya faili katika ziwa zitekelezwe haraka iwezekanavyo na utendakazi usishushe hadhi habari mpya inapoongezwa, unahitaji:
- Hifadhi safu wima za faili kando (ili sio lazima usome mistari yote ili kuelewa kile kilicho kwenye safu). Kwa hili tulichukua muundo wa parquet na ukandamizaji
- Ni muhimu sana kugawanya faili kwenye folda kama: lugha, mwaka, mwezi, siku, wiki. Injini zinazoelewa aina hii ya sharding zitaangalia tu folda zinazohitajika, bila kuchuja data zote mfululizo.
Kimsingi, kwa njia hii, unaweka data ya chanzo katika fomu yenye ufanisi zaidi kwa injini za uchambuzi zilizowekwa juu, ambazo hata kwenye folda zilizopigwa zinaweza kuingiza na kusoma tu safu muhimu kutoka kwa faili. Huna haja ya "kujaza" data popote (hifadhi itapasuka tu) - mara moja kwa busara kuiweka kwenye mfumo wa faili katika muundo sahihi. Kwa kweli, inapaswa kuwa wazi hapa kwamba kuhifadhi faili kubwa ya csv katika DataLake, ambayo lazima kwanza isomwe mstari kwa mstari na nguzo ili kutoa safu, haifai sana. Fikiria juu ya mambo mawili hapo juu tena ikiwa bado haijulikani kwa nini haya yote yanafanyika.
AWS Athena - jack-in-the-box
Na kisha, wakati wa kuunda ziwa, kwa bahati mbaya tulikutana na Amazon Athena. Ghafla ikawa kwamba kwa kupanga kwa uangalifu faili zetu kubwa za kumbukumbu katika shards za folda katika umbizo sahihi la safu (parquet), unaweza haraka sana kufanya chaguzi zenye habari kutoka kwao na kuunda ripoti BILA, bila nguzo ya Apache Spark/Glue.
Injini ya Athena inayoendeshwa na data katika s3 inategemea hadithi - mwakilishi wa familia ya MPP (usindikaji mkubwa sambamba) wa mbinu za usindikaji wa data, kuchukua data ilipo, kutoka s3 na Hadoop hadi Cassandra na faili za maandishi za kawaida. Unahitaji tu kuuliza Athena kutekeleza swali la SQL, na kisha kila kitu "hufanya kazi haraka na kiotomatiki." Ni muhimu kutambua kwamba Athena ni "smart", inakwenda tu kwenye folda za sharded muhimu na inasoma tu safu zinazohitajika katika ombi.
Bei ya maombi kwa Athena pia inavutia. Tunalipia . Wale. sio kwa idadi ya mashine kwenye nguzo kwa dakika, lakini ... kwa data iliyochanganuliwa kwenye mashine 100-500, data muhimu tu ili kukamilisha ombi.
Na kwa kuomba tu nguzo muhimu kutoka kwa folda zilizopigwa kwa usahihi, ikawa kwamba huduma ya Athena inatugharimu makumi ya dola kwa mwezi. Kweli, nzuri, karibu bila malipo, ikilinganishwa na uchanganuzi kwenye vikundi!
Kwa njia, hivi ndivyo tunavyogawanya data yetu katika s3:
Kama matokeo, kwa muda mfupi, idara tofauti kabisa katika kampuni, kutoka kwa usalama wa habari hadi uchambuzi, zilianza kufanya maombi kwa Athena na haraka, kwa sekunde, kupokea majibu muhimu kutoka kwa data "kubwa" kwa muda mrefu: miezi, nusu mwaka, nk. P.
Lakini tulienda mbali zaidi na kuanza kwenda kwenye wingu kwa majibu : mchambuzi anaandika swali la SQL katika koni inayojulikana, ambayo kwenye mashine 100-500 "kwa senti" hutuma data kwa s3 na kurudisha jibu kwa kawaida katika sekunde chache. Starehe. Na haraka. Bado siwezi kuamini.
Matokeo yake, baada ya kuamua kuhifadhi data katika s3, katika muundo bora wa safu na kwa kugawanya data kwa busara kwenye folda ... tulipokea DataLake na injini ya uchambuzi ya haraka na ya bei nafuu - bila malipo. Na akawa maarufu sana katika kampuni, kwa sababu ... inaelewa SQL na hufanya kazi maagizo ya ukubwa kwa haraka zaidi kuliko kupitia kuanza/kusimamisha/kuanzisha vikundi. "Na ikiwa matokeo ni sawa, kwa nini ulipe zaidi?"
Ombi kwa Athena linaonekana kama hii. Ikiwa unataka, bila shaka, unaweza kuunda kutosha , lakini tutajiwekea kikomo kwa kuweka vikundi rahisi. Wacha tuone ni misimbo gani ya majibu ambayo mteja alikuwa nayo wiki chache zilizopita kwenye kumbukumbu za seva ya wavuti na hakikisha kuwa hakuna makosa:
Matokeo
Baada ya kupita, bila kusema njia ndefu, lakini chungu, tukikagua vya kutosha hatari na kiwango cha ugumu na gharama ya usaidizi, tulipata suluhisho la DataLake na uchanganuzi ambao hauachi kutupendeza kwa kasi na gharama ya umiliki.
Ilibadilika kuwa kujenga ufanisi, haraka na kwa bei nafuu kuendesha DataLake kwa mahitaji ya idara tofauti kabisa za kampuni ni kabisa ndani ya uwezo wa hata watengenezaji wenye ujuzi ambao hawajawahi kufanya kazi kama wasanifu na hawajui jinsi ya kuteka mraba kwenye viwanja na. mishale na kujua maneno 50 kutoka kwa mfumo ikolojia wa Hadoop.
Mwanzoni mwa safari, kichwa changu kilikuwa kikitengana na mbuga nyingi za wanyama za programu wazi na zilizofungwa na uelewa wa mzigo wa uwajibikaji kwa wazao. Anza tu kuunda DataLake yako kutoka kwa zana rahisi: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., kukusanya maoni na kuelewa kwa kina fizikia ya michakato inayofanyika. Kila kitu ngumu na giza - kuwapa maadui na washindani.
Ikiwa hutaki kwenda kwenye wingu na kupenda kuunga mkono, kusasisha na kuweka kiraka miradi ya programu huria, unaweza kuunda mpango sawa na wetu ndani ya nchi, kwenye mashine za bei nafuu za ofisi zenye Hadoop na Presto juu. Jambo kuu sio kuacha na kusonga mbele, kuhesabu, kutafuta suluhisho rahisi na wazi, na kila kitu kitafanya kazi! Bahati nzuri kwa kila mtu na kukuona tena!
Chanzo: mapenzi.com