关于技术选型:火山引擎-DataLeap-下-Notebook-系列文章一技术选型之路

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群Notebook 是一种反对 REPL 模式的开发环境。所谓「REPL」,即「读取-求值-输入」循环:输出一段代码,立即失去相应的后果,并持续期待下一次输出。Notebook 通常使得探索性的开发和调试更加便捷,在 Notebook 环境,用户能够交互式地在其中编写代码、运行代码、查看输入、可视化数据并查看后果,应用起来非常灵活。 在数据开发畛域,Notebook 广泛应用于数据清理和转换、数值模仿、统计建模、数据可视化、构建和训练机器学习模型等方面。 然而显然,做数据开发,只有 Notebook 是不够的。目前火山引擎 DataLeap 数据研发平台提供了工作开发、公布调度、监控运维等一系列能力。研发团队将 Notebook 作为一种工作类型,退出了火山引擎 DataLeap 数据研发平台,使用户既能领有 Notebook 交互式的开发体验,又能享受一站式大数据研发治理套件提供的便当。 如果还不够直观的话,试想以下场景: 在交互式运行和可视化图表的加持下,用户很快就调试实现了一份 Notebook。简略整顿了下代码,依据应用到的数据配置了上游工作依赖,上线了周期调度,并棘手挂了报警。之后,基本上就不必管这个工作了:不须要每天手动查看上游数据是否就绪;不须要每天来点击运行,因为调度零碎会主动帮用户执行这个 Notebook;执行失败了有报警,能够间接上平台来解决;上游数据出错了,能够请零碎发动深度回溯,对立修数。2019 年末,基于业务需要决定反对 Notebook 工作的时候,火山引擎 DataLeap 研发团队调研了许多 Notebook 的实现,包含 Jupyter、Polynote、Zeppelin、Deepnote 等。Jupyter Notebook 是 Notebook 的传统实现,它有着极其丰富的生态以及宏大的用户群体,置信许多人都用过这个软件。 事实上,在字节跳动数据平台倒退晚期,就有了在物理机集群上对立部署的 Jupyter(基于多用户计划 JupyterHub),供外部的用户应用。思考到用户习惯和其弱小的生态,Jupyter 最终成为了火山引擎 DataLeap 研发团队的抉择。 (图:Jupyter Notebook 界面) Jupyter Notebook 是一个 Web 利用。通常认为其有两个外围的概念:Notebook 和 Kernel。 Notebook 指的是代码文件,个别在文件系统中存储,后缀名为ipynb。Jupyter Notebook 后端提供了治理这些文件的能力,用户能够通过 Jupyter Notebook 的页面创立、关上、编辑、保留 Notebook。在 Notebook 中,用户以一个一个 Cell 的模式编写代码,并按 Cell 运行代码。Notebook 文件的具体内容格局,可参考 The Notebook file format ...

April 18, 2023 · 1 min · jiezi

亲历创业公司如何死掉的

亲历,创业公司如何死掉的虽然目前尚未离职,但期限迫在眉睫。失望过后还得整顿自己再出发,新开始之前老感觉缺点东西,还是回顾一下东家是如何在这条创业路上死掉的,顺便记录下,已警示后来的自己。1. 目标宏达,出发点错误大Boss目标太过宏大,短时间内无法开发,项目周期太长, 项目落地时出发点偏离,导致刚开始就造重复的轮子。 2. 技术团队人员分布不合理领导在寻求技术团队领导太过感性(后来才知道谈了一个就确定了),技术领导招人的方向出现偏差(以前端全栈为标准),导致出现5个前端没有后端,迫不得已才招1个后端,技术选型也很不友好(用到的技术实践的公司很少)。 3. 缺少专业产品经理和懂市场人员后来才知道产品经理是UI零时转型,产品开发没有切合市场需求, 想当然。 4. 领导不懂技术,缺少团队赋能大boss传统企业出身,不懂互联网技术,作为创业公司很少和团队见面,也不去主导产品的方向。 5. 工资迟发,影响氛围工资长期迟发, 导致员工情绪很大程度受到了影响,人员变动也频繁。 ...我得到了什么学习领导的的一些理念。看清楚创业公司不应搞犯的错误。主导从0到1的项目过程,尝试做了小团队的管理者。发现自己对产品经理非常感兴趣,除了coding,产品将是我的第二职业,非要排出的第三的话,不想做厨师的coder不是好PM。对于如何生活,有了新的认识,当然也是受领导的感染。创业不是有钱就能干的,很大可能是一帮志同道合的人没钱给干成了, 所以初 期的创业公司招人这个路数风险很大, 找人才是上策。见识了当下融资的困境和面临的问题, 必须要有的硬核担当,总的来说,当下的经济形势,资本已将对待A轮公司的标准移到了种子轮或者天使轮, 所以创业更需要硬核产品,砸地必须有坑的产品,这也资本才可能青睐。责任心和正道必须是创业者必须有的基本素质。选择前要慎重, 选择后要要极力证明自己选择的正确性,而不是盲目草率的重新选择。领导看过后觉得写得很好, 欣慰之至,还点赞了, 期望新的开始能让自己变得更好更强大,也希望能给新东家贡献自己的力量。

