米兰小球迷 发表于 2021-2-17 12:49 static/image/common/back.gif
层主是Data Engineer吗？DE岗shibushi要求会javascript这些语言，才能构建大型企业的数据仓库？ ...
是的，我在DE这块工作了几年，现在带一个小的DE team。DE这个职位的业务范畴可大可小，取决于公司的规模和公司现有的数据基础设施（Data Infrastrucutre，包括Data pipeline, Data lake, Data warehouse等等）。一般来讲DE最基础的工作是
1.搭建Data ETL pipeline
2.Data warehouse的数据清理/数据转化的脚本
3. 设计如何应用Data lake
4. 数据备份
5. Data Infrastructure的logs，metrics和dashboard
如果是构建数据仓库（infrastructure as code, networking layer）一般是devops的工作，但是如果公司devops能力有限或人手不够，infrastructure的部分DE也会做。尤其公司如果大量运用云服务，很多像load balancing, availability, scalability, authentication, uptime, SLA这些考虑因素都是云服务在统筹，通过修改设置就可以很轻松的调节，infra的构建相对on-prem会容易很多。
设计数据仓库里的数据结构（schema）是DE的工作范畴，但是一般会和business stakeholder一起完成。
因为每个公司有不同的数据查询频率，历史数据量，每日新增数据量，数据摄入速率等要求，所以DE很大一部分工作是根据需求和公司现有的科技栈来设计Data Infrastructure方案。最适合的方案既要涵盖所有需求又不能over engineered（因为公司没有无限的耐心）。尤其公司如果没有或者没有好的Data Architect，DE的工作其实很挣扎，因为stakeholder很多。
JavaScript可能不是DE最重要的语言，基本上最流行的DE工具和框架都可以用python和sql写，如果会Java那就更好，kafka, hadoop, spark, flink等上手会比较快。
其实我理解的DE就是software engineer，不过是比较专注于数据领域。好的software engineer转型做DE其实很容易。
mendietaczfls 发表于 2021-2-17 18:10 static/image/common/back.gif
是的，我在DE这块工作了几年，现在带一个小的DE team。DE这个职位的业务范畴可大可小，取决于公司的规模 ...
很精彩，非常感谢分享
Udacity对于Tableau的教学属于很简单的，没有任何复杂的或者进阶的功能。这也就是说在需要做一些复杂一点的，或者比较特殊计算和功能的时候，没有办法从之前学到的得以实现。这个就是Udemy只教学Tableau这个课程的好处，十几个小时，从入门到高级的Tableau的功能的介绍，和全部的视频的，一步一步的实现的详细讲解。看了几个Advanced Calculation的视频，感觉这些都非常有用，可以直接应用到最后的作业里。
休闲一些，赶赶edX 《Statistical Thinking for Data Science and Analytics》的进度(Source Ref: https://www.forbes.com/sites/gilpress/2013/05/28/a-very-short-history-of-data-science/?sh=5332923055cf)
太阳底下无新事哈......
原来Data Science这么性感的词，1996年就已经提出来了：“1996 Members of the International Federation of Classification Societies (IFCS) meet in Kobe, Japan, for their biennial conference. For the first time, the term “data science” is included in the title of the conference (“Data science, classification, and related methods”). The IFCS was founded in 1985 by six country- and language-specific classification societies, one of which, The Classification Society, was founded in 1964. The classification societies have variously used the terms data analysis, data mining, and data science in their publications.”
更加前瞻性的，早在1990s时代，人们就已经打算使用已有的收银数据和数据库，预测人们的消费趋势，是不是听起来非常的熟悉哈。“September 1994 BusinessWeek publishes a cover story on “Database Marketing”: “Companies are collecting mountains of information about you, crunching it to predict how likely you are to buy a product, and using that knowledge to craft a marketing message precisely calibrated to get you to do so…An earlier flush of enthusiasm prompted by the spread of checkout scanners in the 1980s ended in widespread disappointment: Many companies were too overwhelmed by the sheer quantity of data to do anything useful with the information… Still, many companies believe they have no choice but to brave the database-marketing frontier.”
说说AI，《HBR's (Harvard Business Review) 10 Must Reads on AI, Analytics, and the New Machine Age》里有讲到三个方向，Three types of AI:
* Robotic Process Automation: the most common type (48% of total) is the automation of digital and physical tasks - typically back-office administrative and financial activities - using Robotic Process Automation technologies.RPA is more advanced than earlier business-process automation tools, because the "robots" act like a human inputting and consuming information from multiple IT systems.RPA is the least expensive and easiest to implement of the cognitive technologies and typically brings a quick and high return on investment.
* Cognitive Insight: the second most common type of project (38% of the total) uses algorithms to detect pattern in vast volumes of data and interpret their meaning.Think of it as "Analytics on steroids."Cognitive insights provided by machine learning differ from those available from traditional analytics in three ways: they are usually much more data-intensive and detailed, the models typically are trained on some part of the data set, and the models get better - that is, their ability to use new data to make predictions or put things into categories improves over time.
* Cognitive Engagement: projects that engage employees and customers using natural language processing chat bots, intelligent agents, and machine learning are the least common type (16% of total)......Despite their rapidly expanding experience with cognitive tools, however, companies face significant obstacles in development and implementation.
忽然一周 发表于 2021-1-29 23:07
灵魂还是对业务的理解
灵魂还是对钱的理解
完成了edX Statistical Thinking for Data Science and Analytics第一周的课和作业
分享一篇<<What is Data Science?>>-The future belongs to the companies
and people that turn data into products，挺详细的讲解了一些概念和应用逻辑。: http://cdn.oreilly.com/radar/2010/06/What_is_Data_Science.pdf
Negotiation或者讨价还价，是一个长久的，而且艰难的过程。跟业务部门确定时间和资源，和IT部门讨论实现需要的技能和完成时间，都是需要摆事实讲道理，既强硬又留下可供讨论的余地。即使话不投机谈不下去，表面也不能崩，甚至表面谈崩了，下次会议依旧需要重整心情继续谈。
从实际出发，在业务部门，打算通过以节约时间提高效率，来把现有的报表分析系统，整合成一个标准的Data Lake + Reporting Tool的模式，几乎不可能提交出有高价值的business case的，因为单从性价比和投资回报来说，即使现有系统有种种的不足，那都是经过了多年的投入和修改而来的。而要新建一套新的，单单可行性分析，架构，研发出一整套方案，就需要很多的R&D费用了。所以只能往两个方向试着找出有价值的：
1. 和IT部门合作，在时机对的时候，成为其中的一份子，加入进去。因为这个时候，可以加入很多有利于IT部门的成果，比如Data Governance, Data Security, Risk Control, Future Technical Development & Support Cost Reduction, Outsource Support Operating Model等等。利用和其他部门一起合作的机会，达到共同负担费用，得到宝贵的预算，来进行整个系统的升级和整合。
2. 先把原有的整个Platform放一边，从小做起。先在新系统里做出一些新的有价值的东西，慢慢得到大家的认可。随着越来越多业务部门的头头们用到了这个新系统，并认为好的东西都是从这里来的。然后再提出大的整合方案，拿到支持和预算。整个过程往往经历很长的时间，有时候会达到好几年的时间长度。这个过程需要很大的耐心和恒心，还要有一定要实现这些的坚持和信仰。
mendietaczfls 发表于 2021-2-17 18:10 static/image/common/back.gif
是的，我在DE这块工作了几年，现在带一个小的DE team。DE这个职位的业务范畴可大可小，取决于公司的规模 ...
"其实我理解的DE就是software engineer，不过是比较专注于数据领域"
非常同意的
继续做第三个小项目，Superstore Performance Dashboard。基本的分析的Sheets已经做出来，需要整合成一个Dashboard，自己的要求是要做的好看，还在努力中......
这个Youtube的视频讲解如何做好Format的非常值得一看，特别是最后快进的部分，把整个Dashboard的等级提高了很多：https://www.youtube.com/watch?v=RV3QB5r7G1M
本帖最后由 hxsh2000 于 2021-2-24 07:58 编辑
又忙活了一个晚上，把整个Dashboard给做出来了。接下来还需要加颜色，加标注，加注意事项等，按着上面链接的视频调节背景和整体
本帖最后由 hxsh2000 于 2021-2-25 00:41 编辑
学习了数据收集和分析过程中的Limitations and Biases，很多时候会被忽略的一部分，就是这个过程中会不会影响分析结果。有点接近在读Research Degree过程中，case study analysis的找到比较靠谱的sampling，还有如何更好的收集到数据，用哪些方法可以尽量避免Biases的数据收集。
Udacity的课程打算多学一个月，里面有很多有用的知识点可以借鉴。如果没有完成整个Nanodegree，中间就停了subscription，那么也就没办法用到这些资源了。如果完成了整个Nanodegree，那么结束后还可以有一年的时间可以用到这些资源。虽然这个degree没有非常大的用处，看来还是得争取完成，以能够继续access这些知识。
从开始到现在，刚好一个月，平均每天三个小时，不错的开始！
非常感谢楼主的分享！:thumbup:
完成了Final Dashboard Project，通过了。
楼主，你了解coursera上ibm data analyst课程吗？感觉你学的都很深，还挺复杂
海绵萧萧 发表于 2021-3-3 00:57 static/image/common/back.gif
楼主，你了解coursera上ibm data analyst课程吗？感觉你学的都很深，还挺复杂
之前有看过，觉得课程挺不错的，我记得还是免费的。当时没选主要是IBM这个课程会用自己的Tool，而我现在用的工具不是IBM。
还是看你打算学什么，职业或者兴趣规划是啥，选适合的课程吧。每个课程适合的对象是不同的，特别是这些bootcamp，需要很多时间和commitment
确定了reporting strategy和整个analytics platform，明确了接下来几个月需要完成的目标。也争取到budget并招到了合同工的Data Analysts，开始和技术部门确定合作方式。接下来几周可以讨论如何有效沟通，如何确定requirement & delivery的管理模式，并慢慢的标准化这个business requirement, ETL, Data visualization的开发流程和合作效率。
长周末可以好好的完成Udacity Data Visualization的两个Data Storytelling的项目了哈！
Udacity现在的课程75% off，每门课差不多五六百（四到五个月），很不错的价格了。我现在50% off，每个月都需要$300。等Data Visualization学的差不多了，这个月可以注册intermediate的Data Analyst，快速的学习和逐渐掌握整体和系统的知识。
很多的项目，想要做的好甚至成功实施，都是需要打通上下游，做好好的整合。IT项目更是如此，最重要的是Top Management Support，很关键也需要manage expectations。应用和软件公司，公司业务和IT部门很多时候为了促成选择，往往会在投标和路演的时候，把很多需要定制化和特殊处理的功能，不加以区分的告诉客户是能够实现的功能。公司管理层为了推进改变，也往往会跟下级讲很多这些应用和软件的好处，于是在开始阶段（还没有go-live），大家的expectations都非常高。到了真正的实施的时候，很多定制化的功能往往会耗费非常多的精力和开发费用，使得项目费用超支和拖延。
想起来在08年的时候，毕业后工作了一年，当时申请了Monash Uni的Data Analyst工作并拿到了面试。在和Panel面试的时候，问说兴趣和喜欢做什么，自己说了很喜欢和business打交道，并且很享受和业务部门一起做流程优化和提升。当时面试官就说，如果你的兴趣是Business Analysis，那么做Data Analyst可能会觉得很无聊和Boring的。辗转了十几年，回到了Data Analytics的职业上来了，而现在的Data Analytics也有了更多的参与感和通过分析和研究数据提升企业竞争力的机会。
完成了第四个项目，根据movie dataset做一个insightful story。只给了数据，之后需要自己定义
problem statement: 需要解决什么问题
Synthesis and executive summary
Hypothesis and issue trees
接着按照hypothesis中的定义做出数据和可视化来验证关联性
定义数据dataset和分析中的limitation and bias
进一步给出下一步的方向。
使用了ghost deck的approach或者叫方法一步一步的定义问题，假设和验证
这个其实就是consultant和客户做分析和presentation的流程了。
很厉害，学习了
行业知识很重要，需要多年的积累
现在的Data Visualisation这门课学的部分，比如动画和配音，已经和现在的工作内容不是很相关了，这部分的学习也慢了下来。这周花了一些时间学了edX Statistical Thinking for Data Science and Analytics概率的部分。由于Udacity 75% off，报了一个Data Analyst的课程，四个月的课，$500。这样子就不用非常赶着学完了。
这样一年下来的话，整个系统的从最前端往后端，一个一个来，先Data Visualisation，再Data Analyst，然后Data Engineer，一年下来整个Data & Analytics的技能和技术链都能系统的涵盖了。顺便刚好再用八九个月的时间，把Columbia University的Data Science for Executives的三门课完成，拿到Professional Certificate。算是把一个一年的学习计划完全确定，并一步一步的完成中......
六天来，赶着完成了ColumbiaX University 《DS101X: Statistical Thinking for Data Science and Analytics》第三周和第四周的课程。第三周的课主要是关注Bayes' Formula的应用以及如何建立模型分析和预测Natural Language，感觉语言和文字的分析模型很难懂，太多的数学公式，而且包括处理语言的方式。
还有第五周的课程，关注模型分析Bayesian Modelling / Inference，就能完成这个系列课程的第一门课了。
在职场上有句话，叫“如果你没有能够定义你自己，那么别人就会按照他们的方式定义你”。越是做到高层的人，越需要坚持自己做事情的风格，展现优势以做出成绩。自己先定义自己能够做的，并且充满信心，并以此创造各种条件和资源，把事情完成。没有这样做的话，非常容易进入一种困境，就是伴随着使用不熟悉的做事方式，展现出来的是劣势，没有很强的信心和感染力，那么几乎不可能能够做出成果或者让更高层认可，于是获得不了资源和预算，也就创造不了更多的价值。
能够站上高级管理层职位的，往往都需要有很强的坚持，坚持自己做的是对的并且自己的背景是适合这些职位的。由于有了这种坚持和信心，于是招聘过程中，也更容易找到那些相同背景的人，一方面是互相熟悉，容易合作；另一方面，在这个认可的过程中，也再次认可了自己并强化了信心。所以我们往往可以看到，整个部门的人中，做事风格，方式甚至背景都很相似。
以前写的一些东东：
公司里的每个部门，都有他们自己的职能和KPI，这些对于他们自己部门来说，是最重要的衡量指标，这些也是各个部门的头头们需要争取更多的资源和要完成的目标。直接点的来说，身为部门主管，这些就是部门的Priority。额外的，也是非常重要的，是扩大部门的影响力，让自己和整个部门能够更有机会做那些更能体现价值和能够做出成绩的任务。于是：
1. 每个部门会尽力去争取可以争取到的最大的资源，保证充分的资源完成，并完成好自己的KPI；如果可能，尽量介入和主导那些更上层（CXO）重视的项目中去，或者和公司Vision有关的重要事情，这样能保证在未来的位置上和更上层能看到的地方，有自己和部门的位置，因为这些最容易做出成绩；
2. 对于配合其他部门，做有利于其他部门的项目，或者事情，这些如果可以有亮点，或者和KPI有关系的，那么会参加，但不一定是Priority；而如果只是配合，甚至这些有可能会影响到自己部门的事情，则肯定不在Priority上，能拖就拖；
3. 对于部门的主管或者Manager，首要的是能够带领自己的Team完成自己的Priority和KPI，这些当然是更上层确定的，也就自然的代表了和帮助更上层的意志和成为争取本部门利益最大化的一份子。然后是能够争取到资源和扩大影响力。只有有了足够的资源，才能完成更多的工作和有完成更多的工作的潜力，也可以避免因资源不足而完成不了或者部门任务完成不达标的风险。以前Manage了整个SAP Implementation，对我来说，最重要的是要保证按质按量的完成项目，我更上层项目的Sponsor，APAC CFO和Australia公司的Board也是这么认为，因为这也是他们的KPI，我要做的就是尽量在Budget内完成。最好的是按Budget完成，次好的是Over Budget完成，最不好的就是，最后一刻说因为不够Budget而完成不了。这个就是为什么在各种Budget和Process Re-engineering的会议里，即使是大到Board meeting，各个头头们也都是吵翻天的，有时候会为了那么几个Head count，或者一些流程谁完成而根本达不成一致；
4. 所以如果一个部门主管，能够对外要到足够的资源，又能顺利的完成任务，甚至能够在重要的项目中让本部门占据位置，那么肯定是一个做的很成功的主管。想想看，对比一个在外面要不到资源，只能让组里的人做更多的活，而且还是Routine的活的主管，差别是很大的。
5. 主管还要有和各种头头脑脑们打好交道的能力，因为这样能够得到很多新的消息，对于人事的，对于公司战略的，对于新的项目和机会。只有这样，才能有能力分辨出哪些是好的机会和重要的，哪些是切合公司的Vision，哪些是战略性的。如果没有这种能力，那么就只能接那些别人挑剩的活，好不到哪里去，干辛苦活，还不一定能得个好。
6. 要看这个主管对公司的贡献度，这个要衡量战略性的，战术性的，还是日常性的。比如我在做项目经理的时候，以前公司的CFO对于SAP COPA这块不熟悉又特别想要这个功能，而内部的实施顾问按照之前定的合同，不愿意花太多时间做Demo和Training。所以我找了以前的同事，我们Pay他来做Demo，让CEO/CFO熟悉和知道这个到底如何做，也最后决定要实施这个功能。比如当时的CRM，新来的CEO觉得由于technical support的第三方同时也支持我们的竞争对手，而且双方关系很好，怕数据泄露，所以打算换CRM系统，我能够到市场上和通过自己的关系找到这些供应商。我个人认为，这些就是资源和价值了吧。
Pippa 发表于 2021-1-30 14:50 static/image/common/back.gif
我个人还是倾向于认为数据分析可以作为个人技能发展的一个思路和方向。前提是你已经是某专业/行业的资深 ...
承诺了要回答你这个问题的哈，现在说说：
传统的系统构架，由于集中性不够高，所以经常性的会出现不同的部门使用不同的应用平台(application platform)来管理每个部门的数据，并且由于这种应用平台和数据的特殊管理模式，使得集中化和标准化的数据分析往往很难应用到这种模式中。因为这种系统和数据应用的特殊性和客制化性。特殊和分散化的系统构架，使得最终用户或者SME成为解释数据，和理解数据的核心，所以在这种模型下，那些懂业务，懂数据，懂一些开发的全能型人才变得不可或缺。
新的系统架构，对于大公司特别是国际化的特大型公司，近十年来都在集中和标准化应用和数据平台，上线集团公司层面上并应用到个部门的标准和集中化的系统。由于有了标准的应用平台（比如CRM，ERP，Planning and Consolidation，HR & Payroll），公司里的数据流程也变得大大的标准化和易于理解，通用性更高了。而大数据平台，云数据池的推出，又强化了把这些标准平台的数据集中到统一的数据平台上，比如AWS Redshift，Oracle / SAP Data Lake，于是很多这些大公司，都集中化了数据分析的这个部门，以提高标准化和开发管理效率。我近几年工作的几个公司，都是在实现统一化的ERP/CRM系统的同时，花很大的精力和费用实施Data Lake和标准化的分析系统的。最大的好处是，上层能够得到统一的分析和数据透明。
我近一个多月来，基本搭建起来了一套按技能图表展现的构架，算是搭好了平台和各个方面的专才，并尝试开始管理和协调相互有效的合作模式。这里面核心的有Business Owner（需求方和业务方向的贡献者），Data Visualisation Specialist，ETL/Data Engineer，其他的参与者是Business SME，Business / Data Analyst。
Pippa 发表于 2021-1-30 14:50 static/image/common/back.gif
我个人还是倾向于认为数据分析可以作为个人技能发展的一个思路和方向。前提是你已经是某专业/行业的资深 ...
你提到的这个问题，我觉得很值得探讨一番。
举一个不一定特别关联的例子：在网上购物平台刚刚流行起来的阶段，当时的Walmart如日中天，Amazon业务扩展的还不错。当时对于Walmart来说，觉得还是保持好现有市场和业务是核心，并且把网上平台购物增加为一个很好的发展方向，辅助原有的业务类型。而Amazon的业务类型和发展方向，却完完全全的没有依靠线下的类型，继续往新的互联网和技术平台发展，强化网上购物的体验。
这个就是发展模式和对未来趋势的理解的不同了，这十年来在业务和数据平台越来越标准化和集中化的过程中，如果这个标准化趋势继续发展下去，那么掌握这些业务和数据平台技能的人员，会变得越来越重要。甚至在未来的某个时候，可以直接的和Business Owner交流做出东西，而中间的人员或者流程在分析和开发的过程中都可能被Eliminated。我是这个趋势的支持者，所以对我来说，我坚持并一直在实现这种Operating / Collaboration Model
你怎么有 75% off？ 网上只有15%
hxsh2000 发表于 2021-3-19 14:15
承诺了要回答你这个问题的哈，现在说说：
传统的系统构架，由于集中性不够高，所以经常性的会出现不同的 ...
你说的应该是数据分析、报告需求被列入构建新系统之前的design requirements。这点早就是新系统上架的标配了。我的体会是，新系统上架这个过程因为时间、人力和预算的限制，不可能照顾到每个层面的数据需求。单说一项，派进project team里所谓subject matter expert不一定对自己部门需求有全面了解。所以新系统上架后肯定还会有几波customisation 需求的。我已经经历过五六趟新ERP上架项目了，没看过例外的。最近公司又要上新的ERP啦，我一看project team名单就知道后面会有什么问题了。历史总在不断重演。