为纪念数据模式和反模式的科学项目工件

视频记录

大家好,感谢参加今天的会议。我是德里克希金斯。我我们的企业数据科学团队高级总监蓝十字蓝盾的伊利诺斯州、蒙大拿、新墨西哥州,俄克拉何马州和德克萨斯州。我和我的同事在Sonjia Waxmonsky。和我们的高级数据科学家。我们想和你今天一点谈谈一些实践来存储构件与数据科学相关项目。所以我们在周围的几个不同的组织数据科学空间——一些较小的组织中,一些更大的组织,我们看到团队倾向于组织项目的工件。一些好的实践和大量的实践,是复制也许不是好主意。但我们进入之前,让我告诉你一点关于我们作为一个组织。所以我们蓝十字蓝盾的伊利诺斯州、蒙大拿、新墨西哥州,俄克拉荷马州,和德州,我们蓝军之一。 These are health insurers who do business under the Blue Cross / Blue Shield trademark. But we’re a little bit unique among these Blues in a couple of ways. For one thing, we’re a pretty big health insurance company. We’re the 4th largest private insurer in the Unites States. We insure 1 in 12 American adults. But also because we are a not-for-profit insurer. So we are owned by our members, so we certainly have a financial incentive to control costs and ensure that we use our members’ premiums wisely. But we also put alignment with our member’s interests otherwise, ensuring that they get good access to care and support in the communities in which they live. Okay. So the first type of pattern I wanna talk a little bit about is one in which we see there’s really not even one place where the whole project lives. There’s really not even a central repository or starting point for looking at what constitutes the data science project. So, some of you have probably had conversations that go a little bit like this where you’ve got some team that you work with.

代码碎片

也许你做建模,这个团队工作数据管道,并提供输入。有一天你看到事情已经改变在某种程度上这是令人惊讶的。所以你接触到团队中的人谁负责,你说,“你能告诉我一点关于这个变量是否有些事情已经改变了吗?似乎有点不同了。”,他们会说,“嗯,我们做了一些改变。我们总是做出改变。但是没有任何结果的,我们认为应该给你。”“好的,但是你能告诉我究竟发生了什么?什么变化?”,那么如果你够幸运,你可以让他们发邮件给你一份代码或代码今天存在的快照。或者你有一个类似的对话在另一边有一个团队,是消费的输出模型,它们以某种方式显示给用户。 But the display isn’t exactly what you expect. So you reach out, say, “Can you tell me exactly how you are rolling these scores up to be shown in your dashboard?” “Well, it’s the average.” “Okay, well, the average, but is it the average of all scores in a day, or average by members in a day?” “Uh, not sure. Let me get back to you when I get the right answer for that.” So these are both kind of frustrating conversations, right? Because there’s some dependency between your project or your code and other teams, but you can’t get immediate ground truth or you can’t get transparency about how your code is operating in it’s larger context. This will not be surprising to those of you who are familiar with Conway’s Law. So Conway’s Law says, “Any organization that designs a system, defined broadly, will produce a design whose structure is a copy of the organization’s communication structure.” And in Data Science, often our teams look something like this — where there’s a data science team that does the modeling and some other things. There’s an adjacent data team that develops data pipelines. There’s a front-end team or an application team that takes the outputs of the model and embeds them in some user base in the application. And maybe there’s an infrastructure team that supports all these teams. And if you have four teams collaborating together on this project, you’re gonna end up with four different ___ And this leads to all sorts of problems as we’ve seen. We’ve got the inefficient way of communicating between teams with this manual interface where you gotta reach out by Slack or by email or whatever the tooling is that your company prefers. It’s hard to reproduce results end-to-end that involve the pieces that were developed by different teams. In general, big challenges for governance and for quality assurance.