May 9, 2019 · 1 min · jiezi

不要争了!技术选择没那么重要

摘要: 技术没有高下之分,做好产品才是王道。很多开发者非常热衷于比较不同技术,比如:Angular 是否比 Vue.js 更好?Node.js 能否取代 Java?究竟应该选择 MySQL 还是 MongoDB 呢?认真对比不同技术之间的优劣是非常有价值的事,可以加深我们对技术的理解,根据业务场景选择更合适的技术。但是,对技术选择过于较真,争得面红耳赤,对于产品或者个人来讲,都是没有必要的。因为,技术选择真的没有那么重要。技术只是产品的实现手段对于一个产品,技术仅仅只是实现手段。或者说,条条大路通罗马,这个产品可以用 Angular + Java + MySQL 实现,那它用 Vue.js + Node.js + MongoDB 来实现也完全没问题。不同技术在细节上确实有不少区别,但是它们在本质上它们是一样的,Angular 和 Vue.js 是前端框架,Java 和 Node.js 是编程语言,MySQL 和 MongoDB 是数据库。产品面向的是用户,而不是开发者自己,在开发者开来,选择某个技术栈也许很重要,但是对于用户来说,很抱歉,他们完全不关心!用户关心的是:是否有我想要的功能?UI 设计是否合理?BUG 有没有及时修复?生活中,我们都是用户,我们每天聊微信、刷抖音、逛京东、打王者荣耀,你会关心它们的后台是用 Java 还是用 Node.js 吗?如果产品的技术栈还没有确定,选择一个目前使用者足够多并且保持更新的技术就好了,用的人多的技术不会太差,还在更新则不用担心 BUG 没人修复。如果产品的技术栈已经确定了,那就更简单了,直接撸代码啊;即使技术选择有一些问题,抱怨是没有用的,也没人愿意为了你的个人偏好去换技术栈,除非是产品需要。作为开发者,应该利用自己已经掌握和需要学习的技术去实现一个好用的产品,满足用户的需求。如果产品没有成功,有可能是产品的需求有问题,没有市场;有可能市场很大,但是推广得不够成功;有可能推广得不错,但是商业模式有问题,赚不到钱…当然,也有可能是技术问题,是技术不够好,而不太可能是技术选择错了。Fundebug 的技术栈当我们决定做Fundebug的时候,现在所使用的技术并不熟悉,而对于它们的同类型技术,我们更是一无所知。所以,这里也不存在所谓的选择的问题,我们使用了自己会用的技术:Angular + Node.js + MongoDB。它们使用者足够多并且保持更新,符合我所说的标准。对于这样的似乎有些轻率技术选择,基本上没有对我们产品开发造成什么困恼,用户需要的功能我们能够尽量满足。或者说,正真困恼我们的从来都不是技术选择所造成的问题,而是产品设计、市场推广、用户沟通等问题。我会负责一些后端开发,对于我们的技术栈,我热爱 Node.js,因为它语法简洁,文档清晰、有着简单的异步编程模式和丰富的 NPM 生态系统;我也很喜欢 MongoDB, 因为它的数据模型足够灵活,然后文档非常详细,运维起来轻松很多。这里没有丝毫冒犯 Java 和 MySQL 的意思,因为我几乎完全没有接触过它们,所以无法进行比较。我也相信,Java 和 MySQL 也非常优秀,如果我们当初选择它们应该也没有什么问题。对于 Fundebug 的技术栈,我经常喜欢和人炫(chui)耀(niu)的一点是我们的所有应用包括 MongoDB 都是运行在 Docker 容器里面,这极大的简化了我们的运维工作。把应用打包到 Docker 镜像里面之后,我们只需要在集群上安装 Docker,而不需要安装任何应用,就可以在任意节点运行任意应用。我们可以根据需要(重新分配 CPU 和内存资源或者进行多副本扩容)随时在任意节点之间移动应用。在集群需要增加新的节点时,也只需要安装 Docker,这个新节点可以用来运行任何应用。我一直在思考 Docker 的价值,发现它确实很有用。所谓“如果你手里有一把锤子,所有东西看上去都像钉子”,我用了将近 4 年 Docker,非常熟悉也非常喜欢,那我当然觉得 Docker 是个好东西。如果我们不使用 Docker 会怎样?运维当然会比较痛苦,但是我们应该也没有什么大问题。大量公司还没有 Docker 化,它们都活着好好的。我对技术的迷思和很多开发者,我也曾经迷信过一些技术,谁没年轻过呢?大三暑假学了一门叫做《大规模数据处理/云计算》的课,听着很炫酷,其实主要是学习 Hadoop,用 Hadoop 去实现 PageRank 等算法。PageRank 是 Google 创始人提出的网页排序算法,是 Google 搜索引擎的基础。Hadoop 如此厉害,居然可以造 Google,当时年少无知,觉得学会了 Hadoop 就够了。事实上,知乎上也有类似的问题:Hadoop 就业前景如何?但是,现在呢?Hadoop 的光环早已褪去,它只不过是对大规模数据进行批处理的常规工具,并没有太大门槛。而 Hadoop 生态系统还有很多其他工具比如 Spark, HBase 等,仅仅使用 Hadoop 完全不足以应对各种复杂业务场景。读研的时候第一次接触 Docker,被深深吸引,因为 Docker 可以完美解决软件安装和配置的问题。大学毕业设计我曾花了至少 1 个星期时间配置一个 4 个实体机器组成的 Hadoop 集群(当时不熟悉 Linux),而使用 Docker 的话,无需安装,可以直接运行。我的开源项目hadoop-cluster-docker就是将 Hadoop 集群运行到多个 Docker 容器中,这个项目已经累积了近千个 Star,可见大家对于使用 Docker 简化 Hadoop 安装还是非常认可的。我接触 Docker 的时间算是很早了,Docker 最热门的时候还收到过大公司的相关工作邀请,因此觉得熟悉 Docker 非常好,这次算是站在风口了。而现在呢?Docker 已经逐渐普及化!因为 Docker 并没有什么高深之处,上手非常快。国内很多大公司,例如腾讯, 京东等早已 Docker 化。无论是 Hadoop 和 Docker,多少都算是改变世界的技术,也曾经大红大紫,现在依然在发光发热,但是早已不再自带光环效应。这也是技术发展的客观规律,新的技术不断出现,它们解决了某些问题,受到热捧,然后逐渐普及,被更新的技术所超越甚至取代。事实上,我从来也没有依靠 Hadoop 或者 Docker 去工作,它们也是靠不住的。技术发展如此之快,怎么可能一招鲜吃遍天,现在热门的技术迟早会冷却,甚至会被淘汰。再说,技术是为工作服务的,而不是围绕技术栈去圈定自己的工作内容;工作的时候,需要什么技术就学习什么技术,永远呆在舒适区是一件很危险的事情。参考技术路线的选择重要但不具有决定性关于FundebugFundebug专注于JavaScript、微信小程序、微信小游戏、支付宝小程序、React Native、Node.js和Java线上应用实时BUG监控。 自从2016年双十一正式上线,Fundebug累计处理了10亿+错误事件,付费客户有Google、360、金山软件、百姓网等众多品牌企业。欢迎大家免费试用!版权声明转载时请注明作者Fundebug以及本文地址:https://blog.fundebug.com/2018/07/19/technology-selection-is-not-critical/ ...

