اختيار استراتيجية لوحدة ثنائية

Question

الشركة التي أعمل فيها تنتج نظام إدارة المحتوى (CMS) مع مختلف الوظائف الإضافية للنشر ، والتجارة الإلكترونية ، والطباعة عبر الإنترنت ، وما إلى ذلك. نحن الآن بصدد إضافة "وحدة الإبلاغ" وأحتاج إلى التحقيق في الإستراتيجية التي ينبغي ملاحق. تُعرف "وحدة الإبلاغ" بخلاف ذلك ذكاء الأعمال, أو ثنائية.

من المفترض أن تكون الوحدة قادرة على تتبع تنزيلات العناصر وتنفيذ عمليات البحث وإنتاج تقارير مختلفة منها. في الواقع ، ليس من المهم نوع البيانات التي يتم تقطيعها كما هو الحال على المدى الطويل ، فقد نرغب في أن نكون قادرين على دفع ما نعتقد أنه مطلوب والحصول على تقرير منه.

تقريبا ، لدينا خياران.

الخيار 1 هو كتابة حل يعتمد على Apache Solr (على وجه التحديد ، باستخدام https://issues.apache.org/jira/browse/solr-236). إيجابيات هذا النهج:

• مجاني / مفتوح المصدر / نوعية جيدة
• نستخدم Solr/Lucene في مكان آخر حتى نعرف المجال جيدًا
• المرونة الكلية على ما يتم فهرسته حيث يمكننا أخذ البيانات الواردة (بتنسيق XML) ، ودفعها من خلال XSLT وتغذيةها إلى solr
• المرونة التامة لكيفية إظهار نتائج البحث. على غرار الخطوة أعلاه ، يمكن أن يكون لدينا قالب بحث XSLT مخصص وإظهار النتائج مرة أخرى في أي تنسيق نعتقد أنه ضروري
• إن مطوري الواجهة الأمامي لدينا يتقونون XSLT ، لذا فإن تركيب هذه الآلية لعميل مختلف يجب أن يكون سهلاً نسبيًا
• يوفر SOLR البحث في الوقت الفعلي / الكامل / البحث عن الوجه وهو ضروري للغاية بالنسبة لنا. تمكنت النموذج الأولي السريع (استنادًا إلى SOLR ، 1M سجلات) من تقديم نتائج البحث في 55 مللي ثانية. يبلغ الحد الأقصى لسجلاتنا المقدرة حوالي 1 مليار من الصفوف (هذا ليس كثيرًا لتطبيق BI النموذجي) وإذا كان الأمر أسوأ أسوأ ، فيمكننا دائمًا النظر إلى Solrcloud ، إلخ.
• هناك شركات تقوم بأشياء متشابهة جدًا باستخدام SOLR (معجم قرص العسل ، على سبيل المثال)

سلبيات هذا النهج:

• قد يكون أو لا يكون SOLR-236 مستقرًا ، علاوة على ذلك ، لم يكن واضحًا بعد/إذا تم إصداره كجزء من الإصدار الرسمي
• قد يكون هناك بعض الأشياء التي يتعين علينا أن نكتبها للحصول على بعض الميزات الخاصة بـ ثنائية العمل. هذا يشبه إلى حد ما إعادة اختراع العجلة
• المشكلة الأكبر هي أننا لا نعرف ما قد نحتاجه في المستقبل (مثل التكامل مع بعض برامج BI ، والتصدير إلى Excel ، وما إلى ذلك)

الخيار 2 هو القيام بتكامل مع بعض برامج BI المجانية أو التجارية. حتى الآن نظرت إلى وابيت وسوف تلق نظرة على qlikview, ، ربما الآخرين. إيجابيات هذا النهج:

• لا حاجة لإعادة اختراع العجلة ، يتم تجربتها (نأمل) (نأمل) تجربتها واختبارها
• من شأنه أن يوفر لنا الوقت الذي يمكننا إنفاقه في حل المشكلات التي نتخصص فيها

سلبيات:

• نظرًا لأننا متجر Java وحلنا عبر المنصات ، يتعين علينا القضاء على الكثير من الخيارات الموجودة في السوق
• لست متأكدًا من مدى مرونة برنامج BI. سيستغرق الأمر بعض الوقت للذهاب إلى بعض عروض BI لمعرفة ما إذا كان بإمكانهم القيام بفهرسة مرنة ، والوقت الحقيقي / البحث عن النص الكامل ، والنتائج القابلة للتخصيص بالكامل ، وما إلى ذلك.
• قيل لي إن عروض BI مفتوحة المصدر ليست ناضجة بما فيه الكفاية في حين أن مكررات BIS التجارية (SAP ، أخرى) تتكلم ثرواتها ، وتبدأ تراخيصها من عشرات الآلاف من الجنيهات/الدولارات. على الرغم من أنني لست ضد الاختيار التجاري في حد ذاته ، إلا أنه سيضيف ما يصل إلى السعر الإجمالي الذي يمكن أن يصبح بسهولة كبيرة جدًا
• لست متأكدًا من مدى جودة صنع BI للعمل مع بيانات أقل مخططًا

أنا بالتأكيد لست أفضل مرشح للعثور على خيار التكامل الأكثر اعتمادًا في السوق (وذلك أساسًا بسبب عدم وجود المعرفة في منطقة BI) ، ولكن يجب اتخاذ القرار بسرعة.

هل كان أي شخص في وضع مماثل ويمكنه أن ينصح بالمسار الذي يجب اتخاذه ، أو حتى أفضل - تقديم المشورة بشأن إيجابيات/سلبيات محتملة للخيار رقم 2؟ المشكلة الأكبر هنا هي أنني لا أعرف ما لا أعرفه ؛)

