શું આપણે ડેટા લેકની જરૂર છે? ડેટા વેરહાઉસ સાથે શું કરવું?

આ લેખ માધ્યમ પરના મારા લેખનો અનુવાદ છે - ડેટા લેક સાથે પ્રારંભ, જે કદાચ તેની સાદગીને કારણે ખૂબ જ લોકપ્રિય બન્યું. તેથી, મેં તેને રશિયનમાં લખવાનું નક્કી કર્યું અને ડેટા વેરહાઉસ (ડીડબ્લ્યુ) શું છે અને ડેટા લેક શું છે (ડેટા લેક) અને તેઓ કેવી રીતે ડેટા નિષ્ણાત નથી તે સામાન્ય વ્યક્તિને તે સ્પષ્ટ કરવા માટે થોડું ઉમેરવાનું નક્કી કર્યું. સાથે મેળવો.

હું ડેટા લેક વિશે કેમ લખવા માંગતો હતો? હું 10 વર્ષથી વધુ સમયથી ડેટા અને એનાલિટિક્સ સાથે કામ કરી રહ્યો છું, અને હવે હું ચોક્કસપણે કેમ્બ્રિજમાં Amazon Alexa AI ખાતે મોટા ડેટા સાથે કામ કરી રહ્યો છું, જે બોસ્ટનમાં છે, જોકે હું વાનકુવર ટાપુ પર વિક્ટોરિયામાં રહું છું અને ઘણીવાર બોસ્ટન, સિએટલની મુલાકાત લઉં છું. , અને વાનકુવરમાં, અને ક્યારેક મોસ્કોમાં પણ, હું પરિષદોમાં બોલું છું. હું પણ સમયાંતરે લખું છું, પરંતુ હું મુખ્યત્વે અંગ્રેજીમાં લખું છું, અને મેં પહેલેથી જ લખ્યું છે કેટલાક પુસ્તકો, મને ઉત્તર અમેરિકાના એનાલિટિક્સ વલણો પણ શેર કરવાની જરૂર છે, અને હું ક્યારેક લખું છું તાર.

મેં હંમેશા ડેટા વેરહાઉસ સાથે કામ કર્યું છે, અને 2015 થી મેં એમેઝોન વેબ સેવાઓ સાથે નજીકથી કામ કરવાનું શરૂ કર્યું, અને સામાન્ય રીતે ક્લાઉડ એનાલિટિક્સ (AWS, Azure, GCP) પર સ્વિચ કર્યું. મેં 2007 થી એનાલિટિક્સ સોલ્યુશન્સના ઉત્ક્રાંતિનું અવલોકન કર્યું છે અને ડેટા વેરહાઉસ વિક્રેતા ટેરાડેટા માટે પણ કામ કર્યું છે અને તેને Sberbank પર અમલમાં મૂક્યું છે, અને તે જ સમયે Hadoop સાથે બિગ ડેટા દેખાયો. બધાએ કહેવાનું શરૂ કર્યું કે સ્ટોરેજનો યુગ વીતી ગયો છે અને હવે બધું હડૂપ પર છે, અને પછી તેઓ ફરીથી ડેટા લેક વિશે વાત કરવા લાગ્યા કે હવે ડેટા વેરહાઉસનો અંત ચોક્કસપણે આવી ગયો છે. પરંતુ સદભાગ્યે (કદાચ કમનસીબે એવા કેટલાક લોકો માટે કે જેમણે Hadoop સેટ કરીને ઘણા પૈસા કમાવ્યા હતા), ડેટા વેરહાઉસ દૂર ન થયું.

આ લેખમાં આપણે જોઈશું કે ડેટા લેક શું છે. આ લેખ એવા લોકો માટે બનાવાયેલ છે જેમને ડેટા વેરહાઉસનો ઓછો અથવા કોઈ અનુભવ નથી.

ચિત્રમાં લેક બ્લેડ છે, આ મારા મનપસંદ તળાવોમાંનું એક છે, જો કે હું ત્યાં માત્ર એક જ વાર હતો, મેં તેને મારા બાકીના જીવન માટે યાદ રાખ્યું. પરંતુ અમે બીજા પ્રકારના તળાવ વિશે વાત કરીશું - ડેટા લેક. કદાચ તમારામાંથી ઘણાએ આ શબ્દ વિશે એક કરતા વધુ વાર સાંભળ્યું હશે, પરંતુ એક વધુ વ્યાખ્યા કોઈને નુકસાન પહોંચાડશે નહીં.