March 19, 2019 · 1 min · jiezi

前端项目技术选型

技术选型做技术选型时,要考虑实际的项目需求,不要跟风(时髦驱动开发)和凑热闹(热闹驱动开发)。踏实的研究和对目标成果的认真思考。面临的是一整套技术、方案、规范和产品的选型考虑因素项目因素(天时)明确项目的规模、重要程度。项目的需求(特别是非功能性需求)也会限制技术的选型。团队因素(人和)考虑团队成员的技术组成。考虑招聘新人对技术的接纳程度技术因素(地利)技术特性考虑(前景、易用、易维护)向上拔高整体考虑(扩展性、灵活性、弹性、稳定性)正确的流程根据业务场景提出至少两套及以上(竞品公司、新技术、团队讨论、高工指导)可用的技术选型,然后进行各方面之间的对比。先测试 -> 再研究 -> 最后决定先快速搭建小型的以产品为原型的Demo。不要从博客学习,而要从经验学习,然后组件成员讨论利弊,产出对比结论。判定标准明确选型的需求和目的,列出需要考虑的各种因素以及评判标准(方便后期在各原型之间进行对比)。寻找技术和产品时,范围尽量扩大一点,搜集尽可能多的候选技术和产品。初步筛选。把一些由于各种限制无法选择或明显不可能的技术或产品排除(一定要列清除理由)。最后流出2个及以上的备选方案。做一些详尽的调查和分享。集合第一条的评判标准列一个技术选型分析表。咨询其他产品是否使用过这个技术,求教实践经验。注意事项进行可行性分析。不要思维定势,不要赶时髦。考虑后期兼容,所以尽量保证技术选项的扩展性、灵活性和弹性。架构一旦则确立尽可能统一,避免一个领域引入太多相同或不同的技术。

November 1, 2018 · 1 min · jiezi