首页 > 数据分析 > 使用DSX Jupyter notebo 来分析GitHub数据

[悬赏]使用DSX Jupyter notebo 来分析GitHub数据 (已翻译83%)

查看 (208次)
英文原文:Using DSX Jupyter Notebooks to Analyze GitHub Data
标签: 数据分析
admin 发布于 2018-02-01 13:33:48 (共 6 段, 本文赏金: 20元)
参与翻译(2人): 廿九_ lightfish 默认 | 原文

【已悬赏】 赏金: 1元

IBM数据科学体验(DSX)为任何软件开发人员提供了丰富的功能,特别是那些对数据科学感兴趣的软件开发人员。该功能的一个重要部分是使用笔记本,这是一种方便而直观的方法,可以划分代码库的不同部分。

廿九_
翻译于 2018-02-02 11:27:07
 

参与本段翻译用户:
廿九_

显示原文内容

【已悬赏】 赏金: 3元

使

IBM Watson数据平台(WDP)集成团队管理各种服务的系统验证缺陷,并利用GitHub的“问题”特性跟踪每个缺陷的状态、细节和任务。目前,我们没有办法量化团队每周的活动。每个服务每周有多少缺陷被打开、关闭和处理?这些问题有多严重?

在本文中,我们将探讨如何跟踪和展示特定开发团队每周活动的高级概述。其目标是从GitHub收集原始数据,对其进行组织和排序,然后以一种有意义的方式想象它。在分析了有关服务缺陷的组织数据之后,观察者可以对团队和代码库进行有针对性的推断。该程序是在Watson机器学习(WML)的积极开发过程中开发的,它将反映在下面的示例图表中。


廿九_
翻译于 2018-02-02 11:29:36
 

参与本段翻译用户:
廿九_

显示原文内容

【已悬赏】 赏金: 5元

收集信息

该程序从Python笔记本中开始,它从GitHub检索缺陷信息,解析数据,并将其存储在云表上的三个单独的DB2Warehouse中(每个集成团队被分配给每个服务)。

下面的代码显示了将数据从元组推送到数据帧,以及一个云表更新上的DB2Warehouse示例。



# Put those tuples into dataframes that will be pushed to the dashDB tables (note the WML service is the only one that has pipeline info recorded) 
# Pipeline info is updated through our JavaScript program on the Fyre server, since we cannot access ZenHub from the DSX due to firewall restrictions
sparkSession = SparkSession.builder.getOrCreate() 
df_catalog_data = sparkSession.createDataFrame(catalogdatatuples).toDF("NUMBER", "TITLE", "LINK", "ASSIGNEES", "COMPONENT LABELS", "SEVERITY LABELS", "CREATEDAT", "CLOSEDAT", "TIMESTAMP")
df_DSX_data = sparkSession.createDataFrame(DSXdatatuples).toDF("NUMBER", "TITLE", "LINK", "ASSIGNEES", "COMPONENT LABELS", "SEVERITY LABELS", "CREATEDAT", "CLOSEDAT", "TIMESTAMP")
df_WML_data = sparkSession.createDataFrame(WMLdatatuples).toDF("NUMBER", "TITLE", "LINK", "ASSIGNEES", "COMPONENT LABELS", "SEVERITY LABELS", "CREATEDAT", "CLOSEDAT", "TIMESTAMP", "PIPELINE")
from ingest.Connectors import Connectors
# Writing to catalog table in dashDB 
targetOptionscatalog = { 
  Connectors.DASHDB.HOST : credentials["host"],
  Connectors.DASHDB.DATABASE : credentials["db"],
  Connectors.DASHDB.USERNAME : credentials["username"],
  Connectors.DASHDB.PASSWORD : credentials["password"],
  Connectors.DASHDB.TARGETTABLENAME : 'DASH107803.CATALOGISSUES',
  Connectors.DASHDB.TARGETTABLEACTION : 'replace'
}
df_catalog_data.write.format('com.ibm.spark.discover').options(**targetOptions_catalog).save()

多亏了DSX,我们才能安排这个项目每小时运行一次并更新一次。该表将保持最新,最低限度的维护所需。单击DSX笔记本中的时钟图标来设置SCH编辑工作:


一旦你安排了一个笔记本,你就会在你预定的工作中看到它。这些作业显示在项目的“概述”部分:

廿九_
翻译于 2018-02-02 11:32:46
 

