type
status
date
slug
summary
tags
category
icon
password

写在前面

 
作为数据领域的techPM,自己一直有关注data stack和一些工具类的产品。在一次PM线下见面会上机缘巧合知道了bytebase,之后就被他们的Logo、官网、文档、招聘流程、远程办公、成员背景吸引,好奇这样神奇的团队到底能做出什么样的早期产品出来 🧐。
 
一直想使用这个产品,但又一直没把这件事的优先级放得那么高。上周以会落选的心态(毕竟我只是个PM,不是这个产品的核心目标用户 🤣报名了 Bytebase新手村任务,意外被通知入选了 😛(看来还是不能给自己设限hhh),这周末的P1事项就安排给了bytebase。
 
根据任务需求进行了产品体验,于是乎有了这篇文章。夸夸夸的部分集中在【2.1让人眼前一亮的功能点】和【3 summary】,其他部分主要讨论一些使用上的一些细节问题(毕竟还是要以帮助产品迭代为目的)。
 
以下是本文目录,可根据实际需求食用:
 

1 个人背景

  • a 2-year data platform PM at an indigenous tier-2 public cloud provider, focusing on privacy-preserving computing, data security, data opening, system security, product process optimization, product QA test, user experience, & etc.
  • have experiences in data mining projects, but no SWE/SRE/DBA work background
  • have experiences in using ubuntu, docker, aws rds, google bigquery, snowflake, databricks, fivetran, dbt, chatgpt, notion ai, web & data security products
  • familiar with sql, python, gitlab, jira, dbeaver
 

2 feature snapshots & thoughts

2.1 让人眼前一亮的功能点(a.k.a.我自己私心特别喜欢的)

💡
Quickstart
作为一个新用户,虽然之前零星看过bytebase的功能介绍、demo视频,但自己部署后面对左侧和顶部的一级菜单确实会一时搞不清楚逻辑,但我又不想浪费时间不分主次地逐个去点击。于是乎这里的Quickstart就能让对to-do-list有强划线习惯的我跟着这里的list去看到底都有些什么功能,这个交互真的太赞了。
notion image
 
💡
ChatSQL
作为一个没怎么写过ddl和select以外dml、以及一段时间不写select后再写时经常因为脑子记不住太细节的语法而被报错的人,有了ChatSQL后终于感觉自己终于不是拖油瓶了!!!依赖奇奇怪怪语法细节或者SQL方言的事情它可以直接帮我做,而我所需做的就是在报错后及时排错,这样太解放人类大脑了吧。发现它对中文的支持也不错后就更放心了。
notion image
 
💡
Alter schema时的及时交互
很喜欢这个schema diagram的可视化风格,比navicat和dbeavor的上世纪风格好看太多了。
notion image
看到点击删除、修改not null设置后,直接有了红色和黄色的醒目提醒,这个功能很喜欢。
notion image
notion image
这个upload和sync的功能也很喜欢。upload可以用在有别人写的/在其他地方写的sql脚本文件快速同步过来的(避免了手动复制粘贴)。sync可以检查刚刚在editor编辑的语句。
notion image
 
💡
drop table前的重命名
这个删表前需要重命名的功能,很喜欢,让人谨慎谨慎又谨慎。
notion image
 

2.2 ChatSQL使用细节问题

2.2.1 OpenAI API key 私密性问题

OpenAI的API key在产生后,便是遮挡显示,甚至没有设置可见的👁️按钮。
notion image
notion image
但是Bytebase的AI增强在输入key后,直接连,全部明文显示😲,连像密码中设置不可见👁️按钮都没有,让人有点不安心。
notion image
 

2.2.2 ChatSQL block放置位置

ChatSQL的交互是ChatGPT和NotionAI的结合体,但放置位置有点奇怪。
ChatGPT的对话框输入内容在底部,生成的对话内容在上面,这点没什么问题,因为对话内容就是返回结果,没有又一层执行sql后的返回结果。
Notion AI的对话框输入内容在上方,生成的对话内容在下方,这点也没有什么问题,因为可以直接把对话内容插入进文档中。
但这里ChatSQL放在中间,先在中间输入需求,然后自动在输入框上方生成对话,然后执行sql后再在输入框下方生成查询结果。虽然有点吹毛求疵,但这种交互确实有点奇怪。
notion image
另外,上方对话内容生成SQL语句后,有时会出现执行按钮错位的UIUX类的小问题。
 

2.2.3 结合insert需求使用ChatSQL,发现生成的SQL没把schema中要求的唯一性考虑在内

  • scenario
希望探索change data后的审核功能,模拟的场景是在department表中insert一条数据提交给tech lead审核。但我忘了具体的insert语句怎么写,于是想到了用chatsql帮我写。
  • summary
功能使用不方便之处:
💡
1)chatsql不仅可以用在select语句中,也可以应用在change data中自动生成insert/update/delete语句。但目前用户需要先到sql editor中生成带select的insert语句,不能直接在change data中的sql区直接生成,使用上很难受。 2)使用change data时,issue的creator在发现sql语句有错需要返回修改时,会被retry误导
发现了bug:
💡
1)schema editor里面的row count字段有错。 2)chatsql在生成insert语句时没有把名称唯一性要求考虑在内。
  • specific steps / how to reproduce
