کاربرد کم کد در بسترهای تحلیلی

خوانندگان عزیز، روز بخیر!

وظیفه ساخت پلتفرم های فناوری اطلاعات برای جمع آوری و تجزیه و تحلیل داده ها دیر یا زود برای هر شرکتی که کسب و کارش مبتنی بر مدل ارائه خدمات بارگذاری شده فکری یا ایجاد محصولات از نظر فنی پیچیده است، مطرح می شود. ساخت پلتفرم های تحلیلی یک کار پیچیده و زمان بر است. با این حال، هر کاری را می توان ساده کرد. در این مقاله می خواهم تجربه خود را در استفاده از ابزارهای کم کد برای کمک به ایجاد راه حل های تحلیلی به اشتراک بگذارم. این تجربه در طول اجرای تعدادی از پروژه ها در جهت راه حل های کلان داده شرکت نئوفلکس به دست آمد. از سال 2005، مدیریت Big Data Solutions Neoflex با مسائل مربوط به ساخت انبارهای داده و دریاچه ها، حل مشکلات بهینه سازی سرعت پردازش اطلاعات و کار بر روی روشی برای مدیریت کیفیت داده ها می پردازد.

هیچ کس نمی تواند از انباشت آگاهانه داده های ضعیف و/یا ساختار قوی جلوگیری کند. شاید حتی اگر در مورد مشاغل کوچک صحبت کنیم. از این گذشته، یک کارآفرین آینده‌دار هنگام گسترش یک کسب‌وکار با مسائل مربوط به توسعه یک برنامه وفاداری مواجه می‌شود، می‌خواهد اثربخشی نقاط فروش را تجزیه و تحلیل کند، به تبلیغات هدفمند فکر می‌کند و از تقاضا برای محصولات همراه متحیر می‌شود. . با تقریب اول، مشکل را می توان "روی زانو" حل کرد. اما با رشد کسب و کار، رسیدن به یک پلت فرم تحلیلی هنوز اجتناب ناپذیر است.

با این حال، در چه موردی وظایف تجزیه و تحلیل داده‌ها می‌تواند به مشکلات کلاس «Rocket Science» تبدیل شود؟ شاید در لحظه ای که در مورد داده های واقعا بزرگ صحبت می کنیم.
برای سهولت در علم موشک، می توانید فیل را تکه تکه بخورید.

هرچه برنامه‌ها/خدمات/سرویس‌های میکرو گسسته‌تر و مستقل‌تر باشند، هضم فیل برای شما، همکارانتان و کل تجارت آسان‌تر خواهد بود.

تقریباً همه مشتریان ما با بازسازی چشم انداز بر اساس شیوه های مهندسی تیم های DevOps به این اصل رسیدند.

اما حتی با یک رژیم غذایی "فیل جداگانه"، ما شانس خوبی برای "اشباع بیش از حد" چشم انداز فناوری اطلاعات داریم. در این لحظه ارزش توقف، بازدم و نگاه کردن به طرف را دارد پلت فرم مهندسی کم کد.

بسیاری از توسعه دهندگان وقتی از نوشتن مستقیم کد به سمت «کشیدن» فلش ها در رابط های رابط کاربری سیستم های کم کد دور می شوند، از چشم انداز بن بست در حرفه خود می ترسند. اما ظهور ماشین ابزار منجر به ناپدید شدن مهندسان نشد، بلکه کار آنها را به سطح جدیدی رساند!

بیایید بفهمیم چرا

تجزیه و تحلیل داده ها در زمینه لجستیک، صنعت مخابرات، تحقیقات رسانه ای، بخش مالی همیشه با سوالات زیر همراه است:

• سرعت تجزیه و تحلیل خودکار؛
• توانایی انجام آزمایش‌ها بدون تأثیر بر جریان اصلی تولید داده.
• قابلیت اطمینان داده های تهیه شده؛
• تغییر ردیابی و نسخه سازی؛
• منشأ داده، اصل و نسب داده، CDC.
• تحویل سریع ویژگی های جدید به محیط تولید؛
• و بدنام: هزینه توسعه و پشتیبانی.

به این معنی که مهندسان دارای تعداد زیادی وظایف سطح بالا هستند که تنها با پاک کردن آگاهی خود از وظایف توسعه سطح پایین می توان آنها را با کارایی کافی تکمیل کرد.

پیش نیاز توسعه دهندگان برای حرکت به سطح جدید، تکامل و دیجیتالی شدن تجارت بود. ارزش توسعه‌دهنده نیز در حال تغییر است: کمبود قابل توجهی از توسعه‌دهندگان وجود دارد که بتوانند خود را در مفاهیم کسب‌وکار خودکار غرق کنند.

