අපි ඉතා කාර්යක්ෂම සහ මිල අඩු DataLake සංවිධානය කළ ආකාරය සහ මෙය එසේ වන්නේ ඇයි

අපි ජීවත් වන්නේ ඔබට ඉක්මනින් සහ පහසුවෙන් සූදානම් කළ විවෘත මූලාශ්‍ර මෙවලම් කිහිපයක් සම්බන්ධ කර, “බහු අකුරු” ගැන සොයා බැලීමකින් තොරව, ස්ටැක්වර්ෆ්ලෝ හි උපදෙස් අනුව ඔබේ “විඥානය ක්‍රියා විරහිත කර” ඒවා සකසා දියත් කළ හැකි පුදුමාකාර කාලයක ය. ඒවා වාණිජමය ක්‍රියාකාරිත්වයට. ඔබට යාවත්කාලීන කිරීමට/පුළුල් කිරීමට අවශ්‍ය වූ විට හෝ යමෙකු අහම්බෙන් යන්ත්‍ර කිහිපයක් නැවත පණගන්වන විට - යම් ආකාරයක උමතු නරක සිහිනයක් ආරම්භ වී ඇති බව ඔබට වැටහේ, සියල්ල හඳුනාගත නොහැකි ලෙස නාටකාකාර ලෙස සංකීර්ණ වී ඇත, ආපසු හැරීමක් නැත, අනාගතය නොපැහැදිලි සහ ආරක්ෂිතයි, ක්‍රමලේඛනය වෙනුවට මී මැස්සන් බෝ කර චීස් කරන්න.

වඩා පළපුරුදු සගයන්, ඔවුන්ගේ හිස් දෝෂවලින් වැසී ඇති අතර ඒ නිසා දැනටමත් අළු පැහැයෙන් යුක්ත වන අතර, “විලාසිතාගත භාෂා” වලින් සාදන ලද සහය ඇතිව සේවාදායක දුසිම් ගණනක “කැට” තුළ “කන්ටේනර්” ඇසුරුම් ඇදහිය නොහැකි තරම් වේගයෙන් යෙදවීම ගැන කල්පනා කිරීම නිකම්ම නොවේ. අසමමුහුර්ත-අවහිර නොවන I/O, නිහතමානීව සිනාසෙන්න. ඔවුන් නිශ්ශබ්දව දිගටම “man ps” නැවත කියවා, ඔවුන්ගේ ඇස්වලින් ලේ ගලන තුරු “nginx” මූලාශ්‍ර කේතය සොයා බලයි, සහ ඒකක පරීක්ෂණ ලිවීම, ලිවීම, ලිවීම. අලුත් අවුරුදු උදාවේදී එක් දිනක් “මේ සියල්ල” රාත්‍රියේදී පරදුවට තැබූ විට වඩාත්ම සිත්ගන්නා දෙය පැමිණෙන බව සගයන් දනිති. තවද ඔවුන්ට උපකාර වනු ඇත්තේ unix හි ස්වභාවය, කටපාඩම් කරන ලද TCP/IP රාජ්‍ය වගුව සහ මූලික වර්ග කිරීමේ-සෙවුම් ඇල්ගොරිතම පිළිබඳ ගැඹුරු අවබෝධයකින් පමණි. චයිම්ස් වැඩ කරන විට පද්ධතිය නැවත ජීවයට ගෙන ඒමට.

ඔහ් ඔව්, මම ටිකක් අවධානය වෙනතකට යොමු කළා, නමුත් මම බලාපොරොත්තු වන තත්වය ප්‍රකාශ කිරීමට සමත් වූවා යැයි මම බලාපොරොත්තු වෙමි.
සම්පූර්ණයෙන්ම වෙනස් ව්‍යුහාත්මක බෙදීම් සඳහා සමාගමේ බහුතර විශ්ලේෂණාත්මක කාර්යයන් විසඳන DataLake සඳහා පහසු සහ මිල අඩු තොගයක් යෙදවීමේ අපගේ අත්දැකීම් බෙදා ගැනීමට අද මට අවශ්‍යය.

කලකට පෙර, සමාගම්වලට නිෂ්පාදන සහ තාක්ෂණික විශ්ලේෂණ යන දෙකෙහිම ඵල වැඩි වැඩියෙන් අවශ්‍ය බව අපි අවබෝධ කර ගත්තෙමු (යන්ත්‍ර ඉගෙනීමේ ස්වරූපයෙන් කේක් මත ඇති අයිසිං ගැන සඳහන් නොකරමු) සහ ප්‍රවණතා සහ අවදානම් තේරුම් ගැනීමට - අපි එකතු කර විශ්ලේෂණය කළ යුතුය. වැඩි වැඩියෙන් මෙට්රික්ස්.

Bitrix24 හි මූලික තාක්ෂණික විශ්ලේෂණ

මීට වසර කිහිපයකට පෙර, Bitrix24 සේවාව දියත් කිරීමට සමගාමීව, යටිතල පහසුකම්වල ගැටළු ඉක්මනින් දැකීමට සහ ඊළඟ පියවර සැලසුම් කිරීමට උපකාරී වන සරල සහ විශ්වාසදායක විශ්ලේෂණ වේදිකාවක් නිර්මාණය කිරීම සඳහා අපි ක්‍රියාකාරීව කාලය සහ සම්පත් ආයෝජනය කළෙමු. ඇත්ත වශයෙන්ම, හැකි තරම් සරල සහ තේරුම් ගත හැකි සූදානම් කළ මෙවලම් ගැනීම යෝග්ය විය. එහි ප්‍රතිඵලයක් වශයෙන්, අධීක්ෂණ කටයුතු සඳහා nagios ද විශ්ලේෂණ සහ දෘශ්‍යකරණය සඳහා මුනින් ද තෝරා ගන්නා ලදී. දැන් අපි nagios හි චෙක්පත් දහස් ගණනක්, munin හි ප්‍රස්ථාර සිය ගණනක් ඇති අතර, අපගේ සගයන් සෑම දිනකම ඒවා සාර්ථකව භාවිතා කරයි. ප්‍රමිතික පැහැදිලිය, ප්‍රස්ථාර පැහැදිලිය, පද්ධතිය වසර ගණනාවක් විශ්වසනීයව ක්‍රියාත්මක වන අතර නව පරීක්ෂණ සහ ප්‍රස්ථාර එයට නිතිපතා එකතු කරනු ලැබේ: අපි නව සේවාවක් ක්‍රියාත්මක කරන විට, අපි පරීක්ෂණ සහ ප්‍රස්ථාර කිහිපයක් එකතු කරමු. වාසනාව.

