在字节跳动,基于深度学习的应用遍地开花,工程师关注模型效果的同时也需要关注线上服务一致性和性能,早期这通常需要算法专家和工程专家分工合作并紧密配合来完成,这种模式存在比较高的 diff 排查验证等成本。 随着 PyTorch/TensorFlow 框架的流行,深度学习模型训练和在线推理完成了统一,开发者仅需要关注具体算法逻辑,调用框架的 Python API 完成训练验证过程即可,之后模型可以很方便的序列化导出,并由统一的高性能 C++ 引擎完成推理工作。提升了开发者训练到部署的体验。 然而,完整的服务通常还存在大量的预处理/后处理等业务逻辑,这类逻辑通常是把各种输入经过加工处理转变为 Tensor,再输入到模型,之后模型的输出 Tensor 再加工成目标格式,一些典型的场景如下:
本文面向 BitSail 的 Connector 开发人员,通过开发者的角度全面的阐述开发一个完整 Connector 的全流程,快速上手 Connector 开发。
从 2017 年到 2020 年,我花了大约 4 年的时间,从零到一,实现了一个可切换 WebGL 和 Canvas2D 渲染的,跨平台支持浏览器、SSR、小程序,基于 DOM 结构和支持响应式的,高性能支持批量渲染、针对可视化场景优化、支持 WebWorker 的图形系统——SpriteJS。 在这个“造轮子”过程中,我一步步将一个很简陋的渲染库,变成一个能够支撑可视化应用和游戏开发的,还算不错的一个图形库,其中有许多积累,也有许多思考。因为毕竟是两年多前的研究,有些细节可能记得不是特别清晰,其中有些特性也许已经有点过时,但我想,还是有不少内容能给大家带来参考和启发。
随着低代码的普及,在低代码平台上构建企业级应用逐渐成为生产趋势。同时,随着低代码技术的提升,越来越多的复杂应用在低代码平台中完成。在其研发生命周期中,低代码开发者就会面临多人协作、并行开发、维护多版本的场景。而现有的低代码平台普遍缺乏这一能力或支持较弱,导致对协同开发的成本较高,限制了迭代的效率。
在使用BI工具的时候,经常遇到的问题是:“不会SQL怎么生产加工数据、不会算法可不可以做挖掘分析?” 而专业算法团队在做数据挖掘时,数据分析及可视化也会呈现相对割裂的现象。流程化完成算法建模和数据分析工作,也是一个提效的好办法。 同时,对于专业数仓团队来说,相同主题的数据内容面临“重复建设,使用和管理时相对分散”的问题——究竟有没有办法在一个任务里同时生产,同主题不同内容的数据集?生产的数据集可不可以作为输入重新参与数据建设?
前端程序员最容易搞出 P0 事故的就是白屏,PC 上的白屏我们比较好调,打开 Chrome Devtools 就能看见。 但是手机上的白屏怎么调?以及远程用户手机上的白屏又该怎么调?这时候就需要使用远程调试的技术了。
本文整理自火山引擎开发者社区技术大讲堂第四期演讲,主要介绍了数据湖仓开源趋势、火山引擎 EMR 的架构及特点,以及如何基于火山引擎 EMR 构建企业级数据湖仓。