امروزه حجم عظیمی از دادههای موجود را فعالیت‌ها و اطلاعاتی که کابران در فضای مجازی به اشتراک می‌گذارند، تشکیل می‌دهد. این داده‌ها می‌توانند از منابع متنوعی همچون شبکه‌های اجتماعی، دادههای ابری، اینترنت اشیا و هر منبع اشتراکِ داده بر روی فضای مجازی باشد. این داده‌ها مبنای بسیاری از آنالیز‌ها و تحلیل‌های انجام شده در هر سازمانی هستند. دادههای موجود در هر بستری را می‌توان در دو دسته دادههای با ساختار و بدون ساختار تقسیم بندی و ذخیره نمود. به صورت دقیق نمی‌توان یک دسته را از دسته دیگر برتر دانست اما براساس نیازهای یک سازمان می‌توان به بهترین نحو از این دو دسته در بزنگاه‌های مختلف بهره جست. ذخیره و استفاده از داده به صورت بدون ساختار این امکان را به یک سازمان می‌دهد تا از انواع گوناگون منابع، داده‌ها را جمع‌آوری و ترکیب کند تا نتیجه بهتری در فرآیند‌های سازمانی خود فراهم آورد. این فرآیند‌ها می‌تواند تجاری و یا استراتژیک باشد. به عبارت دیگر استفاده از داده‌ها به صورت بدون ساختار، ابزار بیشتری را در اختیار مدیران و تصمیم‌گیران یک سازمان قرار می‌دهد.
مهمترین نکته در هنگام کار با دادههای بدون ساختار، پردازش حجم عظیمی از چنین داده‌هایی است. در بسیار از سامانه‌ها و پروژه‌ها لازم است حجم زیادی از داده ذخیره و پردازش شود که این عمل برای یک ماشین امکان پذیر نیست. همچنین در بسیاری از موارد لازم است تا دادههای جمع آوری شده توسط چندین ماشین نگهداری و پردازش شوند. این امر لزوم استفاده از سیستم‌های فایلِ توزیع شده را بیش از پیش نمایان می‌سازد. ذخیره دادههای بدون ساختار معمولا توسط ابزارهای زیادی پشتیبانی می‌شوند که هر کدام از این ابزارها ویژگی‌ها و توانایی‌های خاص خود را دارا هستند. مهمترین ابزار در حوزه کلان داده را شرکت Apache معرفی و ارائه کرده است. این ابزار یک اکوسیستم است که تمامی مراحل کار با داده را فراهم می‌آورد. ابتدایی‌ترین و مهمترین جز این اکوسیستم HDFS است که فایل سیستم توزیع شده این اکو سیستم را فراهم می‌کند.
پایگاه‌های داده مهمترین رکن از سامانه‌های تحلیل کلان‌داده هستند. پایگاه‌های داده در قدیم تنها دادههای ساختاریافته را پشتیبانی می‌کردند اما امروزه قابلیت ذخیره سازی دادههای بدون ساختار را نیز دارا هستند. Wide column، Document store، key value و Graph DB دسته‌های مهم از پایگاه دادههای بدون ساختار هستند که بسته به نیازهای هر سازمان برای اجرای هر کدام از روال‌های تحلیلی آن مورد استفاده قرار می‌گیرند. معماری‌های متداول در سامانه‌های تحلیل کلان داده بیشتر به سمت استفاده ترکیبی از مجموعه پایگاه دادههای رابطه‌ای و بدون ساختار تمایل دارد.
معماری پایگاه دادههای موجود در شرکت دیتاک ترکیبی از پایگاه دادههای ساختار یافته و بدون ساختار است که به صورت هماهنگ نیازهای اطلاعاتی ما در شرکت را فراهم می‌کنند. پایگاه داده ساختار نیافته ما HBase است که یکی از ارکان اکوسیستم Apache Hadoop می‌باشد. این پایگاه داده در دسته‌بندی پایگاه داده‌ها در قالب پایگاه دادههای بدون ساختار wide columns قرار می‌گیرد. در این دسته مهمترین رقیب HBase پایگاه داده Cassandra است. مزیت‌های متعدد HBase نسبت به Cassandra ما را بر آن داشت تا دست به این انتخاب بزنیم. اما باید به این نکته اشاره کرد که مانند هر مقایسه بین دو ابزار در تمامی موارد HBase عملکرد بهتری نسبت به رقیب خود نداشته و در مواردی کارایی آن از Cassandra پایین‌تر بوده است.
در معماری پیاده‌سازی شده برای HBase چهار عنصر HMaster، HMaster-passive ،RegionServer و Zookeeper در نظر گرفته شده است که HMaster عنصر هماهنگ‌کننده و نودِ مستر کلاستر است. عنصر HMaster-passive نودِ مستر پشتیبان است که در هنگام ایجاد مشکل برای نود مستر اصلی، به عنوان نود مستر وارد سیکل خدمات‌دهی می‌شود. RegionServerها محل نگهداری داده‌ها هستند و بار اصلی ذخیره‌سازی و واکِشی اطلاعات بر عهده این نود‌ها است. Zookeeper نیز خود یک مجموعه‌ای از ماشین‌هاست که در کنار یکدیگر زنده بودن کلاستر HBase را تضمین می‌کنند. به عبارت دیگر این مجموعه از ماشین‌ها به صورت دوره‌ای زنده بودن تک تک عناصر کلاستر را بررسی و اعلام می‌کنند. کلاستر پیاده‌سازی شده برای میزبانی از این مجموعه از عناصر، از حدود ۱۰ سرور اختصاصی تشکیل شده است که هر کدام از آن‌ها میزبانی یک یا چند عنصر بالا را بر عهده دارند. نودهای RegionServer دارای سرورهای اختصاصی هستند تا از نظر بار و منابع دچار کمبود نشوند. دو عنصر دیگر را می‌توان بر روی ماشین‌های مجازی راه‌اندازی کرد. نکته مهم در خصوص کلاستر HBase ، راه ارتباطی نودهاست که ممکن است ریسک‌های زیادی را به کل کلاستر تحمیل کند برای حل این موضوع ما از شبکه ۱۰G استفاده کردیم تا بتوانیم ارتباط ما بین نودهای کلاستر را به بهترین شکل ممکن برقرار کنیم که در غیر اینصورت مسلما کلاستر ما دچار محدودیت‌هایی در جهت سرویس دهی می‌شد.
برای درج و واکشی از کلاستر HBase ابزارهای متعددی وجود دارند که مهترین آن‌ها استفاده از کدهای بومی جاوا و راه‌اندازی سرورهای مبتنی بر REST و Thrift است. به دلیل اینکه بیشتر درخواست‌های واکشی و درج ما از طریق زبان پایتون بوده، درنتیجه ما نیاز داشتیم تا یکی از دو سرور REST و یا Thrift را در کنار کلاستر HBase داشته باشیم تا بتوانیم از طریق آن درج و واکشی اطلاعات را مدیریت کنیم. با این معماری ما توانستیم تا ۶۰۰۰ پیام در ثانیه را به HBase از طریق سرور Thrift نسخه ۲ انتقال دهیم. باید به این نکته توجه داشت که این تعداد پیام ماکسیممِ توانایی کلاستر ما نبوده است. همچنین میزان خواندن از HBase از همین طریق در حدود ۱ میلیارد پیام در روز است. همچنین باید خاطر‌نشان کرد که این مقدار در زمانی محقق شده که کدهایی که از HBase اطلاعات را واکشی کرده‌اند، در داخل همان شبکه ۱۰G بوده‌اند. تعداد جداول نگهداری شده در HBase در حدود ۷۰ جدول است که این تعداد جدول در قالب حدود ۳۰۰۰ region نگهداری می‌شود.
