Byggja upp Analytics lið að ósk

Þegar ég gekk fyrst til liðs við Wish fyrir tveimur og hálfu ári gengu hlutirnir vel. Wish appið hafði náð toppstöðum bæði í iOS og Android app verslunum og seldi yfir tvær milljónir vara á dag.

Óska - ná Android topp 10 (heimild)

Mjög fáir töldu að hægt væri að byggja stórfyrirtæki með því að selja lágvörur. Með því að nota gögn hefur Wish getað prófað og mótmælt þessum forsendum. Að vera rekinn gögnum var í DNA fyrirtækisins.

En frá gríðarlegum vexti fyrirtækisins voru miklir vaxtarverkir í greiningarhliðinni. Sérhvert teymi þurfti brýnan stuðning gagna og hafði skort á sýnileika inn á eignarhaldssviðin sín. En greiningargeta Wish var enn á barnsaldri og gat ekki fylgst með eftirspurninni.

Flöskuhálsar voru við aðgang að gögnum. Eina fólkið sem tókst að smíða skýrslur og draga gögn voru verkfræðingar sem unnu vöruna. Þar sem gagnamannvirkin voru svo bein, gátum við ekki ráðið greiningaraðila til að hjálpa. Gagnatímar mældust í vikum og samkvæmt beiðnum um gögn og skýrslugerð.

Næstu tvö ár lögðum við hart að okkur við að byggja upp greiningar hjá Wish. Við smíðuðum gagnalögn frá grunni sem gerir verkfræðingum, greiningaraðilum og gagnafræðingum kleift að ETL gögn á áreiðanlegan og öruggan hátt til að knýja vinnu sína. Við byggðum gagnageymslu í Redshift og BigQuery með kjarnatöflum sem hægt er að nota til að knýja framhaldstöflur sem sérfræðingar þurfa. Og við rúlluðum út Looker, notuðum nú fyrirtæki víða sem sannleikans fyrir gögn yfir 200 manns í þremur heimsálfum.

Við höfum nú yfir 30 manns sem eru tileinkaðir því að vinna að greiningarmálum með áætlun um að tvöfalda þá tölu á þessu ári. Við erum fullviss um að kerfi okkar og ferlar geta verið í stærðargráðu og að við getum mætt hvers konar eftirspurn sem fyrirtækið hefur.

Í þessari færslu ætla ég að deila lærdómnum sem við lærðum og bjóða upp á vegvísun fyrir önnur fyrirtæki sem eru að leita að því að mæla greiningaraðgerð sína.

Þessi grein skiptist í fjóra hluta og tala hver um mismunandi áherslur við uppbyggingu gagnateymis.

  1. 1. hluti - Endurbygging stofnunarinnar
  2. Hluti 2 - Stærð gagnaverkfræði
  3. Hluti 3 - Stærð gagnagreiningar
  4. 4. hluti - Ráðning

1. hluti - Endurreisn sjóðsins

Byrjum á fyrstu dögum. Hlutirnir voru nokkuð skýrir eftir að ég tók þátt í því að það voru alvarleg mál varðandi það hvernig við værum að vinna með gögn.

Snemma gagnapallur

Fyrir það eitt var fyrirspurnargögn martröð. Um þetta leyti vorum við með einn stærsta MongoDB þyrping í heimi (topp 3). Af áreiðanleika ástæðum hafði innviði teymið slökkt á fyrirspurnum Mongo samanlagðar, sem þýðir að samsöfnun gagna þurfti að gera á viðskiptavininum (í Python handriti). Það sem hefði átt að vera einfaldar SUM og GROUP BY fullyrðingar í SQL þurfti að skrifa sem Python forskriftir sem endurtók í gegnum milljónir skjala í einu og halda utan um árangur í hreiðurritunarritum. Þessar fyrirspurnir voru sársaukafullar að skrifa og tóku að eilífu að hlaupa.