بیایید یک قیاس با زبان های برنامه نویسی سطح پایین و سطح بالا ترسیم کنیم. انتقال از زبان‌های سطح پایین به زبان‌های سطح بالا، گذار از نوشتن «دستورالعمل‌های مستقیم به زبان سخت‌افزار» به «دستورالعمل‌هایی به زبان مردم» است. یعنی اضافه کردن لایه ای از انتزاع. در این مورد، انتقال به پلتفرم‌های کم‌کد از زبان‌های برنامه‌نویسی سطح بالا، انتقالی از «دستورالعمل‌ها به زبان مردم» به «دستورالعمل‌هایی به زبان تجارت» است. اگر توسعه دهندگانی هستند که از این واقعیت ناراحت هستند، پس شاید از لحظه ای که جاوا اسکریپت متولد شده است که از توابع مرتب سازی آرایه استفاده می کند، ناراحت بوده اند. و این توابع، البته، پیاده سازی نرم افزار در زیر هود با ابزارهای دیگر همان برنامه نویسی سطح بالا دارند.

بنابراین، کم کد فقط ظاهر سطح دیگری از انتزاع است.

تجربه کاربردی با استفاده از کم کد

موضوع کم‌کد بسیار گسترده است، اما اکنون می‌خواهم در مورد کاربرد عملی «مفاهیم کم‌کد» با استفاده از مثال یکی از پروژه‌هایمان صحبت کنم.

بخش Big Data Solutions Neoflex بیشتر در بخش مالی تجارت، ساخت انبارهای داده و دریاچه‌ها و خودکارسازی گزارش‌های مختلف تخصص دارد. در این طاقچه، استفاده از کم کد مدت هاست که به یک استاندارد تبدیل شده است. از دیگر ابزارهای کم کد می توان به ابزارهای سازماندهی فرآیندهای ETL اشاره کرد: Informatica Power Center، IBM Datastage، Pentaho Data Integration. یا Oracle Apex که به عنوان محیطی برای توسعه سریع رابط ها برای دسترسی و ویرایش داده ها عمل می کند. با این حال، استفاده از ابزارهای توسعه کم کد همیشه شامل ساخت برنامه های کاربردی بسیار هدفمند بر روی یک پشته فناوری تجاری با وابستگی آشکار به فروشنده نیست.

با استفاده از پلتفرم‌های کم‌کد، می‌توانید سازماندهی جریان‌های داده را سازماندهی کنید، پلتفرم‌های علم داده یا مثلاً ماژول‌هایی برای بررسی کیفیت داده‌ها ایجاد کنید.

یکی از نمونه های کاربردی تجربه در استفاده از ابزارهای توسعه کم کد، همکاری نئوفلکس و مدیاسکوپ، یکی از پیشتازان بازار تحقیقات رسانه ای روسیه است. یکی از اهداف تجاری این شرکت تولید داده‌هایی است که بر اساس آن تبلیغ‌کنندگان، بسترهای اینترنتی، کانال‌های تلویزیونی، ایستگاه‌های رادیویی، آژانس‌های تبلیغاتی و برندها در مورد خرید تبلیغات تصمیم می‌گیرند و ارتباطات بازاریابی خود را برنامه‌ریزی می‌کنند.

تحقیقات رسانه ای یک حوزه تجاری بارگیری شده از نظر فناوری است. تشخیص دنباله‌های ویدیویی، جمع‌آوری داده‌ها از دستگاه‌هایی که مشاهده را تجزیه و تحلیل می‌کنند، اندازه‌گیری فعالیت در منابع وب - همه اینها نشان می‌دهد که این شرکت دارای کارکنان بزرگ فناوری اطلاعات و تجربه عظیمی در ساخت راه‌حل‌های تحلیلی است. اما رشد تصاعدی در حجم اطلاعات، تعداد و تنوع منابع آن، صنعت داده های فناوری اطلاعات را به پیشرفت مداوم وادار می کند. ساده‌ترین راه‌حل برای مقیاس‌بندی پلت‌فرم تحلیلی Mediascope که قبلاً کار می‌کرد، می‌تواند افزایش کارکنان فناوری اطلاعات باشد. اما راه حل بسیار مؤثرتر، تسریع روند توسعه است. یکی از گام‌هایی که در این مسیر پیش می‌رود، ممکن است استفاده از پلتفرم‌های کم‌کد باشد.

