vibehacker.fm
Eng Cafe
January 24, 2021
EN
Data Engineering at Uber and Lyft
程序员喝咖啡的时候都谈论些什么？探讨Uber和Lyft的数据工程实践，大规模数据平台的架构设计与技术挑战。
Also on 小宇宙
0:00
0:00
1x
Transcript
Auto-scroll ON
0:00
欢迎大家来到Edge Cafe,我是主播星杆,我是主播Maggie,今天我们请到了在Lift工作的我们的朋友李全来,欢迎他来到我们的节目,请他来给大家做一个自我介绍吧,大家好,我是全来啊,我是之前在Uber工作,现在在Lift工作,不过两个工作的那个内容有些区别啊,我在Uber做的是Data Infrastructure Engineer,在Lift做的是Data Engineer,
0:25
Data Infrastructure其实也是Sub Engineer的一个分支,但是Data Engineer可能在很多情况下不是,所以我们今天也可以比较比较这两个公司,以及比较比较这两个不同的职位的区别。
0:41
你说你是在Uber和Lift都在做Data Engineering是吧?
0:48
在Uber那个叫做Data Infrastructure Engineer,就是它其实是属于Software Engineer,或者叫Data Platform Engineer,就是说我们做的东西是一个Platform,这个Platform比如说那个specifically就是Piper,或者后来改名叫YouWork,那么就是这个东西它其实是属于我们做的是一个Platform,然后让别的人去使用它,对吧?
1:15
然后呢在Lift更像是做Data Engineer就是去使用那些Platform的Engineer,当然就是Data Engineer属于一个比较新的领域,那么在不同的公司它的定义是不一样的,比如说Data Engineer在Uber其实基本上没有Data Engineer的这样的一个称谓,就是只有Data Scientist和Software Engineer,就是说我Data Scientist我要做一个Pipeline,那就我Data Scientist自己去做,而在Lift呢它把这两个职位分开了,
1:43
就是说我Data Scientist我只用去写一个Query,然后Data Engineer负责去负责提升这个Query的一个稳定性啊,或者是把这个QueryProductionize,就好像像有些公司它会分那个Site Reliability Engineer,对吧?SRE,然后Software Engineer,那在有的公司就不分,就是说你自己你写的程序你就得负责它在Production运行环境中的一个部署,对吧?
2:12
所以我觉得Data Engineer就有点像那个Data领域的SRE,就是说我去把这些Data部署,我去把这些Data Pipeline部署到Production,遇到的问题我要去解决,那么在有些公司这些完全是Data Scientist去做的,就是说我写了Query我就要负责把它在Production领域中做好,所以这是不同的公司对于这个职位的区别。
2:37
我记得Facebook公司有很大的一个Data Engineering的组,然后Lyft也有一个相对比较大的Data Engineering的组,但是可能在其他公司不一定有类似的这些样的岗位。
2:49
OK,所以你在Uber的时候就等于是Platform Provider,Provider给的那些Consumer是Data Scientist,你在Lyft就相当于做Consumer那端的活,那能不能说一下就你的印象中在Uber或者在Lyft处于这两端每天Day-to-Day的工作内容和方式有什么样的区别?
3:13
对,那么就比如说,我说Piper可能大家不太懂,但是我说Airflow可能会有更多的人去懂,就是其实是类似的东西,就是叫做ETL Platform,就是负责Data的这个获取,然后Transformation,对吧,和Loading,当然其实还有可能更多的像什么Management,Ownership Management,然后Security之类的附加的一些功能。
3:37
那么我在Uber就主要去负责,就是说我要去给这些ETL去加新的Feature,去给它加新的Integration,比如说在Uber的时候有很多人要写Machine Learning Pipeline,对吧,那么之前他们可能要写很多的Boilerplate,就是要写很多的复制粘贴性的一些代码,甚至要去做很多的Configuration,比如Hive Configuration,那么这些东西其实并不是必要的,
4:05
那么我们最后就做了一个Integration,就是说你这个东西你只要你在你,首先就是说你只要在Production Test过了以后,就只要去看Query,这样的Query在Production Test过了以后,我们可以直接把它搬到Production,然后后来做了更多的Integration,就是说你只要在你的Local Environment Test成功的话,那我们就可以把这个东西我们进行一些相应的,比如说设置的一些变化,当然就很多东西需要Parameterize,
4:34
比如说你的这些Schema Name,这些东西肯定在Local Environment和Production Environment是不一样的,那么我们就需要做相应的变化,然后放到Production Environment里,那么这个就相当于大家提高了Production,就是相当于提高了这些工作效率,比如说我原来我要去管Production的各种环境的设置,然后作为Data Science,其实他们不一定很懂,那么现在他们就只需要去管他们的Query了,所以做的会更方便一点,
5:02
然后另一个东西就是说我们要去部署这些Pipeline到Production Environment里面,那么部署的话其实有很多的部署的办法,尤其是就是这个Pipeline Repository,如果大家在用的话都知道其实你有成百上千个Data Scientist,然后Operation,就是Ops,那么这些东西,这些人他们就是时时刻刻都在做Big Commit,也就是说你时时刻刻都要去Deploy,那么怎么样让这个Deploy的效果更Efficient,
5:32
其实是一个,我觉得是一个挺有系统,就是更偏Computer System的一个和Networking的一个东西,就是说我可能有几百个机器,就是我们等会会聊到Airflow的价格,其实和Pipeline是类似的,那么我们有这么多的机器,我们如何就是让,
5:50
那么比如说我们整个Pipeline Repository可能有比如说一千,可能有几个Gigabyte,怎么样把这个东西我去Deploy到一千个机器上面,这其实不是一个容易的事情,因为如果我们都做Gateway,Gate Pool的话,其实那个Gate Server它不能支持这么大的一个流量的,对吧,
6:15
所以那么我们就得想其他的办法去把这些东西Deploy到机器上,我觉得这个东西当时做的还挺有意思的,然后最后其实我们做的那个速度其实是比原来快了很多,原来可能是二十多分钟,最后我们做的就是只要三分钟就可以Deploy到Production,所以还挺有意思的。
6:36
这个是之前在Uber做的提高Data Pipeline Deploy效率的一些Improvements。
6:44
对对,然后其他的包括我们有做Security的,因为就是其实Data Pipeline它可能不像你写Code,你写Code会有一个,就是比如说假如说出了个问题,然后我就可以去查Gate Committer到底是哪出了问题,那么假如说你一个Table里面,你有一些数据出问题了,
7:03
那么目前来说没有一个Industry Standard,就是说这个数据到底是谁插入的或者说谁修改的,那么我们就想做一个东西,就是说我们要给一个Accountability to这个东西,对吧,所以我们就说首先就是谁写数据,那么我们都要写数据要有一个Ownership,然后就是Table要有一个Ownership,然后要去Import这些东西。
7:26
其实Hive它有相关的这些功能,但是就是因为实际情况就很多人他没有Configure这个Permission,Ownership,所以很多人就是大家都用的是那些Root Level的或者是Admin Level的那些东西,我去写这个数据,所以其实有时候会造成一点混乱,但是可能在一些小一点的公司他们会没有那么在意这个东西,但是就是公司稍微成长一点。
7:52
对对,所以公司成长了以后你就要注意,这个Table只有比如说只有Financial Team的人可以去写,对吧,然后另一个Table可能你只有这个做那个Driver Incentive的Team可以去写,然后谁可以去读这些都要去做仔细的一些Configuration,那么包括在Pipeline,就比如说你写了一个Pipeline,那么我可不可以把那个Current Off,在目前的Airflow里面应该还是可以的,对吧,你写一个Pipeline,过几天一看,诶,怎么不写了。
8:22
没有数据了,然后最后后来发现不知道被谁Turn Off了,那么那么我们呃,我在Uber做的一个工作就说啊,我要确认你到底有没有这样的一个Trend,包括你离职了,你离职了以后这个Pipeline Ownership会谁,我们就会有一个相应的一个机制,就是说你离职以后Pipeline Ownership会自动变成你的老板,然后你的老板再可以Assign给亲人,比如说Assign给Maggie,对吧,呃,所以其实有很多这样子一方面的考虑,就是说呃,我们会把这个一条的管理给它更加细致一点,对吧,所以其实有很多这样子一方面的考虑,就是说呃,我们会把这个一条的管理给它更加细致一点,对吧
8:52
然后会有更加,呃,就是呃,更深度Granularity的一个管理,嗯,所以你们的产品并不是只是Data Scientist在用,就是Engineers也都可以来写Query,来Query你们的产品,是吗,然后那关于这个权限是不是就是分一些DB Groups,哪些组有什么样的权限呢,对,对,但是就是呃,第一是这个权限,它是比较复杂的,因为就是说呃,我我首先有Unix的Unity,我首先有Unix的Unity,因为就是说呃,我首先有Unix的Unity,
9:23
然后我还有Hype的UserName,对吧,呃,然后就是我们首先要做一个一对一的Match,就是说你的Unix的UserName和Hype的UserName,
9:30
包括你的邮箱这些,它们是不是一对一的,有很多情况下它们不是一对一的,然后包括就是说你的那个呃,就是包括你的什么TeamName,然后这些呃,东西它很有可能是就是并没有一对一的一个Matching,
9:46
我们就是要有一个系统去给它们把这些呃,不同的系统之间的权限,呃,然后都要去统一一下,对吧,呃,然后就比如说你在Unix的情况下,或者说呃,你要去访问一个AWS S3的一个File,对吧,那它又需要另一个Credentials,呃,然后你去访问Hype的东西,它需要一个Credentials,那么我们就需要就是通,比如说我现在有你的UnixName,
10:12
然后我就去去发一个请求到Hype的一个Server,然后去找到你的Hype的Credentials,然后在你的HypeCredentials去做一个Query,呃,所以就是说它的这个在不同的系统中,其实它的这些呃,Credentials是不一样的,所以我们要去做一个Credentials的Management,呃,包括就是呃,那你Hype的这个Credentials可能一个小时就Expire了,对吧,那么我们要给你自动去呃,相当于自动续费吧,就相当于自动更新。
10:41
如果你的Query没有跑完,然后你Hype的Credentials又Expire了,那你可能就是这个Query就会Fail了,我们就去自动去给你更新,对吧,呃,所以所以这些这些有很多细节的东西,呃,还是需要去仔细处理的。
10:55
呃,然后关于我们的这个用户,嗯,嗯,我们的用户主要还是,呃,在Uber的时候主要还是Data Scientist,呃,呃,有一些Engineer就是他们如果要做呃,和那些Data相关的东西,呃,他们也可以去,嗯,用这个,呃,去用这个Pipeline,然后我们的当然是我们就是这个它的功能很多,就是说它不光是可以Schedule Data Pipeline,就你可以Schedule其他的什么呃,
11:25
像什么Python Task或者是那个Bash Task,呃,那么你把Python Task和Bash Task,就是说如果你,呃,做其他的东西需要去Schedule一些东西,它不一定和Data相关的,但是,呃,你也可以去用这个Pipeline去做,只不过就这样的use case可能会少一点。
11:45
嗯,那,呃,就我们刚刚说是Data Pipeline,你从拿数据到,呃,Pipeline这一层,那,呃,生产数据,比如说Client Side的Event Production,这一部分会有能Track Owner或者Specification的吗?
12:02
比如说Client App,在App里面,UI Engineer和iOS Engineer,他们Implement Tracking,那这个Event Send Back to Server,这一部分有没有一些能够Track谁来Implement这个Event,谁来从Event的Derive Data,谁来写的Tracking Spec,这方面你有接触过吗?
12:22
嗯,对,这个东西,我觉得如果是,呃,从UI方面呢,他们可能就是会有一个Streaming Service,对吧,可能是Kafka或者Kinesis,呃,然后在这里面,你,呃,应该是,呃,你可以在比如说Kafka Topic里面,你会设置一个,呃,Field,比如说是Owner of this,呃,Owner of this,然后呢,呃,之后你就可以去,呃,检查就是这个,呃,比如说这些数据到底是谁Create的。
12:51
或者是User ID之类的东西,呃,所以就是说,呃,那这些东西最后呢,他们会流向不同的Data Sync,对吧,那么比如说他会,呃,假如说流向Hive了以后,那么流,流到Hive啊,或者是流到DynamoDB啊之类的东西,那么这些Database,我们再去通过这个,呃,我们再去通过Piper或者Airflow去调用,那么我们也会知道这些的Ownership。
13:17
当然,就是说,还有一个就是说,你在Create这些Database的时候,你就其实本来就应该Create一个,呃,相应的一些,就是Owner,对吧,呃,CreateDatabase的语句的里面,你可以设置它的那个,呃,权限是什么,呃,只不过可能现在有些公司他不一定会做这个东西,比如说在这层目前应该是没有这个东西,就是说大家,我的这个Table谁都可以用,但有的公司他就比较喜欢Transparency,对吧,他就说,这个数据其实应该是大家都可以用的。
13:48
呃,有的公司可能会更希望大家去控制这个Ownership。
13:54
那在关于一些比较Privacy的数据的时候,你们也会有比较保护他们吧?
13:59
对,对,我觉得比较重要的一个是GDPR,然后还有一个,呃,是,呃,我忘了叫什么,呃,ABC还是叫什么Compliance,呃,GDPR就讲的是,呃,欧洲的用户,他们需要删除一个数据的话,我们就需要,呃,给这个数据脱明,对吧,比如说某某某某数据是Thomas的,但是Thomas说我现在要删除我的信息,那么我们在Thomas的这个Record里面,
14:29
呃,应该是我们要把他的那个,呃,姓名,包括就是敏感信息,包括姓名邮件,呃,电话号码,呃,甚至地址这些我们都要删除,但是我们有些东西我们又要去做Record Keeping,所以这个东西会稍微复杂一点,呃,但这个东西主要还是从另一个系统去做的,呃,而不是我们来做,呃,然后还有一个就是说,还有一个就是,呃,ABC Compliance应该是说公司上市的时候,上市公司的话,
14:58
他的那些,呃,财务状况,呃,不能,呃,全公司的任何人都能看到,就只能特定的人才能看到,那么在这种情况下,呃,我们就其实还是要给一个数据加上Ownership,就是说,呃,加上这个,这样子的话,比如说我去访问一些,呃,Financial Data,我就会被block住,呃,是这样子的。
15:21
嗯,对,一般,呃,就刚刚讨论这个问题,一般有几个方式,一个是要Data Obfuscation,呃,Data Obfuscation,就是说,呃,公司里大家能query的数据会分两种,一部分是我可以query到PII Data,这种需要有Owner权限,另外一种是我把数据跟个人信息相关的部分给它抹除掉,你看到的是完全匿名的信息,这部分是一般Engineer或者Data Scientist的,呃,权限。
15:51
可以访问的一些数据,还有一个technique是你要去hash PII Data,所以当用户因为GDPR,他要求删除我的数据的时候,你能够根据他的User ID,能够找到哪些数据是需要删除的,但是你看到这个数据的时候,你并不能知道这些数据是属于哪个人的,所以这也是一些,呃,在Data方面会用到一些technique,呃,还有一方面是,呃,比如说LinkedIn的Data是会做在Schemas,
16:21
我们要annotate某一个Field,它是属于PII Data,哪一个Field是跟PII无关的,那你再从,从这个Data的Schemas,derive出另外一个Schemas的时候,它就可以知道我的继承关系,我是不是继承了一个PII Data,如果是的话,那我这个Field自动的也是成为PII Data,之后再做数据抹除,或者再做aggregation的时候,有的会有相应的处理,这是我们公司的一个处理方式。
16:51
嗯,对的,对的,我觉得可能,呃,呃,很多公司会用类似的办法,就是基本上就是说,如果就是我需要办法可以写数据,到底,嗯,一些Column,它到底是不是敏感的Column,如果是敏感的Column的话,那么它的权限会更紧,对吧,然后,而且就是说这些敏感的Column,呃,在derive的Data里面应该也属于敏感的Column。
17:14
是的,呃,那,呃,刚刚也说,就有些Uber做的Lift不太做,呃,当你从Uber跳槽转转到Lift工作之后,你也从Platform转到Data Engineer,呃,就这个转变对你来说,每天日常工作的方式和内容组的组成结构之类的有什么变化,你们谈一下感受吗?
17:39
嗯,我觉得就是,呃,做Data Engineer的话,我在Lift做Data Engineer,可能更多的就是还是会偏Operations,或者就就好像我之前说的SRE,从Cycle Engine转到SRE的话,呃,就是说,每天的工作,我觉得好像会,呃,单调一点,就是说,我,我,我保证Production的东西,呃,运行完善,然后我自己需要,呃,去写一些新的Pipeline,但是,呃,总体来说,写Pipeline,它的技术含量其实不是特别的高,就是说,我写Pipeline,
18:09
呃,其实就影响于本来是Data,就是在Uber是Data Science也可以做,对吧?那么在Lift是,就是,呃,要多一个Data Engineer这个role,那么总体来说,它其实,呃,技术含量并不是那么高,然后呢,除此以外,就是需要去解决一些,呃,这些,呃,Data Query出现的Production Issue,呃,在很多情况下,它们是,可能是Hive Issue,呃,然后或者是不同的Database之间的Issue,然后呢,还有就是要确保,就是一个Pipeline,
18:39
Pipeline它的Upstream和Downstream,呃,的这种,呃,稳定性,对吧?还有可能就是说,我,我们某某Table A source from Table B,那么Table B它不稳定,比如说,我们知道它每天8点的时候,它就有,呃,前一天的数据,对吧?
18:54
呃,那么,我们的这个要求,它不一定会满足,它可能就是隔三差五的会出问题,那么,呃,比如说,我们要求Table B每天8点的时候获得有前一天数据,这样子,我们Table A在每天12点的时候有前一天的数据,那么,这个Dependency就会出问题,呃,所以就是,我们要去有,就有一个很,在有些Table,有些比较重要的Table,就会有很,比较重要的那些,呃,Scheduling,就是说,你,你必须要保证你,呃,所谓的SLA,对吧?
19:24
呃,我们必须要保证这个protocol是完善的,那么,有时候不完善的话,我们就会考虑,那如果Table B老是出问题的话,我们就要去换一个Table,或者说是我们就需要Escalate,呃,所以我们会经常会有这种的,就是,呃,对SLA的各种的分析,呃,然后包括,呃,我们自己也就是,也会去,呃,尽量保证我们自己的Table,就是非常的reliable,然后要去做各种Data Quality Check,呃,然后要去做各种
19:54
各样的,就是,呃,怎么说呢?就是Performance Improvement,呃,可能这是我们比较常做的一些新的东西,那,那这种维护性的工作的所占用的时间比例大概是多少呢?占用你总的工作时间的比例,我觉得可能去年的话会占的比较多,可能会有40%左右,今年呢,稍微少一点,呃,就是我们自己也得improve就reliability,今年可能会占在20%左右,20%到30吧,呃,然后还有就是
20:24
呃,其他的,包括我们自己去做那个自己去写Pipeline可能也会占用一些时间,然后包括就是我们对Pipeline的设计,我觉得这个也会很重要,就是说你设计一个稳定的Pipeline,然后它需要去从比较稳定的那些,呃,数据源去获取数据,不是说啊,我这里看到一个Table,我觉得它里面的数据很有用,我就用了,但它的数据可能是隔三差五更新一次,或者说它里面的数据就是可能它的那个误差会比较大,因为我们在做这些Data的东西都不可能
20:54
达到百分百,百分之百完美,可能比如说它有百分之零点一的duplicate,会有什么数据,这些这些可能都会影响我们对于这个source table的选取,啊,然后甚至就有时候你你没办法,就是你没办法找到一个,呃,可以给你,呃,就是既有高质量quality,然后又有你想要的数据的一个信息,对吧,假如说啊,我想知道某某乘客他的,呃,当然,但现在就大部分我能想想到的可能是已经high quality
21:24
了,但比如说我想知道某某乘客,他可能我会给一些乘客有一个什么所谓的信用分,对吧,那么那么可能这个信用分他不一定很准,就可能是一个很守时的乘客,然后他从来不cancel他的信用分,可能没有那么高,那么就是说data set的quality也是一个我们要考虑的一个因素。
21:43
嗯,那你是怎么知道一个数据源或者一个data set它的quality是怎么样的?你是去直接ping owner问你这个data quality,你觉得如果还是有一些metric能去评估,一般来说就是说它会有一个tier,就是service tier,就是有像有一点像那software里面的service tier,那么tier 0就是我们可以保证就几乎是那个非常好的quality,tier 1就是说可能稍微差一点,然后之后的就是说不保证tier,就比如说,呃,我们可以保证就是几乎是那个非常好的quality,tier 1就是说可能稍微差一点,然后之后的就是说不保证tier,就比如说,呃,我们可以保证就是几乎是那个非常好的quality,tier 1就是说可能稍微差一点,然后之后的就是说不保证tier,就比如说,�
22:13
我只是一个data scientist,我就随便create一个table,我拿来玩,然后就是我可能就是create,比如说我就跑了一次,然后之后就不管了,那它就就不是tier 1,tier 2,呃,甚至tier 2都不算,tier 2就是说我至少还是得有一定的保证,那可能就是我只是随便去做一个analytics,对吧,所以service tier是一个比较重要的,然后还有就是看owner,就是owner如果是一个data engineer的话,我们会更相信,呃,如果是data scientist的话,
22:43
我们就会犹豫一点,呃,然后如果是其他人的话呢,我觉得就基本上就是,呃,就基本上不能用,我觉得是这样子,嗯,啊,这这部分非常有意思,因为我现在在做的就是annotate data tier,我现在在做的就是作为data producer那一边怎么去定义这个tier,呃,那你刚刚也说tier 0,1,2,那不同的tier具体来说是有哪些影响不一样,比如说,呃,可能那是quality of service,呃,那可能那是quality of service,呃,那可能那是quality of service,呃,那可能那是quality of service,呃,那可能那是quality of service,呃,那可能那是quality of service,呃,那可能那是quality of service,呃,那可能那是quality of service,呃,那可能那是quality
23:13
of service,我有99.9%的delivery guarantee,或者有它的monitoring,alerting setup,那具体的,比如说tier 0, tier 1,有哪些不同的具体的要求不一样,嗯,我觉得首先是你要看它的那个use case,对吧,就是如果有的那个,呃,东西它是需要,比如说更接近real time的东西,就是非常重要的,接近real time的东西,比如说我到底,我每天有多少rides,对吧,我每天有多少的排,对吧,我每天有多少的排,对吧,我每天有多少的排,对吧,我每天有多少的排,对吧,我每天有多少的排,对吧,我每天有多少的排,对吧,我每天有多少的排,对吧,我每天有多少的排,对吧,我每天有多少的排,对吧,
23:43
这个东西是大家其实就是,呃,很多人每天都会关心的一个东西,那么这个东西一般来说就是tier 0,呃,然后如果是tier 0的话,首先就是我们有unclog engineer,就是24小时unclog,呃,然后还有就是我们需要保证就是tier 0的upstream都是tier 0,对吧,然后呢,那个tier 1就是说,呃,我们需要就是,比如说,呃,就是说它如果出错的话,我们会有一个fallback的东西,对吧,
24:13
比如说,呃,就比如说我们会说啊,我们这一周会给,呃,一部分的driver的信用分去修改,那么如果我们不修改,那么我们就用上一周的,应该也没太大的差别,对吧,然后其实就是这些一般都每天都都在跑,所以就是今天的没更新,昨天的也可以,然后这种东西的话呢,我们就是会要求他,呃,unclog engineer,就是工作室,
24:38
之间是必须要去处理
24:41
然后它的upstream必须也是tier1或者tier0
24:45
然后tier2呢就是说它有一定的business impact
24:49
但是可能可以更长时间
24:51
就是说如果它出问题了
24:53
我们会容忍它更长时间出问题
24:55
对吧
24:56
那么这种东西其实更多的可能偏analytics的
24:59
就是说它基本上不会有downstream的一些影响
25:04
对吧
25:04
或者说它不会有直接的downstream的影响
25:07
比如说我想一想
25:10
有一个tier2的
25:11
好像就是说我们去看一个用户
25:14
就是说我打开app以后
25:16
它多久以后下单
25:19
然后这个东西就是说我们只是做一个analytics
25:22
就是说假如说它
25:24
比如说我们给它给的价格很高
25:26
然后它就下单时间晚一点甚至不下单
25:29
然后我们给它价格低一点
25:30
然后它就下单时间很快
25:32
那么这个东西就是说第一它并不会影响
25:35
就是说如果我们这个数据可能它出了点小问题
25:38
可能并不会影响我们其他立即的决策
25:42
对吧
25:43
所以我们就会多花一点时间去处理
25:45
然后这种东西一般来说就是tier2
25:48
tier3的或者就是就无所谓
25:52
就是说这东西可能我们就是考一次
25:55
然后以后就不管了
25:57
比如说我只有一次的一个三番
26:01
比如说三番的总统日的一个discount
26:07
对吧
26:07
或者投票日一个discount
26:09
然后我们就只跑一次
26:12
然后跑完了以后
26:13
就是我们就要找看给谁给discount
26:16
那么我们跑一次以后可能就不需要了
26:19
对吧
26:19
毕竟可能就是投票也就4年一次
26:22
那你这个data set就可以不用管了
26:24
然后所以这种就是tier3
26:26
然后就是tier2和tier3的话
26:29
就是就没有on call的
26:31
如果你发现问题
26:33
你就去聘那个owner
26:34
然后owner在工作时间去给你处理就行了
26:37
但是就是基本上就是就相当于就是说
26:42
你得来找我
26:43
我才会给你处理的这种感觉
26:46
那你们会raise tier吗
26:48
比如说之前一个data它是tier2
26:52
但是你们公司决定要做一个新的业务
26:54
有一个新的decision
26:56
rely on这个data
26:58
但是新的业务可能是需要tier1
27:01
或者tier0
27:02
那你们会escalate跟他说
27:03
我们需要你这个tier提高
27:05
你要加on call之类的一些决定吗
27:08
这个是可以的
27:10
但是实际上发生的比较少
27:12
因为第一是大家都不喜欢on call对吧
27:15
你要让我on call
27:16
那我会说你这个东西
27:18
首先你要有justification
27:20
然后你给我列一堆justification
27:22
我说这个东西没那么重要
27:24
这个是很常见的一个行为
27:27
所以虽然理论上可以raise tier
27:30
但是就对于我们data engine
27:32
我们更喜欢当轨的tier
27:34
就是我后来发现这个东西
27:35
它其实没那么重要
27:36
我给你当轨的
27:37
从tier0当轨到tier1
27:39
这个其实在我们组发生过一次
27:41
我们后来发现
27:42
就是我们有一个报表
27:44
他说每天9点都要跑出来
27:46
但我们后来发现他9点跑出来没人看
27:49
然后我们就说
27:49
那既然没人看我们就当轨的对吧
27:51
就是也许我10点给你跑出来也可以
27:53
对吧
27:54
可能会有这种情况发生
27:55
那么当然确实有raise tier
27:57
一般来说raise到tier0的会比较少
28:00
因为tier0的
28:01
就真的是大家都非常紧急
28:03
都非常重要的这种
28:04
这种东西其实它早就有了
28:06
就是说这种排盘它已经establish很久了
28:10
或者说它是非常basic的排盘
28:12
说今天有多少的rides
28:14
今天有多少的user sessions
28:16
然后比如说要给司机付多少钱
28:21
这些东西
28:21
这些东西早已经是tier0了
28:24
然后比较常见的是tier2 raise到tier1
28:27
就是说
28:28
我本来只是一个比较carry的一个experiment
28:30
然后我后来发现这个experiment
28:32
怎么好像给公司带来很多的利润
28:34
我们要以后就周期性做这个experiment
28:37
那可能会raise到tier1
28:38
而这种东西我会遇到一些
28:40
然后一般raise到tier1
28:41
我们会检查就是说首先你的upstream
28:43
那upstream必须得是比较reliable的
28:45
就是说你不可以一个tier2的table
28:50
你不可以tier1的table
28:52
reliant tier2的table对吧
28:54
upstream要准确
28:56
我们要保证就是说看你这个东西
28:58
就是你的query到底是efficiency怎么样
29:01
就是说你这个东西会不会
29:02
就是突然跑个5小时结果给崩了
29:05
这种东西一般来说
29:07
在tier1的数据里面不应该出现
29:10
然后还有就是说
29:11
这个就是说我们要确保
29:16
就是有足够的ownership
29:17
就是说首先我们要有一个data engineer
29:20
一般来说tier1
29:21
就需要有一个data engineer去做on call
29:23
我们就得找哪个data engineer的组
29:25
比较合适去给你on call
29:27
比如说我原来可能是一个science的组
29:30
去on一个这个tier2的table
29:32
那么如果要remote到tier1的话
29:34
就必须要有一个data engineer的组去on这个table
29:38
这也是一个需要考虑的一点
29:42
那这个时候可能要raise tier
29:47
大家可能更愿意去create new data
29:50
create new event
29:52
可能这个会更方便一些
29:54
对对
29:55
就是说一方面raise tier
29:58
create new的也有
30:00
那就是一般来说做一个新的东西
30:01
但是新做的东西一般来说也不会是tier 0
30:04
就是我刚才说的就是
30:06
第一是tier 0的东西
30:07
它是一般来说都是well established的东西
30:11
一般来说你新create的一个东西
30:13
你很难做tier 0
30:14
因为你tier 0你必须要保证
30:16
我这个东西我可以是很长时间我都没出过问题
30:20
它的质量非常高
30:22
然后我才能确定它是tier 0
30:24
如果你这个东西经常出问题
30:27
或者说你刚做出来
30:28
我也不知道它会不会经常出问题
30:30
那一般来说不会是tier 0
30:32
那可能是tier 1或者tier 2比较多
30:35
那你刚才也提到很多时候会downgrade tier
30:39
那有经历过其他比如说data proliferation的问题吗
30:43
就是数据太多了
30:44
有的数据根本不需要
30:46
会不会定期清除一些数据
30:48
但这时候又发现有一些
30:50
根本不知道什么哪家的downstream service
30:52
rely on这个data
30:54
然后又出了一些问题
30:55
对
30:56
就首先是
30:57
首先数据我们不会去主动删除的
30:59
因为其实这个数据存储的成本是很低的
31:02
对吧
31:02
那么就是数据它为什么我们会
31:05
我们可能会关掉pipeline
31:07
关掉pipeline有几个因素
31:09
第一个就是说
31:10
这个pipeline经常出问题
31:11
对吧
31:12
那我们可能会关掉它
31:13
那么第二就是说
31:15
这个pipeline需要太多的那个computational cost
31:18
对吧
31:19
就假如说它这个computation的这个resource
31:22
它需要很多
31:23
那么我们可能会考虑关掉它
31:25
但是你关掉之前
31:27
你肯定要去看downstream是什么
31:29
就一方面你要看downstream table是什么
31:31
然后另一方面你要看
31:32
就有些人他不一定是一个
31:35
就downstream他不一定是一个table
31:37
或者不一定是一个那个
31:39
不一定是一个pipeline
31:40
它可能是一个dashboard
31:42
它可能甚至就是个有一个人
31:43
他偶尔query一下
31:45
对吧
31:45
我偶尔query一下
31:46
我既没有把这个写成code
31:48
放到我们的一个repository里面
31:49
我也没有把这个存成一个dashboard
31:52
对吧
31:52
放在我们的一个dashboard里
31:54
所以总体来说
31:55
这个还是会稍微
31:56
稍微复杂一点
31:58
所以我们就是
32:00
其实就是关掉pipeline
32:02
这种行为也比较少
32:03
而且一般deprecate一个pipeline的话
32:05
我们或者说
32:06
我deprecate这个pipeline
32:08
但是你有什么某某信息
32:10
你可以从这里找到某某信息
32:12
你可以从那里找到
32:13
对吧
32:14
可能会有这样子的一个替代的措施
32:16
会告诉大家
32:17
然后而且就是
32:17
其实在deprecate的pipeline里面
32:20
我们必须要有一个note
32:22
就是说Among Us
32:23
其实就是做这个东西的
32:23
就是说我一个data set里面
32:25
我可以很便捷的去查到
32:29
谁是这个data set的user
32:30
谁是这个data set的owner
32:32
谁是这个
32:33
然后这个data set里面有多少column
32:35
然后如果这个data setdeprecate
32:38
那么我们代替的东西是什么
32:40
对吧
32:41
这些东西就即使
32:42
我后来发现这个data set
32:44
现在他deprecate不更新了
32:46
或者说数据出问题了
32:48
那我应该去找谁
32:49
或者说我应该去找哪个table
32:50
这些至少得告诉别人
32:53
对于不做data的
32:54
像我这样的engineer来说
32:56
我比较感兴趣的是
32:57
像Uber和Lyft这种业务
33:00
有相近地方的公司
33:02
都是打都做打车业务
33:04
那他们在数据量的区别
33:06
在数据量级上有区别吗
33:09
如果有的话
33:09
这个数据量级的区别
33:11
对data scientist
33:12
data engineer的每天的日常工作
33:15
会带来影响吗
33:17
嗯
33:18
那首先我就说这个量级
33:20
基本上是没有区别的
33:22
对吧
33:23
我觉得就是他那个
33:25
Lyft可能是Uber的
33:27
比如说res数量的三分之一
33:29
或者二分之一
33:30
那么一般两倍三倍
33:31
其实不算一个量级的区别
33:33
对吧
33:33
所以就是说你五分钟能跑完的
33:35
我十分钟跑完对吧
33:36
其实并不是一个很大的问题
33:39
那么我觉得主要还是就是说
33:41
公司的一个就是
33:43
他的一些策略
33:45
就比如说
33:46
我觉得我自己的感受是在Uber的
33:49
那个experiment的迭载的速度是比较快的
33:52
就是说
33:54
那Machine Learning的组他会经常出
33:56
哎我今天我要做这么样一个experiment
33:59
对吧
34:00
然后然后发给大家
34:02
然后然后就是会有很多这种experiment
34:05
比如说我今天说啊
34:06
假如说是我给这个
34:09
ride 50 miles以上的人
34:11
我给他打个9折
34:14
然后明天我又测试是什么
34:15
比如说给姓李的人打个8折
34:18
对吧他会有这样的不同
34:19
就是很有意思的去测试
34:21
然后然后看哎今天这个打折
34:23
我们最后赚了多少钱
34:24
明天的打折我们赚了多少钱
34:26
这种东西很多
34:28
我觉得我在Lyft工作的时候
34:30
这种东西稍微少一点
34:31
就是说啊好像没有那种就是
34:34
我我今天做这样的一个测试
34:36
然后啊当然就是在Uber
34:37
的时候我觉得做的比较好
34:39
也就是user segmentation做的比较好
34:41
就是呃
34:44
就是他会知道你你你用Uber是
34:46
这个我用来上下班
34:48
还是我出门玩
34:49
还是说我用Uber是去机场对吧
34:52
他其实知道这些东西
34:54
嗯在Lyft我我到了以后
34:56
其实这些东西才逐渐的做起来
34:58
就是之前就是很粗糙的一个科幻
35:01
那么首先就是你要有一个非常targeting
35:04
的那个advertisement
35:07
或者promotion的话
35:08
你就必须得
35:09
你就必须得有一个segmentation
35:10
那么在Uber这个东西做的好
35:12
然后这个东西做的好
35:13
就empower他可以去做更多的那个
35:15
experimentation
35:16
啊在Lyft我觉得这个东西在逐渐改善
35:19
当然也和那个COVID有关
35:20
就COVID一到可能大家的
35:22
用户习惯突然就变了
35:23
然后我们确实就是也呃
35:25
很多experiment就停了
35:27
那你因为大家也不上班了
35:28
你怎么去做这个这些东西
35:31
呃所以就是
35:33
这个我觉得可能就是呃
35:36
不光是这个data
35:38
size的区别
35:39
还有一个就是说
35:40
我们怎么去用data
35:41
就是
35:42
我觉得好像在Uber用这些data会更
35:44
intensive一点
35:46
嗯
35:48
那COVID对你们的影响怎么样
35:51
那COVID的影响
35:54
对对对我觉得还是
35:56
还是比较严重的
35:57
当然尤其是去年那会儿就是
35:59
呃我我记得是
36:02
这个反正已经公开数据了嘛
36:03
就是我们的那个ride从
36:05
就是突然掉到了之前的20%
36:08
这个是非常严重的事情对吧
36:10
你想一个一个公司业务突然变成
36:11
之前的五分之一
36:13
那么那么就会
36:14
就就非常严重
36:15
然后我们的股价也掉了
36:17
之前的三分之一
36:18
对吧然后呃
36:20
但后来有有一定的recovery
36:22
就比如说我们的那个
36:24
我们后来的rise大概现在可能
36:27
我我忘了回答多少了
36:28
这个可能还属于隐私
36:29
反正就是有一定的recovery
36:31
但是肯定是比COVID之前
36:32
还是要少很多的
36:34
呃另一点就是说
36:35
因为一方面大家不上班
36:36
另一方面大家不出行了
36:38
这是两个很重要的
36:39
我们的那个rise的来源对吧
36:41
呃所以这两个就会呃
36:44
这两个就会那个
36:45
导致我们的那个业务下降很多
36:47
而且我们还没有外卖业务对吧
36:48
uber其实有外卖业务
36:50
呃然后呃
36:53
还有uber他可以卖掉他的atg啊
36:55
什么的那些业务
36:56
我们这个有一个
36:58
自动驾驶的业务
36:59
但我也不知道做的怎么样
37:01
可能不一定能卖出那个atg那么多钱
37:04
然后嗯
37:06
还有就是
37:07
我觉得那个
37:08
这个对我们的影响是比较大的
37:10
对吧你现在
37:11
因为因为很多的公司在疫情期间啊
37:13
互联网公司在疫情期间受益对吧
37:15
amazon
37:16
google这些netflix
37:18
他们的股票层层增长
37:19
然后我们都断言是下跌
37:22
然后就慢慢恢复
37:23
但后来就是加州不是还有一个ab5吗
37:27
就是说要把那些司机换
37:29
呃规划成那个
37:31
呃employee
37:34
那么这个最后没有通过
37:35
其实会对我们的股价有一定的提升
37:37
然后包括vexen
37:38
然后就是我们现在股价就大概回到了
37:41
我入职的那个
37:42
那个点稍微高一点
37:44
呃所以所以就是我有时候
37:46
然后你知道吗
37:47
我们之前不是还裁员吗
37:48
就有的人裁员以后啊他特别郁闷
37:51
然后最后去了另一家公司
37:53
然后去另一家公司以后
37:54
然后另一家公司的股价就增增增长
37:57
然后我们公司股价就是原地踏步
37:59
所以有时候就觉得还不如被裁了
38:01
还不如被裁了
38:02
我去另一家公司
38:03
发展的更好
38:05
呃是说去年那波uber裁员风暴
38:09
呃去年uber和lift都有裁员
38:11
对呃2020年
38:13
但是2019年uber也有裁员
38:15
我觉得uber有多轮裁员就是
38:18
嗯你是在uber2020裁员
38:21
前不久跳槽到lift是吧
38:24
对对呃
38:26
我是就是这样子是
38:28
uber2019年裁员过一次
38:29
然后当时我开始准备跳槽
38:32
呃然后我在20
38:33
呃20年年初跳槽到lift
38:35
然后
38:36
但是呢最后又感染covid
38:38
然后lift也和uber也都裁员了
38:40
是这样子的
38:42
虽然你们有裁员
38:43
你们也有股价也降过一阵子
38:45
但是我觉得你们uber和lift都是
38:48
有颠覆性的产业
38:51
就是能让极大的
38:52
便利了人们的出行生活
38:56
对对嗯
38:57
对我觉得是是这样子的
38:59
嗯但是我后来呢也就是
39:03
想明白一个道理就是说
39:05
很多颠覆性的产业
39:07
在很多颠覆性的东西他
39:09
不一定那么赚钱啊
39:11
我觉得我觉得这个是我我
39:13
现在想明白的一个东西就是说
39:15
嗯
39:16
尤其是这个和那个
39:19
和人力成本相关的东西我觉得
39:23
嗯其实他对
39:25
就是说他可以让你过得
39:27
更方便
39:28
但是他可能在其他地方的cost也会很多
39:31
所以就是说其实嗯
39:33
盈利能力有限就比如说
39:35
嗯而且就还要看竞争
39:37
就比如说我记得dropbox刚刚出来的时候
39:41
他其实也挺颠覆性的对吧
39:43
就你之前大家都要用优盘啊什么的
39:45
然后后来大家都用网盘了
39:47
然后其实你看现在大家用的都是icloud呀
39:50
啊什么嗯
39:52
google google drive
39:53
但是就dropbox这个公司他并没有那么
39:57
就是他并没有赚那么多对吧
39:59
然后包括推特
40:00
我觉得推特太颠覆性了对吧
40:02
特朗普都靠推特
40:03
哦特朗普上台可能很重要一个因素推特
40:05
但是推特他就是
40:08
股价呀什么盈利呀
40:09
他其实也就是那个不上不下对吧
40:13
所以就是
40:14
我觉得这个这个是我最后才
40:17
最近才悟出的一个道理
40:19
然后所以我觉得嗯
40:20
一方面要考虑颠覆性
40:22
另一方面就是
40:23
商业模式对对现在就是
40:26
呃能赚钱的公司
40:28
基本上是要形成垄断的公司
40:30
形成垄断公司你就得
40:31
或者你要至少要有规模效应
40:33
那么要有规模效应
40:34
你必须你有很多的data对吧
40:36
你才能通过这个
40:38
这个东西你才能获取新的一些信息
40:40
对吧啊然后
40:42
所以就是说其实在新的这些就是说
40:46
呃
40:47
不管是新的公司还是老的公司
40:49
就是说你要维持你的垄断地位
40:51
或者说你维持你的这个
40:53
preeminence
40:54
那么你必须要对data有很好的去掌控
40:57
对吧首先你要有这个数据
40:58
其次就是说你要
41:00
能够分析
41:01
就是能够高效的去分析这个数据
41:03
从这个数据中得到你需要的insights
41:06
呃所以我觉得总体来说就是这个业界
41:08
会对于data
41:10
呃data platform和data infrastructure的
41:12
那个需求会越来越多
41:14
呃然后包括machine learning的发展
41:16
他可能会对这个computation resource
41:19
啊然后包括这个各种各样的data
41:22
set的夸大他也的要求都会提高
41:25
刚刚提到了那machine learning
41:27
呃infra engineer
41:28
嗯就是我也不知道这可能是个题外话
41:31
不知道你对这方面了不了解
41:33
就是你现在是
41:34
你你你比较喜欢data infra engineer
41:36
那如果你想转到machine learning
41:38
infra engineer
41:39
是不是也会有相通之处呢
41:41
以及这俩的工作是不是也有相通之处呢
41:43
哎我觉得这还挺有意思
41:45
但是我对于machine learning
41:46
呃我觉得有一个
41:48
问题就是我对于machine learning的
41:50
了解没有那么多
41:51
嗯可能
41:52
呃可能你要做这方面的经验就是
41:55
呃我我自己的理解啊
41:57
其实他是比较偏还是
42:00
他好像有一点像data engineer
42:02
呃我我我出我设计一个
42:05
我设计一个machine learning的算法
42:06
呃我可能是一个
42:09
scientist
42:09
然后需要一个machine learning engineer
42:10
去给我去做实现
42:12
然后去跑这个数据啊
42:14
我有一个朋友是machine learning engineer
42:16
然后他呢就是
42:18
第一他在facebook工作
42:19
他特别有意思的一点是他和别人抢
42:21
那个computation resource
42:22
啊然后就是好像
42:24
呃就很多的那个facebook
42:25
不是有很多服务器吗
42:26
但是他把这个算法写出来以后
42:28
半天没有服务器让他跑
42:30
好像有这样的一个问题
42:31
嗯我然后还有就是说呃
42:34
他需要花很多时间去等这个数据
42:37
去那个ready
42:39
呃这个可能要比我们做data pipeline的
42:41
更更难受
42:41
因为我们做data pipeline
42:43
就是说大部分的hack query
42:45
呃可以在一小时内跑完
42:46
但是你要machine learning model
42:48
你不光一小时
42:49
你可能会花更多的时间
42:50
呃所以我觉得呃
42:53
我我之前的machine learning engineer理解
42:55
就是就是类似data engineer
42:58
但是把这个东西
43:00
在简单的data pipeline
43:01
做成一个machine learning model
43:04
但是好像machine learning engineer
43:06
他们也有做那个
43:07
machine learning infrastructure的
43:08
呃我觉得如果做这方面的话
43:10
会更有意思点
43:11
呃嗯然后而且就是做machine learning的话
43:14
他
43:15
呃其实他比较
43:17
呃和这个比较相关
43:19
还有就是你要去做
43:21
cloud computing
43:22
对吧呃你要做distributed computing
43:24
呃然后其实我之前在Berkeley
43:27
做的一个research就是说
43:29
我要在distributed platform上
43:31
去做那个machine learning的
43:32
那个算法
43:33
这个其实要比在那个
43:35
单机器上做machine learning的算法
43:37
还要复杂很多
43:38
因为你很就你很多机器上我的数据
43:41
不同不同步的对吧
43:42
我我这个机器上
43:43
传出来的数据是这个
43:44
那个机器上传出来数据是那个
43:46
然后我们数据要去做交换对吧
43:48
然后做交换还要考虑它的bandwidth
43:51
因为如果你在一个机器上
43:52
呃你完全可以知道啊
43:54
呃比如说我这个这个node
43:56
假如说是一个neural network
43:57
我这个node传出来是这个东西
43:58
那个node传出来是那个东西
44:00
我可以即时获取
44:01
那么在distributed的那个东西
44:03
它就不是的就是说
44:05
我们传出来的数据不一样
44:06
然后我们就需要做communication
44:08
然后另一点就是说
44:09
呃我们的这个
44:11
首先我们要分发这个数据对吧
44:12
我们我们的那个input data可能
44:14
它就它就得分给不同的机器
44:16
然后去怎么去分这个
44:18
啊总体来说我觉得好像是
44:21
还是有挺多research
44:23
呃的东西
44:24
一般的scientist他不会去考虑这个了
44:26
就是说我要做一个neural network
44:27
我不会考虑我在100个机器上去跑
44:30
和一个机器上跑有什么区别
44:31
但是事实上是有区别的
44:33
然后这个区别
44:35
可能就是需要一部分的
44:37
这个engineering处理
44:38
呃所以我觉得这个还挺有意思的
44:40
但是这个可能属于比较前沿的一些研究
44:43
呃我我觉得啊
44:44
我觉得不一定是在每个公司都会有这样的机会的
44:48
嗯那如果呃如果我们有听众对data engineering
44:52
或者machine learning engineering感兴趣
44:54
想要从事这一行业
44:56
呃你会对
44:58
想要参加做这部分工作的人
45:00
有哪些建议上手入门呢
45:03
嗯对首先我就是说呃
45:06
我觉得分两种一种是你是
45:09
那个刚大学毕业的萌新对吧
45:11
那这个我觉得首先是你看你自己能呃
45:16
因为现在好像找工作也不容易
45:17
那就看你自己能找到什么样的工作
45:19
然后你就去
45:21
呃如果你刚毕业你就你就去哪家公司
45:25
呃给你给的给你给offer
45:28
然后给你给待遇好先去哪家公司
45:30
我觉得就如果你没决决定的话
45:33
可能从这里出发比较好
45:34
但是有很多的
45:35
其实有很多人他就是从那个
45:38
尤其是转专业的
45:39
他可能就是从
45:40
呃data scientist
45:41
data engineer开始做起的
45:43
然后之后如果你对engineering就是兴趣更高
45:46
你可以去转到software engineering
45:49
呃然后如果你如果就是说你data engineer
45:51
当然你这条路你可以走到e5对吧
45:54
e5可能再往上会稍微难一点
45:56
那你就可以去转型做manager
45:58
或者是做其他的data infrastructure
46:00
engineer也可以
46:01
呃然后
46:03
呃如果你一开始做software engineer的话
46:05
我当时呢也是我就是
46:07
engineering会变成data engineer
46:09
我自己总体来说觉得这个data engineer
46:11
他的技术可能没有那么高
46:13
呃所以我可能会更喜欢software engineering
46:16
一点
46:16
呃而且data engineer他需要很多的
46:20
communication
46:20
我觉得我就是
46:22
我可能更希望就是
46:24
一个人去做一个设计
46:25
但data engineer他更多dependency
46:27
就你这个downstream upstream
46:29
然后user这些你需要很多
46:31
你需要把这些东西都调节好
46:33
有一点这一点有点像pm
46:35
我觉得就是你要把这个就是
46:37
就是各种各样的
46:40
复杂的关系你要去给他梳理清楚
46:42
呃software engineer的话
46:43
我觉得在初级阶段
46:45
可能不一定有这样的一个需求
46:47
呃然后我我可能我觉得可能我
46:50
我会比较倾向于做software engineer
46:52
但是
46:53
我觉得第一是每个人要看自己的兴趣
46:55
呃第二就是呃
46:57
你自己的机会不一定就是说
47:00
呃有那么多对吧
47:01
就比如说我我当时
47:03
呃高考之前我就说啊
47:04
我要上清华大学还是北京大学呢
47:06
对吧
47:07
最后我发现我只能上这家大学
47:09
那我就去这家大学
47:10
所以就是先看你自己有什么选项
47:12
呃然后再从选项
47:13
如果你真的有很多选项的话
47:15
呃我自己比较建议
47:17
software engineer
47:18
因为我觉得他要发展路径比较广
47:20
呃这就是我的想法
47:21
嗯这家大学也很好嘛
47:23
哈哈呃
47:25
是是是都不错都不错嗯
47:28
呃稍等一下
47:29
我在做一个小广告
47:30
因为我自己也在做博客
47:31
然后我我做的博客是
47:33
呃那个
47:34
呃 product talk 叫产品新语
47:37
啊然后前段时间是我我暂停了一段时间
47:40
但是我最近准备起步
47:42
呃呃主要讲的是产品可能技术方面
47:45
呃讲的不会那么深
47:46
但是我觉得如果感兴趣的话
47:48
呃也可以去subscribe
47:50
那全来有没有想对大家说有没有
47:53
呃想对大家说的呢
47:56
嗯对然后我就是希望大家可以多多关注
47:59
这个 podcast 对吧
48:01
呃然后
48:02
我觉得这个就是你们做的这个东西
48:04
质量也特别好
48:05
我也听了第一期啊
48:07
我也很荣幸被邀请过来
48:08
然后也希望下一次以后还有机会
48:10
可能可以去你家去喝
48:12
那个手磨的咖啡对吧
48:13
啊然后而且我觉得嗯可以
48:17
跟大家分享这么多
48:19
啊我自己在行业里面的
48:21
各种的想法和见解
48:22
然后也可以听到别人的想法和见解
48:25
然后甚至在疫情期间可以和老朋友
48:27
reconnect
48:28
啊我觉得都是非常不错的体验
48:30
然后希望你们这个 podcast 越办越好
48:33
好的谢谢全来
48:35
好那
48:36
啊就是如果观众想要联系全来
48:40
呃可以通
48:41
就如果我们有观众对 data engineering
48:43
感兴趣或者对 uberlift
48:45
想要深更深一步的了解
48:47
或者就联系全来
48:49
那通过什么方式比较方便
48:53
呃我觉得用邮箱吧
48:54
我的邮箱是mail at全来到底
48:57
呃应该还比较好记啊
48:59
mail mail at q u a n l a i dot e
49:04
然后这个这个也是我自己买的一个域名
49:06
然后啊
49:07
呃所以就是希望大家可以
49:10
用这个来联系我
49:12
好的我们会加到 show notes 里面
49:14
好那今天就到这里了