从这样的情况,我们想摆脱它。我们想搬到一个情况,我们有了更多的透明度。我们可以了解其他地区的组织。那里有一些版本的代码,我们可以状态依赖的其他存储库的版本,我们依靠。还有,你知道,最大的群体之间的互操作性。但这并不容易,尤其是在更大的组织。首先,不同的团队可以有不同的工具链。如果一个团队是在Python和前端工作团队是在Java脚本,它可以很难的谈判。特别是考虑到不同的团队可能会有不同层次的技术规格。所以它可能并非易事,即使它的,原则上,可能,可能不容易一些团队采用一种不同的语言或采用一套不同的工具来完成他们的工作,一旦他们已经有了一个过程。 There may be teams that don’t write code at all. They really just use GUIs or manual processes to produce their outputs. So you can obviously make it very difficult to have their process codified in a place that’s transparent. And, of course, even if we can solve all of these technical issues, there are other reasons why it might be difficult for teams to converge around a more transparent solution. You know, some teams may not have incentives to actually move towards transparency.

所以,如果我们能对齐努力朝着这个目标,不同的战术应用而言,如何实现它。

策略

我们可能会决定,“好吧,让我们的代码的所有这些不同的团队,把它放在一个地方,把它放在一个共享库,例如,一个GitHub库,但这很难做。特别是在大型矩阵机构有一定程度的地坑。也许一步短的一种方法是使用松散耦合,而不是一个常见的存储库,有多个存储库,一个仍然与每一个团队,但至少一个版本计划在每一个团队,这样他们可以联系。在一些组织中,也不可能的。但至少我们可以争取的最低限度是有住的地方的代码可以被发现。地方——你知道,组织内部的公共场所,和有一些文档代码在哪里,周围的人是谁联系的问题。

好的,嗯。另一种模式我想讨论的是,而不是一个存储库本身,我们使用一个文件夹在推动地方我们存储项目的位置和它的所有工件。

所以,你们中的一些人可能是由于我工作的管理角色,收到这样的邮件过去。这是一封电子邮件,我在最近的过去,当一个员工离开组织。基本上说,“嘿,这个人已经离开,他们有一堆东西的电脑。你能通过这并决定看什么是重要,什么可以扔掉吗?“不幸的是,这是数据项目有时,往往从一个人到另一个地方。叶子一个人或一个人变得忙于一个新项目,和他们所有的东西在一个文件夹的地方上了新的面向人,这样他们就可以得到的。

自然,应该是这样,因为你知道,一个文件夹是一种我们已经存储项目工件的时间和纪念肯定在数字时代开始之前。这是一个文件——一组文件夹组织层级结构放在我的桌子上,我使用管理家务管理项目。它有东西关于我的公寓,和关于医疗问题的东西在我的家人和家里的改进有关的东西。这是一个自然的方式来存储项目信息。它的灵感——非常明确的一些机制在地方今天在电脑上存储的信息。这图实际上是由巴纳德从1958年的一篇论文&费恩描述分层文件系统ERMA Mark 1系统设计。也许,这取决于你相信谁,第一层次的计算机文件系统。你可以看到从图中很明确建模在纸上文件夹,我们用来存储信息,并根据类别组信息。

问题:缺乏版本控制

但当我们把这个类比隐喻和翻译成数字世界,我们采用分层文件夹的局限性为不必要的项目组织。在数字世界中,我们可以做得更好,但是——(清理喉咙)在采用这一策略,我们把一些不必要的限制。例如,版本控制的缺乏。文件夹不支持版本控制的文件,通常。经常,我确信你们中的一些人已经看到项目组织,这张截图所示,你有不同版本的一些脚本,有人写了,因为文件系统并不直接支持版本控制,作者试图硬塞进一些版本控制的通过添加后缀文件名,”。“v1。”贝克”、“。最后,“也许添加一些文件的日期做某种特别的版本控制。即使我们有支持某种形式的版本控制的文件系统,例如,SharePoint或S3 bucket,通常它不跟踪你真正关心的东西——谁改变?为什么他们要作出这些改变?

当然,第二个问题是,如果您正在使用一个文件夹在你的光盘存储所有与该项目相关联。