ස්පන්දනය මත ඇඟිල්ල - උසස් තාක්ෂණික විශ්ලේෂණ

"හැකි ඉක්මනින්" ගැටළු පිළිබඳ තොරතුරු ලබා ගැනීමට ඇති ආශාව සරල සහ තේරුම්ගත හැකි මෙවලම් සමඟ ක්රියාකාරී අත්හදා බැලීම් වලට අපව යොමු කළේය - pinba සහ xhprof.

Pinba විසින් PHP හි වෙබ් පිටු වල කොටස්වල ක්‍රියාකාරීත්වයේ වේගය පිළිබඳව UDP පැකට් වල සංඛ්‍යාලේඛන එවා ඇති අතර, අපට MySQL ගබඩාවේ (Pinba වේගවත් සිදුවීම් විශ්ලේෂණ සඳහා තමන්ගේම MySQL එන්ජිමක් සමඟ පැමිණේ) ගැටළු ලැයිස්තුවක් සහ ඒවාට ප්‍රතිචාර දැක්වීමට සබැඳිව දැක ගත හැකිය. ඔවුන්ට. xhprof ස්වයංක්‍රීයව සේවාදායකයින්ගෙන් මන්දගාමී PHP පිටු ක්‍රියාත්මක කිරීමේ ප්‍රස්ථාර එකතු කිරීමට සහ මෙයට හේතු විය හැකි දේ විශ්ලේෂණය කිරීමට අපට ඉඩ සලසයි - සන්සුන්ව, තේ වත් කිරීම හෝ වඩා ශක්තිමත් දෙයක්.

කලකට පෙර, මෙවලම් කට්ටලය ප්‍රතිලෝම සුචිගත කිරීමේ ඇල්ගොරිතම මත පදනම් වූ තවත් තරමක් සරල සහ තේරුම්ගත හැකි එන්ජිමකින් නැවත පුරවන ලද අතර එය ජනප්‍රිය ලුසීන් පුස්තකාලයේ - ඉලාස්ටික් / කිබානා හි පරිපූර්ණ ලෙස ක්‍රියාත්මක විය. ලඝු-සටහන් හි සිදුවීම් මත පදනම්ව ලේඛන ප්‍රතිලෝම ලුසීන් දර්ශකයකට බහු-නූල් පටිගත කිරීමේ සරල අදහස සහ මුහුණු බෙදීම භාවිතයෙන් ඒවා හරහා ඉක්මන් සෙවීම ඇත්තෙන්ම ප්‍රයෝජනවත් විය.

“බාල්දිය” “ඉහළට ගලා යාම” වැනි පහත් මට්ටමේ සංකල්ප සහිත කිබානා හි දෘශ්‍යකරණයන්හි තරමක් තාක්‍ෂණික පෙනුම සහ තවමත් සම්පූර්ණයෙන්ම අමතක වී නැති සම්බන්ධතා වීජ ගණිතයේ ප්‍රතිනිර්මාණය කරන ලද භාෂාව තිබියදීත්, මෙවලම පහත සඳහන් කාර්යයන් සඳහා අපට හොඳින් උදව් කිරීමට පටන් ගත්තේය:

  • පසුගිය පැය තුළ Bitrix24 සේවාදායකයාට p1 ද්වාරයෙහි PHP දෝෂ කීයක් තිබේද සහ ඒවා මොනවාද? තේරුම් ගන්න, සමාව දෙන්න සහ ඉක්මනින් නිවැරදි කරන්න.
  • පෙර පැය 24 තුළ ජර්මනියේ ද්වාරවල වීඩියෝ ඇමතුම් කීයක් සිදු කර තිබේද, කුමන ගුණාත්මක භාවයෙන්ද සහ නාලිකාව/ජාලය සමඟ යම් දුෂ්කරතා තිබේද?
  • නවතම සේවා යාවත්කාලීනයේ මූලාශ්‍රයෙන් සම්පාදනය කර සේවාලාභීන් වෙත ලබා දී ඇති පද්ධති ක්‍රියාකාරිත්වය (PHP සඳහා අපගේ C දිගුව) කෙතරම් හොඳින් ක්‍රියා කරයිද? segfaults තිබේද?
  • පාරිභෝගික දත්ත PHP මතකයට ගැලපේද? ක්‍රියාවලි සඳහා වෙන් කර ඇති මතකය ඉක්මවා යාමේ දෝෂ තිබේද: "මතකයෙන් බැහැර"? සොයාගෙන උදාසීන කරන්න.

මෙන්න නිශ්චිත උදාහරණයක්. පරිපූර්ණ සහ බහු මට්ටමේ පරීක්ෂණ තිබියදීත්, ඉතා සම්මත නොවන නඩුවක් සහ හානියට පත් ආදාන දත්ත සමඟ සේවාදායකයාට කරදරකාරී සහ අනපේක්ෂිත දෝෂයක් ලැබුණි, සයිරන් නාද වූ අතර එය ඉක්මනින් නිවැරදි කිරීමේ ක්‍රියාවලිය ආරම්භ විය:

අපි ඉතා කාර්යක්ෂම සහ මිල අඩු DataLake සංවිධානය කළ ආකාරය සහ මෙය එසේ වන්නේ ඇයි

මීට අමතරව, නිශ්චිත සිදුවීම් සඳහා දැනුම්දීම් සංවිධානය කිරීමට කිබානා ඔබට ඉඩ සලසයි, සහ කෙටි කාලයක් තුළ සමාගමේ මෙවලම විවිධ දෙපාර්තමේන්තු වල සේවකයින් දුසිම් ගණනක් භාවිතා කිරීමට පටන් ගත්තේය - තාක්ෂණික සහාය සහ සංවර්ධනයේ සිට QA දක්වා.