در زمان شروع پروژه، شرکت قبلاً یک راه حل محصول کارآمد داشت. با این حال، پیاده‌سازی راه‌حل در MSSQL نمی‌تواند به طور کامل انتظارات برای عملکرد مقیاس‌بندی را برآورده کند و در عین حال هزینه توسعه قابل قبولی را حفظ کند.

وظیفه پیش روی ما واقعا جاه طلبانه بود - Neoflex و Mediascope مجبور بودند یک راه حل صنعتی را در کمتر از یک سال ایجاد کنند، مشروط به انتشار MVP در سه ماهه اول تاریخ شروع.

پشته فناوری Hadoop به عنوان پایه ای برای ساخت یک پلت فرم داده جدید بر اساس محاسبات کم کد انتخاب شد. HDFS به استانداردی برای ذخیره سازی داده ها با استفاده از فایل های پارکت تبدیل شده است. برای دسترسی به داده های موجود در پلتفرم از Hive استفاده شده است که در آن تمامی ویترین های موجود در قالب جداول خارجی ارائه شده است. بارگذاری داده ها در فضای ذخیره سازی با استفاده از Kafka و Apache NiFi اجرا شد.

ابزار Lowe-code در این مفهوم برای بهینه سازی کار فشرده ترین کار در ساخت یک پلت فرم تحلیلی - وظیفه محاسبه داده ها - استفاده شد.

ابزار کم کد Datagram به عنوان مکانیزم اصلی برای نگاشت داده ها انتخاب شد. دیتاگرام نئوفلکس ابزاری برای توسعه تحولات و جریان های داده است.
با استفاده از این ابزار می توانید بدون نوشتن کد Scala به صورت دستی انجام دهید. کد اسکالا به طور خودکار با استفاده از رویکرد معماری مبتنی بر مدل تولید می شود.

مزیت آشکار این رویکرد تسریع روند توسعه است. با این حال، علاوه بر سرعت، مزایای زیر نیز وجود دارد:

• مشاهده محتوا و ساختار منابع / گیرنده ها.
• ردیابی مبدأ اشیاء جریان داده در فیلدهای جداگانه (نسب و اصل)؛
• اجرای جزئی تبدیل ها با مشاهده نتایج میانی.
• بررسی کد منبع و تنظیم آن قبل از اجرا.
• اعتبار سنجی خودکار تحولات؛
• دانلود خودکار داده 1 در 1.

مانع ورود به راه حل های کم کد برای ایجاد تبدیل ها بسیار کم است: توسعه دهنده باید SQL را بداند و تجربه کار با ابزارهای ETL را داشته باشد. شایان ذکر است که ژنراتورهای تبدیل کد محور ابزار ETL به معنای وسیع کلمه نیستند. ابزارهای کم کد ممکن است محیط اجرای کد خود را نداشته باشند. یعنی کد تولید شده در محیطی که حتی قبل از نصب راه حل کم کد روی خوشه وجود داشت اجرا می شود. و این شاید مزیت دیگری برای کارمای کم کد باشد. از آنجایی که، به موازات یک تیم کم کد، یک تیم کلاسیک می تواند کار کند که عملکردی را اجرا کند، به عنوان مثال، در کد Scala خالص. آوردن پیشرفت‌ها از هر دو تیم به تولید ساده و بدون درز خواهد بود.

شاید شایان ذکر باشد که علاوه بر کم کد، راه حل های بدون کد نیز وجود دارد. و در هسته آنها، اینها چیزهای متفاوتی هستند. Low-code به توسعه دهنده اجازه می دهد تا با کد تولید شده بیشتر تداخل داشته باشد. در مورد دیتاگرام، امکان مشاهده و ویرایش کد اسکالا تولید شده وجود دارد؛ بدون کد ممکن است چنین فرصتی را فراهم نکند. این تفاوت نه تنها از نظر انعطاف پذیری راه حل، بلکه از نظر راحتی و انگیزه در کار مهندسان داده بسیار قابل توجه است.

معماری راه حل

بیایید سعی کنیم دقیقاً بفهمیم که چگونه یک ابزار کم کد به حل مشکل بهینه سازی سرعت توسعه عملکرد محاسبه داده کمک می کند. ابتدا به معماری عملکردی سیستم نگاه می کنیم. نمونه ای در این مورد مدل تولید داده برای تحقیقات رسانه ای است.

منابع داده در مورد ما بسیار ناهمگن و متنوع هستند:

• مترهای مردمی (تلویزیون متر) ابزارهای نرم افزاری و سخت افزاری هستند که رفتار کاربر را از پاسخ دهندگان پنل تلویزیون می خوانند - چه کسی، چه زمانی و چه کانال تلویزیونی در خانواده شرکت کننده در مطالعه تماشا شده است. اطلاعات ارائه شده جریانی از فواصل مشاهده پخش است که به بسته رسانه و محصول رسانه ای مرتبط است. داده ها در مرحله بارگیری در دریاچه داده را می توان با ویژگی های جمعیت شناختی، طبقه بندی جغرافیایی، منطقه زمانی و سایر اطلاعات لازم برای تجزیه و تحلیل تماشای تلویزیون از یک محصول رسانه ای خاص غنی کرد. اندازه گیری های انجام شده می تواند برای تجزیه و تحلیل یا برنامه ریزی کمپین های تبلیغاتی، ارزیابی فعالیت ها و ترجیحات مخاطبان و تدوین شبکه پخش استفاده شود.
• داده‌ها می‌توانند از سیستم‌های نظارت برای پخش پخش‌های تلویزیونی و اندازه‌گیری مشاهده محتوای منابع ویدیویی در اینترنت به دست آیند.
• ابزارهای اندازه گیری در محیط وب، از جمله مترهای سایت محور و کاربر محور. ارائه دهنده داده برای Data Lake می تواند یک افزونه مرورگر نوار تحقیق و یک برنامه تلفن همراه با VPN داخلی باشد.
• داده‌ها همچنین می‌تواند از سایت‌هایی باشد که نتایج پر کردن پرسشنامه‌های آنلاین و نتایج مصاحبه‌های تلفنی در نظرسنجی‌های شرکت را ادغام می‌کنند.
• غنی سازی اضافی دریاچه داده می تواند با بارگیری اطلاعات از لاگ شرکت های شریک رخ دهد.

پیاده سازی as is loading از سیستم های منبع در مرحله اولیه داده های خام می تواند به روش های مختلفی سازماندهی شود. اگر برای این اهداف از کد پایین استفاده می شود، تولید خودکار اسکریپت های بارگیری بر اساس ابرداده امکان پذیر است. در این مورد، نیازی به پایین آمدن به سطح منبع در حال توسعه برای هدف‌یابی نقشه‌ها نیست. برای پیاده سازی بارگذاری خودکار، باید با منبع ارتباط برقرار کنیم و سپس لیست موجودیت هایی که باید بارگذاری شوند را در واسط بارگذاری تعریف کنیم. ساختار دایرکتوری در HDFS به طور خودکار ایجاد می شود و با ساختار ذخیره سازی داده در سیستم منبع مطابقت دارد.

اما در چارچوب این پروژه تصمیم گرفتیم از این ویژگی پلتفرم کم‌کد استفاده نکنیم، زیرا شرکت Mediascope قبلاً به‌طور مستقل کار خود را برای تولید سرویس مشابه با استفاده از ترکیب Nifi + Kafka آغاز کرده است.

بلافاصله باید نشان داد که این ابزارها قابل تعویض نیستند، بلکه مکمل یکدیگر هستند. Nifi و Kafka می توانند هم به صورت مستقیم (Nifi -> Kafka) و هم به صورت معکوس (Kafka -> Nifi) کار کنند. برای پلتفرم تحقیقات رسانه ای، از اولین نسخه بسته نرم افزاری استفاده شد.

در مورد ما، NayFi نیاز به پردازش انواع مختلف داده ها از سیستم های منبع و ارسال آنها به کارگزار کافکا داشت. در این مورد، پیام ها با استفاده از پردازنده های PublishKafka Nifi به یک موضوع خاص کافکا ارسال می شد. ارکستراسیون و نگهداری این خطوط لوله در یک رابط بصری انجام می شود. ابزار Nifi و استفاده از ترکیب Nifi + Kafka را می‌توان رویکردی کم‌کد برای توسعه نیز نامید که مانع کم‌تری برای ورود به فناوری‌های Big Data است و روند توسعه اپلیکیشن را سرعت می‌بخشد.