问题:灾难性故障

和你的代码,你的数据,所有的文档等,它与你的电脑生活和死亡。如果你的笔记本掉你的自行车上下班,如果你有一个灾难性的系统故障,如果你把你的笔记本电脑无人你不应该的地方。你可能会失去你所有的工作,它不见了。

和使用文件夹来存储项目工件的第三个问题是,它不是好的合作。所以,如果你的项目数据生活在您的机器上,没人会发现它的存在,除非你告诉他们。即使他们知道问你,没什么可以做从合作的角度来看。你可以电子邮件的副本代码时,他们可以使用。但是当他们实际使用和改进它,使它适应新环境,没有一个简单的方法来得到他们的贡献的回到你的工作只是一个不可调和的分数。

所以你可能会说,“哦,这些都是限制使用文件夹在我的本地驱动器上存储数据,但是共享驱动呢?如果你使用共享驱动器可能会解决所有的问题。”,它解决了一些问题,但我认为它实际上让一些其他问题更糟。所以谈论灾难性故障的风险,如果你的代码共享驱动器上,暴露于整个公司或团队中每个人。用户正在越多,机会越多是有人无意中删除或者改变一些东西的方式并不是目的。当你谈论更大的开发团队,其中一些版本控制按照惯例,添加日期等等,这只是会分解。它不会工作。另一个,我想,更多的小问题如果你使用一个共享驱动器上的合作,你必须连接到您的VPN,您的组织的网络所有的时间如果你想使用这段代码,可以限制。

保存项目文件在哪里

所以,当选择某个地方来存储工件与存储库应该是版本,文件存储应该有弹性,这样你就不会失去你所有的东西,应该是透明的,让人们找到你的代码或找到你的项目构件和支持在不同团队间的合作。

所以,你知道是什么版本,透明的,并支持协作?GitHub。

所以很多团队使用GitHub——一种中央门户网站与他们相关的存储库用于存储工件。但是你绝对可以走极端。我们看到人走极端。一旦他们了解Git,他们意识到的一些好处,他们倾向于过度使用的东西真的不适合。我们只是给出了一个例子,我相信你们都熟悉TensorFlow——大神经网络库由谷歌支持的。(最近我)-清理喉咙克隆TensorFlow存储库到我的机器上。如果你这样做,大约500 MB的数据。我花了10分钟我的家庭网络。可以理解的,因为它是这样一个大型项目有这么多分支和贡献者。但也有其他项目在GitHub肯定不如TensorFlow复杂,没有独立的人尽可能多的贡献,但大得多。 So I found one, uh, name obscured here to protect the guilty, that is a relatively simple data science project, but because it contains a lot of image data it’s about 2 GB in size, took like 40 minutes to clone this repository into my local machine on my network.

在GitHub是什么?

所以,什么属于GitHut而言,我们肯定想把代码的东西在里面,往往是小,他们改变很多人逐步发展,他们是人类可读的。如果你显示文件的两个版本之间的差异,他们会被人们可以回顾和思考,并确定他们是否有意义。所以的例子,像任何一种代码,数据管道,程序代码的建模、基于文本的配置文件,你写的脚本设置hyperparamaters建模运行。减价的适当格式的文档。事情不要在GitHub将二进制文件的事情,往往是非常大的,不会改变很多。所以例子显然不适合Git存储库将序列化模型,我们的培训脚本的输出。我们训练我们的机器学习模型的数据。然后任何形式的中间文件生成的粗运行我们的数据是否转换版本数据或编译后的可执行文件。,总是会有一些类型的边界情况,我们可以争论。我有很多很多讨论笔记本电脑和笔记本是否真的属于GitHub或者应该是别的地方。 They’re kind of like code, you can to some extent get a meaningful gist of two versions of a notebook. But then they’re also — they also present some of the same challenges that we have with the things on the far right of the slide where they can be large if they have embedded visualizations and images. They can also potentially contain sensitive data and the output (indistinct) So, you know, we can continue to discuss these edge cases.