Aðstæður gagnaleiðslunnar voru ekki miklu betri. Kerfið var of einfalt og skorti lykilatriði sem gerðu það að verkum að hægt var að styðja mikið magn af ETL verkefnum, svo sem stjórnun á ávanabindingu og aftur reynt rökfræði. Bilun var brothætt og hrakin, sem gerði það að verkum að bardagar við eldinn voru nánast í fullu starfi.

Við þurftum að endurbyggja innviði - og hratt. Við þurftum að breyta gagnaleiðslunni í meira stigstærð og áreiðanlegt kerfi. Og við þurftum að byggja upp sérstaka gagnageymslu fyrir greiningar sem gerir fyrirspurnir og byggingarskýrslur mun hraðar.

Það sem gerði þetta erfitt var að þar sem einn af tveimur greiningarmiðuðum ráðningum í fyrirtækinu varð ég að púsla á milli þess að halda núverandi leiðslum í rekstri, fylgjast með miklu magni af skýrslugerð og gagnabeiðnum og skera út tíma til að endurreisa kerfið. Þetta þýddi oft að skipta fram og til baka milli gagnaverkfræðinga og gagnagreiningarverkefna - tvenns konar vinna sem krefst mjög mismunandi færni og hugsunar. Með því að púsla báðum held ég ekki að ég hafi sinnt báðum hlutverkunum mjög vel.

Það sem endaði með því að bjarga deginum var að lokum ráðinn fyrsti gagnagagnfræðingurinn okkar. Við vorum heppin að við fundum að lokum háttsettir greiningaraðilar tæknilegir til að geta skrifað ad hoc fyrirspurnir fyrir MongoDB og unnið eftir Python byggðum tölvupóstskýrslum. Þeir voru líka nógu reynslumiklir til að þeir vissu hvernig á að sigla í skjalalausum og nýjum gögnum. Þetta þýddi að þeir gætu tekið eignarhald á fjölda skýrslugerðarverkefna sem ég var grafinn undir.

Næsta ár byggðum við út grunninn að greiningardeild hjá Wish. Sérfræðingarnir tóku að sér slönguna á gagnabeiðnum sem komu frá öllum hornum fyrirtækisins. Ég gat einbeitt mér að því að endurbyggja innviði.

Hvorki ég né sérfræðingateymi okkar hefði staðið mjög lengi hjá þessu fyrirtæki hefði annað hvort okkar ekki gengið í félagið. Vandamálin tvö sem við unnum, að draga gögn / byggja skýrslur og vinna að því að bæta innviði, voru erfið á mjög mismunandi vegu. Þeir kröfðust svo aðgreindrar færni að hvorugur aðilinn var mjög góður í hlutverki hvers annars.

Helsta kennslustundin er sú að krafan um að stofna gagnateymi er að hafa bæði gagnaverkfræðing og greiningaraðila. Án að minnsta kosti eins gagnagreiningaraðila verður gagnaverkfræðingurinn grafinn undir skýrslutöku og gagnaflutning. Án gagnaverkfræðingsins verða gagnfræðingarnir brenndir úr fyrirspurnum um erfiða gagnaheimilda meðan þeir eru að fást við gögnin óska ​​eftir slönguslöngu. Það þarf að hafa reynslu af báðum gerðum. Og báðir hópar þurfa að geta mala það út í einhvern tíma þar til kerfið er byggt.

Í næstu tveimur hlutum mun ég ræða nánar um þær áskoranir sem blasa við í hverju hlutverki og ráð um hvernig hægt er að draga úr þeim.

Tók til liðs við sig sem frumgreinandi

Að vera einn af fyrstu greiningaraðilum hjá Wish þýddi að taka eignarhald á stórum klump skýrslugerðar og vera einn af þeim fyrstu í röðinni til að taka á sig gagnabeiðnir.

Tilkynning var kerfi sem samanstendur af Python forskriftum sem skiluðu HTML tölvupósti sem sendur var út með reglulegu millibili. Það voru yfir hundrað slíkra sem náðu til mismunandi kerfa og aðgerða innan fyrirtækisins.