Answer 1

لقد قضيت بعض الوقت في اللعب مع كليهما qlikview و وابيت, ، ويجب أن أقول ، أشعر بخيبة أمل شديدة.

كان لدي توقع أن صناعة BI بأكملها لديها بالفعل بعض العلوم تحتها ولكن من ما وجدت أن هذه مجرد كلمة طنانة. هذه المقالة MSDN كان في الواقع فتاحة العين. يتكون العمل الكامل لـ BI من أخذ بيانات من مخططات طبيعية (يسمونها OLTP) ، وضعها في مخططات أقل طبيعية (olap, ندفة الثلج- أو نوع النجوم) وإنشاء مؤشرات لكل جانب تريده (المصطلحات الصناعية لهذا مكعب البيانات). الباقي هو مجرد بعض البرمجة النصية للحصول على الرسوم البيانية الجميلة.

حسنًا ، أعلم أنني أفرط في تبسيط الأشياء هنا. أعلم أنني ربما فاتني العديد من الجوانب المختلفة (تقارير لطيفة؟ التصدير إلى Excel؟ التنبؤات؟) ، ولكن من وجهة نظر علوم الكمبيوتر ، لا يمكنني ببساطة رؤية أي شيء يتجاوز فهرس قاعدة البيانات هنا.

قيل لي إن بعض أدوات BI تدعم ضغطًا. لوكين يدعم ذلك أيضًا. قيل لي إن بعض أدوات BI قادرة على الاحتفاظ بجميع الفهرس في الذاكرة. لذلك هناك ذاكرة التخزين المؤقت لوكين.

الحديث عن المرشحين (Wabit و Qlikview) - الأول غير ناضج ببساطة (لدي عشرات الاستثناءات عند محاولة الخروج من ما تم اقتراحه في العرض التوضيحي) بينما يعمل الآخر فقط تحت النوافذ (ليس لطيفًا جدًا ، ولكن يمكن أن أعيش مع ذلك) ومن المرجح أن يطلب مني التكامل أن أكتب بعض vbscript (yuck!). اضطررت إلى قضاء بضع ساعات في منتديات QlikView لمجرد الحصول على التحكم في نطاق التاريخ البسيط وفشلت لأن الإصدار الشخصي الذي لم أدعمه مشاريع تجريبية قابلة للتنزيل متوفرة على موقعهم. لا تخطئني ، فهي أدوات جيدة لما تم بناؤه من أجله ، لكنني ببساطة لا أرى أي نقطة في القيام بالتكامل معهم لأنني لن أكسب الكثير.

لمعالجة (قدرتها على الجدال) ، سأقوم بتعريف واجهة برمجة تطبيقات مجردة حتى أتمكن من نقل جميع البيانات إلى قاعدة بيانات تدعم الاستعلامات النصية الكاملة إذا حدث أي شيء خاطئ. وإذا كان الأمر أسوأ أسوأ ، فيمكنني دائمًا كتابة أشياء فوق Solr/Lucene إذا كنت بحاجة إلى ذلك.

Answer 2

إذا كنت حقًا في سيناريو حيث أنت لست كذلك تأكد من ما لا تعرفه أعتقد أنه من الأفضل استكشاف أداة مفتوحة المصدر وتقييم فائدتها قبل الغوص في تنفيذك. قد يكون استخدام حل المصدر المفتوح سيساعدك على زيادة تبلور فهمك والميزات المطلوبة.
لقد عملت سابقًا مع حل مفتوح المصدر يسمى بنتاهو. شعرت بجدية أنني فهمت الكثير من خلال تعلم استخدام ميزات Pentaho لنهايتي. بالطبع ، كما هو الحال في العمل مع معظم الحلول المفتوحة المصدر ، بدا أن بنتاهو مخيف بعض الشيء في البداية ، لكنني تمكنت من الحصول على قبضة جيدة في غضون شهر. عملنا أيضا مع غلاية ETL أداة و موندريان مكعبات - والتي أعتقد أن معظم أدوات BI الخطيرة هذه الأيام تبني فوقها.
في وقت سابق ، كانت كل هذه المكونات مستقلة ، لكن أعتقد أن بنتاهو قد امتلك جميع هذه المشاريع.

ولكن بمجرد أن تكون واثقًا مع ما تحتاجه وما لا تفعله ، أقترح بناء بعض أداة إعداد التقارير الأساسية الخاصة بك على رأس تنفيذ موندريان. يمكن أن يكون تخصيص أداة متطورة مفتوحة المصدر مشكلة كبيرة. الى جانب ذلك ، هناك تراخيص يجب أن تكون حذرة. أعتقد أن Pentaho GPL ، على الرغم من أنك قد ترغب في التحقق من ذلك.

Answer 3

أولاً ، يجب أن توضح ما يجب أن تظهره تقاريرك. ما هي ميزة الإبلاغ التي تحتاجها؟ ما هي تنسيقات الإخراج التي تريدها؟ هل تريد إظهاره في المتصفح (HTML) أو كـ PDF أو مع عارض تفاعلي (Java/Flash). أين البيانات (قاعدة البيانات ، جافا ، إلخ)؟ هل تحتاج إلى إعداد تقارير مخصصة أم فقط بعض التقارير المشفرة الصلبة؟ هذه ليست سوى بعض الأسئلة.

بدون إجابات على هذا السؤال ، من الصعب تقديم توصية حقيقية ، لكن توصيتي العامة ستكون أنا تقارير واضحة (اعتاد أن يسمى i-net crystal clear). إنها أداة Java. إنها أداة تجارية ولكن التكلفة أقل مثل SAP و CO.