step1:忘了insert语句怎么写,让chatsql帮我写。看自动生成的sql语句也符合该表各字段的名称命名规范,决定在change data中去掉select后执行该insert语句。
notion image
step2:从change data进入,复制刚才的insert语句,create issue
step3:作为审核者,在看到run check都没warning的情况下,点击approve。可是结果却报错???
notion image
notion image
step4:发现error是名称唯一性约束导致的后,返回sql editor,查询department表中的数据。结果发现是有数据的(明明之前schema editor里面显示该表是没有行的)。这意味着:1)之前schema editor里面的row count字段是错的;2)chatsql在生成insert语句时也没有把名称唯一性要求考虑在内。
notion image
notion image
step5:找到错误原因后,想返回修改insert语句。直觉想法是在下面的sql区内直接修改,结果提示我这一块儿是只读的。于是以为需要retry后才能修改,可是点击上方的retry按钮后发现retry是重新执行dml语句,而不是返回到ddl语句修改。摸索一阵后才发现旁边小小的编辑按钮。
notion image
step6:重新编辑insert语句后终于成功。
notion image
 

2.3 issue review使用细节问题

2.3.1 没有disapprove,虽然提供的cancle issue也能达到disapprove目的,但cancle的说法会让人误解成删除此条issue记录

在审核schema变更issue时,当需要disapprove的时候,发现找不到入口。
notion image
notion image
notion image
notion image
虽然实验下来发现能直接通过cancle issue来拒绝变更,但如果没有拿一个sample issue来实验的话,还是不太敢直接点cancle。
notion image
 

2.3.2 报错后,retry按钮的置灰应该是和activity中的状态有联动

发现随机insert的内容违反命名规范后,想直接返回修改sql语句,但retry按钮和sql功能区都不能让我快速返回修改。
notion image
第一反应是点击retry返回修改sql,但发现retry是基于现有的sql尝试执行change data,会多一条报错。然后反应是在sql区修改,但提示这里是只读。第3次尝试点了旁边的编辑按钮后,才发现还是可以修改sql语句的,这才顺利修改。
notion image
为什么retry不是直接返回到修改sql的状态?为什么要让我进行前面2次试错?
考虑到实际生产环境中,issue的creator和reviewer应该是2个人,所以重新建了个DBA角色的用户作为creator,将这个issue分配给admin角色的用户,体验在retry时两个页面的区别。
果然,发现刚才的问题是因为creator和assignee是同一个人才造成的。creator创建issue后,由于没有retry按钮的干扰,在发现sql问题后,直接在sql区编辑被提醒后,根据人的直觉很容易点击旁边的编辑按钮进行重新编辑,就没有了刚才的问题。
notion image
但作为assignee的admin在approve后,发现因为名称唯一性问题sql执行报错,出现了retry按钮。但此时要修改错误的话,流程应该是先把issue返回creator修改sql,确认creator修改后再retry,而不是直接让admin直接retry。虽然也能根据activity来判断issue的creator是否有根据要求修改,但感觉retry按钮的置灰应该和issue的返回/或者下面activity的状态来调整。
notion image
 

2.3.3 把issue重新assign给DBA后,DBA却没有approve权限

为了体验admin/DBA/dev的角色权限差别,重新部署容器后,把默认的schema审核任务分配给DBA。但以DBA的身份登录后,却发现没有approve入口???
notion image
notion image
再做个小实验。
以developer的身份新建project后,分配给DBA。但以DBA的身份登录后,命名看到assign给自己了,点进去审核却发现还是没有approve按钮。
notion image
notion image
notion image
重新把assignee修改为admin后,以admin的身份登录,才发现有approve按钮。
notion image
notion image
既然只有admin角色的用户可以approve,那为什么assignee的下拉框要有DBA角色的用户呢?这个问题不知是否只是此次镜像的问题。
 

2.3.4 default issue name

默认的issue name是dbname+action+timestamp,但我作为用户,为了快,就懒得去修改默认名称。导致最后list里面一堆同名issue我不知道是啥,也没有显示description,就让我需要逐个点击进去看。
notion image
notion image
感觉可能默认名称修改为事件会好一些。
 

2.4 alter schema 使用细节问题

2.4.1 弹窗跳转

点击列表内容后,页面直接跳转,next按钮没什么用。
notion image
 

2.4.2 rename table时的提示

drop table前需要重命名表,这个功能非常喜欢。但这里【_del$】的正则表达式和【_del】的后缀会让人有点混淆到底要不要加【$】。比如此次重命名就先改为【_del$】后发现无法删除,才又返回改为【_del】
notion image
notion image
 

2.5 RBAC 细节问题