当我们把事情真的不属于这里的GitHub而言,我们的数据科学项目,我们遇到一些类型的问题。一个,再一次,这是不利于合作。当需要半个小时克隆一个Git存储库,这是砂光的齿轮。另一方面,它可能导致生产部署的问题,如果我们有很多东西在我们的仓库,应该有,我们仓库的臃肿,这样会导致结构问题,如果我们想说,部署到一个AWSλ,它可能是太大了。可能会有敏感数据存储库中不适合在生产环境中。最后,有些会集成挑战,如果我们有一些状态保存在存储库,如数据集的状态,可以成为符合管道的其他部分,我们的系统中运行。你遇到的问题。因此最好使用GitHub的东西真的擅长。和不需要滥用这样在任何情况下。真的有更好的解决方案。 Some better solutions in the Databricks platforms. So, specifically, delta lake is a great way to version data sets, you can store different versions of data and access them by timestamp, so identify the state of a data set at a given point and time. And then on the compiled model side, or serialized model, there’s the ML Flow model registry that allows us to train, identify, and then deploy models from our machine-learning code. And there are other solutions as well, so get large file storage if we really, really wanna use GitHub as our central entry point our data science project, then we can link other types of data to that repository Git large file storage. And there are also solutions through cloud providers. S3 and other cloud storage services do support some sort of versioning for larger files, and might be a good compliment to what’s available in GitHub. Okay. So with that, I’m gonna hand the baton off to my collaborator, Sonjia. – So Derrick just talked about ways to organize our data science projects, and some of the pitfalls of not taking steps to do this organization in advance. Next, I’m gonna talk about how we use our code and our repost to store an important output of our projects. Which is the analytics decisions we make based on our data.

所以,是什么意思分析决策?数据科学家,我们经常编写代码嵌入隐藏的配置和参数。

隐藏的配置——建模

这包括建模参数,过滤器,我们穿上我们的人口,阈值,决定我们将如何聚合和返回数据。通常,这些参数不是给我们的业务。相反,它们来自我们自己所做的研究数据。例如,观察一个年龄分布设置一个阈值。我认为这真的使编程数据科学不同于一般的软件工程。作为数据科学家,我们常常首先探索数据集以特别的方式,我们发现和结论。然后我们把我们所学到的知识构建代码,进入了可再生的管道建模和得分。

发现和EDA作为一个产品oo

这分析——分析我们可以采取许多形式。这可能包括标准建模步骤像相关分析,或评估变量趋势随着时间的推移和填充率。或者,我们可能需要理解数据模型或故事了解我们的数据来了解我们的最终用户和他们的问题。现在我可以说,我已经工作了许多年的项目,我也继承了其他团队编写的代码,和许多不同的格式。,我知道了,有必要将勘探作为一个一流的工作产品。这意味着它应该记录,记录为未来的读者如果我们需要解释或调试这些决定,我们对我们的配置,然后我们有一个为我们的研究起点。有时我将回到我自己的EDA,六个月前我做了我自己,我回顾一下我学习和我能救自己的工作时间和理解我遇到的特定问题。这是一个笔记本的例子是由一个数据科学家写的我的一个项目。这是在做相关分析,他救了他的工作在他的结论和他写清楚地描述他所做的。现在我有一个方法来解释为什么我们决定我们做这个项目,为什么我们把特定的变量。 And I also have a way to rerun what he did if our data set changes. So, as Derrick mentioned, there’s different options for doing work on a shared environment. GitHub supports notebook rendering, so we can put these types of notebooks into GitHub, and this has the option also that it’s pinned to our code directly. The Databricks environment also has a shared notebook workspace that has the advantage that teammates can look at each other’s work even if they’re working in different clusters.

现在,让我们讨论下一阶段建设的科学数据生命周期模型和存储所有的输出结果的建模过程。所以这也是一个步骤,真正重要的是认识到的人将来会从事其他项目,谁会继承我们的工作。

