د سرور تحلیلي سیسټمونه

دا د تحلیلي سیسټمونو په اړه د مقالو لړۍ دویمه برخه ده (د لومړۍ برخې لینک).

نن ورځ ، پدې کې شک نشته چې د معلوماتو دقیق پروسس کول او د پایلو تشریح کولی شي نږدې هر ډول سوداګرۍ کې مرسته وکړي. پدې برخه کې ، تحلیلي سیسټمونه د پیرامیټونو سره ډیر او ډیریږي ، په غوښتنلیکونو کې د محرکاتو او کاروونکو پیښو شمیر مخ په ډیریدو دی.
د دې له امله ، شرکتونه خپلو شنونکو ته ډیر او ډیر "خام" معلومات ورکوي ترڅو تحلیل او سم پریکړو ته یې واړوي. د شرکت لپاره د تحلیلي سیسټم اهمیت باید کم نه وي، او سیسټم باید پخپله د باور وړ او پایښت وړ وي.

د مراجعینو شنونکي

د مراجعینو تحلیلونه یو خدمت دی چې یو شرکت د رسمي SDK له لارې د خپلې ویب پاڼې یا غوښتنلیک لپاره نښلوي، دا په خپل کوډبیس کې مدغم کوي، او د پیښې محرکات غوره کوي. دا طریقه یو څرګند نیمګړتیا لري: ټول راټول شوي معلومات نشي کولی په بشپړ ډول پروسس شي لکه څنګه چې تاسو غواړئ، د هر غوره شوي خدمت محدودیتونو له امله. د مثال په توګه، په یو سیسټم کې به د MapReduce دندو چلول اسانه نه وي، په بل کې به تاسو د خپل ماډل چلولو توان ونلرئ. بل زیان به د خدماتو لپاره منظم (اغیزمن) بل وي.
په بازار کې د پیرودونکو ډیری تحلیلي حلونه شتون لري، مګر ژر یا وروسته، شنونکي د دې حقیقت سره مخ دي چې هیڅ یو نړیوال خدمت شتون نلري چې د کومې دندې لپاره مناسب وي (پداسې حال کې چې د دې ټولو خدماتو نرخونه په دوامداره توګه وده کوي). په داسې حالت کې، شرکتونه اکثرا پریکړه کوي چې د ټولو اړین دودیز ترتیباتو او ځانګړتیاو سره خپل تحلیلي سیسټم جوړ کړي.

د سرور شنونکي

د سرور اړخ تحلیلونه یو خدمت دی چې د شرکت په خپلو سرورونو او (معمولا) دننه دننه ځای په ځای کیدی شي. پدې ماډل کې ، د کارونکي ټولې پیښې په داخلي سرورونو کې زیرمه شوي ، پراختیا کونکو ته اجازه ورکوي چې د ذخیره کولو لپاره مختلف ډیټابیسونه هڅه وکړي او خورا مناسب جوړښت غوره کړي. او حتی که تاسو لاهم غواړئ د ځینې دندو لپاره د دریمې ډلې پیرودونکي اړخ تحلیلونه وکاروئ ، دا به لاهم امکان ولري.
د سرور اړخ تحلیلونه په دوه لارو کې ځای په ځای کیدی شي. لومړی: د خلاصې سرچینې ځینې اسانتیاوې غوره کړئ ، په خپلو ماشینونو کې یې ځای په ځای کړئ او د سوداګرۍ منطق رامینځته کړئ.

Плюсы
Минусы

تاسو کولی شئ هر څه تنظیم کړئ
ډیری وختونه دا خورا ستونزمن وي او جلا پراختیا کونکو ته اړتیا وي

دوهم: د خپل ځان د ځای په ځای کولو پرځای د SaaS خدمات (ایمیزون ، ګوګل ، Azure) واخلئ. موږ به په دریمه برخه کې په تفصیل سره د SaaS په اړه وغږیږو.

Плюсы
Минусы

دا په منځنۍ حجم کې ارزانه کیدی شي، مګر د لوی زیاتوالي سره دا به لاهم خورا ګران شي
د ټولو پیرامیټونو کنټرول نشي کولی