为了体会DBA&Developer&TechLead的工作协作,重新部署了重启拟分角色协作。
在admin创建member时没有设置密码,内心os:这里又没有自定义密码或者默认密码或者发邮件给用户让他新设置密码,那这些用户怎么登陆?
notion image
果然,登录的时候提示密码错误。点击forgot password也是要联系admin,可是我admin也没有reset password的权限啊;点击sign up也是提示用户已存在。无解。
notion image
notion image
只好新注册dev2和dba2用户,然后登录admin来修改他们的角色。
notion image
内心os:逻辑难道不应该是一开始admin在分配用户角色的时候就报错该用户不存在吗?为什么要让我分配后发现该用户无法登录,然后再新建用户,然后再重新分配用户角色?
不知这是不是镜像的问题,还是saas服务中也存在该问题。
 

2.6 system security细节问题

注册时密码没有格式及长度要求都可以注册好,密码位数不够,明显不安全。
notion image
在故意输错密码后连续20+次点击sign in,只是报错密码错误,没有出于安全问题进行账号冻结/锁定,这明显是不符合等保的基本要求的。
notion image
看到注册和登录的安全防范机制是这样的后,有点不太敢使用SSO等功能,怕因为bytebase这里有安全漏洞害我别的账户受牵连。
 

2.7 others

2.7.1 sign up时的交互提醒问题

notion image
notion image
 

2.7.2 subscription说明有点让人混淆

作为一个PM,自然会好奇Pricing方案。但看到我的subscription既是写的enterprise plan,但seat count又是team plan、subcribe也在team plan下时,内心OS:所以我这到底是什么plan?
notion image
notion image
 

2.7.3 GitOps / SSO 让人充满好奇

看到bytebase对自己的介绍是服务于GitOps工作流,想到日常和SRE+developer工作时他们的任务流的混乱,就特别想体验这个功能。
notion image
根据提示在Github完成了OAuth配置、拿到了ClientID和secret,却发现报错没有配置external url,回到新手指南配好它,结果却连github都无法访问了,还以为是配external url时候直接修改了我本机的网关。排查一通下来发现是因为我自己的梯子服务商出问题无法进行下一步,哎。SSO也是同样的梯子问题。
只有等梯子好了再重新试试。对这一块儿功能实在是太好奇了。
 

3 summary

💡
关于新手指南
get started文档写得非常清晰,从deploy到configure external url都没有遇到什么关键步骤是文档中没有提的,给文档工作点10086个赞👍。
此外,产品中的issue review/alter schema/change data/project/database/environment等功能也能够直接根据自己的认知+产品页面功能设计去一步步把流程往下推,不需要再依赖看其他文档/操作手册来进行下一步,这点非常难得,谢谢PM的良苦用心😀。
大致看了看gitbook中get started附近的其他文档和tutorial,应该会在之后使用saas产品时来逐一摸索。
 
💡
关于部署
虽然一开始会好奇既然镜像在docker hub,为什么没有docker pull就直接开始docker run,但实际操作后还是很顺利地就把bytebase的容器给拉起来了。初次部署上没遇到什么问题。
但后来想配置external url又担心影响现有的容器,就又新拉了一个容器,2个容器同时run。可能是共享了一些volumn的原因,新容器用了老容器的账户系统,但又在拼命报错,额。
于是就把2个容器删掉从头再新部署,愉快地重新开始玩耍。
但后续即使容器重新部署了,电脑关机后再重启容器,会在进入setup admin account时,页面下方疯狂报错invalid。
 
💡
关于SQL editor
自己之前用狗家的BigQuery时,就一直感叹这SQL editor做得也太好了吧。现在看到一款才做没多久的产品能够媲美当时用狗家产品时的体验,就很惊喜。
再加上现在接入OpenAI API后,直接解放sql女工!
之后探索其saas产品如果发现能完美契合自己的其他常用的数据库/RDS的话,之后的sql editor应该就选它了,navicat/dbeaver/sqltron这种单点工具应该也就放弃了。
 
💡
关于对Bytebase核心功能的探索
此次产品体验真的又应证了那句话:
要快速有实感地了解一个产品,最好的方法还是直接用。
虽然之前一直有关注bytebase,知道它大概在干什么、属于哪个范围的产品,但明确知道bytebase在干什么还是这次亲自上手用后。
此次对其issue review, alter schema, change data, sql editor, sql advisor, RBAC功能都有了实感,但对backup & restore,回滚,批量等功能还没有仔细体会,之后应该会用其saas产品来进一步了解。
notion image
 
💡
in-a-nutshell
  • aha moment:1)deploy的方便性;2)真正把用户当人去尊重的UIUX风格和文档清晰度;3)SQL workflow的整体流畅度
  • 犹豫点:自己部署试用过程中发现了一些产品bug和安全性担忧,之后应该会通过探索saas产品来看看这些问题是否一直存在。如果自己的顾虑能打消的话,会把bytebase作为个人常用工具。如果个人使用一段时间后非常流畅的话,会把Bytebase推荐给团队的SRE/DBA/TechLead。
SQLChat尝鲜记工作繁重,我们是否还应花时间阅读文学?