في الآونة الأخيرة ، كان هناك تقلب كبير في أسواق الأسهم ، عندما ، على سبيل المثال ، قد تفقد ورقة مستقرة لشركة معروفة جيدًا عدة في المائة في وقت واحد بسبب أنباء العقوبات ضد إدارتها أو العكس بالعكس إلى السماء على تقرير إيجابي وتوقعات المستثمرين بشأن أرباح مربحة للغاية.
كيف يمكن تحديد ما إذا كانت ملكية ورقة مالية معينة قد جلبت دخلاً أم خسرت فقط وخيبة أمل؟
(المصدر)في هذه المقالة سأخبرك بكيفية تحديد وتصور النتيجة المالية المعدلة للأوراق المالية.
باستخدام مثال تقارير الوسيط الافتتاحي للعميل ، سننظر في تحليل ودمج تقارير الوساطة لسوق الأوراق المالية ، وبناء بنية نظام التقارير السحابية مع التحليل اللاحق البسيط والمريح في AWS Quicksight.
وصف المهمة
تخبرنا العديد من الدورات التدريبية والدروس التعليمية عن الحاجة إلى دفتر يوميات المتداول ، حيث يتم تسجيل جميع معلمات المعاملات لمزيد من التحليل وتلخيص استراتيجية التداول. أوافق على أن هذا النهج للعمل في البورصة يسمح لك بتأديب تاجر ، وزيادة وعيه ، ولكن يمكن أيضًا أن يتعبك من عملية شاقة.
أعترف أنه في البداية حاولت بعناية اتباع نصيحة يوميات ، كتبت بدقة كل معاملة مع معلماتها في جدول Excel ، وقمت ببناء بعض التقارير ، والرسوم البيانية الموجزة ، والمعاملات المستقبلية المخطط لها ، ولكن ... سئمت من كل ذلك بسرعة.
لماذا يعد الاحتفاظ بمجلة التاجر أمرًا غير مريح يدويًا؟- ملء يدوي للمجلة (حتى باستخدام الأتمتة الجزئية ، في شكل تفريغ المعاملات اليومية من منصة التداول) بسرعة الإطارات ؛
- هناك خطر كبير لحدوث خطأ أو خطأ مطبعي مع إدخال يدوي ؛
- قد يحدث أن يصبح التاجر النشط مستثمرًا سلبيًا ويعود إلى هذه المجلة أقل وأقل ، ثم ينسى تمامًا ذلك (حالتي) ؛ جيد وأخيرًا
- يمكننا البرمجة ، فلماذا لا نستفيد من هذا وأتمت العملية برمتها؟ لذا ، دعنا نذهب!
غالبًا ما تكون شركات السمسرة عبارة عن مؤسسات ذات تقنية عالية توفر لعملائها تحليلات عالية الجودة إلى حد ما بشأن جميع القضايا المهمة تقريبًا. من الإنصاف القول إن هذا التقرير يتحسن بشكل أفضل مع كل تحديث ، ولكن حتى أكثرها تقدمًا قد لا يكون لديه التخصيص والدمج الذي يريد العملاء المتطلبون والفضولون رؤيته.
على سبيل المثال ، يتيح لك فتح وسيط لتلقي تقارير السمسرة بتنسيق XML في حسابك الشخصي ، ولكن إذا كان لديك IIA وحساب وساطة عادي في بورصة موسكو (MOEX) ، فسيكون هذان تقريران مختلفان ، وإذا كان لديك حساب آخر في سانت. بورصة بطرسبورغ (SPB) ، ثم تضيف الأولى والثانية واحدة أخرى.
في المجموع ، من أجل الحصول على دفتر يومية موحد للمستثمر ، سيكون من الضروري معالجة ثلاثة ملفات بتنسيق XML.
تختلف التقارير المذكورة أعلاه عن MOEX و SPB اختلافًا طفيفًا في تنسيقاتها ، والتي يجب أن تؤخذ في الاعتبار في عملية تنفيذ رسم خرائط البيانات.
بنية النظام قيد التطوير
يوضح الرسم البياني أدناه نموذج العمارة للنظام قيد التطوير:
تنفيذ المحلل
سوف نتلقى تقارير عن جميع الحسابات الثلاثة في الحساب الشخصي لأقصى فترة ممكنة (يمكن تقسيمها إلى عدة تقارير لكل عام) ، وحفظها بتنسيق XML ووضعها في مجلد واحد. كبيانات اختبار للدراسة ، سنستخدم محفظة عملاء وهمية ، ولكن مع معلمات قريبة قدر الإمكان من حقائق السوق.
لنفترض أن المستثمر X قيد الدراسة لديه محفظة صغيرة من خمسة أوراق مالية:
- سيحتوي التقرير الخاص ببورصة SPB على ورقتين: Apple و Microsoft؛
- يحتوي تقرير بورصة MOEX (السمسرة) على ورقة واحدة: FGC UES؛
- يحتوي التقرير في بورصة MOEX على اثنين من الأوراق المالية: MMK و OFZ 24019 ؛
وفقًا لأوراقنا المالية الخمسة ، قد تكون هناك معاملات على الشراء / البيع ، ودفع أرباح الأسهم وقسيمة ، قد يتغير السعر ، إلخ. نريد أن نرى الوضع في الوقت الحالي ، وهو: النتيجة المالية ، مع مراعاة جميع المدفوعات والمعاملات والقيمة السوقية الحالية.
وهنا يأتي دور Python ، نقرأ المعلومات من جميع التقارير في صفيف واحد:
my_files_list = [join('Data/', f) for f in listdir('Data/') if isfile(join('Data/', f))] my_xml_data = []
للتحليلات ، من التقارير نحتاج إلى عدة كيانات ، وهي:
- مواقع الأوراق المالية في المحفظة ؛
- الصفقات المبرمة
- العمليات غير التجارية وحركات الحساب الأخرى ؛
- متوسط أسعار الصفقات المفتوحة
من أجل إعداد العينة ، سنستخدم أربعة قواميس لوصف المجموعات المذكورة أعلاه.
dict_stocks = {'stock_name': [], 'account': [], 'currency': [], 'current_cost': [], 'current_cost_rub': [], 'saldo' : []} dict_deals = {'stock_name': [], 'account': [], 'date_oper': [], 'type_oper': [], 'quantity': [], 'price': [], 'currency': [], 'brokerage': [], 'result': []} dict_flows = {'stock_name': [], 'account': [], 'date_oper': [], 'type_oper': [], 'result': [], 'currency': []} dict_avg_price = {'stock_name': [], 'account': [], 'avg_open_price' : []}
بضع كلمات حول ماهية هذه القواميس.
قاموس Dict_stocksقاموس dict_stocks مطلوب لتخزين معلومات عامة عن المحفظة:
- اسم الورقة (stock_name) ؛
- اسم الحساب (SPB ، MOEX BROK ، MOEX IIS) (الحساب) ؛
- العملة المستخدمة للتسويات على هذه الورقة (العملة) ؛
- القيمة الحالية (وقت إنشاء التقرير في وسيط فتح الحساب الشخصي) (current_cost). هنا أود أن أشير إلى أنه بالنسبة للعملاء الذين يطلبون الكثير ، من الممكن إجراء تحسينات إضافية في المستقبل واستخدام الاستلام الديناميكي لعرض أسعار الأمان من منصة التداول أو من موقع البورصة المقابلة ؛
- القيمة الحالية للموضع الأمني في وقت إنشاء التقرير (current_cost_rub)
على غرار البند أعلاه ، هنا يمكنك أيضًا الحصول على سعر البنك المركزي في الوقت الحالي أو سعر الصرف ، كما تريد. - الرصيد الحالي للأوراق المالية (saldo)
قاموس dict_dealsقاموس dict_deals مطلوب لتخزين المعلومات التالية عن المعاملات المكتملة:
- اسم الورقة (stock_name) ؛
- اسم الحساب (SPB ، MOEX BROK ، MOEX IIS) (الحساب) ؛
- تاريخ المعاملة ، أي T0 (date_oper) ؛
- نوع العملية (type_oper) ؛
- حجم الأوراق المالية المشاركة في المعاملة (الكمية) ؛
- السعر الذي نفذت به المعاملة (السعر) ؛
- العملة التي تمت بها المعاملة (العملة) ؛
- عمولة السمسرة في المعاملة (الوساطة) ؛
- النتيجة المالية للمعاملة (النتيجة)
قاموس Dict_flowsيعكس قاموس dict_flows حركة الأموال في حساب العميل ويستخدم لتخزين المعلومات التالية:
- اسم الورقة (stock_name) ؛
- اسم الحساب (SPB ، MOEX BROK ، MOEX IIS) (الحساب) ؛
- تاريخ المعاملة ، أي T0 (date_oper) ؛
- نوع العملية (type_oper). يمكن أن يستغرق عدة قيم: div ، NKD ، ضريبة ؛
- العملة التي تمت بها المعاملة (العملة) ؛
- النتيجة المالية للعملية (النتيجة)
القاموس dict_avg_priceإن قاموس dict_avg_price ضروري للمعلومات المحاسبية بمتوسط سعر الشراء لكل ورقة:
- اسم الورقة (stock_name) ؛
- اسم الحساب (SPB ، MOEX BROK ، MOEX IIS) (الحساب) ؛
- متوسط سعر الصفقة المفتوحة (avg_open_price)
نعالج مجموعة من مستندات XML ونملأ هذه القواميس بالبيانات المناسبة:
كل المعالجة تمر عبر الحلقة عبر جميع بيانات XML من التقارير. معلومات حول منصة التداول ، رمز العميل هو نفسه في جميع التقارير ، لذلك يمكنك استخراجها بأمان من نفس العلامات دون استخدام الخرائط.
ولكن يجب علينا بعد ذلك استخدام تصميم خاص يوفر الاسم المستعار الضروري للعلامة استنادًا إلى التقرير (SPB أو MOEX) ، لأن البيانات ذات الطبيعة المتطابقة في هذه التقارير تسمى بشكل مختلف.
التناقضات في العلامات- تكمن عمولة وسيط المعاملات في تقرير SBP في علامة الوساطة ، وفي تقرير MOEX - broker_commission ؛
- تاريخ معاملات الحساب غير المتداول في تقرير SPB هو تاريخ التشغيل ، وفي MOEX ، هو تاريخ_العمل ، إلخ.
مثال لرسم الخرائط tags_mapping = { 'SPB': { 'current_position': 'briefcase_position', 'deals': 'closed_deal', 'flows': 'nontrade_money_operation', ... 'stock_name_deal': 'issuername', 'paymentcurrency': 'paymentcurrency', 'currency_flows': 'currencycode' }, 'MOEX': { 'current_position': 'spot_assets', 'deals': 'spot_main_deals_conclusion', 'flows': 'spot_non_trade_money_operations', ... 'stock_name_deal': 'security_name', 'paymentcurrency': 'price_currency_code', 'currency_flows': 'currency_code' } }
تُرجع الدالة get_allias اسم العلامة الضرورية للمعالجة ، مع أخذ اسم منصة التداول كمدخل:
دالة Get_allias def get_allias(exchange_name): return( tags_mapping[exchange_name]['current_position'], tags_mapping[exchange_name]['deals'], tags_mapping[exchange_name]['flows'], ... tags_mapping[exchange_name]['stock_name_deal'], tags_mapping[exchange_name]['paymentcurrency'], tags_mapping[exchange_name]['currency_flows'] )
الوظيفة get_briefcase مسؤولة عن معالجة المعلومات حول حالة حافظة العميل:
دالة Get_briefcase def get_briefcase(XMLdata):
بعد ذلك ، تسترد وظيفة get_deals معلومات حول المعاملات:
دالة Get_deals def get_deals(XMLdata): stock_name_proc = '' closed_deal = XMLdata.find(deals) if not closed_deal: return
بالإضافة إلى معالجة مصفوفة بمعلومات حول معلمات المعاملة ، يتم أيضًا حساب متوسط سعر المركز المفتوح وتحققه PNL باستخدام طريقة FIFO. إن فئة PnlSnapshot مسؤولة عن هذا الحساب ، حيث تم إنشاء الكود المقدم هنا مع التعديلات الصغيرة كأساس:
حساب الربح والخسارةوأخيرًا ، فإن أصعب عملية التنفيذ هي وظيفة الحصول على معلومات حول العمليات غير التجارية -
get_nontrade_operation . يكمن تعقيدها في حقيقة أنه في كتلة التقرير المستخدمة للعمليات غير التجارية ، لا توجد معلومات واضحة حول نوع المعاملة والأمان الذي ترتبط به هذه العملية.
مثال على وجهات الدفع للعمليات غير التجاريةيمكن بيان دفع أرباح الأسهم أو أرباح الكوبونات المتراكمة على النحو التالي:
- دفع أرباح دخل العميل <777777> < APPLE INC-ao> -> دفع أرباح الأسهم من تقرير SPB ؛
- دفع أرباح عميل الدخل <777777> < MICROSOFT COM->
- دفع دخل العميل 777777i (NKD 2 OFZ 24019 ) الضريبة المقتطعة 0.00 روبل -> دفع القسيمة من تقرير MOEX ؛
- دفع الدخل للعميل 777777 أرباح من FGC UES -ao ضريبة الاستقطاع XX.XX روبل -> دفع أرباح الأسهم من تقرير MOEX. الخ.
وفقًا لذلك ، سيكون من الصعب الاستغناء عن التعبيرات العادية ، لذلك سنستخدمها على أكمل وجه. الجانب الآخر من المسألة هو أن اسم الشركة لا يتطابق دائمًا مع الاسم في المحفظة أو في المعاملات لغرض الدفع. لذلك ، يجب أن يرتبط الاسم المستلم للمصدر من غرض الدفع بالإضافة إلى القاموس. كقاموس سنستخدم مجموعة من الصفقات ، لأن هناك قائمة كاملة من الشركات.
تسترجع الدالة
get_company_from_str اسم المصدر من التعليق:
دالة Get_company_from_str def get_company_from_str(comment): company_name = ''
تؤدي الدالة
get_company_from_briefcase اسم الشركة إلى القاموس إذا وجدت تطابقًا بين الشركات التي شاركت في المعاملات:
دالة Get_company_from_briefcase def get_company_from_briefcase(company_name): company_name_full = None value_from_dic = df_deals[df_deals['stock_name'].str.contains(company_name)] company_arr = value_from_dic['stock_name'].unique() if len(company_arr) == 1: company_name_full = company_arr[0] return company_name_full
وأخيرًا ، الوظيفة الأخيرة لجمع البيانات عن العمليات غير التجارية هي
get_nontrade_operation :
دالة Get_nontrade_operation def get_nontrade_operation(XMLdata): nontrade_money_operation = XMLdata.find(flows) if not nontrade_money_operation: return try: for child in nontrade_money_operation: comment = child.get('comment') type_oper_match = re.search('||^.+.+.+$', comment) if type_oper_match: company_name = get_company_from_str(comment) type_oper = get_type_oper(comment) dict_flows['stock_name'].append(company_name) dict_flows['account'].append(account_name) dict_flows['date_oper'].append(to_dt(child.get(operationdate)).strftime('%Y-%m-%d')) dict_flows['type_oper'].append(type_oper) dict_flows['result'].append(float(child.get('amount'))) dict_flows['currency'].append(child.get(currency_flows)) except Exception as e: print('get_nontrade_operation --> Oops! It seems we have a BUG!', e)
ستكون نتيجة جمع البيانات من التقارير ثلاثة DataFrames ، وهي تقريبًا ما يلي:
- DataFrame بمعلومات عن متوسط أسعار الصفقات المفتوحة:
- إطار بيانات الصفقة:
- DataFrame مع معلومات حول العمليات غير التجارية:
لذلك ، كل ما تبقى لنا هو القيام باتحاد خارجي لجدول المعاملات مع جدول معلومات المحفظة:
df_result = pd.merge(df_deals, df_stocks_avg, how='outer', on=['stock_name', 'account', 'currency']).fillna(0) df_result.sample(10)
وأخيرًا ، الجزء الأخير من معالجة مصفوفة البيانات هو دمج مصفوفة البيانات التي تم الحصول عليها في الخطوة السابقة مع DataFrame للمعاملات غير التجارية.
نتيجة العمل المنجز هي طاولة مسطحة كبيرة واحدة مع جميع المعلومات اللازمة للتحليل:
df_result_full = df_result.append(df_flows, ignore_index=True).fillna(0) df_result_full.sample(10).head()
يتم تحميل مجموعة البيانات الناتجة (التقرير النهائي) من DataFrame بسهولة إلى CSV ويمكن استخدامها بعد ذلك للتحليل التفصيلي في أي نظام BI.
if not exists('OUTPUT'): makedirs('OUTPUT') report_name = 'OUTPUT\my_trader_diary.csv' df_result_full.to_csv(report_name, index = False, encoding='utf-8-sig')
تحميل ومعالجة البيانات في AWS
التقدم لا يقف ساكناً والآن تكتسب الخدمات السحابية ونماذج الحوسبة بدون خادم شعبية كبيرة في معالجة البيانات وتخزينها. ويرجع ذلك إلى حد كبير إلى بساطة ورخص هذا النهج ، عندما لا تحتاج إلى شراء معدات باهظة الثمن لبناء بنية نظام للحوسبة المعقدة أو معالجة البيانات الضخمة ، ولكن عليك فقط استئجار الطاقة في السحابة للوقت الذي تحتاجه ونشر الموارد اللازمة بسرعة كافية مقابل رسوم صغيرة نسبيًا .
يعتبر Amazon من أكبر مزودي الخدمات السحابية وأكثرهم شهرة في السوق. دعنا نلقي نظرة على مثال بيئة Amazon Web Services (AWS) لبناء نظام تحليلي لمعالجة البيانات في محفظتنا الاستثمارية.
تحتوي AWS على مجموعة واسعة من الأدوات ، ولكننا سنستخدم ما يلي:
- Amazon S3 - تخزين الكائن ، والذي يسمح لك بتخزين كميات غير محدودة من المعلومات ؛
- AWS Glue - أقوى خدمة ETL السحابية التي يمكنها تحديد الهيكل وإنشاء رمز ETL من بيانات المصدر المحددة ؛
- تتيح لك Amazon Athena ، وهي خدمة استعلام SQL عبر الإنترنت بدون خادم ، تحليل البيانات بسرعة من S3 دون الكثير من التحضير. لديه أيضًا حق الوصول إلى البيانات الوصفية التي يعدها AWS Glue ، والتي تتيح لك الوصول إلى البيانات مباشرة بعد اجتياز ETL ؛
- Amazon QuickSight - خدمة BI بدون خادم ، يمكنك إنشاء أي تصورات وتقارير تحليلية "على الطاير" ، إلخ.
وثائق أمازون على ما يرام ، على وجه الخصوص ، هناك مقال جيد
أفضل الممارسات عند استخدام Athena مع AWS Glue ، والذي يصف كيفية إنشاء واستخدام الجداول والبيانات باستخدام AWS Glue. دعونا نستفيد من الأفكار الرئيسية لهذه المقالة ونطبقها لإنشاء هيكلنا الخاص لنظام إعداد التقارير التحليلية.
ستتم إضافة ملفات CSV التي أعدها المحلل اللغوي للتقرير إلى مجموعة S3. من المخطط أن يتم تجديد المجلد المقابل على S3 كل يوم سبت - في نهاية أسبوع التداول ، لذلك لا يمكنك الاستغناء عن تقسيم البيانات بحلول تاريخ تكوين التقرير ومعالجته.
بالإضافة إلى تحسين تشغيل استعلامات SQL لهذه البيانات ، سيسمح لنا هذا النهج بإجراء تحليل إضافي ، على سبيل المثال ، للحصول على ديناميكيات التغييرات في النتيجة المالية لكل ورقة ، وما إلى ذلك.
العمل مع Amazon S3- إنشاء دلو على S3 ، يطلق عليه "محلل التقرير" ؛
- في هذا الدلو "report-parser" قم بإنشاء مجلد يسمى "my_trader_diary" ؛
- في الدليل "my_trader_diary" قم بإنشاء دليل بتاريخ التقرير الحالي ، على سبيل المثال ، "date_report = 2018-10-01" وضع ملف CSV فيه ؛
- فقط من أجل التجربة وفهم التقسيم بشكل أفضل ، سننشئ دليلين إضافيين: "date_report = 2018-09-27" و "date_report = 2018-10-08". نضع نفس ملف CSV فيها ؛
- يجب أن يبدو دلو S3 النهائي "محلل التقرير" كما هو موضح في الصور أدناه:
العمل مع الغراء AWSبشكل عام ، يمكنك القيام فقط بـ Amazon Athena لإنشاء جدول خارجي من البيانات الموجودة على S3 ، ولكن AWS Glue هي أداة أكثر مرونة وملاءمة لهذا.
- ننتقل إلى AWS Glue وننشئ زاحفًا جديدًا ، والذي سيجمع جدولًا واحدًا من ملفات CSV منفصلة حسب تواريخ إعداد التقارير:
- تعيين اسم الزاحف الجديد ؛
- نشير إلى المستودع حيث نحصل على البيانات من (s3: // report-parser / my_trader_diary /)
- نختار أو ننشئ دور IAM جديدًا يمكنه الوصول إلى تشغيل الزاحف والوصول إلى المورد المحدد على S3 ؛
- بعد ذلك ، تحتاج إلى تعيين تردد البدء. بينما نضع الطلب ، ولكن في المستقبل ، أعتقد أن هذا سيتغير وسيكون الإطلاق أسبوعيًا ؛
- احفظ وانتظر إنشاء الزاحف.
- عندما يدخل الزاحف إلى حالة الاستعداد ، ابدأ!
- بمجرد أن يعمل ، سيظهر جدول my_trader_diary جديد في غراء AWS: قاعدة البيانات -> علامة التبويب الجداول:
ضع في اعتبارك الجدول الذي تم إنشاؤه بمزيد من التفاصيل.
إذا قمت بالنقر فوق اسم الجدول الذي تم إنشاؤه ، فسننتقل إلى الصفحة مع وصف البيانات الوصفية. يوجد في الأسفل تخطيط جدول وآخرها عمود لم يكن في ملف CSV المصدر - date_report. ينشئ هذا العمود AWS Glue تلقائيًا استنادًا إلى تعريف أقسام بيانات المصدر (في Bucket S3 ، سمينا بشكل خاص المجلدات date_report = YYYY-MM-DD ، مما سمح لنا باستخدامها كأقسام مفصولة حسب التاريخ).
تقسيم الجدولفي نفس الصفحة في الزاوية اليمنى العليا يوجد زر عرض الأقسام ، عن طريق النقر على التي يمكننا أن نرى الأقسام التي يتكون جدولنا الذي تم إنشاؤه من:
تحليل البيانات
بعد تحميل البيانات المعالجة تحت تصرفنا ، يمكننا بسهولة البدء في تحليلها. للبدء ، ضع في اعتبارك إمكانيات Amazon Athena على أنها أسهل وأسرع طريقة لإجراء استعلامات تحليلية. للقيام بذلك ، انتقل إلى خدمة Amazon Athena ، وحدد قاعدة البيانات التي نحتاجها (مالية) واكتب كود SQL التالي:
select d.date_report, d.account, d.stock_name, d.currency, sum(d.quantity) as quantity, round(sum(d.result), 2) as result from my_trader_diary d group by d.date_report, d.account, d.stock_name, d.currency order by d.account, d.stock_name, d.date_report;
سيعرض لنا هذا الطلب نتيجة مالية صافية لكل تأمين لجميع تواريخ إعداد التقارير. لأن قمنا بتنزيل نفس التقرير ثلاث مرات لتواريخ مختلفة ، ولن تتغير النتيجة ، والتي بالطبع ستكون مختلفة في السوق الحقيقية:
ولكن ماذا لو أردنا تصور البيانات المستلمة في شكل جداول أو رسوم بيانية مرنة؟ هنا يأتي Amazon QuickSight إلى الإنقاذ ، والذي يمكنك من خلاله تكوين تحليلات مرنة بسرعة تقريبًا مثل كتابة استعلام SQL. سنذهب إلى خدمة Amazon QuickSight (إذا لم تكن قد سجلت هناك ، فالتسجيل مطلوب).
انقر فوق الزر تحليلات جديدة -> مجموعة بيانات جديدة وفي النافذة التي تظهر حدد مصادر مجموعة البيانات ، انقر فوق أثينا:
سنخرج باسم لمصدر بياناتنا ، على سبيل المثال ، "PNL_analysis" وانقر على زر "إنشاء مصدر بيانات".
بعد ذلك ، تفتح نافذة اختيار الجدول الخاص بك ، حيث تحتاج إلى تحديد قاعدة البيانات وجدول مصدر البيانات. نختار قاعدة البيانات - المالية والجدول الموجود فيها: my_traider_diary. بشكل افتراضي ، يتم استخدام الجدول بالكامل ، ولكن إذا حددت "استخدام SQL مخصص" ، فيمكنك تخصيص عينة البيانات التي تحتاجها وضبطها بدقة. على سبيل المثال ، نستخدم الجدول بأكمله وننقر فوق الزر تحرير / معاينة البيانات.
سيتم فتح صفحة جديدة حيث يمكنك إجراء إعدادات إضافية ومعالجة البيانات الموجودة.
نحتاج الآن إلى إضافة حقول محسوبة إضافية إلى مجموعة البيانات لدينا: ربع وسنة التشغيل. قد يلاحظ القارئ اليقظ أن مثل هذه التلاعبات كانت أسهل في الجانب اللغوي قبل حفظ التقرير النهائي إلى CSV. بلا شك ، هدفي الآن هو إظهار قدرات ومرونة إعدادات نظام BI على الطاير. نواصل إنشاء الحقول المحسوبة بالنقر فوق الزر "حقل جديد".
يتم استخدام الصيغ البسيطة لإبراز عام العملية والربع:
عندما يتم إنشاء الحقول المحسوبة وإضافتها إلى التحديد بنجاح ، قم بتسمية مجموعة بياناتنا ، على سبيل المثال ، "my_pnl_analyze" وانقر على زر "حفظ وتصور".
بعد ذلك ، ننتقل إلى اللوحة الرئيسية في Amazon QuickSight وأول شيء يجب علينا القيام به هو إعداد مرشح لتاريخ التقرير (مع الأخذ في الاعتبار حقيقة أن نفس البيانات تم جمعها من ثلاثة أقسام). حدد تاريخ التقرير 2018-10-01 وانقر على زر تطبيق وانتقل إلى علامة التبويب تصور.
يمكننا الآن تصور نتيجة المحفظة في أي طائرة ، على سبيل المثال ، لكل ورقة مالية داخل حساب التداول ، وتقسيمها بحسب العملة (لأن النتيجة غير قابلة للمقارنة بعملات مختلفة) وأنواع العمليات. دعنا نبدأ بأقوى أداة لأي BI - الجداول المحورية. لتوفير المساحة وعرض المرونة ، أضع العملة في عنصر تحكم منفصل (تمثيلي للشريحة في MS Excel)يوضح الجدول أعلاه أنه إذا قرر المستثمر بيع جميع أسهم FGC UES الآن ، فسوف يسجل بالتالي خسارة ، توزيعات أرباح مدفوعة بمبلغ 1.509.91 ص. فهي لا تغطي تكاليفها (1،763.36 روبل - فرق سعر صرف سلبي و 174 روبل - ضريبة الدخل الشخصي على أرباح الأسهم). من المنطقي الانتظار والانتظار لأوقات أفضل في البورصة.
الرسم البياني التالي هو مخطط شريطي:والآن سنشكل جدولاً يوضح لنا مقدار ما استثمرناه في كل ورقة ، وعدد الأيام في محفظتنا وما هي الربحية طوال فترة الملكية. للقيام بذلك ، أضف حقلين محسوبين جديدين: sum_investment و count_days.مبلغ الاستثمارsum_investment ( ) :
ifelse({stock_name} = ' 24019',{avg_open_price} * quantity * 10,{avg_open_price} * quantity)
, – ( – 1000).
عدد الحقول_أيامcount_day ( ) :
dateDiff(parseDate({date_oper}),parseDate({date_report}))
يتم عرض الجدول النهائي في لقطة الشاشة أدناه:الاستنتاجات والملخص
لقد فحصنا معك تنفيذ محلل التقرير وطرق تحليل البيانات التي أعدها "على الطاير" باستخدام خدمات أمازون. كما تطرقنا إلى بعض الجوانب التجارية والجوانب الأساسية لتحليل المحفظة الاستثمارية ، مثل هذا الموضوع ضخم تقريبًا ويصعب تضمينه في مقال واحد ، أعتقد أنه من المنطقي وضعه في منشور منفصل أو حتى سلسلة من المنشورات.أما فيما يتعلق باستخدام أداة معالجة تقارير الوسيط والأساليب والخوارزميات المستخدمة فيها ، فيمكن استخدامها (مع التعديل المناسب) لمعالجة تقارير الوسطاء الآخرين. على أي حال ، إذا كنت تخطط لتكييف الشفرة مع احتياجاتك ، فأنا على استعداد لإعطاء بعض النصائح ، لذلك لا تتردد في طرح الأسئلة - سأحاول بالتأكيد الإجابة عليها.أنا متأكد من أن هذا النظام سيجد تطبيقه وسيكون له مزيد من التطوير. على سبيل المثال ، من المخطط أن تضاف إلى حساب PNL الكامل للمحفظة محاسبة الإيداع والرسوم الأخرى (على سبيل المثال ، لسحب الأموال) ، وكذلك سداد السندات ، وما إلى ذلك ... تم استخدام الحقول المحسوبة على جانب Quicksight لأغراض العرض التوضيحي ، في الإصدار التالي من المحلل اللغوي ، سيتم نقل جميع هذه الأعمدة الإضافية إلى Python وسيتم حسابها على جانب المحلل اللغوي.بصفتي مهندسًا معماريًا وعميلًا رئيسيًا لهذا الحل ، أرى ترقية أخرى على النحو التالي: حسنًا ، لا أريد طلب تقارير XML يدويًا في كل مرة! بالطبع ، لا توجد إمكانية أخرى حتى الآن ، ولكن واجهة برمجة تطبيقات Broker مع نقل الرمز المميز ونطاق أخذ العينات ستكون مثالية لتلقي التقارير الأولية الأسبوعية. المعالجة التلقائية الكاملة اللاحقة على جانب Amazon: من تشغيل ETL-job على AWS Glue إلى الحصول على نتائج جاهزة في شكل رسوم بيانية وجداول في Amazon QuickSight ستسمح لك بأتمتة العملية بالكامل.يمكن العثور على شفرة المصدر الكاملة في مستودع GitHub الخاص بي