是的 broker load的方式
我们怎么看数据是都分布的合理呢，这个判断标准是什么呢
DISTRIBUTED BY HASH( l_orderkey ) BUCKETS 48 根据分布键
select l_orderkey,count(*) from lineitem group by l_orderkey order by 2 desc limit 50;
MySQL [tcph10tmp]> select count(1) from lineitem;
±------------+
| count(1) |
±------------+
| 51199950286 |
±------------+
1 row in set (1 min 4.83 sec)
我现在count 还是慢 现在还没有完全导入完成呢，我现在在执行select l_orderkey,count(*) from lineitem group by l_orderkey order by 2 desc limit 50;，看看什么情况
MySQL [tcph10tmp]> select l_orderkey,count() from lineitem group by l_orderkey order by 2 desc limit 50;
±-----------±------------+
| l_orderkey | count() |
±-----------±------------+
| NULL | 46904984552 |
| 1345636898 | 14 |
| 944357792 | 14 |
| 1511810471 | 14 |
| 125824292 | 14 |
| 287069280 | 14 |
| 1902992324 | 14 |
| 1745455492 | 14 |
| 1910429350 | 14 |
| 233651809 | 14 |
| 673284514 | 14 |
| 1193814086 | 14 |
| 1968488804 | 14 |
| 1131159168 | 14 |
| 1776574114 | 14 |
| 1206609600 | 14 |
| 1379747171 | 14 |
| 108635363 | 14 |
| 1204960965 | 14 |
| 2093444805 | 14 |
| 846092358 | 14 |
| 1756731746 | 14 |
| 1374039939 | 14 |
| 1112054019 | 14 |
| 262918050 | 14 |
| 25623621 | 14 |
| 180110054 | 14 |
| 393122181 | 14 |
| 2044928417 | 14 |
| 1287582535 | 14 |
| 2096369223 | 14 |
| 1360970052 | 14 |
| 630086883 | 14 |
| 2084742528 | 14 |
| 496438787 | 14 |
| 348854210 | 14 |
| 1570258400 | 14 |
| 280433312 | 14 |
| 1246097378 | 14 |
| 106387719 | 14 |
| 1903591333 | 14 |
| 1922962370 | 14 |
| 129803427 | 14 |
| 24486048 | 14 |
| 1089363301 | 14 |
| 56552423 | 14 |
| 1781086722 | 14 |
| 1584127648 | 14 |
| 1163945442 | 14 |
| 583365825 | 14 |
±-----------±------------+
50 rows in set (4 min 51.66 sec) 还是有很多null值，生产数据太消耗时间了，有其他的办法处理吗
还是那么多NULL，是生成的数据有问题，还是导入有问题，还是sed没执行上，后面|没去掉导致。
明细模型不支持update语句的，那么多值都是NULL，就算支持update也不好改，还是从导入解决才行。
400多亿都是NULL，这个测试没法跑下去。
我怀疑是不是有很多文件 sed那步没执行成功 就是数据最后|没去掉，就跟以前说的那个问题就一致了。
数据的问题有点头疼，只能是从新处理一下数据吗
是的，导入时都有问题了，刚好出问题就是最重要的分布键，如果是其他字段就还好。
如果选择其他的分布键有什么影响呢
选一个分布均匀的，然后有些SQL就用不了colocate join，全部走shuffle join
目前有用starrocks 跑10t 数据做-tcph基准测试吗
没有，后续有同学会把做10T的tcp-h，在官网上公布。
可以这样，你先导入几十个亿（确保数据是正确的），通过insert into xxx select * from table where 分区;
这样会快很多吧，数据起码是分布均匀，虽然重复值较多。
那几个分布键，一定要正确，这么多NULL测试不了。
嗯嗯好的，我现在在处理，处理完了在测试吧，到时候在麻烦您吧
好的 我时刻准备着
好的，感谢您的大力支持