Að halda þessum skriftum í gangi samkvæmt áætlun var fullt starf. Það er erfitt að vinna úr gögnum með Python og ná yfir öll mál. Málefni eins og tegundavillur, gögn sem vantar eða ófullkomin og skjávandamál voru öll galla sem birtust daglega og myndu valda því að skýrslur sendust ekki. Venjulega var ekki nægur tími í viku til að laga allt það sem kom upp, svo að tilkynna átti um galla og forgangsraða.

Það var ekki nóg með að við héldum bara kerfinu í rekstri. Vöxtur fyrirtækisins skapaði mikla eftirspurn eftir nýjum skýrslum. Við höfðum nýlega ráðið nýjan yfirmann rekstrar, sem þýddi að allar þjónustuskýrslur viðskiptavina okkar þyrftu að endurbyggja. Við vorum einnig að koma af stað nýjum kaupmannaforritum eins og Wish Express, 7 daga flutningarkosti okkar. Hvert þessara forrita þurfti sitt eigið skýrslur.

Ofan á skýrsluna var stöðugur straumur af gagnabeiðnum sem komu frá öllum hliðum fyrirtækisins. Það virtist alltaf eins og hraðinn sem þessir komu inn jókst veldishraða. Við urðum að vera mjög sértækir um að skera niður óþarfa spurningar og forgangsraða að vinna aðeins að áhrifamestu beiðnum.

Þetta var erfitt starf. Það var alltaf freistingin til að flýta fyrir hlutunum sem svar við umfangi komandi vinnu. Þetta leiddi til mistaka, sem mjög fljótt skera niður trúverðugleika greiningaraðila.

Að ná árangri í þessu hlutverki þýðir tvennt:

  1. Til að geta skilað nákvæmum gögnum stöðugt
  2. Til að geta séð um óeðlilegt magn beiðna.

Ég mun ræða nánar um þetta tvennt - hvers vegna þau eru snemma erfið og hvernig hægt er að vinna bug á þessum erfiðleikum.

Að senda ekki slæm gögn

Sending slæmra gagna <Að gera ekkert <Senda rétt gögn

Óreyndir gagnfræðingar hafa tilhneigingu til að spyrjast fyrir um gögn án þess að vita alveg hvernig hlutirnir virka.

Til að gefa þér dæmi, segjum við að við höfum beðið um að fá núverandi endurgreiðsluhlutfall á heimsvísu. Barnaleg leið til að fá þetta væri að skoða gagnalíkanið fyrir pantanir og sjá að það er með reit vegna endurgreiðsluástæðna. Með því að sía á tilvist þessa, yfir allar pantanir sem gerðar eru á tilteknum tíma, getum við fengið endurgreiðsluhlutfall - # endurgreiðslur / # pantanir. Við sendum það síðan af stað.

Þá skulum við segja að við heyrum til baka og nú vill topp eir sjá hvernig endurgreiðsluhlutfall er mismunandi fyrir pakka sem eru sendir með staðfestingu á afhendingu og án. Barnalegt, við gætum líka beitt sömu aðferð og fundið aðskilið gagnalíkan til að mæla pöntun, og sjá að það er með reit sem kallast afhentur staðfestur tími. Og að hægt sé að tengja það við pöntun frá fyrsta gagnalíkaninu með því að nota rekjaauðkenni sem er til í báðum gerðum.

Við skrifum sama toga og áður, en skilyrðum nú hvort staðfestingartími sé fyrir afhendingu til að fá tvo mælikvarða:

  1. Endurgreiðsluhlutfall - Pantanir með staðfestingu á afhendingu: X%
  2. Endurgreiðsluhlutfall - Pantanir án staðfestingar á afhendingu: Y%

Nógu einfalt. Við sendum það síðan sent út.

Sástu mistökin?

