كيفية مشاركة البيانات عبر المؤسسة

Question

ما هي بعض الطرق الجيدة للمؤسسة لتبادل البيانات الرئيسية عبر العديد من عمليات التخلص والتطبيقات؟

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

هل هناك أي طرق جيدة أخرى لمشاركة البيانات؟ وكيف تقارن مقارباتك مع المناهج المذكورة أعلاه فيما يتعلق بالمخاوف مثل:

بيانات مكررة

خطأ في عمليات مزامنة البيانات

ضيقة مقابل اقتران فضفاض (تقليل التبعيات/التنسيق الهشاشة/الاختبار)

التبسيط المعماري

الأمان

أداء

واجهات محددة جيدًا

المخاوف الأخرى ذات الصلة؟

ضع في اعتبارك أن بيانات العميل المشتركة تُستخدم بعدة طرق ، من استفسارات السجلات الفردية البسيطة إلى التعليقات المعقدة والمتعددة المسبقة والمتعددة ، تنضم إلى بيانات المؤسسة الأخرى المخزنة في قواعد بيانات مختلفة.

شكرا لاقتراحاتك ونصائحك ...

Answer 1

أنا متأكد من أنك رأيت هذا قادمًا ، "يعتمد الأمر".

ذلك يعتمد على كل شيء. وقد يكون الحل لمشاركة بيانات العميل للقسم A مختلفًا تمامًا لمشاركة بيانات العميل مع القسم B.

مفهومي المفضل الذي ارتفع على مر السنين هو مفهوم "الاتساق النهائي". جاء المصطلح من Amazon يتحدث عن الأنظمة الموزعة.

الفرضية هي أنه على الرغم من أن حالة البيانات عبر مؤسسة موزعة قد لا تكون متسقة تمامًا الآن ، فإنها "في النهاية" ستكون كذلك.

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

عندما تعمل مع نظام واحد ، ليس لديك "EC" ، بل لديك تحديثات فورية ، "مصدر الحقيقة" ، وعادة ما تكون آلية قفل للتعامل مع ظروف السباق والصراعات.

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

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

الآن ، هذا مثال متطرف ومبسط وخشن للغاية من EC.

ولكن النظر في نظام كبير مثل جوجل. كمستهلك للبحث ، ليس لدينا أي فكرة عن متى أو المدة التي تستغرقها نتيجة البحث التي تحصد Google إلى كيفية ظهور صفحة البحث. 1 مللي ثانية؟ 1S؟ 10s؟ 10 ساعات؟ من السهل تصوير كيف إذا كنت تضرب خوادم Googles West Coast ، فقد تحصل على نتيجة بحث مختلفة جدًا عما إذا كنت تضغط على خوادم الساحل الشرقي. في أي وقت من الأوقات ، هاتان الحالتين متسقة تمامًا. ولكن حسب القياس الكبير ، فهي متسقة في الغالب. ولحالة استخدامهم ، لا يتأثر مستهلكوهم حقًا بالتأخير والتأخير.

النظر في البريد الإلكتروني. يريد A إرسال رسالة إلى B ، ولكن في العملية يتم توجيه الرسالة من خلال النظام C و D و E. كل نظام يقبل الرسالة ، وتولى المسؤولية الكاملة لها ، ثم يسلطها إلى آخر. يرى المرسل أن البريد الإلكتروني يذهب في طريقه. لا يفوتها المتلقي حقًا لأنهم لا يعرفون بالضرورة قادمًا. لذلك ، هناك نافذة زمنية كبيرة يمكن أن تستغرقها هذه الرسالة للتنقل عبر النظام دون أن يهتم أي شخص بمعرفة أو رعاية مدى السرعة.

من ناحية أخرى ، كان يمكن أن يكون على الهاتف مع B. "لقد أرسلته للتو ، هل حصلت عليه بعد؟ الآن؟ الآن؟ احصل عليه الآن؟"

وبالتالي ، هناك نوع من مستوى الأداء والاستجابة الضمنية. في النهاية ، "في نهاية المطاف" ، يطابق صندوق A Outbox في صندوق الوارد B.

هذه التأخيرات ، قبول البيانات التي لا معنى لها ، سواء كانت عمرها يوم أو 5-5 سنوات ، هي التي تتحكم في الاقتران النهائي لأنظمتك. كلما كان هذا المطلب أكثر مرونة ، كلما زاد عدد المرونة التي لديك تحت تصرفك من حيث التصميم.

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

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

تحرير ، ردا على التعليق الأول.

صحيح ، بالضبط. اللعبة هنا ، على سبيل المثال ، إذا لم تتمكن B من تغيير بيانات العميل ، فما هو الضرر مع بيانات العميل المتغيرة؟ هل يمكنك "المخاطرة" بأنها قديمة لفترة قصيرة؟ ربما تأتي بيانات العميل ببطء بما يكفي بحيث يمكنك تكرارها من A إلى B على الفور. قل أن التغيير يتم وضعه في قائمة انتظار ، بسبب انخفاض الحجم ، يتم التقاطها بسهولة (<1s) ، ولكن حتى أنه سيكون "خارج المعاملة" مع التغيير الأصلي ، وبالتالي هناك نافذة صغيرة حيث سيكون هناك A البيانات التي لا.

الآن يبدأ العقل حقًا في الدوران. ما يحدث خلال 1s من "التأخر" ، ما هو أسوأ سيناريو ممكن. وهل يمكنك المهندس من حوله؟ إذا تمكنت من المهندس حول تأخر 1S ، فقد تتمكن من المهندس حول 5S أو 1M أو حتى تأخر أطول. ما مقدار بيانات العميل التي تستخدمها بالفعل على B؟ ربما B هو نظام مصمم لتسهيل اختيار الطلبات من المخزون. من الصعب تخيل أن أي شيء ضروري أكثر من مجرد معرف العميل وربما اسم. مجرد شيء لتحديد من هو أمره أثناء تجميعه.

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

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

كل هذا يمكن أن يخفف من خلال إجراءات صلبة وفهم شامل لسير العمل. تحديد المخاطر وعمل السياسة والإجراءات للتعامل معها.

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

Answer 2

هذا بالتأكيد ليس رد شامل. عذرًا ، في مشاركتي الطويلة وآمل أن يضيف إلى الأفكار التي سيتم تقديمها هنا.

لدي بعض الملاحظات حول بعض الجوانب التي ذكرتها.

duplicate data

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

well-defined interfaces

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

tight coupling vs loose coupling

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

architectural simplification

بالنسبة لي هذا هو مفتاح مكافحة جميع المشكلات التي ذكرتها في سؤالك. SIP vs H.323 VoIP قصة تأتي في ذهني. SIP مبسطة للغاية وسهلة الإنشاء بينما حاول H.323 مثل معيار الاتصالات النموذجي أن يتصور كل مشكلة على الكوكب حول VoIP وتوفير حل لذلك. النتيجة النهائية ، نمت SIP بسرعة أكبر. إنه لألم أن يكون حل H.323 متوافق. في الواقع ، H.323 الامتثال هو صناعة باك ضخمة.

On a few architectural fads that I have grown up to.

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

Answer 3

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

إنها مثل الترجمة المركزية ؛ بدلاً من الاضطرار إلى كتابة رمز محدد للرسم البياني من A-> B و A-> C و B-> C ، مع زيادة الحضور الأسية أثناء إضافة المزيد من الأنظمة ، تحتاج فقط إلى التحويل إلى/من المحور: A- > Hub ، b-> hub ، c-> hub ، d-> hub ، etc.