اداره په بشپړه توګه د خدمت چمتو کونکي اوږو ته لیږدول کیږي
دا تل نه پوهیږي چې د خدمت دننه څه دي (ممکن اړتیا ونلري)

د سرور تحلیلونو راټولولو څرنګوالی

که موږ غواړو د مراجعینو تحلیلونو کارولو څخه لیرې شو او خپل ځان جوړ کړو، لومړی موږ باید د نوي سیسټم جوړښت باندې فکر وکړو. لاندې به زه تاسو ته ګام په ګام ووایم چې تاسو اړتیا لرئ په پام کې ونیسئ ، ولې هر مرحلې ته اړتیا ده او کوم اوزار چې تاسو یې کارولی شئ.

1. د معلوماتو ترلاسه کول

لکه څنګه چې د پیرودونکي تحلیلونو په حالت کې، لومړی د شرکت شنونکي د پیښو ډولونه غوره کوي چې دوی غواړي نور مطالعه کړي او په لیست کې یې راټول کړي. معمولا، دا پیښې په یو ځانګړي ترتیب کې واقع کیږي، کوم چې د "پیښې سکیم" په نوم یادیږي.
برسېره پردې، راځئ چې تصور وکړو چې یو ګرځنده غوښتنلیک (ویب پاڼه) منظم کاروونکي (وسیلې) او ډیری سرورونه لري. د وسیلو څخه سرورونو ته پیښې په خوندي ډول لیږدولو لپاره ، مینځنۍ پرت ​​ته اړتیا ده. د معمارۍ پورې اړه لري، د پیښو ډیری مختلف کتارونه واقع کیدی شي.
اپاپي کافيکا دی پب/فرعي کتار، کوم چې د پیښو راټولولو لپاره د قطار په توګه کارول کیږي.

د په Quora کې پوسټ په 2014 کې، د اپاچي کافکا جوړونکي پریکړه وکړه چې سافټویر ته د فرانز کافکا په نوم نوم ورکړي ځکه چې "دا د لیکلو لپاره مطلوب سیسټم دی" او ځکه چې هغه د کافکا له لیکنو سره مینه درلوده. — ويکيپېډيا

زموږ په مثال کې، ډیری ډیټا تولیدونکي او د دوی مصرف کونکي (وسیلې او سرورونه) شتون لري، او کافکا د دوی سره د یو بل سره نښلولو کې مرسته کوي. مصرف کونکي به په راتلونکو مرحلو کې په ډیر تفصیل سره تشریح شي، چیرې چې دوی به اصلي لوبغاړي وي. اوس موږ به یوازې د ډیټا تولیدونکي (پیښې) په پام کې ونیسو.
کافکا د کتار او ویش مفکورې راټولوي، په ځانګړې توګه د دې په اړه دا غوره ده چې په بل ځای کې ولولئ (د مثال په توګه، اسناد). پرته له دې چې توضیحاتو ته لاړشئ ، راځئ تصور وکړو چې د ګرځنده اپلیکیشن دوه مختلف عملیاتي سیسټمونو لپاره پیل شوی. بیا هره نسخه خپل جلا جلا جریان رامینځته کوي. تولیدونکي کافکا ته پیښې لیږي، دوی په مناسب کتار کې ثبت کیږي.

(انځور له دې ځایه)

په ورته وخت کې، کافکا تاسو ته اجازه درکوي چې په ټوټو کې ولولئ او په کوچنیو بستونو کې د پیښو جریان پروسس کړئ. کافکا یوه ډیره اسانه وسیله ده چې د مخ پر ودې اړتیاوو سره سم اندازه کوي (د بیلګې په توګه، د پیښو جیو ځای کول).
معمولا یو شارډ کافی وي، مګر شیان د اړیکو سره ډیر پیچلي کیږي کله چې اندازه کول (د تل په څیر). شاید هیڅوک نه غواړي چې په تولید کې یوازې یو فزیکي شارډ وکاروي، ځکه چې جوړښت باید د غلطو زغم وړ وي. د کافکا سربیره، یو بل مشهور حل شتون لري - RabbitMQ. موږ دا په تولید کې د پیښې تحلیلونو لپاره د قطار په توګه نه دی کارولی (که تاسو داسې تجربه لرئ ، موږ ته یې په نظرونو کې ووایاست!). په هرصورت، AWS Kinesis کارول کیده.

