ما مدى سهولة تقديم الطلب ومعرفة عنوان العميل (ليس غاية)

مرحبا بالجميع! اسمي دينيس جيركو ، أنا مهندس النظام الأساسي لمنصة التجارة الإلكترونية في لامودا. في العام الماضي ، تحدثت في مؤتمر DevConf مع تقرير أود أن أشاركه معك.

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

ماذا سيكون حول؟ سأخبرك:

• حول عملية التسليم وتحديد المشاكل ؛
• كيفية تخزين مناطق التسليم في قاعدة البيانات بشكل فعال ؛
• كيفية تحسين جودة البيانات التي نتلقاها من العميل ؛
• كيفية البحث عن المرسل إليه في قاعدة بيانات العنوان للعثور على نتائج أكثر دقة.

نظام تسليم الطلبات العام لامودا

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

يقبل Lamoda الطلب ، ويسأل العميل عن العنوان في وقت التسجيل ويمرره إلى حامل البريد.

ماذا لو لم يكن لدينا خدمة بريد سريع ، ولكن عدة؟ ثم تتم إضافة الخطوة التالية - لتحديد خدمة التسليم التي سنأخذها.

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

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

سيتم تحسين المخطط العام وسيبدو كما يلي:

• طلب عنوان
• معرفة أي خدمات البريد السريع يمكن أن تقدمه ؛
• حدد واحد تريد من تلك المتاحة.

الآن أكثر قليلاً عن هذه الخطوات.

نسأل العميل عن العنوان

كيف يمكنني أن أسأله؟

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

ما هي خدمة التوصيل التي ننقلها؟

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

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

لماذا فهارس مفقودة؟

مثال بسيط: ليوبرتسي. بالقرب من قرية Marusino. لا يوجد لدى Marusino مكتب بريد ؛ وتأتي مراسلاتهم في أحد مكاتب البريد في Lyubertsy. إذا أردنا إضافة التسليم إلى Lyubertsy ، ولكن ليس التسليم إلى Marusino ، لأنه قد لا يكون مربحًا من الناحية المالية بالنسبة لنا ، فلن نتمكن من القيام بذلك فقط عن طريق الفهرس.

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

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

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

واجهة إنشاء منطقة المضلع

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

واجهة التوجيه

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

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

يقدم نموذج السحب نصائح لإضفاء الطابع الرسمي على بيانات العنوان

قاعدة العنوان

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

لدينا أيضًا مجموعة من البرامج النصية لـ PHP تأخذ التنسيق الذي تأتي به قاعدة العناوين إلينا ، وبنفس الطريقة تقريبًا تضيفه إلى PostgreSQL . لماذا في نفس الشكل؟ لأن إحدى المهام هي تحديث قواعد البيانات هذه بشكل دوري من نفس المصادر. هذا يعني أنه إذا قدمنا ​​التحويل ، فسيتعين تكراره مع كل تحديث ، وبالتالي ، يتم نقل البيانات إلى PostgreSQL ، ومن هناك يتم تحويلها وتخزينها في Apache Solr ؛ يسمح لك Solr بالبحث بسرعة عنهم والقيام sajest. خادم الويب PHP صغير قادر على بناء الطلبات في Solr ، وفقا لنتائجها ، يتم إنشاء قائمة للعميل على الموقع ل sugest.

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

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

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

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

فيما يلي الطبقات التي لدينا في PostgreSQL.

الجداول الموجودة على اليسار هي بيانات خام تم تنزيلها من المصدر.

وراءهم هي وجهات النظر التي تحول البيانات إلى تنسيق قياسي.

عمليات التخطي المحلية هي مجموعة الجداول التي تعيد تحديد بعض سمات بيانات العناوين المحملة. لقد أدرجنا هنا ، على سبيل المثال ، أن السجل الذي يحمل مثل هذا المعرف يجب أن يتلقى بدلاً من "Chuvash rep. - Chuvashia "هو اسمنا المختار.

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

كائنات العنوان - قاعدة العناوين المشكلة مع جميع التصحيحات والإضافات.

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

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

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

إضافة: على الشاشة - قطعة من الكود الحقيقي من الخدمة ، والتي أصبحت غير ضرورية لمجرد الحلول الموصوفة.

لقد صنفت هذه المشاكل.

1) أسماء معادلة لنفس الكائنات. على سبيل المثال ، مثل المرادفات الشائعة مثل تشوفاشيا وجمهورية تشوفاش.

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

3) الكثير من الاخطاء. غالبًا ما يكون مخطئًا في وضع المستوطنات. هناك قرية ، هنا قرية أو هنا قرية ، هناك مزرعة.

4) كلمات أجنبية مترجمة إلى الروسية ، وغالبا ما يتم ترجمة نفس الاسم بطرق مختلفة.

5) هناك العديد من الأخطاء في التسلسل الهرمي: Zelenograd ، عادة ، ينتمي إلى منطقة موسكو ، على الرغم من أنها مدرجة رسميا في موسكو باعتبارها FIAS. اكتب بشكل صحيح "مدينة موسكو ، زيلينوغراد."

كيف توصلنا إلى هذا؟

أول شيء نفعله هو فصل جميع المكونات غير المهمة من العنوان عن الأسماء. نحن لا نرميهم ، فهم يشاركون في البحث ، ولكن بشكل منفصل عن الأجزاء المهمة.

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

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

نحن تصحيح الأخطاء المطبعية وإصلاح التصميم.

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

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

وأين وجدنا مثل هذا البحث؟

• مرة أخرى ، نقوم بتشغيل العنوان الذي أدخله العميل من خلال هذا البحث. إذا لم يستخدم نصائحنا في صفحة الخروج ، فلدينا فرصة أخرى لتحويل الخطوط التي أدخلها في معرفات. نحصل على عنوان رسمي.
• ننفذ في هذا البحث كل شيء ترسله لنا خدمات البريد السريع - نحن ندرك المدن التي يرسلونها إلينا. هذا سمح لنا بإطلاق 10 قطع فقط في اليوم ، وهذا أمر يتعلق بـ B2B - تقدم Lamoda توصيلها إلى شركات خارجية ، لذلك هناك الكثير من خدمات التوصيل الجديدة المتصلة بكل وحدة زمنية.
• هذا سمح لنا ب "توحيد" المعلومات المفيدة المختلفة في معرفاتنا في قواعد بيانات العناوين. على سبيل المثال ، قمنا بتنزيل مناطق زمنية وعناوين IP للبحث عن المدن عن طريق عناوين IP للعملاء.
• لدينا الآن الفرصة لإخفاء قاعدة العناوين المدمجة من مصدرين مع أحد معرفاتنا. وهذا يعني أنه سمح بتجنب التكرارات ومطابقة كائنات العنوان نفسها في كلا الأساسين.

نحن لا نتوقف. هذه عملية لا يزال بإمكاننا تحسينها.

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

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

على الشريحة عبارة عن جزء من الواجهة يسمح لك بتكوين المنطقة يدويًا ، ولكن في الواقع يتم تكوين كل شيء من قوائم كائنات العناوين المحملة على دُفعات في شكل سلاسل.

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

نتخلص من PHP في سلسلة البحث عن بيانات العنوان. نعيد كتابة الرمز الذي وصل إلى Solr على Lua. تم استبدال nginx بـ Openresty ، والآن أصبح كل شيء سريعًا للغاية ويمكنه تحمل الأحمال الثقيلة. 95 ٪ من ردود خدمة البحث لدينا تتناسب مع 10 ميلي ثانية ، وهو أكثر من كاف بالنسبة لنا.

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

استنتاج

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