සමාගම තුළ ඇති ඕනෑම දෙපාර්තමේන්තුවක ක්‍රියාකාරකම් ලුහුබැඳීමට සහ මැනීමට පහසු වී ඇත - සේවාදායකයේ ලොග් අතින් විශ්ලේෂණය කරනවා වෙනුවට, ඔබට අවශ්‍ය වන්නේ එක් වරක් විග්‍රහ කිරීමේ ලඝු-සටහන් සකසා ඒවා භුක්ති විඳීමට ප්‍රත්‍යාස්ථ පොකුරට යැවිය යුතුය, උදාහරණයක් ලෙස, කිබානා ගැන මෙනෙහි කිරීම. උපකරණ පුවරුව පසුගිය චන්ද්‍ර මාසය සඳහා ත්‍රිමාණ මුද්‍රණ යන්ත්‍රයේ මුද්‍රණය කරන ලද හිස් දෙකේ පූස් පැටවුන් ගණන.

මූලික ව්යාපාර විශ්ලේෂණ

සමාගම්වල ව්‍යාපාර විශ්ලේෂණ බොහෝ විට ආරම්භ වන්නේ, ඔව්, එක්සෙල් අතිශයින් ක්‍රියාකාරී භාවිතයෙන් බව කවුරුත් දනිති. නමුත් ප්රධාන දෙය නම් එය එතැනින් අවසන් නොවන බවයි. Cloud-පාදක Google Analytics ද ගින්නට ඉන්ධන එකතු කරයි - ඔබ ඉක්මනින් හොඳ දේවල් වලට හුරු වීමට පටන් ගනී.

අපගේ එකඟතාවයෙන් වර්ධනය වන සමාගම තුළ, විශාල දත්ත සහිත වඩාත් තීව්‍ර කාර්යයේ “අනාගතවක්තෘවරුන්” මෙහි සහ එහි පෙනෙන්නට පටන් ගත්තේය. වඩාත් ගැඹුරු සහ බහුවිධ වාර්තා සඳහා අවශ්‍යතාවය නිතිපතා පෙනෙන්නට පටන් ගත් අතර, විවිධ දෙපාර්තමේන්තු වල පිරිමි ළමයින්ගේ උත්සාහයෙන්, කලකට පෙර සරල හා ප්‍රායෝගික විසඳුමක් සංවිධානය කරන ලදී - ClickHouse සහ PowerBI සංයෝජනයකි.

සෑහෙන කාලයක් යනකන් මේ නම්‍යශීලී විසඳුම ගොඩක් උදව් වුනා, ඒත් ටිකෙන් ටික තේරෙන්න පටන් ගත්තා ClickHouse රබර් නෙවෙයි එහෙම සමච්චල් කරන්න බෑ කියලා.

ClickHouse, Druid වැනි, Vertica වැනි, Amazon RedShift (postgres මත පදනම් වූ) වැනි, තරමක් පහසු විශ්ලේෂණ සඳහා ප්‍රශස්ත කරන ලද විශ්ලේෂණාත්මක එන්ජින් බව මෙහිදී හොඳින් අවබෝධ කර ගැනීම වැදගත් වේ. ), නිසා MySQL සහ අප දන්නා අනෙකුත් (පේළි-නැඹුරු) දත්ත සමුදායන් මෙන් නොව, සම්බන්ධතා වගු වල තීරු කාර්යක්ෂමව ගබඩා කිරීම සඳහා සංවිධානය කර ඇත.

සාරාංශයක් ලෙස, ClickHouse යනු ඉතා පහසු ලක්ෂ්‍යයෙන් ලක්ෂ්‍ය ඇතුළත් කිරීමක් නොමැති වඩාත් ධාරිතාවයෙන් යුත් “දත්ත සමුදායක්” පමණි (එය අදහස් කරන්නේ එසේ ය, සියල්ල හරි ය), නමුත් ප්‍රසන්න විශ්ලේෂණ සහ දත්ත සමඟ වැඩ කිරීම සඳහා සිත්ගන්නා ප්‍රබල කාර්යයන් සමූහයකි. ඔව්, ඔබට පොකුරක් පවා නිර්මාණය කළ හැකිය - නමුත් අන්වීක්ෂයකින් නියපොතු මිටීම සම්පූර්ණයෙන්ම නිවැරදි නොවන බව ඔබට වැටහෙන අතර අපි වෙනත් විසඳුම් සෙවීමට පටන් ගතිමු.

පයිතන් සහ විශ්ලේෂකයින් සඳහා ඉල්ලුම

PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash වලින් වසර 10-20ක් සෑම දිනකම පාහේ කේත ලියන බොහෝ සංවර්ධකයින් අපගේ සමාගම සතුව ඇත. සංඛ්‍යාලේඛන නීතිවලට නොගැලපෙන අතිශයින් ඇදහිය නොහැකි ව්‍යසන එකකට වඩා අත්විඳ ඇති බොහෝ පළපුරුදු පද්ධති පරිපාලකයින් ද සිටිති (උදාහරණයක් ලෙස, වැටලීම-10 හි තැටි බහුතරයක් ප්‍රබල අකුණු පහරකින් විනාශ වූ විට). එවැනි තත්වයන් තුළ, "පයිතන් විශ්ලේෂකයෙකු" යනු කුමක්දැයි දිගු කලක් තිස්සේ පැහැදිලි නොවීය. පයිතන් PHP වැනිය, නම පමණක් ටිකක් දිගු වන අතර පරිවර්තකගේ මූල කේතයේ මනස වෙනස් කරන ද්‍රව්‍යවල අංශු මාත්‍ර ටිකක් අඩුය. කෙසේ වෙතත්, වැඩි වැඩියෙන් විශ්ලේෂණාත්මක වාර්තා නිර්මාණය වූ විට, පළපුරුදු සංවර්ධකයින් numpy, pandas, matplotlib, seaborn වැනි මෙවලම්වල පටු විශේෂීකරණයේ වැදගත්කම වැඩි වැඩියෙන් අවබෝධ කර ගැනීමට පටන් ගත්හ.
තීරනාත්මක භූමිකාව, බොහෝ දුරට, "ලොජිස්ටික් ප්‍රතිගමනය" යන වචනවල සංයෝජනයෙන් සේවකයින් හදිසියේ ක්ලාන්ත වීම සහ ඔව්, ඔව්, pyspark භාවිතා කරමින් විශාල දත්ත මත ඵලදායී වාර්තා කිරීම ප්‍රදර්ශනය කිරීම මගින් ඉටු විය.