مرحله بعدی در اجرای پروژه، آوردن داده های دقیق به قالب یک لایه معنایی بود. اگر یک موجودیت دارای ویژگی های تاریخی باشد، محاسبه در زمینه پارتیشن مورد نظر انجام می شود. اگر موجودیت تاریخی نباشد، به صورت اختیاری می توان کل محتوای شی را مجدداً محاسبه کرد، یا به طور کامل از محاسبه مجدد این شی (به دلیل عدم تغییر) خودداری کرد. در این مرحله کلیدها برای همه موجودیت ها تولید می شوند. کلیدها در دایرکتوری‌های Hbase مربوط به اشیاء اصلی ذخیره می‌شوند، که حاوی متناظری بین کلیدهای پلتفرم تحلیلی و کلیدهای سیستم‌های منبع هستند. ادغام موجودیت های اتمی با غنی سازی با نتایج محاسبات اولیه داده های تحلیلی همراه است. چارچوب برای محاسبه داده ها Spark بود. عملکرد توصیف شده برای آوردن داده ها به معنایی واحد نیز بر اساس نگاشت از ابزار کم کد Datagram پیاده سازی شد.

معماری هدف نیازمند دسترسی SQL به داده ها برای کاربران تجاری بود. از Hive برای این گزینه استفاده شده است. هنگامی که گزینه "Registr Hive Table" را در ابزار کم کد فعال کنید، اشیاء به طور خودکار در Hive ثبت می شوند.

کنترل جریان محاسبه

دیتاگرام یک رابط برای ایجاد طرح های جریان کار دارد. نقشه‌ها را می‌توان با استفاده از زمان‌بندی Oozie راه‌اندازی کرد. در رابط توسعه دهنده جریان، امکان ایجاد طرح هایی برای تبدیل داده های موازی، متوالی یا وابسته به اجرا وجود دارد. پشتیبانی از اسکریپت های پوسته و برنامه های جاوا وجود دارد. همچنین امکان استفاده از سرور آپاچی لیوی وجود دارد. Apache Livy برای اجرای برنامه ها به طور مستقیم از محیط توسعه استفاده می شود.

اگر شرکت از قبل ارکستراتور فرآیند خود را داشته باشد، می توان از REST API برای جاسازی نقشه ها در یک جریان موجود استفاده کرد. به عنوان مثال، ما تجربه کاملاً موفقی از تعبیه نگاشتها در Scala در ارکسترهای نوشته شده در PLSQL و Kotlin داشتیم. REST API ابزار کم‌کد شامل عملیات‌هایی مانند تولید یک سال اجرایی بر اساس طراحی نقشه‌برداری، فراخوانی نقشه‌برداری، فراخوانی دنباله‌ای از نگاشت‌ها و البته ارسال پارامترها به URL برای اجرای نقشه‌ها است.

همراه با Oozie، امکان سازماندهی یک جریان محاسباتی با استفاده از جریان هوا وجود دارد. شاید زیاد روی مقایسه بین Oozie و Airflow تمرکز نکنم، اما به سادگی می گویم که در زمینه کار روی یک پروژه تحقیقاتی رسانه ای، انتخاب به نفع Airflow بود. بحث اصلی این بار یک جامعه فعال تر در حال توسعه محصول و یک رابط توسعه یافته تر + API بود.

جریان هوا نیز خوب است زیرا از پایتون محبوب برای توصیف فرآیندهای محاسبه استفاده می کند. و به طور کلی، پلتفرم های مدیریت گردش کار منبع باز زیادی وجود ندارد. راه اندازی و نظارت بر اجرای فرآیندها (از جمله نمودار گانت) فقط به کارمای Airflow امتیاز می دهد.

فرمت فایل پیکربندی برای راه‌اندازی نگاشت راه‌حل‌های کم‌کد تبدیل به spark-submit شده است. این اتفاق به دو دلیل افتاد. ابتدا، spark-submit به شما امکان می دهد مستقیماً یک فایل jar را از کنسول اجرا کنید. ثانیا، می‌تواند حاوی تمام اطلاعات لازم برای پیکربندی گردش کار باشد (که نوشتن اسکریپت‌هایی را که Dag تولید می‌کنند آسان‌تر می‌کند).
رایج ترین عنصر جریان کاری جریان هوا در مورد ما SparkSubmitOperator بود.

SparkSubmitOperator به شما این امکان را می دهد که jars - نگاشت Datagram بسته بندی شده را با پارامترهای ورودی از پیش تولید شده برای آنها اجرا کنید.

شایان ذکر است که هر وظیفه Airflow در یک تاپیک جداگانه اجرا می شود و در مورد وظایف دیگر چیزی نمی داند. بنابراین، تعامل بین وظایف با استفاده از عملگرهای کنترلی مانند DummyOperator یا BranchPythonOperator انجام می شود.

روی هم رفته، استفاده از راه‌حل کم‌کد دیتاگرام در ارتباط با جهانی‌سازی فایل‌های پیکربندی (تشکیل Dag) منجر به تسریع و ساده‌سازی قابل توجهی در روند توسعه جریان‌های بارگذاری داده شد.