સૌ પ્રથમ, અહીં ડેટા લેકની સૌથી લોકપ્રિય વ્યાખ્યાઓ છે:

"સંસ્થામાં કોઈપણ વ્યક્તિ દ્વારા વિશ્લેષણ માટે ઉપલબ્ધ તમામ પ્રકારના કાચા ડેટાનો ફાઇલ સ્ટોરેજ" - માર્ટિન ફાઉલર.

“જો તમને લાગે છે કે ડેટા માર્ટ એ પાણીની બોટલ છે - શુદ્ધિકરણ, પેકેજ્ડ અને અનુકૂળ વપરાશ માટે પેકેજ્ડ, તો ડેટા લેક તેના કુદરતી સ્વરૂપમાં પાણીનો વિશાળ ભંડાર છે. વપરાશકર્તાઓ, હું મારા માટે પાણી એકત્રિત કરી શકું છું, ઊંડા ડૂબકી મારી શકું છું, અન્વેષણ કરી શકું છું” - જેમ્સ ડિક્સન.

હવે અમે ખાતરીપૂર્વક જાણીએ છીએ કે ડેટા લેક એ એનાલિટિક્સ વિશે છે, તે અમને તેના મૂળ સ્વરૂપમાં મોટા પ્રમાણમાં ડેટા સ્ટોર કરવાની મંજૂરી આપે છે અને અમારી પાસે ડેટાની આવશ્યક અને અનુકૂળ ઍક્સેસ છે.

હું ઘણી વાર વસ્તુઓને સરળ બનાવવાનું પસંદ કરું છું, જો હું કોઈ જટિલ શબ્દને સરળ શબ્દોમાં સમજાવી શકું, તો હું મારી જાતને સમજી શકું છું કે તે કેવી રીતે કાર્ય કરે છે અને તેની શું જરૂર છે. એક દિવસ, હું આઇફોન ફોટો ગેલેરીમાં ફરતો હતો, અને તે મારા પર ઉઠ્યું, આ એક વાસ્તવિક ડેટા લેક છે, મેં કોન્ફરન્સ માટે એક સ્લાઇડ પણ બનાવી છે:

બધું ખૂબ જ સરળ છે. અમે ફોન પર ફોટો લઈએ છીએ, ફોટો ફોનમાં સેવ થાય છે અને iCloud (ક્લાઉડ ફાઇલ સ્ટોરેજ)માં સેવ કરી શકાય છે. ફોન ફોટો મેટાડેટા પણ એકત્રિત કરે છે: શું બતાવવામાં આવ્યું છે, જીઓ ટેગ, સમય. પરિણામે, અમે અમારો ફોટો શોધવા માટે iPhone ના વપરાશકર્તા-મૈત્રીપૂર્ણ ઇન્ટરફેસનો ઉપયોગ કરી શકીએ છીએ અને અમે સૂચકો પણ જોઈ શકીએ છીએ, ઉદાહરણ તરીકે, જ્યારે હું ફાયર શબ્દ સાથે ફોટા શોધું છું, ત્યારે મને આગની છબી સાથે 3 ફોટા મળે છે. મારા માટે, આ એક બિઝનેસ ઇન્ટેલિજન્સ ટૂલ જેવું છે જે ખૂબ જ ઝડપથી અને સચોટ રીતે કામ કરે છે.

અને અલબત્ત, આપણે સુરક્ષા (અધિકૃતતા અને પ્રમાણીકરણ) વિશે ભૂલવું જોઈએ નહીં, અન્યથા આપણો ડેટા સરળતાથી સાર્વજનિક ડોમેનમાં સમાપ્ત થઈ શકે છે. મોટા કોર્પોરેશનો અને સ્ટાર્ટઅપ્સ વિશે ઘણા સમાચાર છે જેમનો ડેટા વિકાસકર્તાઓની બેદરકારી અને સરળ નિયમોનું પાલન કરવામાં નિષ્ફળતાને કારણે સાર્વજનિક રૂપે ઉપલબ્ધ થયો છે.