Apache Spark, එහි ක්‍රියාකාරී සුසමාදර්ශය මත සම්බන්ධිත වීජ ගණිතය හොඳින් ගැලපේ, සහ එහි හැකියාවන් MySQL වලට හුරු වූ සංවර්ධකයින් කෙරෙහි එතරම් හැඟීමක් ඇති කළ අතර පළපුරුදු විශ්ලේෂකයින් සමඟ ශ්‍රේණිගත කිරීම් ශක්තිමත් කිරීමේ අවශ්‍යතාවය දවසින් දවස පැහැදිලි විය.

Apache Spark/Hadoop ගුවන් ගත කිරීමට ගත් තවත් උත්සාහයන් සහ පිටපතට අනුව සිදු නොවූ දේ

කෙසේ වෙතත්, ස්පාර්ක් සමඟ යමක් පද්ධතිමය වශයෙන් නිවැරදි නොවන බව ඉක්මනින් පැහැදිලි විය, නැතහොත් ඔබේ දෑත් වඩා හොඳින් සේදීම අවශ්‍ය විය. Hadoop/MapReduce/Lucene Stack එක සාදා ඇත්තේ තරමක් පළපුරුදු ක්‍රමලේඛකයින් විසින් නම්, ඔබ Java හි මූල කේතය හෝ Lucene හි Doug Cutting ගේ අදහස් දෙස හොඳින් බැලුවහොත් පැහැදිලි වේ, එවිට Spark, හදිසියේම, විදේශීය භාෂාව වන Scala වලින් ලියා ඇත. ප්රායෝගිකත්වයේ දෘෂ්ටි කෝණයෙන් ඉතා මතභේදාත්මක වන අතර දැනට සංවර්ධනය වෙමින් පවතී. අඩු කිරීමේ මෙහෙයුම් සඳහා මතකය වෙන් කිරීම සමඟ තාර්කික නොවන සහ ඉතා විනිවිද නොයන වැඩ හේතුවෙන් ස්පාර්ක් පොකුරේ ගණනය කිරීම් නිතිපතා පහත වැටීම (බොහෝ යතුරු එකවර පැමිණේ) එය වටා වර්ධනය වීමට ඉඩ ඇති දෙයක ප්‍රවාහයක් නිර්මාණය කර ඇත. මීට අමතරව, අමුතු විවෘත වරායන් විශාල සංඛ්‍යාවක්, වඩාත් නොතේරෙන ස්ථානවල වැඩෙන තාවකාලික ලිපිගොනු සහ භාජන පරායත්තතාවයන් විශාල සංඛ්‍යාවක් මගින් තත්වය උග්‍ර විය - එමඟින් පද්ධති පරිපාලකයින්ට කුඩා කල සිටම දන්නා එක් හැඟීමක් ඇති විය: දරුණු වෛරය (හෝ සමහර විට) ඔවුන්ට සබන් යොදා අත් සේදීමට අවශ්‍ය විය).

එහි ප්‍රතිඵලයක් වශයෙන්, අපි Apache Spark (Spark Streaming, Spark SQL ඇතුළුව) සහ Hadoop පරිසර පද්ධතිය (සහ එසේ යනාදී) සක්‍රියව භාවිතා කරන අභ්‍යන්තර විශ්ලේෂණ ව්‍යාපෘති කිහිපයක් "ගැලවී" ඇත. කාලයාගේ ඇවෑමෙන් අපි “එය” හොඳින් පිළියෙළ කිරීමට සහ අධීක්ෂණය කිරීමට ඉගෙන ගත් අතර, දත්තවල ස්වභාවයේ වෙනස්වීම් සහ ඒකාකාරී RDD හැෂිං වල අසමතුලිතතාවය හේතුවෙන් “එය” ප්‍රායෝගිකව හදිසියේ බිඳ වැටීම නතර කළද, දැනටමත් සූදානම් කර ඇති දෙයක් ගැනීමට ඇති ආශාව , වලාකුළේ කොතැනක හෝ යාවත්කාලීන කර පරිපාලනය කිරීම ශක්තිමත් සහ ශක්තිමත් විය. අපි Amazon Web Services හි සූදානම් කළ වලාකුළු එකලස් කිරීම භාවිතා කිරීමට උත්සාහ කළේ මේ අවස්ථාවේ දී ය - EMR සහ, පසුව, එය භාවිතා කර ගැටළු විසඳීමට උත්සාහ කළා. EMR යනු Cloudera/Hortonworks builds වැනි පරිසර පද්ධතියෙන් අමතර මෘදුකාංග සමඟ Amazon විසින් සකස් කරන ලද Apache Spark වේ.

විශ්ලේෂණ සඳහා රබර් ගොනු ගබඩා කිරීම හදිසි අවශ්‍යතාවයකි

ශරීරයේ විවිධ කොටස් වලට පිලිස්සුම් තුවාල ඇති Hadoop / Spark "පිසීමේ" අත්දැකීම නිෂ්ඵල නොවීය. දෘඪාංග බිඳවැටීම්වලට ප්‍රතිරෝධී වන සහ විවිධ පද්ධතිවලින් විවිධ ආකෘතිවලින් ගොනු ගබඩා කිරීමටත්, මෙම දත්තවලින් වාර්තා සඳහා කාර්යක්ෂම හා කාලානුරූපී සාම්පල සෑදීමටත් හැකි වන පරිදි තනි, මිල අඩු සහ විශ්වාසදායක ගොනු ගබඩාවක් නිර්මාණය කිරීමේ අවශ්‍යතාව වඩ වඩාත් වැඩි විය. පැහැදිලිව.