Að óska ​​er afpöntun talin endurgreiðsla. Þar sem afpöntun þýðir að pantanir eru ekki sendar enn, svo þær endar alltaf í öðru mæligildi - endurgreiðsluhlutfall fyrir pantanir án staðfestingar á afhendingu. Þetta blæs upp annað endurgreiðsluhlutfall verulega. Mjög slæmar ákvarðanir mætti ​​taka af þessu.

Þetta dæmi gerðist reyndar í raunveruleikanum (sem betur fer veiddist fljótt). Þegar ég hugsaði til baka, hvenær sem ég tók flýtileiðir og sleppti því að skilja kerfið áður en ég ýtti út gögnum, myndi ég að lokum senda út slæmar tölur.

Að forðast þessa gildru tekur reynslu. Hvenær sem er vinna við nýjan mælikvarða eða nýjan gagnaheimild sem sérfræðingurinn þekkir ekki, þeir þurfa að eyða auka tíma í að skoða gögnin og skilja kerfið. Fyrir fyrstu gagnafræðingana í teyminu mun nánast hvert verkefni fela í sér að vinna með ný og óþekkt gögn.

Það þarf reyndan gagnafræðing til að vita hvenær eigi að hægja á honum. Jafnvel þegar þú stendur frammi fyrir miklu magni af þrýstingi og brýnni.

Að meðhöndla mikið magn beiðna

Vinnuálag greiningaraðila við sprotafyrirtæki

Fyrstu daga óskarinnar vorum við handfyllir af greiningaraðilum og verkfræðingum sem stóðu fyrir vexti fyrirtækis sem var að selja marga milljarða dollara á ári. Við hefðum getað verið 20 manna teymi og samt hefði verið unnið hörðum höndum að því að mæta eftirspurn eftir gögnum.

Við urðum að vera góðir í forgangsröðun. Við myndum einbeita okkur að því að klára mikilvægustu verkefnin og fresta og hafna öllu öðru.

En þetta er miklu auðveldara sagt en gert. Hvað gerir það að verkum að ein beiðni hefur meiri forgang en aðra? Verður lögun beiðnum ýtt út áður en villur eru gerðar? Hvaða lið fengu mesta hjálp?

Til að svara þessu dæmdum við allar kröfur út frá tveimur forsendum:

  1. Áhrifin af því að klára verkefnið
  2. Verkið krafist

Áður en við unnum verkefni, urðum við að meta áhrif þess. Þetta þýðir að við ættum að hugsa um hvernig klára verkefnið mun hafa áhrif á það fyrirtæki. Viðeigandi spurningar fela í sér:

  1. Hver eru svæði fyrirtækisins sem þetta verkefni hefur áhrif á og stærð þessara svæða
  2. Getum við áætlað hækkunina? Í gróft, stærðargráðu?
  3. Hver eru líkurnar á árangri?
  4. Er þetta verkefni stefnumótandi fyrir fyrirtækið? Erum við á gagnrýninni leið fyrir stærra frumkvæði?

Þegar við höfum grófa hugmynd um þetta ættum við að bera saman áætlunina við magn vinnu sem um er að ræða. Við höfðum almenna hugmynd um hversu langan tíma verkefni myndi taka. Villuleiðréttingar tóku hálfan dag til dags, skýrslur tóku tvo daga til viku. Og beiðnir um sértæk gögn myndu taka hálfan dag.

Þetta ættu ekki að vera nákvæm vísindi. Allt sem við þurfum er mjög gróft stærðargráðu samanborið við vinnuáætlun sem hjálpar til við að ákvarða hvaða beiðnir ættu að vinna.