محاسبات ویترینی

شاید بیشترین بار ذهنی در تولید داده های تحلیلی، مرحله ساخت ویترین باشد. در زمینه یکی از جریان‌های محاسبه داده‌های شرکت تحقیقاتی، در این مرحله، داده‌ها با در نظر گرفتن اصلاحات برای مناطق زمانی به یک پخش مرجع تقلیل می‌یابند و به شبکه پخش مرتبط می‌شوند. همچنین امکان تنظیم برای شبکه پخش محلی (اخبار و تبلیغات محلی) وجود دارد. از جمله، این مرحله فواصل مشاهده مداوم محصولات رسانه ای را بر اساس تجزیه و تحلیل فواصل مشاهده تجزیه می کند. بلافاصله، مقادیر مشاهده بر اساس اطلاعات مربوط به اهمیت آنها (محاسبه ضریب تصحیح) "وزن" می شوند.

یک مرحله جداگانه در آماده سازی ویترین ها اعتبار سنجی داده ها است. الگوریتم اعتبارسنجی شامل استفاده از تعدادی مدل علوم ریاضی است. با این حال، استفاده از یک پلت فرم کم کد به شما امکان می دهد یک الگوریتم پیچیده را به تعدادی نگاشت جداگانه قابل خواندن بصری تقسیم کنید. هر یک از نگاشت ها یک کار باریک را انجام می دهد. در نتیجه، اشکال زدایی میانی، ثبت و تجسم مراحل آماده سازی داده ها امکان پذیر است.

تصمیم گرفته شد که الگوریتم اعتبار سنجی در مراحل فرعی زیر گسسته شود:

• ایجاد رگرسیون وابستگی تماشای شبکه های تلویزیونی در یک منطقه با مشاهده تمامی شبکه های منطقه به مدت 60 روز.
• محاسبه باقیمانده های دانشجویی (انحراف مقادیر واقعی از مقادیر پیش بینی شده توسط مدل رگرسیون) برای تمام نقاط رگرسیون و برای روز محاسبه شده.
• منتخبی از جفت‌های ناهنجار منطقه-شبکه، که در آن تعادل دانشجویی روز تسویه حساب از حد معمول (مشخص شده توسط تنظیمات عملیات) فراتر می‌رود.
• محاسبه مجدد باقیمانده دانش‌آموزی تصحیح‌شده برای جفت‌های شبکه ناهنجار منطقه-تلویزیون برای هر پاسخ‌دهنده که شبکه را در منطقه تماشا کرده است، تعیین سهم این پاسخ‌دهنده (میزان تغییر در باقیمانده دانشجویی) هنگام حذف مشاهده این پاسخ‌دهنده از نمونه .
• کاندیداهایی را جستجو کنید که حذف آنها تعادل دانشجویی روز پرداخت را به حالت عادی برمی گرداند.

مثال بالا این فرضیه را تأیید می کند که یک مهندس داده در حال حاضر بیش از حد در ذهن خود فکر می کند ... و اگر این واقعا یک "مهندس" است و نه یک "کدگذار"، پس ترس از تخریب حرفه ای هنگام استفاده از ابزارهای کم کد بالاخره باید عقب نشینی کرد

کم کد چه کار دیگری می تواند انجام دهد؟

دامنه کاربرد یک ابزار کم کد برای پردازش دسته ای و جریانی داده ها بدون نیاز به نوشتن دستی کد در Scala به همین جا ختم نمی شود.

استفاده از low-code در توسعه datalake در حال حاضر برای ما به یک استاندارد تبدیل شده است. احتمالاً می توان گفت که راه حل های مبتنی بر پشته Hadoop مسیر توسعه DWH های کلاسیک مبتنی بر RDBMS را دنبال می کنند. ابزارهای کم‌کد در پشته Hadoop می‌توانند هم وظایف پردازش داده و هم وظیفه ساخت رابط‌های BI نهایی را حل کنند. علاوه بر این، باید توجه داشت که BI می تواند نه تنها به معنای نمایش داده ها، بلکه همچنین ویرایش آنها توسط کاربران تجاری باشد. ما اغلب از این قابلیت هنگام ساختن پلتفرم های تحلیلی برای بخش مالی استفاده می کنیم.

