深度对话Monte Carlo的CEO,这家新独角兽要做数据基础设施的Datadog|阿尔法讲故事
阿尔法公社
━━━━━━
阿尔法公社说:在应用程序领域,监测和维护基础设施的需求已经得到部分满足,人们努力确保程序是可靠的,不宕机的,当程序出现错误,工程师也有工具辅助定位错误出在哪儿。
在数据领域,人们努力打造最佳数据仓库、数据湖,最佳ETL、最佳BI软件等等,但能够帮助数据工程师和数据分析师们确保自己使用的数据是正确可靠的,如果出问题能定位问题出在哪个环节的工具还很少,而2019年创立,目前估值16亿美元的新晋独角兽Monte Carlo正试图解决这类问题。
随着世界上越来越多的公司依靠数据来获得竞争优势,数据基础设施需要变得完全可靠。在应用程序领域,监测和维护基础设施的需求已经得到部分满足,还诞生了Datadog这样的标志性领导者。那么谁将成为数据基础设施领域的Datadog?少数数据初创公司已经开始进入擂台,Monte Carlo无疑是这个群体中最引人注目的公司之一。Monte Carlo自我定位为一个端到端数据可观察性平台,旨在通过消除数据宕机时间来增加数据可信度,让工程师可以更多关注创新,减少花在解决数据错误上的时间。它创立于2019年,2年内完成了4轮融资,最近一轮是由IVP领投的1.35亿美元的D轮融资,公司目前估值为16亿美元。专注在现代数据技术栈投资的投资人Matt
Turck对话Monte Carlo的CEO 兼联合创始人Barr
Moses,就数据观察的可操作性和一般的数据基础设施世界进行一场有趣且有启发的对话。以下是对话实录:Matt Turck:Barr Moses是数据可靠性公司Monte Carlo的CEO和联合创始人,Monte Carlo被定位为业界第一个端到端数据观察性平台,创立于2019年夏天。它还是很年轻的公司,但在该领域很热门,也获得了风投的支持,在20 个月内共获得2.36亿美元融资,目前估值16亿美元。Barr,我们先从一个有趣的地方开始,你的推特ID是bm_datadowntime。BM显然指你名字的首字母,但是这个数据宕机时间(data downtime)很有趣,什么是数据宕机时间,为什么它那么重要?Barr Moses:当我们刚开始创办公司的时候,发现数据可观察性、数据宕机时间的概念对大家来说很陌生,行业对这个领域的认知仍处于早期阶段。我们在成立之初就思考,数据团队目前面临的最大问题是什么?我花了好几个月的时间,与从Uber、Netflix和Facebook这样的大公司到小型创业公司的数据团队进行了数百次对话,就问他们一个问题:“什么让你睡不着觉?” 我得到了各种不同的答案,但谈到有件事大家都会不约而同地在谈话中开始出汗以及不自觉目光移动,这个事情就是数据宕机。这是几乎所有从事数据工作的人都会遇到的问题,造成它发生的原因可能是一些数据产品,比如一份报告,一个数据集或你网站上的数据。这些数据使用者的身份可能是高管、CMO、销售团队,也可能是正在使用你的服务的实际客户。这些数据的下游使用者经常遇到错误的数据。数据错误的原因可能是因为数据不是最新的,也可能是因为上游修改之后下游没有调整。它可能对数百万的用户来说是错误的,这让人们感到不安,人们对数据宕机非常不满。我们收集了巨量的数据,非常渴望能够直接应用我们拿到的数据。但事实上,这些数据里掺杂了很多错误,这真的很令人沮丧。Matt Turck:你是否有类似的例子,证明数据错误不仅给人造成困扰,而且导致了非常严重的后果?Barr Moses:当然有,比如有公司向华尔街报告数字,不小心报告了错误的数字或差点报告错误的数字,这种情况可能比你想的要多。福克斯是我们的客户,他们需要转播超级碗这样的重大事件,他们在追踪这些相关活动的很多信息:比如有多少用户正在使用,用户在哪些内容和终端设备上花费时间?这些数据的准确性是非常重要的,因为决策是基于这些数据实时做出的。另一个例子是Vimeo,一个拥有超过2亿用户视频流媒体平台。他们使用数据,并在整个新冠疫情期间使用数据来确定新的收入来源,同时针对他们的用户进行实时决策。假设需要为一个客户推荐他喜欢的内容,并且根据他的需求动态的分配带宽,如果没有获得正确的数据,就很难为用户提供足够良好的体验。我们经常从客户和其他人那里听到,一个事件可能使企业面临数百万美元的风险。Matt Turck:这些例子都特别好。那么,数据宕机的概念进一步引出了数据可观察性的概念。你能解释一下那是什么吗?Barr Moses:从顶部开始,公司和数据团队已经在他们的数据基础设施上投入了大量资金。我们在数据基础设施公司的崛起中看到了这一点。例如,Google的BigQuery有15亿美元的收入,Snowflake有10亿美元,Databricks有8亿美元,而且还在加速增长。因此,企业正在大量投资建设最佳数据基础设施,包括最佳数据仓库、数据湖、最佳ETL、最佳BI、最佳机器学习。同时有完整的团队负责提供数据产品,包括数据工程师、数据分析师、数据科学家。这些数据产品可能是像我们谈到的数据报告,可能是一个在生产中使用的特定数据集,也可能是各种不同的东西。这些团队的任务是提供可信赖的数据产品,但这个真的很难做到,因为数据实际上会经常出错。为了解决这个问题,一种方法是实际看看这个问题在软件工程中是如何解决的?软件工程师实际上有一个类似的角色,那就是确保他们正在建设和设计的基础设施和网络应用程序以及其他软件产品是可靠的,不宕机的。为了确保这一点,在DevOps中已经有了围绕可观察性和软件的发展。有很多现成的解决方案,如Splunk、Datadog、App Dynamics和New
Relic,多年来一直在帮助软件工程师确保他们的产品是可靠的、安全的、易于访问的。所以,如果我们提问把这个概念引入数据世界里会是什么样子?这就是我们所说的,“数据工作流虽好,但是数据不够准确。”数据可观察性这个术语的想法来源是根据一个系统的输出来推断它的运作状况。在软件的可观察性中,有一套追踪指标,有最佳实践案例,有SLA,有可用性。我们把所有这些好的内容移到数据上,作为数据可观察性概念的一部分。我们经常遇到的问题是,“可观察性在策略上到底意味着什么?我们应该真正追踪和测量什么?”在软件可观察性中,这是很常见的,而数据可观察性还没有明确。因此,我们制定数据可观察性的五个支柱的框架,以真正解释一个数据团队应该关注什么以进行自动化、仪器化、监测和分析,帮助我们增强数据可信度。Matt Turck:让我们继续讨论这个问题。这五个支柱是什么?Barr Moses:这个含义的核心是人们可以在实际运营中信任自己的数据,放心应用,这是我们做这个事情的目的。我们不是因为数据可观察性是一个很酷的热词才去实施它。它实际上是有作用的,那就是让人们在数据工作流中可以信任自己使用的数据。这有三个核心部分。第一是检测,需要实际了解数据何时中断,并成为第一个发现的人。第二是解决,一旦知道有问题,如何快速解决它?第三是预防,我们相信,通过制定这些最佳做法,你能够减少你数据宕机事件的数量。Matt Turck:这就是你们所说的数据可靠性生命周期?Barr Moses:是的。这就是我们开发生命周期的方式。数据的可观察性帮助我们在检测部分了解有哪些不同的方式可以检测到这些问题。这就是五大支柱的作用。五个支柱是从数百次关于数据中断的常见原因是什么的对话中总结出来的。我们整合了那些原因,涵盖了80%的内容,因此在使用的初始阶段它就有效果。首先是实时性。新鲜度是指数据的时效性。你可以想想电子商务公司,甚至是金融科技公司,它们依靠接收成千上万的数据源。你如何追踪,确保这数以千计的数据源确实按时到达?必须有一些自动的方法来做到这一点,但这是一个数据中断的常见原因。第二是数量。这是很直接的,你会期待从数据源收到大量的数据,它到底有没有到达?第三是分布,分布是指在字段级。假设有一个信用卡字段正在被更新,或者一个社会安全号码字段被更新。突然它显示出来的内容是字母不是数字,这显然有问题。所以你需要在字段层面上进行测试。第四是架构。架构的变化是造成数据宕机的一大罪魁祸首。通常情况下,工程师或其他团队成员都会对架构进行修改。也许他们添加了一个表,改变了一个字段,改变了一个字段类型,而下游的人不知道发生了什么,突然间一切都出问题了。这种情况一直在发生。因此,第四就是自动跟踪数据架构的变化。第五是我最喜欢的,溯源。我们刚刚发布了一篇博文,介绍我们是如何进行字段级和表级的追溯的。基本的想法是,你是否可以自动推断出数据仓库中的一个特定的表所有的上下游依赖关系,并使用它来理解一个数据质量问题的影响?假设一个特定的表没有收到任何数据,但没有该数据的下游用户。那它可能并不重要。但假设有30个报告需要用到它,或者这个数据每天都会用到,这个数据被用于营销活动,以确定定价,确定折扣。在这种情况下,解决这个问题就很重要。反之亦然,溯源也可以帮助我们了解某个特定问题的根源。因此,假如有一个表没有收到数据,或者它有一个问题,而在上游的某个地方有一个架构变化。我希望那个事件发生的时间与那个数据宕机事件相近,这样我就能真正推断出对那个问题的根本原因并理解这个问题的影响。这就是数据可观察性的五大支柱。Matt Turck:我们有一个来自小组的问题,“数据可观察性对于不同的应用,对于不同的数据模式,结构化与非结构化,实时与历史,是否意味着不同的事情?”Barr Moses:是的,一般来说,数据可观察性这个术语的目标是把它应用于所有的数据。显然,它有不同的含义和不同的数据类型。特别是如果你考虑到非结构化数据和结构化数据。所以在数据栈中,肯定有很多不同的变化正在发生。我们的信念是,你需要能够信任你的数据,无论它在哪里,无论它是什么类型的数据。我们花了很多时间在数据仓库和商业智能上,这是我们开始的地方。我们的想法是,为了建立强大的数据可观察性实践,它必须包括一个概念,称之为端到端。意思是包括你数据的位置,从获取到使用的所有过程。人们一直在努力弄清堆栈中某个特定位置的数据质量。比如,只是在获取时或少数的数据集上。实际上,我认为这种方法已经不再适用。数据的本质是它的流动变化,新的团队成员每天都在添加新的工作流。因此,只有工具流的一个点是不能确保你的数据是准确的。如果你真的在考虑强大的数据可观察性实践,它必须是端到端的。令人沮丧的是,很难从一开始就获得这种准确性或正确性。但这是我认为数据团队应该努力实现的愿景。随着我们对不同类型的堆栈和不同类型的数据的可观察性的标准化,这将变得更加容易。Matt
Turck:谈到团队成员,你如何看待数据可观察性的人文方面?谁拥有这个?是工程师,还是商务人员?你如何在新兴的数据网格的背景下考虑这个问题?Barr Moses:我认为对于不熟悉数据网格的人来说,在一个非常高的水平上,它是一个在数据行业引起风暴的概念,而且尚在讨论中。Matt
Turck:数据的所有权,让不同的团队拥有完整的数据体验,把他们正在做的事情作为一种服务提供给其他人。因此,财务团队拥有整个数据堆栈,并将其作为一项服务提供给组织的其他部门,这公平吗?Barr Moses:是的,这是完全正确的。归功于Zhamak创造了这个术语,并将其普及。我们在一些公司看到了一波又一波的去中心化行动。通常情况下,人们会从去中心化开始,转向集中化,再回到去中心化。但一般来说,使数据去中心化和自助服务的想法是我们经常看到的。这必须作为数据在组织中普及的一部分而发生。所以,在过去,如果你只有两三个人在处理数据,你可以让它集中化,这会起作用。你可以用数据工作,检查它,整个工作流就跑起来了。在今天,一个大公司有数以百计的人在处理数据。只有一个团队掌握着数据的核心这件事已经没有意义了,最后只会形成一个瓶颈。我观察到我的客户有这样的现象:如果他们和自己的数据团队想一起完成一些事情,经常必须等待一年,以便他们完成所有的优先事项。这就是很多数据团队的现实。他们必须等待数月或数年才能完成一些事情,这对于一个想让大量团队真正获得数据的组织来说是没有意义的。你问到了关于人们参与的部分。很多时候,我们看到的是一个数据平台。在一个数据平台中,使用数据的可能有数据产品经理,数据工程师,数据分析师或数据科学家。然后公司里的其他人也在使用这些数据,包括销售、营销、客户成功、产品EPD等。在这些情况下,我认为数据网格是有帮助的,它引入了自助服务的概念,这实际上是非常强大的。因为在这个概念中,数据平台团队实际上是负责建立可以为所有这些团队使用的东西,而不是成为一个瓶颈。因此,当涉及到所有权时,这是一个非常激烈的话题。同样,在宕机时间的概念和数据网格的概念中,我认为数据网格在这里引入了一些概念,使其更容易,因为自助服务意味着有一种像共享的责任。事实上,我们经常谈论RACI矩阵,RACI拼写R-A-C-I,明确责任(responsibility)、问责(accountability)、咨询(consulted)和告知(informed),这里没有一个适合所有人的良方,但数据团队可以好好想想:谁对数据质量负责?谁对仪表盘负责?谁负责数据治理?谁负责每个不同的项目,并实际制定出团队如何合作的规则。Matt
Turck:我很好奇Monte Carlo如何进行销售?比如,谁是你的买家?Barr Moses:我们的使命是通过帮助减少或消除数据宕机时间来加速世界使用数据。因此,这意味着我们与数据团队合作,帮助他们减少数据宕机时间。通常情况下,与我们合作最密切的是数据工程师和数据分析师,因为他们大多是负责数据工作流或确保数据真正准确的人。与他们合作的消费者包括数据科学家或不同的团队,如营销团队或嵌入其业务部门的分析团队,他们可能会使用这些数据。因此,在这种情况下,例如,营销团队的人可能会有这样的问题:“我应该使用哪个数据集,或者我应该使用哪个报告,它是否可靠?”所以你也许可以用Monte Carlo来回答这个问题,但我们的主要用户是数据工程师和数据分析师。Matt
Turck:我们想聊一下产品。让我们从你如何连接到各种数据源或数据堆栈的各个部分开始。我有读到过你们有数据收集器,那是如何工作的?Barr Moses:正如我提到的,我们非常相信端到端的可观察性。关于我们谈到的所有这些事情,最酷的是格式——这不仅仅是市场营销的说法。实际上,我们的产品是围绕着它建立的。Barr Moses:我们非常相信在客户的数据堆栈中拥有端到端可观察性。从云数据仓库、数据湖和BI解决方案开始,我们实际上是市场上唯一的产品,客户可以连接到这些不同的系统,并自动得到他的数据健康状况的概述,以及他的数据在我们之前谈到的指标或变量上的可观察性。Matt
Turck:这是最重要的,客户连接,并且把数据仓库或数据湖的只读访问权给Monte Carlo?Barr Moses:是的,所以我们的系统是基于API的,不自己摄入或处理数据。我们基本上需要只读访问,比如说Snowflake和Looker。然后,我们所做的是收集元数据和关于你的数据的统计数据。收集元数据,如一个特定的表是多久更新一次?比如,每小时更新三次。我们收集该表的时间戳和元数据。比如谁在实际查询它?它被使用的频率是多少?哪些报告和BI依赖于它?我们也开始收集关于数据的统计数据。所以我们可能会重点关注某个字段的分布,会看一下某个字段、某个表的百分比和所有值。最后我们重构溯源,在没有任何输入的情况下,解析查询日志,在表一级重建所有的上游和下游的依赖关系。我们不仅在一个特定的系统(如Snowflake)内这样做,也在整个商业智能中这样做。我们可以覆盖从 Snowflake(数据仓库)到 Looker(商业智能,数据智能平台)的全流程。我们所做的是将这些信息与你的数据健康状况重叠在一起,例如,把各个视图放在一起,观察到:“上游的某个东西改变了,导致Snowflake的一个表现在没有准确的数据,这导致所有这些表的下游受到影响,导致Looker中的这些视图现在也有错误的数据。”因此,你可以有这种端到端的洞察。Matt
Turck:所以,你整合了数据仓库,数据湖,BI系统,以及DBT。这也是整合的一部分吗?Barr Moses:我们不久前刚发布了自己的第一个DBT集成,它是连接ETL、转换、协调的一部分,我们也在研究Airflow的集成。Matt
Turck:听起来你们现在是以现代数据栈为中心,部分想法是进入堆栈的其他部分,特别是机器学习堆栈,功能存储和实时,这是Kafka世界的一部分?Barr Moses:是的,就像我提到的,可观察性在这个意义上是没有区别的。数据需要在任何地方都是准确的,不管是什么堆栈。所以,我们从云和现代数据栈开始,但问题确实存在。对于传统的堆栈,对于机器学习模型,问题也100%存在。从现在起的3年、5年、10年来看,我认为这个问题实际上会在所有这些方面加剧,而不仅仅是一个方面,因为人们正在越来越多地使用他们的数据,对这些数据有更高的要求,有更多的人提出这些要求。因此,这个问题(数据宕机)肯定会渗透到所有地方。Matt
Turck:因此你连接到所有的关键系统,得到数据输出,对它进行统计。你如何确定是否有问题或不存在问题?Barr Moses:事实上,我们用机器学习来确定。我们推断一个健康的基线是什么样的,并根据历史数据进行假设。我们使用历史数据点,收集这些数据,推断、预测,未来应该是什么样子,然后用它来让你知道什么时候出现了问题。举个实时性的例子,假设我们在一个星期内观察到有一个表,每天早上6点被你的CEO使用,这个表在白天每小时更新两次,但在周末不更新,然后在星期二,它突然停止了更新。因为我们已经知道,该表在工作日期间应该每天更新两次,如果它在星期二中午没有更新,就可以认为可能有一个问题,或者至少你想知道发生了什么。很多时候,有趣的事情是,即使一个变化不是所谓的数据宕机,数据团队仍然想知道这个问题,因为它与他们的预期或他们想要的有偏差。因此,有时这个变化是被刻意设置的,但数据团队想确认他们所做的刻意变化是否是成功的。实际上,还有很多东西需要改善关于数据宕机的沟通:这有一个问题,但是这个问题的影响是什么?我应该关心它吗?谁应该解决这个问题?我怎么知道问题发生的根本原因是什么?以及我如何从一开始预防这个问题?如果我们在这里强调数据可观察性,让人们看到这些东西,并考虑对这种情况做出改变,大家实际上可以从一开始就减少数据宕机。Matt
Turck:在这方面使用机器学习很有趣。几年前,Datadog的Olivier Pomel也谈到,在Datadog,他们很晚才开始使用机器学习,而且是特意这样做的,这在很大程度上是基于规则。部分问题是机器学习的噪音和可能导致的误报。你是如何考虑这个问题的?让人们控制他们收到的紧急警报的类型,而不是由机器预测的东西?正如我们所知,机器学习是很好的,但它终究是一门还不完美的科学。Barr Moses:总的来说,我们必须感谢过去几年的技术和观念进步。我认为溯源在自动化和手动输入之间存在着平衡。过去,大家倾向于100%的手动输入,有些公司仍然这样做。我们不相信这一点。有一些方法可以将其自动化。但在某些领域,客户可能只有一个人,例如,首席执行官需要在早上6点看一份报告,这意味着在5点50分,所有的东西都必须是最新的。这是一个机器永远不会有的业务规则,我们很难将这种业务背景自动化。所以我认为这是一种平衡。我认为,今天的团队和组织,以及我在开始Monte Carlo之前的情况是,我们没有太多的耐心。人们没有几个月的时间来启动和看到产品的价值。实际上人们希望在几个小时的时间内看到价值,而不是几天,几个月,几年。当然,我们希望确保我们发出的每一个警报都是真正有意义的。但同样,如果你考虑到发送警报的背景,数据泛滥和造成疲劳实际上是很容易的。但是,如果你考虑一下这样的场景,这里有一个警报被发送,然后有受这个警报影响的所有人,还有其他同时发生的相关事件。这个警报很有可能对组织有更多意义。如果你只是在看数据随时间的变化和指标,那就很容易碰到很多噪音。但是,如果你有认真在看:我们是否在操作这个?我们是否在利用一个检测并从中做一些有意义的事情?我们是否将该警报发送给正确的团队?我们是否在正确的时间、正确的背景下将其转发?然后,它使这些警报实际上更加丰富和可操作。因此,对我们来说,这就是我们所做的大部分事情,如何确保每一个警报都是真正有意义的,能够推动行动?老实说,仅仅获得大量的警报而没有其他的东西是不够的。我们必须远远超越,以帮助数据团队的工作真正变得容易,而不仅仅是收集越来越多的信息。Matt Turck:你们有一个数据目录,也有非常酷的洞察产品,它们是如何工作的?Barr Moses:回到我们要解决的最重要的事情,那就是确保你可以信任你所使用的数据。一部分是知道数据何时中断,另一部分是防止数据中断。当考虑到信息的类型,我们拥有你的系统如何被使用的信息,这可以让我们有很多发现。我们发布了洞察力产品,作为帮助数据团队更好了解数据系统的一种方式。我与客户通话时,有人会说:“我刚刚加入公司,我对我们的数据生态系统一点都不了解。有两个工程师什么都知道,但他们离开了。我需要了解我们的溯源和数据的健康状况,以及数据从哪里来,哪里是重要的数据,例如什么是关键资产。”我们做的第一件事是帮助数据团队知道什么是他们的关键数据资产。因此,要识别那些被使用得最多,查询得最多,团队有最多的依赖性的最重要的表格或最重要的报告。这就是一个洞察力的例子。这个产品来自这个想法:如何能在公司拥有的庞大信息的基础上产生洞察力,使数据团队更容易实现他们正在构建的这些数据产品?这是你问题的第二部分。你问题的第一部分是关于目录的作用。我们不久前写了一篇博文,叫做数据目录已死,数据发现万岁,显然是一个有争议的话题。我们的想法是,通过数据发现或以自动化的方式来了解:数据在哪里,你应该访问什么数据,这是越来越多的数据团队面临的问题。当人们问自己,“我要开始使用数据了工作了,我怎么知道应该使用哪些数据?哪些数据可以真正信任?这些数据是从哪里来的?”实际上这些真的很难回答,除非你有那个几周前离开的工程师,知道所有的答案。因此,真正了解什么是我们发现数据的更好方法,什么是使人们更容易访问正确数据的更好方法,是我认为对许多数据团队真正最重要的领域之一。Matt
Turck:今天最后一个问题来自观众,想问一下团队相对于竞争对手的核心差异化和持久优势。是整合的套件,专有的时间序列模型,CXL领域的重点还是其他?Barr Moses:这个问题的差异化是指相对于竞争对手而言?首先我想说的是,我们很荣幸能够成为数据可观察性类别的先驱,并引领它。我认为现在是这个领域的大好时机。而且我对它的未来也很兴奋,这是肯定的。在差异化方面,我认为一个强大的数据观测平台是很重要的,无论是Monte Carlo还是其他平台。所以这可能是一个很好的总结。第一是你的堆栈的端到端覆盖,我认为这一点非常重要,因为数据的可观察性并不是从某一个地方开始或停止的。第二,思考五个关键的支柱和自动化的问题。深度思考一下自己如何拥有一个能带来最大收益的平台,靠自动化吗?第三是数据质量和数据流的结合和交叉。这些都是我们看到的非常重要的东西,而且实际上能够使其成为可操作的--数据观察能力。最后一点是围绕警报疲劳,我们也提到了。我认为使警报有意义,使你的团队能够真正采取行动,这是非常难做到的事情,我们已经投入了大量资源来做。所以我想说,我会考虑任何数据观察解决方案的这些核心能力。nback="static" style="margin: 0px;padding: 0px;outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;line-height: 0;font-size: 0px;display: inline-block;vertical-align: bottom;user-select: none;inset: auto;">nback="static" style="margin: 0px;padding: 0px;outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;line-height: 0;font-size: 0px;display: inline-block;vertical-align: bottom;user-select: none;inset: auto;">阿尔法公社(Alpha Startup Fund)是中国领先的早期投资基金,由曾带领公司在纳斯达克上市的许四清和前创新工场联合管理合伙人蒋亚萌在2015年共同创立。阿尔法公社基金的三大特点是系统化投资、社交化创业者社区运营和重度产业资源加速成长。专注在半导体、企业服务软件、人工智能应用、物联网技术、金融科技等科技创新领域进行早期投资。目前已经在天使轮投资了包括白山云科技、领创集团(Advance Intelligence Group)、Zenlayer、帷幄科技、所思科技等为数众多的优秀项目。BP请投递到:bp@alphastartups.net,7 天内快速收到回复,直接约见资深合伙人。
特别提示:本信息由相关用户自行提供,真实性未证实,仅供参考。请谨慎采用,风险自负。