مخکې له دې چې بل ګام ته لاړ شئ، د سیسټم یو بل اضافي پرت باید یادونه وشي - د خامو لوګو ذخیره کول. دا لازمي پرت نه دی، مګر دا به ګټور وي په هغه صورت کې چې یو څه غلط شي او په کافکا کې د پیښو کتار صفر ته بیرته راستانه شي. د خامو لاګونو ذخیره کول پیچلي او ګران حل ته اړتیا نلري ، تاسو کولی شئ په ساده ډول دا په سم ترتیب کې ولیکئ (حتی هارډ ډرایو ته).

2. د پیښو جریان اداره کول

وروسته له دې چې موږ ټولې پیښې چمتو کړې او په مناسبو کتارونو کې یې ځای په ځای کړو، موږ د پروسس مرحلې ته ځو. دلته به زه د پروسس کولو دوه خورا عام انتخابونو په اړه وغږیږم.
لومړی اختیار د اپاچي سیسټم کې د سپارک سټریمینګ فعالول دي. د اپاچي ټول محصولات په HDFS کې ژوند کوي، د خوندي نقل فایل سیسټم. سپارک سټریمینګ د کارولو اسانه وسیله ده چې د سټرینګ ډیټا پروسس کوي او ښه اندازه کوي. په هرصورت، دا ساتل ستونزمن کیدی شي.
بله لاره دا ده چې ستاسو د پیښې سمبالونکی جوړ کړئ. د دې کولو لپاره، د مثال په توګه، تاسو اړتیا لرئ چې د Python غوښتنلیک ولیکئ، دا په ډاکر کې جوړ کړئ، او د کافکا په کتارونو کې ګډون وکړئ. کله چې محرکونه په ډاکر کې سمبالونکو ته راشي، پروسس به پیل شي. د دې میتود سره، تاسو اړتیا لرئ چې په دوامداره توګه د غوښتنلیکونو چلولو ته دوام ورکړئ.
راځئ فرض کړو چې موږ د پورته بیان شوي انتخابونو څخه یو غوره کړی او پخپله پروسس ته لاړ شو. پروسیسرونه باید د معلوماتو د اعتبار په چک کولو، د کثافاتو فلټر کولو او "مات شوي" پیښو سره پیل کړي. د اعتبار لپاره موږ معمولا کاروو سربرس. له هغې وروسته، د معلوماتو نقشه کول ترسره کیدی شي: د مختلفو سرچینو څخه ډاټا نورمال شوي او معیاري شوي ترڅو یو عام میز ته اضافه شي.

3. ډیټابیس

دریم ګام د عادي پیښو خوندي کول دي. کله چې د چمتو شوي تحلیلي سیسټم سره کار کول، موږ به ډیری وختونه دوی ته لاسرسی ولرو، نو دا مهمه ده چې یو مناسب ډیټابیس غوره کړئ.
که چیرې معلومات په ثابت سکیما کې ښه وي، تاسو کولی شئ غوره کړئ کلک هاؤس یا کوم بل کالم ډیټابیس. نو راټولونه به په چټکۍ سره کار وکړي. نیمګړتیا دا ده چې سکیم په کلکه ټاکل شوی او له همدې امله دا به کار ونکړي چې پرته له اصالحاتو څخه د خپل سري توکي اضافه کړي (د مثال په توګه ، کله چې غیر معیاري پیښه پیښیږي). مګر دا واقعیا په چټکۍ سره ترسره کیدی شي.
د غیر منظم معلوماتو لپاره، تاسو کولی شئ NoSQL واخلئ، د بیلګې په توګه، اپاچی کاسیاندرا. دا په HDFS چلوي، ښه نقل کوي، تاسو کولی شئ ډیری مثالونه پورته کړئ، او د غلطۍ زغمونکی دی.
تاسو کولی شئ یو څه ساده پورته کړئ، د بیلګې په توګه، MongoDB. دا حتی د کوچنیو حجمونو لپاره خورا سست دی. مګر پلس دا دی چې دا خورا ساده دی او له همدې امله د پیل لپاره مناسب دی.