از جمله، با استفاده از کد پایین و به ویژه دیتاگرام، می توان مشکل ردیابی منشاء اشیاء جریان داده با اتمی را تا فیلدهای جداگانه (نسب) حل کرد. برای انجام این کار، ابزار کم کد رابط را با Apache Atlas و Cloudera Navigator پیاده سازی می کند. اساساً، توسعه‌دهنده باید مجموعه‌ای از اشیاء را در فرهنگ لغت اطلس ثبت کند و در هنگام ساختن نقشه‌ها به اشیاء ثبت‌شده ارجاع دهد. مکانیزم ردیابی مبدا داده ها یا تجزیه و تحلیل وابستگی های شی، زمانی که نیاز به بهبود الگوریتم های محاسباتی باشد، زمان زیادی را صرفه جویی می کند. به عنوان مثال، هنگام تهیه صورت های مالی، این ویژگی به شما امکان می دهد تا با راحتی بیشتری از دوره تغییرات قانونی دوام بیاورید. از این گذشته، هرچه وابستگی بین فرمی را در زمینه اشیاء یک لایه دقیق بهتر درک کنیم، کمتر با نقص های "ناگهانی" مواجه خواهیم شد و تعداد دوباره کاری ها را کاهش خواهیم داد.

کیفیت داده و کد پایین

وظیفه دیگری که توسط ابزار کم کد در پروژه Mediascope پیاده سازی شد، وظیفه کلاس Data Quality بود. ویژگی خاص اجرای خط لوله تأیید داده ها برای پروژه شرکت تحقیقاتی عدم تأثیرگذاری بر عملکرد و سرعت جریان اصلی محاسبه داده ها بود. برای اینکه بتوان جریان‌های تأیید مستقل داده‌ها را هماهنگ کرد، از Apache Airflow از قبل آشنا استفاده شد. با آماده شدن هر مرحله از تولید داده، بخش جداگانه ای از خط لوله DQ به صورت موازی راه اندازی شد.

نظارت بر کیفیت داده ها از لحظه شروع آن در بستر تحلیلی، عمل خوبی در نظر گرفته می شود. با داشتن اطلاعاتی در مورد ابرداده، می توانیم از لحظه ورود اطلاعات به لایه اولیه، مطابقت با شرایط اولیه را بررسی کنیم - نه null، محدودیت ها، کلیدهای خارجی. این قابلیت بر اساس نگاشت های تولید شده به صورت خودکار از خانواده کیفیت داده ها در دیتاگرام پیاده سازی شده است. تولید کد در این مورد نیز بر اساس فراداده مدل است. در پروژه Mediascope، رابط با ابرداده محصول Enterprise Architect انجام شد.

با جفت کردن ابزار کم‌کد با Enterprise Architect، چک‌های زیر به‌طور خودکار ایجاد شدند:

• بررسی وجود مقادیر "تهی" در فیلدهای با اصلاح کننده "not null".
• بررسی وجود موارد تکراری کلید اصلی؛
• بررسی کلید خارجی یک نهاد؛
• بررسی منحصر به فرد بودن یک رشته بر اساس مجموعه ای از فیلدها.

برای بررسی‌های پیچیده‌تر در دسترس بودن و قابلیت اطمینان داده‌ها، نقشه‌برداری با Scala Expression ایجاد شد که یک کد بررسی خارجی Spark SQL را که توسط تحلیلگران Zeppelin تهیه شده است، به عنوان ورودی می‌گیرد.

البته تولید خودکار چک ها باید به تدریج محقق شود. در چارچوب پروژه توصیف شده، مراحل زیر انجام شد:

• DQ پیاده سازی شده در نوت بوک های Zeppelin.
• DQ ساخته شده در نقشه برداری.
• DQ در قالب نگاشت های عظیم جداگانه که شامل مجموعه ای کامل از چک ها برای یک موجودیت جداگانه است.
• نگاشت های DQ پارامتری جهانی که اطلاعات مربوط به ابرداده و بررسی های تجاری را به عنوان ورودی می پذیرد.

شاید مزیت اصلی ایجاد یک سرویس بررسی پارامتری، کاهش زمان لازم برای ارائه عملکرد به محیط تولید باشد. بررسی‌های کیفیت جدید می‌توانند الگوی کلاسیک ارائه کد به‌طور غیرمستقیم از طریق محیط‌های توسعه و آزمایش را دور بزنند:

• وقتی مدل در EA اصلاح می شود، تمام بررسی های فراداده به طور خودکار ایجاد می شوند.
• بررسی در دسترس بودن داده ها (تعیین وجود هر داده در یک نقطه از زمان) را می توان بر اساس دایرکتوری ایجاد کرد که زمان مورد انتظار ظاهر شدن قطعه بعدی داده را در زمینه اشیا ذخیره می کند.
• بررسی های اعتبارسنجی داده های تجاری توسط تحلیلگران در نوت بوک های Zeppelin ایجاد می شود. از آنجا مستقیماً به جداول راه اندازی ماژول DQ در محیط تولید ارسال می شوند.