આટલું સરળ ચિત્ર પણ ડેટા લેક શું છે તેની કલ્પના કરવામાં મદદ કરે છે, પરંપરાગત ડેટા વેરહાઉસ અને તેના મુખ્ય તત્વોથી તેનો તફાવત:

1. ડેટા લોડ કરી રહ્યું છે (ઇન્જેશન) એ ડેટા લેકનો મુખ્ય ઘટક છે. ડેટા બે રીતે ડેટા વેરહાઉસમાં પ્રવેશી શકે છે - બેચ (અંતરે લોડિંગ) અને સ્ટ્રીમિંગ (ડેટા ફ્લો).
2. ફાઇલ સ્ટોરેજ (સ્ટોરેજ) એ ડેટા લેકનું મુખ્ય ઘટક છે. અમારે સ્ટોરેજ સરળતાથી માપી શકાય તેવું, અત્યંત ભરોસાપાત્ર અને ઓછી કિંમત માટે જરૂરી છે. ઉદાહરણ તરીકે, AWS માં તે S3 છે.
3. કેટલોગ અને શોધ (કેટલોગ અને શોધ) - ડેટા સ્વેમ્પથી બચવા માટે (આ ​​ત્યારે થાય છે જ્યારે આપણે બધા ડેટાને એક ખૂંટોમાં ડમ્પ કરીએ છીએ, અને પછી તેની સાથે કામ કરવું અશક્ય છે), ડેટાને વર્ગીકૃત કરવા માટે અમારે મેટાડેટા સ્તર બનાવવાની જરૂર છે. જેથી વપરાશકર્તાઓ સરળતાથી ડેટા શોધી શકે, જેની તેમને વિશ્લેષણ માટે જરૂર હોય છે. વધુમાં, તમે વધારાના શોધ ઉકેલોનો ઉપયોગ કરી શકો છો જેમ કે સ્થિતિસ્થાપક શોધ. શોધ વપરાશકર્તાને વપરાશકર્તા મૈત્રીપૂર્ણ ઇન્ટરફેસ દ્વારા જરૂરી ડેટા શોધવામાં મદદ કરે છે.
4. પ્રક્રિયા (પ્રક્રિયા) - આ પગલું ડેટાની પ્રક્રિયા અને પરિવર્તન માટે જવાબદાર છે. અમે ડેટાને બદલી શકીએ છીએ, તેનું માળખું બદલી શકીએ છીએ, તેને સાફ કરી શકીએ છીએ અને ઘણું બધું કરી શકીએ છીએ.
5. સુરક્ષા (સુરક્ષા) - સોલ્યુશનની સુરક્ષા ડિઝાઇન પર સમય પસાર કરવો મહત્વપૂર્ણ છે. ઉદાહરણ તરીકે, સ્ટોરેજ, પ્રોસેસિંગ અને લોડિંગ દરમિયાન ડેટા એન્ક્રિપ્શન. પ્રમાણીકરણ અને અધિકૃતતા પદ્ધતિઓનો ઉપયોગ કરવો મહત્વપૂર્ણ છે. છેલ્લે, ઓડિટ સાધનની જરૂર છે.

વ્યવહારિક દૃષ્ટિકોણથી, આપણે ત્રણ લક્ષણો દ્વારા ડેટા લેકને લાક્ષણિકતા આપી શકીએ છીએ:

1. કંઈપણ એકત્રિત કરો અને સંગ્રહ કરો — ડેટા લેકમાં તમામ ડેટા, કોઈપણ સમયગાળા માટેનો કાચો અનપ્રોસેસ્ડ ડેટા અને પ્રોસેસ્ડ/ક્લીન ડેટા બંને સમાવે છે.
2. ડીપ સ્કેન - ડેટા લેક વપરાશકર્તાઓને ડેટાનું અન્વેષણ અને વિશ્લેષણ કરવાની મંજૂરી આપે છે.
3. લવચીક ઍક્સેસ — ડેટા લેક વિવિધ ડેટા અને વિવિધ દૃશ્યો માટે લવચીક ઍક્સેસ પ્રદાન કરે છે.

હવે આપણે ડેટા વેરહાઉસ અને ડેટા લેક વચ્ચેના તફાવત વિશે વાત કરી શકીએ છીએ. સામાન્ય રીતે લોકો પૂછે છે:

• ડેટા વેરહાઉસ વિશે શું?
• શું આપણે ડેટા વેરહાઉસને ડેટા લેક સાથે બદલી રહ્યા છીએ અથવા આપણે તેને વિસ્તૃત કરી રહ્યા છીએ?
• શું ડેટા લેક વિના કરવું હજી પણ શક્ય છે?

ટૂંકમાં, કોઈ સ્પષ્ટ જવાબ નથી. તે બધું ચોક્કસ પરિસ્થિતિ, ટીમની કુશળતા અને બજેટ પર આધારિત છે. ઉદાહરણ તરીકે, ડેટા વેરહાઉસને ઓરેકલથી AWS પર સ્થાનાંતરિત કરવું અને એમેઝોનની પેટાકંપની દ્વારા ડેટા લેક બનાવવું - Woot - અમારી ડેટા લેક સ્ટોરી: કેવી રીતે Woot.com એ AWS પર સર્વરલેસ ડેટા લેક બનાવ્યું.

બીજી બાજુ, વિક્રેતા સ્નોફ્લેક કહે છે કે તમારે હવે ડેટા લેક વિશે વિચારવાની જરૂર નથી, કારણ કે તેમનું ડેટા પ્લેટફોર્મ (2020 સુધી તે ડેટા વેરહાઉસ હતું) તમને ડેટા લેક અને ડેટા વેરહાઉસ બંનેને જોડવાની મંજૂરી આપે છે. મેં સ્નોફ્લેક સાથે વધુ કામ કર્યું નથી, અને તે ખરેખર એક અનન્ય ઉત્પાદન છે જે આ કરી શકે છે. મુદ્દાની કિંમત બીજી બાબત છે.

નિષ્કર્ષમાં, મારો અંગત અભિપ્રાય એ છે કે અમને હજી પણ અમારા રિપોર્ટિંગ માટે ડેટાના મુખ્ય સ્ત્રોત તરીકે ડેટા વેરહાઉસની જરૂર છે, અને જે પણ યોગ્ય નથી તે અમે ડેટા લેકમાં સંગ્રહિત કરીએ છીએ. વિશ્લેષણની સંપૂર્ણ ભૂમિકા વ્યવસાય માટે નિર્ણયો લેવા માટે સરળ ઍક્સેસ પ્રદાન કરવાની છે. ગમે તે કહે, બિઝનેસ યુઝર્સ ડેટા લેક કરતાં ડેટા વેરહાઉસ સાથે વધુ કાર્યક્ષમતાથી કામ કરે છે, ઉદાહરણ તરીકે એમેઝોનમાં - ત્યાં રેડશિફ્ટ (વિશ્લેષણાત્મક ડેટા વેરહાઉસ) છે અને ત્યાં રેડશિફ્ટ સ્પેક્ટ્રમ/એથેના (એસ3માં ડેટા લેક માટે એસક્યુએલ ઇન્ટરફેસ) છે. મધપૂડો/પ્રેસ્ટો). આ જ અન્ય આધુનિક વિશ્લેષણાત્મક ડેટા વેરહાઉસને લાગુ પડે છે.

ચાલો એક સામાન્ય ડેટા વેરહાઉસ આર્કિટેક્ચર જોઈએ:

આ એક ઉત્તમ ઉકેલ છે. અમારી પાસે સ્રોત સિસ્ટમ્સ છે, ETL/ELT નો ઉપયોગ કરીને અમે વિશ્લેષણાત્મક ડેટા વેરહાઉસમાં ડેટાની નકલ કરીએ છીએ અને તેને બિઝનેસ ઇન્ટેલિજન્સ સોલ્યુશન સાથે જોડીએ છીએ (મારું મનપસંદ ટેબ્લ્યુ છે, તમારું શું છે?).

આ સોલ્યુશનમાં નીચેના ગેરફાયદા છે:

• ETL/ELT કામગીરી માટે સમય અને સંસાધનોની જરૂર પડે છે.
• નિયમ પ્રમાણે, વિશ્લેષણાત્મક ડેટા વેરહાઉસમાં ડેટા સ્ટોર કરવા માટેની મેમરી સસ્તી નથી (ઉદાહરણ તરીકે, Redshift, BigQuery, Teradata), કારણ કે આપણે એક સંપૂર્ણ ક્લસ્ટર ખરીદવાની જરૂર છે.
• વ્યાપારી વપરાશકર્તાઓને સાફ કરેલ અને ઘણી વખત એકીકૃત ડેટાની ઍક્સેસ હોય છે અને તેમને કાચા ડેટાની ઍક્સેસ હોતી નથી.

અલબત્ત, તે બધા તમારા કેસ પર આધાર રાખે છે. જો તમને તમારા ડેટા વેરહાઉસમાં સમસ્યા નથી, તો તમારે ડેટા લેકની બિલકુલ જરૂર નથી. પરંતુ જ્યારે જગ્યા, શક્તિ અથવા કિંમતની અછત સાથે સમસ્યાઓ ઊભી થાય છે, ત્યારે તમે ડેટા લેકના વિકલ્પ પર વિચાર કરી શકો છો. આ કારણે ડેટા લેક ખૂબ જ લોકપ્રિય છે. અહીં ડેટા લેક આર્કિટેક્ચરનું ઉદાહરણ છે:

ડેટા લેક અભિગમનો ઉપયોગ કરીને, અમે અમારા ડેટા લેક (બેચ અથવા સ્ટ્રીમિંગ) માં કાચો ડેટા લોડ કરીએ છીએ, પછી અમે જરૂરિયાત મુજબ ડેટા પર પ્રક્રિયા કરીએ છીએ. ડેટા લેક બિઝનેસ યુઝર્સને તેમના પોતાના ડેટા ટ્રાન્સફોર્મેશન (ETL/ELT) બનાવવા અથવા બિઝનેસ ઇન્ટેલિજન્સ સોલ્યુશન્સમાં ડેટાનું વિશ્લેષણ કરવાની મંજૂરી આપે છે (જો જરૂરી ડ્રાઇવર ઉપલબ્ધ હોય તો).

કોઈપણ એનાલિટિક્સ સોલ્યુશનનો ધ્યેય વ્યવસાય વપરાશકર્તાઓને સેવા આપવાનો છે. તેથી, આપણે હંમેશા વ્યવસાયની જરૂરિયાતો અનુસાર કામ કરવું જોઈએ. (એમેઝોન પર આ એક સિદ્ધાંત છે - પાછળની તરફ કામ કરવું).

ડેટા વેરહાઉસ અને ડેટા લેક બંને સાથે કામ કરીને, અમે બંને ઉકેલોની તુલના કરી શકીએ છીએ:

મુખ્ય નિષ્કર્ષ જે દોરવામાં આવી શકે છે તે એ છે કે ડેટા વેરહાઉસ ડેટા લેક સાથે સ્પર્ધા કરતું નથી, પરંતુ તેને પૂરક બનાવે છે. પરંતુ તમારા કેસ માટે શું યોગ્ય છે તે નક્કી કરવાનું તમારા પર છે. તેને જાતે અજમાવવા અને યોગ્ય તારણો દોરવા હંમેશા રસપ્રદ છે.

જ્યારે મેં ડેટા લેક અભિગમનો ઉપયોગ કરવાનું શરૂ કર્યું ત્યારે હું તમને એક કિસ્સો પણ જણાવવા માંગુ છું. બધું એકદમ તુચ્છ છે, મેં એક ELT ટૂલ (અમારી પાસે Matillion ETL હતું) અને એમેઝોન રેડશિફ્ટનો ઉપયોગ કરવાનો પ્રયાસ કર્યો, મારું સોલ્યુશન કામ કર્યું, પરંતુ જરૂરિયાતોને બંધબેસતું નહોતું.

મારે વેબ લૉગ્સ લેવા, તેમને રૂપાંતરિત કરવા અને 2 કેસ માટે ડેટા પ્રદાન કરવા માટે તેમને એકત્રિત કરવાની જરૂર હતી:

1. માર્કેટિંગ ટીમ SEO માટે બોટ પ્રવૃત્તિનું વિશ્લેષણ કરવા માંગતી હતી
2. IT વેબસાઇટ પ્રદર્શન મેટ્રિક્સ જોવા માંગે છે

