WeDataSphere
WeDataSphere copied to clipboard
WeBankFinTech
WeDataSphere is a financial grade, one-stop big data platform suite.
一、使用背景 可能和其它公司不太一样，我们公司主要是以接项目开发为主，这二年数据治理、数据分析方面的项目越来越多，大公司的项目本身就有数据开发平台，我们可以直接使用，用过的有阿里的Datawork,华为的dayu，星环的，有些没有数据没有数据开发平台我们都使用这个单一的开源软件 zeppelin、cdh、dolphine、帆软等也能完成任务，这样对于做项目投入成本很高，所有部门解决自己开发一个数据平台，正好这个时候看到dss+linkis这个是国内优秀的开源项目，在这里先感谢微众的小伙伴们的贡献和一直一来的热心指导，基本可以满足我们的要求，DSS组件化的设计也是我们需要的，经过测试后，就选定在此基础上做二次开发。 二、使用情况 现阶段还处于整合阶段，DSS有些功能直接可以满足我们需求，有些功能还需要我们改造，现在的改造地方如下：  1）整合公司现有的系统管理平台也现实用户权限的管理。 2）整合公司现在的编目系统 3）整合dolphinscheduler调度平台 4）整合公司BI系统 三、期待的功能与改进 1、元数据管理 2、数据API共享 3、执行SQL时（初次或者一段时间后会重新启动引擎）效率有待提高 4、数据开发那边没有办法直接引用资源 再次感谢微众的小伙伴们的贡献和一直一来的热心指导。
**应用场景：** 公司的数据分析团队目前使用的是sas软件，界面较落后，需要在每台机器上都安装客户端，单机环境，依赖于机器配置，无法与集群速度相比，缺少高可用高并发的特性。目前公司的数据处理方式，需要先将数据下载到本地，再通过sas编写脚本处理，原始数据、脚本、结果数据会极大占用机器空间。并且sas是国外的成熟商业软件，每年的采购价格不菲。为了节省开支，以及支持办公软件国产化，所以寻找国内优秀的开源软件用以逐步替代sas。 **解决问题：** 使用了dss与linkis组件，以页面化的形式开发脚本，方便快捷，能够使用多种类型脚本直接操作hive数据，不需要数据导出到本地后再处理，对sas节省资源开销，相比较于sas方便的管理HDFS中的文件。目前阶段处于分析人员使用dss开发数据处理脚本，以及使用过程中的问题修复。 **使用情况：** 目前阶段处于linkis适配公司环境，以及修复使用问题，还未新增功能或者新引擎支持，后续如有会分享出来。 公司的大数据相关环境有专门的团队负责，我们在安装使用的过程中进行了一系列的适配： 1.大数据环境使用的是CDH 5.16.1，而源码是社区版本，所以根据具体的版本我们进行了重新编译。 2.HDFS权限被ACL接管，不与Linux系统权限同步，所以直接用hql脚本查询数据时，遇到了HDFS目录无权访问的情况。经过沟通了解到数据团队规定必须通过jdbc，经过域账号验证后，才可访问hive数据。所以在使用中暂时将hql和sql的脚本隐藏，主要使用jdbc和python脚本来处理数据。 3.公司spark版本是2.4.0.cloudera2，修改了后台识别版本的逻辑。 4.CDH对版本校验比较严格，所以修改了pyspark.zip包中的content.py文件，将社区版中的分支判断补充进来： ```py if allow_insecure_env == "1" or allow_insecure_env.lower() == "true": warnings.warn( "You are passing in an insecure Py4j gateway....
### 技术选型 公司所处的是金融服务类的行业，需要给不同银行/公司实施一整套的项目。所以筛选了一圈发现DSS是跟公司场景最吻合的。 ### 改造过程 （1）单点登录 因为公司的服务方向是基于业务会有很多系统一整套的输出，所以第一个改造过程就是让DSS接进公司的单点登录系统。 第一步就是把dss整套先都搭建起来，过程很酸爽 :-）但排除各种问题完整搭建起来后还是非常有成就感的。 在整合过程中顺便提了个issues：https://github.com/WeBankFinTech/Linkis/issues/489 （2）脚本加密 因为公司规划里不想让客户知道具体执行了什么脚本，所以对所有的存储文件、脚本都做了加密，只有在界面跟底层引擎执行时才能看到具体真正的执行逻辑。 （3）适配Oracle、pg 默认DSS jdbc和visualis对 Oracle/pg的适配有些bug，因为后续的输出公司很多都会有极大可能用到Oracle，所以针对这个改动了一些 （4）界面适配 根据公司系统的风格，重新设计了首页，并且给workspace增加了删除的功能 （5）引入Schedulis 默认的DSS全家桶安装包里只有standalone的azkaban，不符合输出的要求，而且发现Schedulis也开源了，Schedulis还是添加了很多实用功能的，比如web节点的高可用，支持用户管理/exec的用户分配管理等等，所以用Schedulis替换了原先 standalone 的 azkaban。过程发现 Schedulis 对 azkaban 的改动还是蛮大的（webank牛逼） （6）优化一键部署脚本 原先的一键部署脚本因为这里引入了Schedulis，并且去掉了qualitis，所以有稍稍优化一下，也优化了一些再分布式部署时的一些小问题 （7）所有数据文件接入HDFS...
**一、使用背景** - dss+linkis是国内优秀的开源项目，感谢微众的小伙伴们的贡献和一直一来的热心指导。 - 我司的大数据平台，包括数据集成、数仓、元数据、数据质量、统一调度、可视化、API开放等。但是比较大的缺憾是没有数据开发模块，在没有dss+linkis之前，我司都是使用hue开发脚本，没有统一的界面进行开发维护，也很难与现有的产品体系集成。 - 自从接触到dss+linkis，和其他相关产品进行比较，感觉dss+linkis非常棒，非常适合我们，所以一直研究如何在我司现有产品体系中使用。 **二、使用情况** 目前阶段处于初步引入以及修复使用问题阶段。 - 引入数据开发Scripts模块，与我司现有的统一认证进行集成，并把该模块整合到现的大数据平台体系中，作为单独的数据开发模块； - 数据开发Scripts管理的脚本与其他模块打通，如与现有调度中心模块、工作流开发模块集成； - 使用linkis作为我们数仓适配层，数仓上层所有的模块通过linkis与数仓交互，上层应用直接通过API接口与linkis交互，无需注意底层的技术细节； - 我司使用的环境是CDH6.0.1版本，根据使用重新编译后，有少量jar冲突需要手工处理； - 目前在初步接入阶段，在QC测试及使用的过程还是有不少问题需要去摸索、解决，希望在后续不断熟悉的基础上不断引入dss+linkis更多优秀的模块。 **三、期待的功能与改进** - 各个功能模块职责清晰，各模块之间独立性高一些，因为DSS中包括很多模块，但是在有些场景下只需要集成其中一个模块 - linkis的各个引擎第一次执行时，启动时间较长，期望能有改进； - linkis对通用算法库的支持，如spark Mlib； - 可以有界面对用户和数据权限进行统一管理； -...
## 天翼云对DSS的公有云改造和后续思路 ### 背景 在此之前，中国电信对内的大数据都没有一个统一的入口，我们大数据团队的负责人刚神很早就关注了wedata社区。在开源方面，DataSphere Sdutio（以下简称DSS）作为大数据一站式开发平台是非常优秀的，同类竞品也比较少或者不够完善，所以我们团队选择了DSS。在我们内部使用一段时间后大家的反馈都还不错，同时领导也提出了把dss+linkis改造成公有云版本的建议，我们团队经过讨论达成一致意见并迅速的开展了相关工作，历时2个多月的时间改造完成并且上线。在这期间得到社区的大力支持，特别是强哥、平哥、黄哥等微众大佬的鼎力支持和问题解答，在此深表感谢。以下就改造工作简单做一下分享： ### 对接天翼云的单点登录 linkis-gateway本身是支持单点登录的，实际接入天翼云cas单点登录也遇到了一些问题，比如：cas回调接口会被网关拦截；2.dss默认设置登陆状态的方法需要移到cas模块，getbaseInfo的设置登陆需要去掉。其他的接入步骤按官方步骤基本上就能正常运行。这块我们也是做成了配置（包括回调接口，重定向地址，ctyun自己的还有appid等） 第一步新建了一个单点登录的模块（我们是ctyunsso）实现SSOInterceptor ``` trait SSOInterceptor { /** * 如果打开SSO单点登录功能，当前端跳转SSO登录页面登录成功后，会重新跳回到DSS首页，这时DSS前端再次请求gateway， * gateway会通过调用该方法获取已SSO登录的用户，然后将用户写入cookie，保证后续请求可直接放行。 * 您需实现该方法，通过Request返回用户名。 * @param gatewayContext * @return */ def getUser(gatewayContext: GatewayContext):...
## DSS应用场景 大数据对于公司的贷前、贷中、模型、风控业务以及客户生命周期管理等各个方面都起到了至关重要的作用，在这个瞬息万变的时代，数据具有时效性，快速高效又安全统一地利用数据是关键。 在未使用DSS前，对业务方来说，作业状态进度并不透明，各业务科室的分析作业没有统一的管理，作业调度发布流程繁琐，发布随意，报表开发复杂，缺乏一个高效的、全流程打通的数据分析平台；对于数据团队来说，管理调度任务非常繁琐，需要耗费大量人力协助业务方开发。 DSS是一个可以解决上述问题的统一数据分析平台，DSS为各个业务科室提供了自助代码开发，任务测试，查看任务状态，取数、创建工作流程、跑批调度以及数据可视化等一站式服务，为业务开发人员免去了很多不必要的沟通联调时间，也让数据分析任务的发布更加流程化，调度发布操作也更加简便和人性化。DSS内置了数据交换，数据开发，数据数据质量，数据可视化和数据发送等功能，业务开发人员通过DSS完成几乎所有的任务。不仅如此，DSS上层支持多种计算引擎，方便业务方开发，也可以很方便地定制和引入新的计算引擎，同时在下层又能兼容多种数据源，对现有集群环境很友好。 ## DSS解决的问题 在萨摩耶数科， DSS作为统一数据分析平台被推广到各个业务科室使用，一些旧任务也开始逐步迁移DSS平台，通过DSS平台来管理。DSS主要解决了以下问题： 1.数据开发分析效率低，需求上线周期长 2.人力投入大 3.数据发现效率低，存储成本高 4.无法提供统一的数据服务 5.任务缺乏统一管理 6.可视化报表开发效率低 ## DSS最佳实践 Linkis、Visualis、Schedulis和工作流在整个大数据平台中的使用频率很高，业务方直接使用这些组件来完成开发、测试、调度和上线工作。 ...
# 背景 我们曾经的大数据平台，是基于CDH构建的，随着大数据两大商业公司CDH和HDP宣布合并，将不再更新新的版本； 我们调研了当前大数据平台的发展状况，对于我们这样体量很大的平台来说，自主研发将极大节约使用商业版的license成本，因此我们准备走上大数据平台核心技术自主研发的道路。 当时设计的架构如下，（这是去年画的架构，现在架构已经有很多优化，后面有空了我会画一个新的）：  其中数据基础能力平台，我们选择基于围绕当时最新的社区版Apache Hadoop3.2 、Spark 3.0以及Hbase 2.2版本进行迭代优化，这样做除了很多性能提升以及新特性之外，最重要的一点是它支持滚动升级 ，代表着我们以后可以随时在用户无感知的情况下升级集群，以后跟着开源社区混了，也能更方便地把我们自己的优化与社区共享；目前已经稳定运行一年，扩容到单集群1W+理论上没有问题，这里暂不细说； 而运营与运维平台，在调研了市面上已有的开源产品后，我们决定自己从头研发，因为已有的包括Ambria等优秀的软件，在我们大规模平台的场景下支持得并不好，这里也暂不细说； 比较头痛的是数据开发与服务平台的技术选型； # 选型 首先，我是非常不赞同上来就自己重新造轮子的，我们人力资源是有限的，整体技术水平也是处于学习阶段，并且时间紧张。放眼望去，已有的数据开发与服务相关的工具还是蛮多的，比如Apache Zeppelin，Apache Livy，Hue等等我们都有用过，我们也曾经基于Apache Livy封装研发了一个作业开发打包提交的工具。但是，这些工具还是相对比较割裂的，因为对于用户来说，如果各个功能都是非常割裂的话，用户体验是比较差的，为了提升用户体验，也为了增加大数据平台的安全性，我们希望能打磨一款能“ 统一作业提交入口的，一站式的大数据开发与服务平台”，在调研了业界众多产品后，我们最终选择基于WDS开源社区的开源产品进行打造，原因如下： 1. Linkis满足了我们 统一入口 的想法，linkis本身从设计上就是为了统一入口而设计的，并且已经经过了微众银行自己内部业务的验证，统一入口能够屏蔽底层的复杂性，且保证持续智能优化的可能性；并且Linkis对资源的管控非常细粒度，这是更加安全可控的； 2. DSS满足了我们 一站式数据开发与服务 的想法，DSS本身是可扩展的，并且工作流开发与底层的具体调度是解耦，这为我们未来的想法提供了很多可能性； 3....
链接：https://blog.csdn.net/ocean_zhc/article/details/109743366 
## 应用场景： 本人是世界XXXL大厂的xxxxxxxx...s组小组组长一名，无头衔。迫于生计，去年开始陆续出去接客，接活。 作为没见过大世面的搬砖小工头，见到客户，只会小声讲我们的产品能做数据的离线处理。没想到客户张口从叙利亚问题谈到美国总统大选，彷佛我们需要交付的特性直接关乎了世界和平。 经过几番周折和理解，基本上搞清了客户对于数据处理的主要诉求： - **拖拉拽。** - **一键式。** - **智能。** - **安全，安全，安全生产！** - **明天能上线吗？** 本人之前是接触过hue的，但是因为是java出身，没有用python做过工程，怕表演砸了饭碗，所以直接放弃了用Hue糊弄一下的想法。 在度娘上徘徊了几圈，经过几番周折，终于从谷歌上搜到了托管在微软的github上的webank开源的linkis，最终也锁定了DSS。 ## 解决的问题： 1 **标配“拖拉拽”**  2 **“轻松”一键式** 1）界面上的一键开始，看图不解释。  2）安装部署的一键式 1. 容器化后各个服务通信问题，注册到eurka上的示例通过ip加port方式。 2....
应用场景： 公司的数据开发团队目前使用的是hue和notepad记事本开发脚本，开发较落后，需要在不同的环境hue界面测试开发脚本，没有统一的界面进行开发维护，而且出错率高，没有自动提示和管理。目前公司数据的处理方式是先用记事本把脚本写好，然后都不同的hue环境测试开发脚本运行结果是否一致。然后在上传脚本到调度平台的脚本目录，并且配置好调度平台调度时间，依赖以及重试次数等配置参数，测试通过后然后在上线的生产环境。此过程较为繁琐，而且脚本不易控制，所以我们使用开发平台与linkis引擎集成，通过用户绑定ldap用户执行不同环境下的脚本查看结果，存储开发脚本规范脚本编写，极大的提高了效率和使用方式。 解决问题： 使用了我们的用户体系与linkis组件，以页面化的形式开发脚本，运行、测试不同执行环境，打包，发布，上线。方便快捷，能够使用多种类型脚本直接操作hive数据，不需要数据导出到本地后再处理，对开发脚本节省开发时间，相比较于以前的方式的管理HDFS中的文件。目前阶段处于分析人员使用linkis引擎开发数据处理脚本，以及使用过程中的问题修复。 使用情况： 目前阶段处于linkis适配公司环境，以及修复使用问题，还未新增功能或者新引擎支持，后续如有会分享出来。 公司的大数据相关环境有专门的团队负责，我们在安装使用的过程中进行了一系列的适配： 大数据环境使用的是CDH 5.14.2，而源码是社区版本，所以根据具体的版本我们进行了重新编译。 HDFS权限被ACL接管，不与Linux系统权限同步，所以直接用hql脚本查询数据时，遇到了HDFS目录无权访问的情况，经过查看源码我们使用ldap用户绑定我们的用户项目组执行脚本，在创建ldap用户的时候我们会调用一个自己预先编好的脚本执行程序自动创建hdfs和linux用户目录。然而后期我们要对用户数据权限进行控制，所以集成了sentry，然而sentry在hive引擎中是无效的（hive引擎使用的hive beeline方式执行脚本），所以采用jdbc执行脚本，经过ldap用戶和密码验证后，才可访问hive数据。所以在使用中我们自己开发一套页面存储脚本（因为我们存放的脚本位置要根据我们的用户体系和环境体系来存储脚本，所以自己开发了一套页面）和执行脚本，主要使用jdbc和spark脚本来处理数据。 公司spark版本是2.2.0.cloudera2，所以把编译的cdh spark替换成集成的spark包，并把json4这类的冲突的包删掉，具体看linkis环境部署指南。 linkis引擎的ldap用户是不带用户组的，所以我们修改了LDAPUtils这个类的登录方法  linkis jdbc编译的包是不支持cdh5.14.2的所以把jdbc-entrance中的hive-jdbc包换成cdh5.14.2的并增加hive-service5.14.2的包，才能正常使用jdbc执行脚本。 期望功能： 日志打印：jdbc日志打印看不到异常信息，必须到jdbc-entrance的log日志目录去看，而且关键信息也只能看到jdbc Exception这种信息，无法分析问题。 结果集获取：无法获取超过5000条以外的数据，有时候获取结果集还会进度条卡死不动。 执行出错：同一用户使用jmeter并发执行50条sql，linkis报队列执行已满，不在响应，sdk不能迅速捕获异常信息。 目前版本的linkis脚本引擎启动时间过长，希望可以改善。 目前遇到了一些脚本持续停留在排队中的情况，重启引擎后才可以正常执行。 _Originally posted by @JavaMrYang in https://github.com/WeBankFinTech/WeDataSphere/issues/12#issuecomment-727215623_
Metadata
Owner
Metadata
WeDataSphere is a financial grade, one-stop big data platform suite.