මෙම වේදිකාවේ මෘදුකාංගය යාවත්කාලීන කිරීම පිටු 20ක ජාවා හෝඩුවාවන් කියවීම සහ Spark History Server සහ backlight විශාලන වීදුරුවක් භාවිතයෙන් පොකුරේ කිලෝමීටරයක් ​​දිග සවිස්තරාත්මක ලඝු-සටහන් විශ්ලේෂණය කිරීම සමඟින් අලුත් අවුරුදු බියකරු සිහිනයක් බවට පත් නොවීමට මට අවශ්‍ය විය. ඉතා හොඳින් තෝරා නොගත් මූලාශ්‍ර දත්ත කොටස් කිරීමේ ඇල්ගොරිතමයක් හේතුවෙන් අඩු කිරීමේ දත්ත සේවකයාගේ මතකයෙන් බැස ගිය විට සංවර්ධකයාගේ සම්මත MapReduce ඉල්ලීම ක්‍රියාත්මක වීම නැවැත්වූයේ නම්, නිත්‍ය කිමිදීමක් අවශ්‍ය නොවන සරල සහ විනිවිද පෙනෙන මෙවලමක් ලබා ගැනීමට මට අවශ්‍ය විය.

Amazon S3 DataLake සඳහා අපේක්ෂකයෙක්ද?

Hadoop/MapReduce සමඟ ඇති අත්දැකීම් අපට කියා දුන්නේ අපට පරිමාණය කළ හැකි, විශ්වාසදායක ගොනු පද්ධතියක් සහ ඊට ඉහළින් පරිමාණය කළ හැකි සේවකයින් අවශ්‍ය බවත්, දත්ත ජාලය හරහා ධාවනය නොකිරීමට දත්තවලට සමීප වන බවත්ය. කම්කරුවන්ට විවිධ ආකෘතිවලින් දත්ත කියවීමට හැකි විය යුතුය, නමුත් වඩාත් සුදුසු වන්නේ අනවශ්‍ය තොරතුරු කියවීමට සහ සේවකයන්ට පහසු ආකෘතිවල දත්ත කල්තියා ගබඩා කිරීමටය.

නැවත වරක්, මූලික අදහස. තනි පොකුරු විශ්ලේෂණ එන්ජිමකට විශාල දත්ත “වත් කිරීමට” ආශාවක් නැත, එය ඉක්මනින් හෝ පසුව හුස්ම හිරවන අතර ඔබට එය කැත ලෙස ඉරා දැමීමට සිදුවනු ඇත. මට අවශ්‍ය වන්නේ ගොනු, ගොනු පමණක්, තේරුම් ගත හැකි ආකෘතියකින් ගබඩා කිරීමට සහ විවිධ නමුත් තේරුම් ගත හැකි මෙවලම් භාවිතයෙන් ඒවා මත ඵලදායී විශ්ලේෂණ විමසුම් සිදු කිරීමටයි. තවද විවිධ හැඩතලවල ගොනු වැඩි වැඩියෙන් පවතිනු ඇත. එන්ජිම නොව ප්‍රභව දත්ත කැබලි කිරීම වඩා හොඳය. අපිට විස්තීරණ සහ විශ්වීය DataLake එකක් අවශ්‍යයි, අපි තීරණය කළා...

ඔබ Hadoop වෙතින් ඔබේම චොප්ස් සූදානම් නොකර, හුරුපුරුදු සහ සුප්‍රසිද්ධ පරිමාණ කළ හැකි වලාකුළු ආචයන Amazon S3 හි ගොනු ගබඩා කරන්නේ නම් කුමක් කළ යුතුද?

පුද්ගලික දත්ත "අඩු" බව පැහැදිලිය, නමුත් අපි එය පිටතට ගෙන "එය ඵලදායී ලෙස ධාවනය" කළහොත් වෙනත් දත්ත ගැන කුමක් කිව හැකිද?

Amazon Web Services හි Cluster-bigdata-analytics පරිසර පද්ධතිය - ඉතා සරල වචන වලින්

AWS සමඟ අපගේ අත්දැකීම් අනුව විනිශ්චය කිරීම, Apache Hadoop/MapReduce දිගු කලක් විවිධ සෝස් වර්ග යටතේ එහි ක්‍රියාකාරීව භාවිතා කර ඇත, උදාහරණයක් ලෙස DataPipeline සේවාවේ (මම මගේ සගයන්ට ඊර්ෂ්‍යා කරනවා, ඔවුන් එය නිවැරදිව සකස් කරන්නේ කෙසේදැයි ඉගෙන ගත්තා). මෙන්න අපි DynamoDB වගු වලින් විවිධ සේවාවන්ගෙන් උපස්ථ සකස් කරමු:
අපි ඉතා කාර්යක්ෂම සහ මිල අඩු DataLake සංවිධානය කළ ආකාරය සහ මෙය එසේ වන්නේ ඇයි

තවද ඒවා දැන් වසර කිහිපයක සිට ඔරලෝසු වැඩ වැනි කාවැද්දූ Hadoop/MapReduce පොකුරු මත නිතිපතා ධාවනය වේ. "එය සකසා එය අමතක කරන්න":

අපි ඉතා කාර්යක්ෂම සහ මිල අඩු DataLake සංවිධානය කළ ආකාරය සහ මෙය එසේ වන්නේ ඇයි

විශ්ලේෂකයින් සඳහා වලාකුළෙහි බ්‍රහස්පති ලැප්ටොප් සැකසීමෙන් සහ AWS SageMaker සේවාව භාවිතයෙන් AI ආකෘති පුහුණු කිරීමට සහ සටනට යෙදවීමෙන් ඔබට දත්ත සාතන්වාදයේ ඵලදායී ලෙස සම්බන්ධ විය හැකිය. මෙන්න එය අපට පෙනෙන්නේ කෙසේද:

අපි ඉතා කාර්යක්ෂම සහ මිල අඩු DataLake සංවිධානය කළ ආකාරය සහ මෙය එසේ වන්නේ ඇයි

ඔව්, ඔබට ඔබටම හෝ වලාකුළේ විශ්ලේෂකයෙකුට ලැප්ටොප් පරිගණකයක් ගෙන එය Hadoop/Spark පොකුරකට ඇමිණිය හැකිය, ගණනය කිරීම් සිදු කර පසුව සියල්ල ඇණ ගැසීම:

අපි ඉතා කාර්යක්ෂම සහ මිල අඩු DataLake සංවිධානය කළ ආකාරය සහ මෙය එසේ වන්නේ ඇයි

තනි විශ්ලේෂණ ව්‍යාපෘති සඳහා සැබවින්ම පහසු වන අතර සමහරක් සඳහා අපි මහා පරිමාණ ගණනය කිරීම් සහ විශ්ලේෂණ සඳහා EMR සේවාව සාර්ථකව භාවිතා කර ඇත. DataLake සඳහා පද්ධති විසඳුමක් ගැන කුමක් කිව හැකිද, එය ක්‍රියා කරයිද? මේ මොහොතේ අපි බලාපොරොත්තුවේ සහ බලාපොරොත්තු සුන්වීමේ අද්දර සිටි අතර සෙවීම දිගටම කරගෙන ගියෙමු.

AWS Glue - ස්ටෙරොයිඩ් මත පිළිවෙලට ඇසුරුම් කරන ලද Apache Spark

AWS සතුව “Hive/Pig/Spark” තොගයේ තමන්ගේම අනුවාදයක් ඇති බව පෙනී ගියේය. කාර්යබහුල භූමිකාව, i.e. DataLake හි ගොනු සහ ඒවායේ වර්ග නාමාවලිය සිදු කරනු ලබන්නේ "Data catalog" සේවාව මගින් වන අතර, Apache Hive ආකෘතිය සමඟ එහි ගැළපුම සඟවන්නේ නැත. ඔබගේ ලිපිගොනු පිහිටා ඇති ස්ථානය සහ ඒවා කුමන ආකෘතියෙන්ද යන්න පිළිබඳ තොරතුරු මෙම සේවාවට එක් කිරීමට ඔබට අවශ්‍ය වේ. දත්ත s3 හි පමණක් නොව දත්ත සමුදායේ ද විය හැකිය, නමුත් එය මෙම පෝස්ටයේ විෂය නොවේ. අපගේ DataLake දත්ත නාමාවලිය සංවිධානය කර ඇති ආකාරය මෙන්න:

අපි ඉතා කාර්යක්ෂම සහ මිල අඩු DataLake සංවිධානය කළ ආකාරය සහ මෙය එසේ වන්නේ ඇයි

ගොනු ලියාපදිංචි කර ඇත, විශිෂ්ටයි. ගොනු යාවත්කාලීන කර ඇත්නම්, අපි අතින් හෝ කාලසටහනකට අනුව අපි crawlers දියත් කරන්නෙමු, එමඟින් වැවෙන් ඒවා පිළිබඳ තොරතුරු යාවත්කාලීන කර ඒවා සුරැකෙනු ඇත. එවිට වැවේ දත්ත සකස් කර ප්‍රතිඵල කොතැනක හෝ උඩුගත කළ හැක. සරලම අවස්ථාවක, අපි s3 වෙත උඩුගත කරමු. දත්ත සැකසීම ඕනෑම තැනක සිදු කළ හැක, නමුත් AWS Glue API හරහා උසස් හැකියාවන් භාවිතා කරමින් Apache Spark පොකුරක් මත සැකසීම වින්‍යාස කිරීමට ඔබට යෝජනා කෙරේ. ඇත්ත වශයෙන්ම, ඔබට pyspark පුස්තකාලය භාවිතයෙන් හොඳ පැරණි සහ හුරුපුරුදු python කේතයක් ගෙන, Hadoop හි බඩවැලේ හාරා නොගෙන, docker-moker බහාලුම් ඇදගෙන යැමකින් තොරව සහ පරායත්තතා ගැටුම් ඉවත් කිරීමකින් තොරව, යම් ධාරිතාවයකින් යුත් පොකුරක N nodes මත එය ක්‍රියාත්මක කිරීම වින්‍යාසගත කළ හැකිය. .

නැවත වරක්, සරල අදහසක්. Apache Spark වින්‍යාස කිරීමට අවශ්‍ය නැත, ඔබට අවශ්‍ය වන්නේ pyspark සඳහා python කේතය ලිවීමට, එය ඔබගේ ඩෙස්ක්ටොප් එකේ දේශීයව පරීක්ෂා කර පසුව එය ක්ලවුඩ් හි විශාල පොකුරක් මත ධාවනය කරන්න, මූලාශ්‍ර දත්ත කොතැනද සහ ප්‍රතිඵලය තැබිය යුත්තේ කොතැනද යන්න සඳහන් කරන්න. සමහර විට මෙය අවශ්‍ය සහ ප්‍රයෝජනවත් වන අතර, අපි එය සකසන ආකාරය මෙන්න:

අපි ඉතා කාර්යක්ෂම සහ මිල අඩු DataLake සංවිධානය කළ ආකාරය සහ මෙය එසේ වන්නේ ඇයි

මේ අනුව, ඔබට s3 හි දත්ත භාවිතා කර Spark පොකුරක් මත යමක් ගණනය කිරීමට අවශ්‍ය නම්, අපි python/pyspark වලින් කේතය ලියා, එය පරීක්ෂා කර, වලාකුළට සුබ පතන්නෙමු.

වාද්‍ය වෘන්දය ගැන කුමක් කිව හැකිද? කාර්යය වැටී අතුරුදහන් වුවහොත් කුමක් කළ යුතුද? ඔව්, Apache Pig ශෛලියෙන් අලංකාර නල මාර්ගයක් සෑදීමට යෝජනා කර ඇති අතර අපි ඒවා පවා උත්සාහ කළෙමු, නමුත් දැනට අපි අපගේ ගැඹුරින් අභිරුචිකරණය කරන ලද PHP සහ JavaScript හි වාද්‍ය වෘන්දය භාවිතා කිරීමට තීරණය කළෙමු (මට තේරෙනවා, සංජානන විසංවාදයක් ඇත, නමුත් එය ක්‍රියාත්මක වේ. වසර සහ දෝෂ නොමැතිව).

අපි ඉතා කාර්යක්ෂම සහ මිල අඩු DataLake සංවිධානය කළ ආකාරය සහ මෙය එසේ වන්නේ ඇයි

විලෙහි ගබඩා කර ඇති ගොනු ආකෘතිය කාර්ය සාධනය සඳහා යතුරයි