参与本段翻译用户:
廿九_

显示原文内容

【已悬赏】 赏金: 6元

清洁和可视化信息

一旦所有缺陷数据被聚合,一个单独的笔记本就会提取出这些信息,并按严重程度对其进行排序,并绘制我们想要看到的信息。



# Pull info from dashDB table and load it into dataframe df_WML
targetOptionsWML = {
  Connectors.DASHDB.HOST : credentials["host"],
  Connectors.DASHDB.DATABASE : credentials["db"],
  Connectors.DASHDB.USERNAME : credentials["username"],
  Connectors.DASHDB.PASSWORD : credentials["password"],
  Connectors.DASHDB.SOURCETABLENAME : 'DASH107803.WMLISSUES_DATA'
}
dfWML = spark.read.format("com.ibm.spark.discover").options(**targetOptionsWML).load()
dfWML = dfWML.replace(["severity-high", "severity-medium", "severity-low"], ["3", "2", "1"], "SEVERITY LABELS")
dfWML = dfWML.orderBy(["CLOSEDAT", "SEVERITY LABELS", "NUMBER"], ascending=[True, False, False])
dfWML = df_WML.replace(["3", "2", "1"], ["severity-high", "severity-medium", "severity-low"], "SEVERITY LABELS")

由于GitHubRESTAPI,我们可以使用每个缺陷的创建和关闭日期。有了这个,我们就可以创建刻录图表。下面,您将看到我们正在分析的三个服务中的一个的图表示例。x轴包含每周工作中的一个滴答,我们绘制了每个滴答的三个数据点:打开的缺陷数量,关闭的缺陷数量,以及在一周结束时仍然打开的缺陷数量(待办事项)。除了刻录图之外,该程序还生成一个图表,以显示每个严重级别的待办事项处理中的缺陷计数。





整个笔记本被推送到GitHub(DSX提供的另一个方便的特性)。然后,我们的Web服务器直接从GitHub存储库中提取笔记本,并将其整齐地显示在网页中。


在所有这些完成之后,排序后的数据将被发送到外部Web页面(通过云表上的DB2Warehouse),并且我们能够使用它来执行其他有用的活动,比如生成图形和表格,列出关于每个缺陷的具体细节。

廿九_
翻译于 2018-02-02 11:36:27
 

参与本段翻译用户:
廿九_

显示原文内容

【待悬赏】 赏金: 4元

Under the Hood

There’s a lot of cross-platform communication going on behind the scenes. Information needs to be extracted, parsed, externally stored, transferred, and re-parsed. Here’s a graphic to show the flow of these two programs:

  1. Make a request from the Node.js server to get the pipeline information of all the issues on the ZenHub boards.*
  2. Sort the pipeline data and put the information in a Db2 Warehouse on Cloud table.*
  3. Get a list of issues from GitHub and parse the relevant information (issue created date, label, severity, and more) into tables.
  4. Push the unsorted GitHub data to a Db2 Warehouse on Cloud table.
  5. Get the defect data from the Db2 Warehouse on Cloud table, sort it, and generate the burn down table. Plot the burn down data on a graph using matplotlib.
  6. Save the burn down data points to a Db2 Warehouse on Cloud table.
  7. On the web page, retrieve the burn down data and defect tables from Db2 Warehouse on Cloud. When a user makes a request on the front end, deliver this information.
  8. Push the Notebook to GitHub as a Gist. This Gist link is embedded into the web page. When the notebook is updated on GitHub, the web page automatically displays that new notebook.
  9. Additional visualizations are made on the web page once the data has been retrieved.
* Steps one and two would be merged with step three if not for some issues we ran into regarding interactions between IBM’s firewall and the different services we were making API requests from.

共1人翻译此段 (待审批1人)


参与本段翻译用户:
lightfish


【已悬赏】 赏金: 1元

结论

最后一个产品包括两个Python笔记本、四个云表上的DB2Warehouse,以及一些托管在IBM提供的Fyre服务器上的JavaScript代码。

IBMDataScience经验已经证明是该项目开发的一个非常有用的资源,它将继续提供用户友好、部分自动化的维护。

 


廿九_
翻译于 2018-02-02 11:37:29
 

参与本段翻译用户:
廿九_

显示原文内容

GMT+8, 2018-7-23 00:41 , Processed in 0.043003 second(s), 11 queries .