建模输出——局部作用域

所以通常当我们开始建模,我们开始工作在一个笔记本,所以这是一个交互式的环境。我们可以调试,我们可以回顾,我们可以想象我们返回的数据。但是缺点在一个笔记本的当然是只有局部作用域。每当我们出口,我们做的事——不管模型中构建记忆丢失,然后我们真的已经离开的是笔记本的输出。所以我们能够表明,我们建立了一个成功的模式,但当有人走过来说道,“嘿,你能申请到这个新的数据集?你能申请2020个成员的人口吗?“我们真的没有办法,我们必须回去从头开始。那么,好吧,那么我们如何把我们的模型投入生产?嗯,这是一种做法的一个例子。这里我们有一个逻辑回归方程的代码粘贴到我们的生产续集,系数已粘贴到我们的代码。 And so this, I think that everyone who works in the insurance industry has had to do something like this at least once. And this actually is fine for a GLM, but as we move more towards more machine-learning methods, we do need a different approach.

建模与MLflow跟踪

具体地说,我们有事情我们必须像hyperparameters缓存,我们必须序列化模型,这样他们就可以被应用到未来的数据。我们仍然还想存储测试指标,可能存储训练数据集和其他我们可能的输出。存储所有的这一切,它允许另一个数据科学家或另一个数据科学团队离开的地方,将我们的工作继续项目的时候需要。所以有不同的方法来保存这些类型的工件。毫升流例如Python API,可以直接从建模被称为脚本。但什么是最重要的,不管我们用,我们可能需要花时间去考虑将来继续这个项目。我们只需要最终二进制吗?我们必须拯救我们的训练数据集吗?如果他们很难牧师或创建数据时可以依赖。同样重要的是,允许空间来保存这些细节在建模过程。 To take the time to tag our code, or to use a model registry to callout when we’ve reached a checkpoint model that we want to save and share and possibly apply to other data sets in the future.

这里有一个例子的网格搜索和Mlflow建模。和你看到的是我有一种方法来检查我们所有的实验,比较hyperparameters和模型输出。结果存储在一个中央位置可以很容易地共享一致的格式与其他数据科学家。

当然模型参数或模型hyperparameters不是唯一杠杆和抵消我们在我们的项目需要调整。当我们应用模型可能需要,在生产中,我们可能需要调整日期范围,我们的观点不同的文件存储如果我们从开发到生产环境中。所以我们会有很多不同的参数,我们可能需要调整。有许多不同的工具和方法,我们可以做这种类型的定制。但通常我们要做的是把所有这些不同的参数,把它们放在一个中央位置所以很容易看到在未来可能需要编辑。所以我们可以不用回到我们的代码回购和修改代码来支持这个。所以一种简单和普遍的理解和命令行参数的方法是,我们也可以使用YAML或(模糊)配置文件,并使用配置文件允许我们有多个并发的配置。如果我们可能工作在不同的机器上,但无论我们做什么,这是很重要的考虑会发生什么。当然,很明显,我们不能预测所有可能需要改变,这是一个现实的给最终用户模型,他们总是要回来的新方法切片的数据我们没有不过的。但总的来说,这就是为什么我们的目标是组织良好的和透明的代码。 So that these changes can be done fairly quickly. Just as an anecdote, recently at Blue Cross/Blue Shield, we built a COVID-19 risk model. And this was something that — the first version was done fairly quickly, in about three weeks. And then after we deployed it, we decided to expand what we did to a larger member population. And the second model, one data scientist on our team was able to do that in about three days. And the reason all that was possible is because that we had done our original work in a way that was well-documented, and modular and transparent. And she was able to take the pieces and put it together. So overall, that’s kind of the goals that we have for this project this is kind of what we would like to convey, that our projects are well-documented and they’re transparent. And they put the work we do that’s successful today and deployed today on a path where it’s easy and well-maintained and can be picked up by others in the future. Okay, so yeah. Thank you for listening to our talk. We hope that these ideas were helpful.