තවත් ප්‍රධාන කරුණු දෙකක් තේරුම් ගැනීම ඉතා වැදගත් වේ. විලෙහි ඇති ගොනු දත්ත පිළිබඳ විමසීම් හැකි ඉක්මනින් ක්‍රියාත්මක කිරීමට සහ නව තොරතුරු එක් කළ විට කාර්ය සාධනය පිරිහී නොයෑමට, ඔබ කළ යුත්තේ:

  • ගොනු තීරු වෙන වෙනම ගබඩා කරන්න (එමගින් තීරු වල ඇති දේ තේරුම් ගැනීමට ඔබට සියලු පේළි කියවීමට සිදු නොවේ). මේ සඳහා අපි සම්පීඩනය සමඟ පාකට් ආකෘතිය ගත්තා
  • භාෂාව, වර්ෂය, මාසය, දිනය, සතිය වැනි ෆෝල්ඩරවලට ගොනු කැබලි කිරීම ඉතා වැදගත් වේ. මෙම ආකාරයේ බෙදා හැරීම තේරුම් ගන්නා එන්ජින්, පේළියේ ඇති සියලුම දත්ත පෙරා නොගෙන අවශ්‍ය ෆෝල්ඩර දෙස පමණක් බලයි.

අත්‍යවශ්‍යයෙන්ම, මේ ආකාරයෙන්, ඔබ ඉහළට එල්ලා ඇති විශ්ලේෂණාත්මක එන්ජින් සඳහා මූලාශ්‍ර දත්ත වඩාත් කාර්යක්ෂම ස්වරූපයෙන් තබයි, එය කැබලි කළ ෆෝල්ඩරවල පවා ගොනු වලින් අවශ්‍ය තීරු පමණක් තෝරාගෙන ඇතුළු කර කියවිය හැකිය. ඔබට ඕනෑම තැනක දත්ත “පිරවීමට” අවශ්‍ය නැත (ගබඩාව සරලව පුපුරා යනු ඇත) - වහාම බුද්ධිමත්ව එය නිවැරදි ආකෘතියෙන් ගොනු පද්ධතියට දමන්න. ඇත්ත වශයෙන්ම, තීරු උකහා ගැනීම සඳහා පළමුව පොකුරෙන් පේළියෙන් කියවිය යුතු විශාල csv ගොනුවක් DataLake හි ගබඩා කිරීම එතරම් සුදුසු නොවන බව මෙහිදී පැහැදිලි විය යුතුය. මේ සියල්ල සිදුවන්නේ මන්දැයි තවමත් පැහැදිලි නැතිනම් ඉහත කරුණු දෙක ගැන නැවත සිතන්න.

AWS Athena - ජැක්-ඉන්-ද-බොක්ස්

ඊට පස්සේ, වැවක් නිර්මාණය කරන විට, අපට අහම්බෙන් Amazon Athena හමු විය. අපගේ විශාල ලොග් ලිපිගොනු නිවැරදි (පාර්කට්) තීරු ආකෘතියෙන් ෆෝල්ඩර කැබලිවලට ප්‍රවේශමෙන් සැකසීමෙන්, ඔබට ඉතා ඉක්මනින් ඒවායින් අතිශය තොරතුරු තෝරා ගැනීම් සිදු කර Apache Spark/Glue පොකුරක් නොමැතිව වාර්තා ගොඩනගා ගත හැකි බව හදිසියේම පෙනී ගියේය.

s3 හි දත්ත මගින් බල ගැන්වෙන Athena එන්ජිම පුරාවෘත්තය මත පදනම් වේ Presto - MPP (දැවැන්ත සමාන්තර සැකසුම්) දත්ත සැකසීම සඳහා ප්‍රවේශයන් පවුලක නියෝජිතයෙක්, දත්ත එය පවතින තැනට ගැනීම, s3 සහ Hadoop සිට Cassandra සහ සාමාන්‍ය පෙළ ගොනු දක්වා. ඔබට SQL විමසුමක් ක්‍රියාත්මක කිරීමට Athena ගෙන් ඉල්ලා සිටිය යුතු අතර, එවිට සියල්ල "ඉක්මන් සහ ස්වයංක්‍රීයව ක්‍රියා කරයි." Athena "smart" බව සැලකිල්ලට ගැනීම වැදගත්ය, එය අවශ්ය ඛණ්ඩිත ෆෝල්ඩර වෙත පමණක් ගොස් ඉල්ලීමෙහි අවශ්ය තීරු පමණක් කියවයි.

ඇතීනා වෙත ඉල්ලීම් සඳහා මිල ගණන් ද සිත්ගන්නා සුළුය. අපි ගෙවනවා ස්කෑන් කළ දත්ත පරිමාව. එම. මිනිත්තුවකට පොකුරේ ඇති යන්ත්‍ර සංඛ්‍යාව සඳහා නොවේ, නමුත්... යන්ත්‍ර 100-500ක ඇත්ත වශයෙන්ම ස්කෑන් කරන ලද දත්ත සඳහා, ඉල්ලීම සම්පූර්ණ කිරීමට අවශ්‍ය දත්ත පමණි.

නිවැරදිව බෙදාගත් ෆෝල්ඩර වලින් අවශ්‍ය තීරු පමණක් ඉල්ලා සිටීමෙන්, Athena සේවාව සඳහා මසකට ඩොලර් දස දහස් ගණනක් වැය වන බව පෙනී ගියේය. හොඳයි, විශිෂ්ටයි, පාහේ නොමිලේ, පොකුරු මත විශ්ලේෂණ සමඟ සසඳන විට!

මාර්ගය වන විට, අපි අපගේ දත්ත s3 හි බෙදා ගන්නා ආකාරය මෙන්න:

අපි ඉතා කාර්යක්ෂම සහ මිල අඩු DataLake සංවිධානය කළ ආකාරය සහ මෙය එසේ වන්නේ ඇයි