ખૂબ જ સરળ, ખૂબ જ સરળ લોગ. અહીં એક ઉદાહરણ છે:

https 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188 
192.168.131.39:2817 10.0.0.1:80 0.086 0.048 0.037 200 200 0 57 
"GET https://www.example.com:443/ HTTP/1.1" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337281-1d84f3d73c47ec4e58577259" "www.example.com" "arn:aws:acm:us-east-2:123456789012:certificate/12345678-1234-1234-1234-123456789012"
1 2018-07-02T22:22:48.364000Z "authenticate,forward" "-" "-"

એક ફાઇલનું વજન 1-4 મેગાબાઇટ્સ હતું.

પરંતુ એક મુશ્કેલી હતી. અમારી પાસે સમગ્ર વિશ્વમાં 7 ડોમેન્સ હતા અને એક દિવસમાં 7000 હજાર ફાઇલો બનાવવામાં આવી હતી. આ વધુ વોલ્યુમ નથી, માત્ર 50 ગીગાબાઇટ્સ છે. પરંતુ અમારા રેડશિફ્ટ ક્લસ્ટરનું કદ પણ નાનું હતું (4 નોડ્સ). પરંપરાગત રીતે એક ફાઇલ લોડ કરવામાં લગભગ એક મિનિટ લાગી. એટલે કે, સમસ્યા માથા પર હલ થઈ નથી. અને આ કેસ હતો જ્યારે મેં ડેટા લેક અભિગમનો ઉપયોગ કરવાનું નક્કી કર્યું. ઉકેલ આના જેવો દેખાતો હતો:

તે એકદમ સરળ છે (હું એ નોંધવા માંગુ છું કે ક્લાઉડમાં કામ કરવાનો ફાયદો એ સરળતા છે). મે વાપર્યુ:

• કમ્પ્યુટ પાવર માટે AWS સ્થિતિસ્થાપક નકશો ઘટાડો (Hadoop).
• AWS S3 ડેટાને એન્ક્રિપ્ટ કરવાની અને ઍક્સેસને મર્યાદિત કરવાની ક્ષમતા સાથે ફાઇલ સ્ટોરેજ તરીકે
• InMemory કમ્પ્યુટિંગ પાવર તરીકે સ્પાર્ક અને લોજિક અને ડેટા ટ્રાન્સફોર્મેશન માટે PySpark
• સ્પાર્કના પરિણામે લાકડાનું પાતળું પડ
• નવા ડેટા અને પાર્ટીશનો વિશે મેટાડેટા કલેક્ટર તરીકે AWS ગ્લુ ક્રાઉલર
• હાલના Redshift વપરાશકર્તાઓ માટે ડેટા લેકના SQL ઇન્ટરફેસ તરીકે Redshift સ્પેક્ટ્રમ

સૌથી નાનું EMR+Spark ક્લસ્ટર 30 મિનિટમાં ફાઇલોના સમગ્ર સ્ટેક પર પ્રક્રિયા કરે છે. AWS માટે અન્ય કેસો છે, ખાસ કરીને ઘણા એલેક્સા સાથે સંબંધિત છે, જ્યાં ઘણો ડેટા છે.

હમણાં જ મેં જાણ્યું કે ડેટા લેકના ગેરફાયદામાંનો એક છે GDPR. સમસ્યા એ છે કે જ્યારે ક્લાયંટ તેને કાઢી નાખવાનું કહે છે અને ડેટા એક ફાઇલમાં હોય છે, ત્યારે અમે ડેટા મેનિપ્યુલેશન લેંગ્વેજનો ઉપયોગ કરી શકતા નથી અને ડેટાબેઝની જેમ ડિલીટ ઓપરેશન કરી શકતા નથી.

હું આશા રાખું છું કે આ લેખ ડેટા વેરહાઉસ અને ડેટા લેક વચ્ચેના તફાવતને સ્પષ્ટ કરે છે. જો તમને રુચિ હોય, તો હું મારા વધુ લેખો અથવા મેં વાંચેલા વ્યાવસાયિકોના લેખોનો અનુવાદ કરી શકું છું. અને હું જે સોલ્યુશન્સ સાથે કામ કરું છું અને તેમના આર્કિટેક્ચર વિશે પણ જણાવો.

સોર્સ: www.habr.com