4. جمع کول

د ټولو پیښو په احتیاط سره خوندي کولو سره، موږ غواړو ټول مهم معلومات د هغه بیچ څخه راټول کړو چې راغلي او ډیټابیس تازه کړي. په نړیواله کچه، موږ اړوند ډشبورډونه او میټریکونه غواړو. د مثال په توګه، د پیښو څخه د یو کارن پروفایل راټولولو او یو څه ډول چلند اندازه کول. پیښې راټول شوي، راټول شوي، او بیا خوندي شوي (د کارونکي په جدولونو کې دمخه). په ورته وخت کې، دا ممکنه ده چې یو سیسټم په داسې طریقه جوړ کړئ چې فلټر هم د همغږۍ راټولونکي سره وصل وي: یوازې د یو ځانګړي ډول پیښو څخه د کاروونکو راټولولو لپاره.
له هغې وروسته ، که چیرې په ټیم کې څوک یوازې د لوړې کچې تحلیلونو ته اړتیا ولري ، تاسو کولی شئ د بهرني تحلیلي سیسټمونو سره وصل شئ. تاسو کولی شئ بیا Mixpanel واخلئ. مګر ځکه چې دا خورا ګران دی، د کاروونکو ټولې پیښې هلته نه لیږل کیږي، مګر یوازې هغه څه چې ورته اړتیا وي. د دې کولو لپاره، موږ اړتیا لرو یو همغږي کونکی رامینځته کړو چې ځینې خام پیښې یا هغه څه چې موږ پخپله مخکې بهرني سیسټمونو ، APIs یا اعلاناتو پلیټ فارمونو ته راټول کړي وي لیږدوي.

5. مخکینۍ برخه

تاسو اړتیا لرئ چې فرنټ انډ د رامینځته شوي سیسټم سره وصل کړئ. ښه بیلګه یې خدمت دی. سور رنګ، د ډیټابیس GUI دی چې د پینلونو په جوړولو کې مرسته کوي. متقابل عمل څنګه کار کوي:

1. کارن د SQL پوښتنه کوي.
2. په ځواب کې، هغه یو نښه ترلاسه کوي.
3. د دې لپاره 'نوي لید' رامینځته کوي او یو ښکلی ګراف ترلاسه کوي چې تاسو دمخه خپل ځان خوندي کولی شئ.

په خدمت کې لیدونه په اوتومات ډول تازه کیږي ، تاسو کولی شئ خپل نظارت تنظیم او تعقیب کړئ. Redash وړیا دی، د ځان کوربه توب په صورت کې، مګر د SaaS په توګه دا به په میاشت کې $ 50 لګښت ولري.

پایلې

د پورته ټولو مرحلو بشپړولو وروسته، تاسو به خپل د سرور اړخ تحلیلونه جوړ کړئ. مهرباني وکړئ په یاد ولرئ چې دا د پیرودونکي تحلیلونو سره وصل کولو په څیر اسانه ندي ، ځکه چې هرڅه باید پخپله تنظیم شي. له همدې امله ، د خپل سیسټم رامینځته کولو دمخه ، دا ارزښت لري چې د جدي تحلیلي سیسټم اړتیا د هغه سرچینو سره پرتله کړئ چې تاسو ورته تخصیص کولو ته چمتو یاست.
که تاسو ټول ریاضی ترسره کړی او وموندل چې لګښتونه خورا لوړ دي، په راتلونکې برخه کې به زه د دې په اړه وغږیږم چې څنګه د شاته پای تحلیلونو ارزانه نسخه جوړ کړئ.

د لوستلو لپاره مننه! زه به په نظرونو کې پوښتنو ته خوښ شم.

سرچینه: www.habr.com