එහි ප්‍රතිපලයක් වශයෙන්, කෙටි කාලයක් තුළ, තොරතුරු ආරක්ෂාවේ සිට විශ්ලේෂණ දක්වා සමාගමේ සම්පූර්ණයෙන්ම වෙනස් දෙපාර්තමේන්තු, ඇතීනා වෙත සක්‍රියව ඉල්ලීම් කිරීමට පටන් ගත් අතර, තත්පර කිහිපයකින්, තරමක් දිගු කාලයක් පුරා “විශාල” දත්ත වලින් ප්‍රයෝජනවත් පිළිතුරු ලබා ගනී: මාස, වසර භාගයක්, ආදිය. පී.

නමුත් අපි තවත් ඉදිරියට ගොස් පිළිතුරු සඳහා වලාකුළට යාමට පටන් ගත්තෙමු ODBC ධාවකය හරහා: විශ්ලේෂකයෙකු හුරුපුරුදු කොන්සෝලයක SQL විමසුමක් ලියයි, එය "සතයක් සඳහා" යන්ත්‍ර 100-500ක දත්ත s3 වෙත යවා සාමාන්‍යයෙන් තත්පර කිහිපයකින් පිළිතුරක් ලබා දෙයි. සුවපහසුයි. සහ වේගවත්. මට තවමත් එය විශ්වාස කළ නොහැක.

එහි ප්‍රතිඵලයක් ලෙස, කාර්යක්ෂම තීරු ආකෘතියකින් සහ සාධාරණ ලෙස දත්ත ෆෝල්ඩරවලට බෙදා හැරීමෙන්, s3 හි දත්ත ගබඩා කිරීමට තීරණය කර තිබීමෙන්... අපට DataLake සහ වේගවත් සහ ලාභ විශ්ලේෂණ එන්ජිමක් - නොමිලේ. ඒ වගේම ඔහු සමාගම තුළ ඉතා ජනප්‍රිය වුණා, මොකද... SQL තේරුම් ගන්නා අතර පොකුරු ආරම්භ කිරීම/නැවැත්වීම/සැකසීමට වඩා වේගයෙන් විශාලත්වයේ ඇණවුම් ක්‍රියා කරයි. "සහ ප්‍රතිඵලය සමාන නම්, වැඩිපුර ගෙවන්නේ ඇයි?"

ඇතීනාගෙන් ඉල්ලීමක් මේ වගේ දෙයක්. අවශ්ය නම්, ඇත්ත වශයෙන්ම, ඔබට ප්රමාණවත් තරම් සෑදිය හැකිය සංකීර්ණ සහ බහු පිටු SQL විමසුම, නමුත් අපි සරල කණ්ඩායම් වලට සීමා වෙමු. වෙබ් සේවාදායක ලොගවල සති කිහිපයකට පෙර සේවාදායකයා සතුව තිබූ ප්‍රතිචාර කේත මොනවාදැයි බලමු සහ දෝෂ නොමැති බවට වග බලා ගන්න:

අපි ඉතා කාර්යක්ෂම සහ මිල අඩු DataLake සංවිධානය කළ ආකාරය සහ මෙය එසේ වන්නේ ඇයි

සොයා ගැනීම්

දිගු, නමුත් වේදනාකාරී මාවතක් නොපවසා, අවදානම් සහ සංකීර්ණතාවයේ මට්ටම සහ ආධාරක පිරිවැය නිරන්තරයෙන් ප්‍රමාණවත් ලෙස තක්සේරු කරමින්, අපි DataLake සහ විශ්ලේෂණ සඳහා විසඳුමක් සොයා ගත්තෙමු, එය කිසි විටෙකත් වේගය සහ හිමිකාරිත්වයේ පිරිවැය යන දෙකින්ම අපව සතුටු කිරීම නතර නොකරයි.

සමාගමේ සම්පූර්ණයෙන්ම වෙනස් දෙපාර්තමේන්තු වල අවශ්‍යතා සඳහා කාර්යක්ෂම, වේගවත් හා ලාභදායි DataLake ක්‍රියාත්මක කිරීම ගොඩ නැගීම සම්පූර්ණයෙන්ම ගෘහ නිර්මාණ ශිල්පීන් ලෙස සේවය කර නැති සහ චතුරස්‍ර මත කොටු අඳින්නේ කෙසේදැයි නොදන්නා පළපුරුදු සංවර්ධකයින්ගේ පවා හැකියාවන් තුළ ඇති බව පෙනී ගියේය. ඊතල සහ Hadoop පරිසර පද්ධතියෙන් පද 50 ක් දැන ගන්න.

ගමන ආරම්භයේදී, විවෘත හා සංවෘත මෘදුකාංගවල බොහෝ වල් සත්වෝද්‍යාන වලින් මගේ හිස වෙන් වෙමින් පැවතුනි, පරම්පරාවට වගකීමේ බර පිළිබඳ අවබෝධය. සරල මෙවලම් වලින් ඔබේ DataLake ගොඩ නැගීම ආරම්භ කරන්න: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., ප්‍රතිපෝෂණ එකතු කිරීම සහ සිදුවන ක්‍රියාවලීන්ගේ භෞතික විද්‍යාව ගැඹුරින් අවබෝධ කර ගැනීම. සෑම දෙයක්ම සංකීර්ණ හා අඳුරු - සතුරන්ට සහ තරඟකරුවන්ට දෙන්න.

ඔබට ක්ලවුඩ් වෙත යාමට අවශ්‍ය නැතිනම් සහ විවෘත මූලාශ්‍ර ව්‍යාපෘති සඳහා සහය දැක්වීමට, යාවත්කාලීන කිරීමට සහ පැච් කිරීමට කැමති නම්, ඔබට දේශීයව අපගේ ව්‍යාපෘතියට සමාන යෝජනා ක්‍රමයක් ගොඩනගා ගත හැකිය, ඉහළට Hadoop සහ Presto සහිත මිල අඩු කාර්යාල යන්ත්‍ර මත. ප්රධාන දෙය නම් නැවැත්වීම සහ ඉදිරියට යාම නොවේ, ගණන් කිරීම, සරල සහ පැහැදිලි විසඳුම් සොයන්න, සහ සෑම දෙයක්ම අනිවාර්යයෙන්ම සාර්ථක වනු ඇත! සැමට සුභ පැතුම් සහ නැවත හමුවෙමු!

මූලාශ්රය: www.habr.com

අදහස් එක් කරන්න