Eftir þessum ramma var hér almenn forgangsröðun fyrir komandi beiðnir:

  • Villuleiðréttingar höfðu yfirleitt mikla forgang. Ef einhver biður um að lagfæra eitthvað, getum við gert ráð fyrir að þeim hafi fundist hluturinn gagnlegur. Svo að festa það mun skila jákvæðu gildi. Oftast voru villuleiðréttingar fljótar, þannig að áhrif þeirra miðað við vinnuhlutfall eru venjulega mikil.
  • Það þurfti að hugsa betur um eiginleikabeiðnir. Mun það bæta hagsmunaaðilum að taka ákvarðanir betri með því að bæta nýjum mælikvarða við þessa skýrslu eða byggja nýja skýrslu?
  • Kerfisbætur, svo sem sameiningar skýrslna eða sameining nokkurra algengra útreikninga í aðskildar leiðslur, skila jákvæðu gildi til meðallangs tíma, en hafa lítil áhrif til skemmri tíma. Þetta ætti að lágmarka við verkefni sem eru nauðsynleg til að koma í veg fyrir að kerfið sprengist.
  • Verkefni með lægsta forgang eru verkefni án þess að hafa skýrt markmið í huga. Þetta er þegar hagsmunaaðilar eru ekki vissir um vandamálið sem þarf að leysa og leita að fleiri gögnum til að kanna. Þessu ætti að ýta til baka þar sem það mun sjaldan leiða til þess að skráin hefur áhrif og hefur tilhneigingu til að taka upp margar endurtekningar á vinnu

Ef beiðnin hefur áhrif, en felur í sér meiri vinnu en nauðsyn krefur, myndum við oft snyrta kröfur frá verkefnum. Ef tölfræði var of erfitt að reikna, myndum við fjarlægja hana úr beiðninni.

Með því að forgangsraða komandi vinnuhlutum og einbeita okkur að verkefnum sem höfðu mest áhrif og minnstu vinnu, gátum við gert mest með því lítinn tíma sem við höfðum.

Til að draga saman, snemma á, er beðið um gagnabeiðnir um, erfitt að fá nákvæmar og koma á óeðlilegan hraða. Jafnvel eftir bestu aðferðum er þetta uppskrift að brennslu. Sérfræðingar geta aðeins haldið út svo lengi.

Afgangurinn stóð að gagnaverkfræði. Okkur vantaði betri innviði.

Tók til starfa sem snemma gagnfræðingur

Lágmarks hagkvæmni afurð gagnainnviða felur í sér:

  1. Gagnalögn sem hægt er að nota til að flytja og troða gögnum
  2. Gagnageymsla sem er fínstillt fyrir greiningarfyrirspurnir
  3. Viðskiptagreindartæki sem greiningaraðilar geta notað til að smíða fljótt töflur

Athugasemd: Greiningar gagnagrunnur (OLAP) er mjög frábrugðinn framleiðslu sem notaður er til að knýja forrit (OLTP). Ef þú ert ruglaður skaltu lesa þetta svar frá StackOverflow

Innleiðing þessara myndi leiða til stórfelldrar hagræðingar. Að búa til gagnaheimild sérstaklega fyrir greiningar fyrirtækja sem auðvelt er að spyrja um til að draga úr þróunartíma okkar á beiðni um 5–7x.

Með því að gera gögnin auðveldari fyrirspurnir dró einnig úr tæknilegum kröfum fyrir greiningaraðila, sem gerði það að verkum að ráðningin var mun hraðari. Við gætum þjálfað þessa færni seinna í starfinu ef þörf krefur.

Að byggja út þetta vegakort er ekki bara verkfræðilegt vandamál. Við urðum að selja þá hugmynd að kaupa viðskiptatækifæri. Wish hafði verkfræðiáherslu menningu sem vildi frekar byggja hluti í húsi, svo við urðum að finna leið til að vinna bug á andmælum og fá innkaup víðs vegar um fyrirtækið.

Hér að neðan mun ég tala um að byggja upp hvert stykki af gagnageymslu. Og nokkrar af helstu kennslustundum.

Endurbygging gagnaleiðslunnar

Þar sem Wish vildi, þar sem núverandi gagnafræðsla leið ekki, var fyrsta forgangsatriðið að endurbyggja það. Við völdum Luigi sem ramma okkar til að endurbyggja það á.

