为什么使用pycassa导出的Cassandra表返回的行数比通过CQL SELECT导出的少

我的任务是将Cassandra安装的数百万条记录从2.1版升级到3.11版（最新版本）。使问题复杂化的是，misencoded UTF8值存在一些内部格式问题

我通过将每个验证器更改为字节类型修复了UTF8问题，因此至少现在所有记录都可见（即不触发格式错误）。但我在将数据导出到CSV文件时遇到问题：

CQL SELECT命令，无论是在cqlsh中还是在通过DataStax驱动程序的脚本中，都是显而易见的解决方案。但是SELECT语句的默认限制是10000，我已经读到，将其更改为更大的值将导致各种错误，事实上，文档建议它不能设置为超过2000000。这就是排除的CQL方法

dsbulk实用程序将是下一个选择。但当我在测试表上尝试这个方法时，它以一种我无法理解的奇怪编码生成了输出字节字符串

所以我不得不求助于C计划，即使用Pycasa驱动程序导出数据。然而，这带来了另一个问题——它读取的记录数大约是CQL看到的记录数的一半！我的问题是为什么

这是我的python2 pycassa脚本（其输出与SQL SELECT相同，以便比较）：

这将产生大约700行，但当我在cqlsh中运行“SELECT COUNT（*）FROM complete”时，大约有1300行。我使用WinMerge检查了输出，丢失的记录是一个具有较大键值的块。因此，似乎出于某种原因，皮卡萨/节俭司机错过了最近的记录

有什么想法吗

-=-=-=-=-=-=-=-=-=-=-=

针对Alex Ott的第一条评论：

非常感谢您的及时回复

表架构为：

CREATE TABLE app2_uat.complete (
    key blob,
    column1 blob,
    value blob,
    PRIMARY KEY (key, column1)
) WITH COMPACT STORAGE
    AND CLUSTERING ORDER BY (column1 ASC)
    AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
    AND comment = ''
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'}
    AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND dclocal_read_repair_chance = 0.0
    AND default_time_to_live = 0
    AND gc_grace_seconds = 864000
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = 'NONE';

我尝试的dsbulk命令是：

dsbulk unload -u cassandra -p cassandra -h '["172.31.44.160"]'  -query "SELECT * from app2_uat.complete;"

我对这种方法的第一个问题是，它使用了坏的旧CQL SELECT和它的限制，我不能任意增加或消除-选择是出于这个原因

我的第二个问题是它以乱七八糟的格式输出blob，例如：

key,column1,value
MTU4,Yy0xNTgyZmYxYzkwMGYxNzQ0ZmFhOWVlOGRkZWQxOTM2OGI3MA==,IA==
MTU4,Yy0xNThhMmYyNDliMWJhOWI0YWVmOTc4OTM5ZjE0NzZmNGFjNQ==,IA==
MTU4,Yy0xNThjODJmZGYyZDIyMjk0YWFjODBhNjQ5Y2NiZGZhMDk5Mg==,IA==
OTQ=,Yy05NDRhYjYyM2YxODMzNDQwM2M5MmNmOTc0ZWJkNjRiZmY0,IA==
MTE3,Yy0xMTc3OTEzNWE0OTNlYjU0YzU1YTNjMTdhNzc5YTk2ZTM1ZQ==,
MTE3,Yy0xMTdiYzQ2ZmNhNTc1ZmQ0MDk3YmQ0NTYxODdhMzQxYTQ1Ng==,
NTg=,Yy01ODZmZmVhNTczYjRjNzQwNGJiYjFjNzM2MzMxNTM5Mzhj,
NTg=,Yy01ODhjMmI3ZWJjNWYwNjQ1OGQ5NGMwNDljOWI1OGRiYjk0,

我无法将其与CQL（和我的pycassa脚本）生成的十六进制输出联系起来：

key      | column1                                                                      | value
----------+------------------------------------------------------------------------------+-------
     0x36 |       0x632d3632373566376561633136323131653338343730303230303839646531306266 |  0x20
     0x36 |       0x632d3633383563356632633136323131653339636363303230303839646531306266 |  0x20
     0x36 |       0x632d3634363737643663633136323131653362346135303230303839646531306266 |  0x20
     0x36 |       0x632d3635353933303361633136323131653361326137303230303839646531306266 |  0x20
     0x36 |       0x632d3636326264653836633136323131653362323363303230303839646531306266 |  0x20
     0x36 |       0x632d3637306662343934633136323131653361616439303230303839646531306266 |  0x20
     0x36 |       0x632d3637663931376230633136323131653361623963303230303839646531306266 |  0x20
     0x36 |       0x632d3638636164373061633136323131653339396134303230303839646531306266 |  0x20

---

你能想出pycassa为什么不输出在CQL中可见的记录块的任何原因吗？

DSBulk必须工作得很好-你能把你正在使用的表和DSBulk命令的模式放进去吗？谢谢Alex，我已经添加了你要求的详细信息。DSBulk将二进制数据编码为base64，以使它们在CSV文件中安全…好的，考虑到某些字符串末尾的“=”s，我认为它可能是base64。这是可以管理的。但是选择限制问题呢？如果dsulk在10000条记录后停止（或选择任何限制，低于2000000条），它将毫无用处。我要把整张桌子都取出来！它应该卸载所有数据-如果不是，那么您应该在日志中看到错误。。。DSBulk确实针对数据加载/卸载进行了大量优化—它将比自编代码好得多—在不重载节点的情况下编写有效的数据卸载并非易事，尤其是对于2.1。。。另外，如果卸载期间DSBulk超时，您可以尝试指定

--schema.splits

，以将令牌范围分成更小的部分

key      | column1                                                                      | value
----------+------------------------------------------------------------------------------+-------
     0x36 |       0x632d3632373566376561633136323131653338343730303230303839646531306266 |  0x20
     0x36 |       0x632d3633383563356632633136323131653339636363303230303839646531306266 |  0x20
     0x36 |       0x632d3634363737643663633136323131653362346135303230303839646531306266 |  0x20
     0x36 |       0x632d3635353933303361633136323131653361326137303230303839646531306266 |  0x20
     0x36 |       0x632d3636326264653836633136323131653362323363303230303839646531306266 |  0x20
     0x36 |       0x632d3637306662343934633136323131653361616439303230303839646531306266 |  0x20
     0x36 |       0x632d3637663931376230633136323131653361623963303230303839646531306266 |  0x20
     0x36 |       0x632d3638636164373061633136323131653339396134303230303839646531306266 |  0x20