هیچ خطری برای ارسال مستقیم فیلمنامه به تولید وجود ندارد. حتی با یک خطای نحوی، حداکثر چیزی که ما را تهدید می کند عدم انجام یک بررسی است، زیرا جریان محاسبه داده ها و جریان راه اندازی بررسی کیفیت از یکدیگر جدا هستند.

در اصل، سرویس DQ به طور دائم در محیط تولید در حال اجرا است و آماده است تا کار خود را در لحظه ظاهر شدن قطعه بعدی داده آغاز کند.

به جای یک نتیجه گیری

مزیت استفاده از کم کد آشکار است. توسعه دهندگان نیازی به توسعه برنامه از ابتدا ندارند. و برنامه نویسی که از وظایف اضافی رها شده باشد، نتایج را سریعتر تولید می کند. سرعت، به نوبه خود، زمان بیشتری را برای حل مسائل بهینه سازی آزاد می کند. بنابراین، در این مورد، می توانید روی راه حل بهتر و سریع تری حساب کنید.

البته، low-code یک دارو نیست و جادو به خودی خود اتفاق نخواهد افتاد:

• صنعت کم کد در حال گذراندن مرحله "قوی تر شدن" است و هنوز استانداردهای صنعتی یکسانی وجود ندارد.
• بسیاری از راه حل های کم کد رایگان نیستند و خرید آنها باید یک اقدام آگاهانه باشد که باید با اطمینان کامل از مزایای مالی استفاده از آنها انجام شود.
• بسیاری از راه حل های کم کد همیشه با GIT/SVN خوب کار نمی کنند. یا اگر کد تولید شده پنهان باشد، استفاده از آنها ناخوشایند است.
• هنگام گسترش معماری، ممکن است لازم باشد راه حل کم کد را اصلاح کنیم - که به نوبه خود، تأثیر "پیوست و وابستگی" را بر تامین کننده راه حل کم کد ایجاد می کند.
• سطح مناسبی از امنیت امکان پذیر است، اما اجرای آن در موتورهای سیستم با کد پایین بسیار کار بر و دشوار است. پلتفرم‌های کم‌کد باید نه تنها بر اساس اصل جستجوی مزایای استفاده از آنها انتخاب شوند. هنگام انتخاب، ارزش دارد در مورد در دسترس بودن عملکرد برای کنترل دسترسی و تفویض/توسعه داده های شناسایی به سطح کل چشم انداز فناوری اطلاعات سازمان سؤال کنید.

با این حال، اگر تمام کاستی های سیستم انتخابی برای شما شناخته شده است، و مزایای استفاده از آن، با این وجود، در اکثریت غالب است، بدون ترس به سراغ کدهای کوچک بروید. علاوه بر این، گذار به آن اجتناب ناپذیر است - همانطور که هر تکاملی اجتناب ناپذیر است.

اگر یک توسعه‌دهنده در یک پلت‌فرم کم‌کد سریع‌تر از دو توسعه‌دهنده بدون کد پایین کار خود را انجام دهد، این امر به شرکت از همه جنبه‌ها یک شروع برتر می‌دهد. آستانه ورود به راه حل های کم کد کمتر از فناوری های "سنتی" است و این تأثیر مثبتی بر موضوع کمبود پرسنل دارد. هنگام استفاده از ابزارهای کم‌کد، می‌توان تعامل بین تیم‌های عملکردی را تسریع کرد و تصمیمات سریع‌تری در مورد درستی مسیر انتخابی تحقیق علم داده اتخاذ کرد. پلتفرم‌های سطح پایین می‌توانند تحول دیجیتالی یک سازمان را هدایت کنند، زیرا راه‌حل‌های تولید شده توسط متخصصان غیر فنی (به ویژه کاربران تجاری) قابل درک است.

اگر ضرب‌الاجل‌های محدود، منطق تجاری پربار، فقدان تخصص در فن‌آوری دارید و باید زمان خود را برای بازاریابی تسریع کنید، پس کد پایین یکی از راه‌های رفع نیازهای شما است.

نمی توان اهمیت ابزارهای توسعه سنتی را انکار کرد، اما در بسیاری از موارد استفاده از راه حل های کم کد بهترین راه برای افزایش کارایی وظایف در حال حل است.

منبع: www.habr.com