Luigi er ETL ramma sem sá um mörg af þeim málum sem leiðslan stóð fyrir:

  1. Núverandi leiðsla notaði cron tímasetningu til að skilgreina ósjálfstæði. Þetta var ógeðfellt og olli bilun í áfalli. Luigi er með ósjálfstæða stjórnun innbyggða í verkefni.
  2. Núverandi leiðsla var með bilanir sem þurftu tímafrekt handvirkar endurtekningar. Luigi er óeigingjarn, sem þýðir að hann man hvaða verkefni eru vel heppnuð og endurtekin aðeins mistök verkefni. Þetta gerir það að verkum að auðvelt er að takast á við bilun.
  3. Núverandi leiðsla tók lengri tíma en sólarhring til að vinna dagsins virði. Luigi er með tímaáætlun, sem tryggir að eitt ETL starf geti ekki keyrt tvisvar á sama tíma. Úr þessu gætum við skipt út einu verkefnaliti yfir nokkrar vélar og skorið tímalengdina um meira en helming.

Á tveimur mánuðum flutti ég yfir 200 ETL störf frá gamla kerfinu okkar og ýmsum Cron forskriftum.

Að flytja ETL-störf yfir á annan vettvang reyndist ekki léttvæg. Verkefninu seinkaði nálægt byrjun þegar ég reyndi að gera of mikið á sama tíma. Eftir að hafa flutt nokkrar leiðslur yfir í nýja kerfið sá ég líka og ákvað að laga nokkur tímabelti í ETL-kóðanum. Niðurstaðan var nýtt kerfi sem var afar erfitt að staðfesta.

Ég lærði nokkrar lexíur af þessu verkefni sem var ágætlega dregið saman í nýlegri grein sem ég las um hvernig hægt væri að bæta eldri kóðabasa:

  1. Reyndu að breyta ekki of mörgum hlutum á sama tíma
  2. Ekki breyta viðskiptafræðinni þegar skipt er um innviði
  3. Sjálfvirk próf með staðfestingarforskriftum

Helsta áhættan með endurgerð er að þú getur kynnt þér tonn af nýjum galla. Með yfir 200 ETL störf til að flytja, að vera laissez faire með að halda lokaniðurstöðu kerfisins eins hefði drepið verkefnið.

Þannig að auðveldasta leiðin til að takast á við þetta er að kynna litlar breytingar sem hægt er að staðfesta sjálfkrafa með prufuramma og passa við gamla kerfið. Forðast ætti breytingar sem breyta lokaniðurstöðunni þar til öllu verkefninu er lokið.

Fyrir þetta verkefni þýddi þetta að byggja prufutæki sem gaf framhjá / mistókst að flytja leiðslur, með því að bera framleiðsla sína saman við gömlu leiðsluna.

Nýja kerfið byggt á Luigi var barbein. En það var stöðugt og afgreiddi eigin mistök. Það var eitthvað sem við gætum reitt okkur á þegar við byggðum upp afganginn af gagnagrunninum.

Að byggja gagnageymsluhúsið

Hægt er að rigga upp skjótan MVP fyrir gagnageymslu úr núverandi codebase

Gagnageymsla er gagnagrunnur sem gerir fljótt að skrifa og keyra greiningarfyrirspurnir. Venjulega felur það í sér töflur sem auðvelt er að skilja og fyrirspurnir - mun hreinni framsetning framleiðsluborða.

Til dæmis er ein af töflunum sem oftast er notuð í vöruhúsinu núna kallað merch_merchanttransaction. Þetta er tafla þar sem hver röð táknar allt um röð sem sérfræðingur gæti viljað vita um. Í stað þess að tímafrekt MongoDB sameinist um að fá upplýsingar um pöntun + mælingar eða upplýsingar um röð + endurgreiðslu, geta sérfræðingar skrifað fyrirspurnir á þessu einstaka töflu og yfirleitt náð árangri á nokkrum mínútum, samanborið við klukkustundir sem þú hefur eytt fyrirspurnum um MongoDB.

Það er mjög auðvelt að rúlla gagnageymslu. Við urðum bara að nota mikið af því starfi sem þegar hafði verið unnið við að byggja upp skýrslugerð.

Við gætum byrjað á hönnun töflanna með því að skoða mikilvægustu skýrslur sem fyrir eru og velja mikilvægustu mæligildin og víddirnar. Við gætum síðan endurnýjuð kóðann sem skilaði þessum tölum í skýrslunum, í gagnalagnir sem ýttu út fleiri kornóttar skrár í gagnageymsluna okkar sem valin var.

Þetta ferli tók innan við þrjár vikur. Í lokin vorum við með gagnageymslu sem náði til stórs% af ferlum fyrirtækisins og var hægt að nota til að flýta fyrirspurnum greiningaraðila.

Við völdum Redshift sem gagnagrunn. Við vorum þegar að nota Hive (TreasureData) til skráningarforrita, svo við notuðum það aftur til að varpa og reikna nýju töflurnar okkar. TreasureData er með Redshift samþættingu, sem við notuðum til að senda nákvæm afrit af þessum töflum í Redshift þyrpinguna okkar.

Dreifa viðskiptagreindartólum

Hluti af þilfari - selja hugmyndina um að kaupa BI verkfæri innvortis

Uppruni var upphaflega gerður með HTML tölvupósti, sendur með python forskriftum. Þetta er í raun mjög árangursríkt:

  1. Þar sem þetta voru bara Python forskriftir sem sendu frá sér HTML sniðin gögn, var hægt að úthluta skýrsluverkefnum til allra verkfræðinga í teyminu.
  2. Engin takmörkun var á því hvernig hægt væri að forsníða töflur og töflur, ólíkt stífari mannvirkjum sem finnast í BI verkfærum. Skýrslan gæti verið nákvæmlega hönnuð fyrir kerfið.

En það voru takmarkanir, sem gerðu þetta kerfi erfitt fyrir að vaxa:

  • Þessar skýrslur voru erfiðar að skrifa og prófa - stundum tók allt að einn dag að keyra.
  • Ekki voru neinar boranir og síun, svo að mismunandi skoðanir á sömu gögnum þyrfti að skera út í nokkrum skýrslum.
  • Að breyta þessum skýrslum með jafnvel minnstu breytingu tók tíma þar sem prófanir voru langar og með tímanum var mikill kóðabas að viðhalda.

Til að laga þetta, þurftum við að setja upp viðskiptagreindartæki, sem meðhöndlaði skjótan myndskreytingu ofan á gagnageymslu.

Framkvæmdin væri auðveld. Nútímaleg ský byggð SaaS lausnir eru meira og minna plug and play.

Stopparinn var að fá samþykki fyrir kaupum. Hvernig sannfærir þú ákvarðanatöku (CTO) okkar um að við þyrftum að kaupa tæki til að flýta fyrir skýrslugerð, þegar hann hefur engin bein tenging við neina sársaukapunkta sem talin eru upp hér að ofan? Allt sem hann sér er niðurstaðan - tölvupóstskýrslur. Og honum, þetta kerfi virkaði fínt.

En sársaukapunktarnir við skýrslutöku voru til og allir verkfræðingar sem unnu tölvupóstskýrslur töldu það. Að lokum átti ég nóg af innkaupum á millistjórnunarstigi til að hefja söluferlið.

Frá upphafi til enda tók þetta yfirtökuferli fyrir Looker um tvo mánuði. Til þess voru hér skrefin sem krafist var:

  1. Kynning til yfirmanns míns (yfirmanns pallsins) um mögulegt virðisauka Looker, þar með talið áætlun um aukinn tíma í mælaborðinu og vinnu vistuð
  2. Að fá innkaup frá hagsmunaaðilum í fyrirtækjarekstri út frá því hve hratt Looker ætlaði að gera byggingarskýrslur fyrir þá
  3. Að fá innkaup frá Jack, yfirmanni okkar gagna, byggð á stuðningi frá 1 + 2
  4. Að semja um prufuáfanga fyrir Looker, svo við gætum smíðað fyrstu mælaborðið okkar (4 vikur)
  5. Notaðu þennan tíma til að búa til grunn sett af mælaborðum fyrir fyrirtækið (20 mælaborð)
  6. Kynning á gögnum frá þessum prufuáfanga, fágað líkan fyrir arðsemi fjárfestingarinnar miðað við tíma sparaðan á mælaborðinu og kynnt fyrir CTO til endanlegrar samþykktar

Þetta gæti hljómað mjög skriffinnsku. Það þarf að skoða vandlega ákvörðunina um að útfæra tæki sem notað er fyrirtæki. Þetta ferli tryggir að áhrifin hafi verið hugsuð í gegn frá sjónarhóli allra notenda sem að lokum munu ráðast af gagnakerfinu.

Með því að setja fram arðsemiskröfu sem byggðist á kostnaðarsparnaði í lækkun á fjölda starfsmanna og endurbótum á skilvirkni samanborið við verð á Looker og Redshift, gátum við ýtt framhjá andmælum um að byggja upp vs kaupa og nota ókeypis ókeypis verkfæri.

Gagnauppbyggingin ... endurbyggð!

Þegar Looker var ræst út hafði okkur tekist að endurreisa grunninn í greiningunni hjá Wish. Héðan af gátum við skipt út höfðatölu og byrjað að mæta eftirspurn eftir gögnum sem hafa verið svo afturhald í fyrirtækinu. Þetta voru risastór tímamót.

Fyrir restina af greininni mun ég tala um næstu skref. Hvernig á að mæla út gagnaverkfræði og teymissérfræðinga og hvernig á að ráða og stjórna fyrir mikla afköst.

Til að halda áfram að lesa, smelltu hér fyrir næsta kafla (Stærð gagnaverkfræði).

Fara til

  1. 1. hluti - Endurbygging stofnunarinnar
  2. Hluti 2 - Stærð gagnaverkfræði
  3. Hluti 3 - Stærð gagnagreiningar
  4. 4. hluti - Ráðning

Komdu að vinna með okkur!

Ég stýri gögnum lið Merchant Platform. Við erum teymið sem styður allt á seljanda hlið markaðsins - vefsíðan sem söluaðilar nota til að stjórna sölu og birgðum og sjá hvort þeir séu í samræmi við stefnu okkar. Við eigum stefnumótandi eiginleika sem fela í sér Wish Express (7 daga sendingarforrit okkar) og ProductBoost, auglýsingapallinn okkar. Við eigum einnig þann notanda sem snýr að flutningsmati.

Komdu með ef þú hefur áhuga á miklu magni af eignarhaldi. Þetta þýðir sem sérfræðingar, þú munt keyra ákvarðanir sem hafa áhrif á fyrirtækið með stórum sveiflum hvað varðar tekjur (+ 1% eða meira). Sem verkfræðingar, munt þú eiga og byggja upp kerfið sem knýr alla gagnareiginleika og stefnu á söluaðila.

Við þurfum nokkrar ráðningar í hvert hlutverk:

  • Gagnasérfræðingur / Senior Data Analyst Eigin stefnu, forrit og vöruaðgerðir. Magnið hæðir og hæðir ákvarðana og drifið þær til loka.
  • Hugbúnaðarverkfræðingur - Gagnagögn eru notuð mikið í seljanda. Það hefur vald á öllum mælaborðum sem snúa að notendum og stefnuvél okkar sem veitir kaupmönnum lélega afkomu. Hjálpaðu til við að byggja upp gagnareiginleika og kvarða kerfið.
  • Magnfræðingur Vinnið við flutningamat, notandi sem snýr að eiginleikum sem segir notendum áætlun um hvenær vörur berast. Vinndu að áhættueiginleikum og minnkaðu svik kaupmanna
  • Öll önnur hlutverk

Sendu mér tölvupóst á netfangið samson@wish.com fyrir tilvísun.